AccountManager, или как Google врет в документации
Первый пост в канале был посвящен адовым проблемам шифрования в Android. Но Android SDK не перестает удивлять. На этот раз AccountManager — системное хранилище аккаунтов. В VK внедряли его, чтобы сохранять данные пользователя и восстанавливать в случае, если приложение-чистильщик затрет все данные приложения ==> мы сохраним авторизацию ==> сэкономим деньги на смс.
Реализовать не сложно: вызвать несколько методов по работе с аккаунтом и реализовать Bound Service для взаимодействия с системой. Но нет, Google оставил подляну.
1) В документации четко сказано, что методы можно вызывать на главном потоке. Но нельзя! Вызов методов на главном потоке приводит к ANR. Получали тысячи событий в Firebase. Пруфы в комментах.
2) В документации нигде не написано, как обработать нажатие на кнопку удаление аккаунта из системы. Нигде. И мало того, есть похожие API в AccountManager, которые могли бы подойти: accountChangeListener, метод из Bound сервиса. Пришлось самому дебажить. Дам код в комментах.
3) Гугл говорит, что хранить данные там небезопасно. Окей, шифруем. Но при очистке данных приложения затираются и ключи с alias’ами в Keystore, итого надежного хранения ключа нет. Использовали другие алгоритмы по другим алгоритмам.
4) Гугл утаивает, что аккаунт в системе можно не показывать. Для этого нужно оставить пустым мета-информацию для Bound сервиса.
Google не перестает удивлять.
Первый пост в канале был посвящен адовым проблемам шифрования в Android. Но Android SDK не перестает удивлять. На этот раз AccountManager — системное хранилище аккаунтов. В VK внедряли его, чтобы сохранять данные пользователя и восстанавливать в случае, если приложение-чистильщик затрет все данные приложения ==> мы сохраним авторизацию ==> сэкономим деньги на смс.
Реализовать не сложно: вызвать несколько методов по работе с аккаунтом и реализовать Bound Service для взаимодействия с системой. Но нет, Google оставил подляну.
1) В документации четко сказано, что методы можно вызывать на главном потоке. Но нельзя! Вызов методов на главном потоке приводит к ANR. Получали тысячи событий в Firebase. Пруфы в комментах.
2) В документации нигде не написано, как обработать нажатие на кнопку удаление аккаунта из системы. Нигде. И мало того, есть похожие API в AccountManager, которые могли бы подойти: accountChangeListener, метод из Bound сервиса. Пришлось самому дебажить. Дам код в комментах.
3) Гугл говорит, что хранить данные там небезопасно. Окей, шифруем. Но при очистке данных приложения затираются и ключи с alias’ами в Keystore, итого надежного хранения ключа нет. Использовали другие алгоритмы по другим алгоритмам.
4) Гугл утаивает, что аккаунт в системе можно не показывать. Для этого нужно оставить пустым мета-информацию для Bound сервиса.
Google не перестает удивлять.
Отзыв на книгу Gang of Four Design Patterns
Последние годы я читаю фундаментальные книги по программированию. Убежден, что многие мои профессиональные навыки и заслуги складывались из них. Одна из первых таких книг была “паттерны объектно-ориентированного программирования”.
Я часто не понимал, почему Java библиотека написана так, как написана. Не понимал код старших программистов. Как разбивать мой код на сущности и классы. И самое главное — как комбинировать мои классы эффективно. Эффективно — значит решать мою задачу и не перепроектировать классы при внесении изменений:
- не зависеть от конкретных реализаций;
- не зависеть от аппартной или программной платформы;
- уменьшать связанность;
- иметь удобство при изменении классов.
Наибольшее впечатление на меня произвела глава про структурные паттерны: адаптер, декоратор, прокси и мост. Она показала мне, как из классов и объектов выстраиваются более крупные структуры. Например, без этой книги я бы в жизни не спроектировал такой API из java библиотеки:
Самое интересное, что эти паттерны невероятно схожи. Например, взгляните на паттерны Декоратор и Прокси. По большому счету с точки зрения использования наследования и композиции в них вообще нет разницы! Скорее всего, это объясняется тем, что все структурные паттерны основаны на небольшом множестве языковых механизмов структурирования кода и объектов (наследование / композиция).
И я в тот же день внедрил пару паттернов в код для проектирования взаимодействия с AccountManager, о котором писал выше:
Последние годы я читаю фундаментальные книги по программированию. Убежден, что многие мои профессиональные навыки и заслуги складывались из них. Одна из первых таких книг была “паттерны объектно-ориентированного программирования”.
Я часто не понимал, почему Java библиотека написана так, как написана. Не понимал код старших программистов. Как разбивать мой код на сущности и классы. И самое главное — как комбинировать мои классы эффективно. Эффективно — значит решать мою задачу и не перепроектировать классы при внесении изменений:
- не зависеть от конкретных реализаций;
- не зависеть от аппартной или программной платформы;
- уменьшать связанность;
- иметь удобство при изменении классов.
Наибольшее впечатление на меня произвела глава про структурные паттерны: адаптер, декоратор, прокси и мост. Она показала мне, как из классов и объектов выстраиваются более крупные структуры. Например, без этой книги я бы в жизни не спроектировал такой API из java библиотеки:
new DataInputStream(new BufferedInputStream(new FileInputStream("example.txt")));
Самое интересное, что эти паттерны невероятно схожи. Например, взгляните на паттерны Декоратор и Прокси. По большому счету с точки зрения использования наследования и композиции в них вообще нет разницы! Скорее всего, это объясняется тем, что все структурные паттерны основаны на небольшом множестве языковых механизмов структурирования кода и объектов (наследование / композиция).
И я в тот же день внедрил пару паттернов в код для проектирования взаимодействия с AccountManager, о котором писал выше:
val repository = AMRepositoryProxy(
delegate = AMEncryptionDecorator(
delegate = AMRepositoryImpl(
accountManager = AccountManager.get(appContext)
)
),
isEnabled = { isEnabledInternal(appContext) }
)
Из минусов книги: код на C++ и надуманные примеры. Поэтому для конспектирования я использовал https://refactoring.guru/ru/design-patterns (в РФ вход только под vpn). Отличный сайт с описанием всех паттернов.
Но помните, что паттерны не должны применяться без разбора. Нередко за гибкость и простоту изменения приходится платить усложнением дизайна или ухудшением производительности. Как вам пример вывода Hello World со скриншота?)
Но помните, что паттерны не должны применяться без разбора. Нередко за гибкость и простоту изменения приходится платить усложнением дизайна или ухудшением производительности. Как вам пример вывода Hello World со скриншота?)
Культ оверинженеринга
Выхожу из творческого отпуска.
Я часто сталкиваюсь с заумными техническими решениями от учеников и коллег. Будто сложное решение = качественное. Это не так.
Вот пример. В коде нельзя было использовать Rx/Flow, но без реактивщины — никуда. К началу нового года коллеги изобрели CustomRxJava4 на тайпалиасах (первые рабочие дни были тяжелыми, понимаю). И тут я придумал простую эвристику: не можешь разобраться в модуле за 30 минут — рефактори. В этом коде было достаточно заменить тайпалиасы на прямое использование нашего Observer'а и Interactor'а.
Не забывайте про принципы Бритвы Оккама и Open/Closed: хорош не тот модуль, в который нечего добавить, а тот, у которого нечего отнять. Если можно быстро что-то переработать или удалить без потери в качестве и бизнес-логике — сделайте это. Позаботьтесь о проекте.
Соблюдение этих принципов снижает когнитивную нагрузку на программистов --> увеличивает метрику поддерживаемости --> уменьшает время внесения изменений --> увеличивает TTM.
Упрощайте.
Выхожу из творческого отпуска.
Я часто сталкиваюсь с заумными техническими решениями от учеников и коллег. Будто сложное решение = качественное. Это не так.
Вот пример. В коде нельзя было использовать Rx/Flow, но без реактивщины — никуда. К началу нового года коллеги изобрели CustomRxJava4 на тайпалиасах (первые рабочие дни были тяжелыми, понимаю). И тут я придумал простую эвристику: не можешь разобраться в модуле за 30 минут — рефактори. В этом коде было достаточно заменить тайпалиасы на прямое использование нашего Observer'а и Interactor'а.
Не забывайте про принципы Бритвы Оккама и Open/Closed: хорош не тот модуль, в который нечего добавить, а тот, у которого нечего отнять. Если можно быстро что-то переработать или удалить без потери в качестве и бизнес-логике — сделайте это. Позаботьтесь о проекте.
Соблюдение этих принципов снижает когнитивную нагрузку на программистов --> увеличивает метрику поддерживаемости --> уменьшает время внесения изменений --> увеличивает TTM.
Упрощайте.
Как я оффер на 600к получил
Хожу на собеседования каждый месяц. Держу руку на пульсе рынка, ищу интересные предложения. Именно такое попалось недавно — оффер на 600к на руки обычным разработчиком в продуктовую команду. Не беттинг или казино. Обычный собес. Поговорили за котлин и андроид, писал код, отвечал на поведенческие вопросы.
Зачем пишу этот пост? Побудить вас ходить на собесы. Во-первых, прохождение собеседований — отдельный навык, который нужно тренировать. Хорошо выполнять свою работу ≠ хорошо проходить собеседования. Если вас ценят на текущей работе, то не факт, что вы быстро смените работу в случае необходимости.
Во-вторых, вы наблюдаете за рынком и в курсе изменений. Уверены, что получаете в рынке? Статистика зарплат хабра манипулирует цифрами и выгодна работодателям. Зачем получать среднюю зарплату, если можно получать по потолку рынка? Попросите ради интереса x2 от вашей зарплаты. Можете приятно удивиться согласием. По моей выборке с 8 офферов нормальное предложение для сеньоров — 400к.
Жалею только о том, что не записал собес — сделал бы отличный контент для бусти🧐
Хожу на собеседования каждый месяц. Держу руку на пульсе рынка, ищу интересные предложения. Именно такое попалось недавно — оффер на 600к на руки обычным разработчиком в продуктовую команду. Не беттинг или казино. Обычный собес. Поговорили за котлин и андроид, писал код, отвечал на поведенческие вопросы.
Зачем пишу этот пост? Побудить вас ходить на собесы. Во-первых, прохождение собеседований — отдельный навык, который нужно тренировать. Хорошо выполнять свою работу ≠ хорошо проходить собеседования. Если вас ценят на текущей работе, то не факт, что вы быстро смените работу в случае необходимости.
Во-вторых, вы наблюдаете за рынком и в курсе изменений. Уверены, что получаете в рынке? Статистика зарплат хабра манипулирует цифрами и выгодна работодателям. Зачем получать среднюю зарплату, если можно получать по потолку рынка? Попросите ради интереса x2 от вашей зарплаты. Можете приятно удивиться согласием. По моей выборке с 8 офферов нормальное предложение для сеньоров — 400к.
Жалею только о том, что не записал собес — сделал бы отличный контент для бусти
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Коллега нагло украл тему моего доклада на Mobius и сделал его еще круче. Андрей расскажет, как шифровать медиафайлы, голосовухи и сканы паспортов. Я буду экспертом на докладе.
23 мая смотрите в онлайне — https://mobiusconf.com/talks/20ec4af1d3684ba3888ec7e71b92ab8e/?referer=/persons/58bd6e1183cf480ba5e074133634ca33/
31 мая и 1 июня — офлайн в Москве. Подходите пообщаться на стендах и на афтепати.
23 мая смотрите в онлайне — https://mobiusconf.com/talks/20ec4af1d3684ba3888ec7e71b92ab8e/?referer=/persons/58bd6e1183cf480ba5e074133634ca33/
31 мая и 1 июня — офлайн в Москве. Подходите пообщаться на стендах и на афтепати.
Исследования IT зарплат
Недавно писал, что статистика зарплат хабра манипулирует цифрами, необъективна и выгодна работодателям. У Киры Кузьменко вышло исследование на 3000+ респондентов про динамику зарплат. Отдельно — по мобильной разработке.
Главные выводы:
— Рост зарплат — у 59% айтишников.
— Зарплаты чаще росли в РФ компаниях, а не иностранных.
— У опытных айтишников зарплаты растут чаще, чем у неопытных.
Последний вывод: повышение оклада (не индексация) — ключевой фактор роста зарплат в РФ, а в иностранных — смена компании. Правда, команда Киры не приводит, насколько повышается зарплата засчет каждого фактора. Обычно повышение оклада внутри компании — самый неэффективный способ увеличения уровня дохода.
У Киры есть аналитика по хантингу за 2022 и 2023 год. Там — реальные зарплаты мидлов и сеньоров. Смешно сравнивать с исследованием хабра. Правда за 2 года потолок вилок вырос не больше, чем на 5-10%. Выделяющийся пример выше — скорее, исключение.
Главный вопрос: когда ж там IT пузырь лопнет?)
Недавно писал, что статистика зарплат хабра манипулирует цифрами, необъективна и выгодна работодателям. У Киры Кузьменко вышло исследование на 3000+ респондентов про динамику зарплат. Отдельно — по мобильной разработке.
Главные выводы:
— Рост зарплат — у 59% айтишников.
— Зарплаты чаще росли в РФ компаниях, а не иностранных.
— У опытных айтишников зарплаты растут чаще, чем у неопытных.
Последний вывод: повышение оклада (не индексация) — ключевой фактор роста зарплат в РФ, а в иностранных — смена компании. Правда, команда Киры не приводит, насколько повышается зарплата засчет каждого фактора. Обычно повышение оклада внутри компании — самый неэффективный способ увеличения уровня дохода.
У Киры есть аналитика по хантингу за 2022 и 2023 год. Там — реальные зарплаты мидлов и сеньоров. Смешно сравнивать с исследованием хабра. Правда за 2 года потолок вилок вырос не больше, чем на 5-10%. Выделяющийся пример выше — скорее, исключение.
Главный вопрос: когда ж там IT пузырь лопнет?)
Ты ненастоящий программист
Проблема, с которой я столкнулся острее всего — снобы сеньоры. Слышали что-то в духе:
- “Ты не знаешь как устроен кэш процессор? Да какой из тебя программист…”
- “Ты не коммитил в опенсорс? Мдааа…”
- “Ты не работал в FAANG, не писал на ассемблере, не читал эту супер-ультра-важную книгу — да какой из тебя программист”.
Новички не идут в IT, а разработчики приобретают известные синдромы именно из-за такой гейткиперской позиции и навязывания всем вокруг, мол IT — это творчество, нужно работать за идею и что обязательно нужно прочитать эту книгу, ведь это база. Это херня, и вот почему.
IT — это не творчество. Нынешние бигтехи — цифровизированные заводы 21 века. У нас есть ограниченный набор языков, инструментов, архитектур и технологии. Правила, стат анализ, коммит хуки, тесты, ревью, QA, фича-тогглы, CI. Это конвейер по производству фичей и продуктов. Ваш код перепишут с выходом новой технологии. Ваш код удалят, если фича не приносит денег. Ваш код не принадлежит вам. Хороший код — тот, что не отличается от кода в соседнем модуле. Где тут творчество?
”Нужно знать Х, ведь это база“. Мне постоянно твердили: читай эту книгу — это основа. Но не объяснили, как это конвертируется в объективные метрики моей жизни (деньги/время). По достижении определенного уровня сеньорства новые знания перестают увеличивать ваш доход, но увеличивают ЧСВ. Новая статья, курс, технология, подкапотная работа композа не влияют на размер зарплаты в конце месяца. Вот мои критерии изучения новой технологии/языка:
- это больше двух раз спросили на собеседовании. Так я изучил корутины и композ;
- я натыкался на это в работе больше двух раз. Так я погрузился в фичамодульную и чистую архитектуру, а потом выкатил фреймворк по систем дизайн интервью;
- это больше двух раз спросили мои ученики — можно изучить что-то и продавать эти знания. Так я пошел на подлодку по оптимизациям UI и погрузился в CI.
Я перестал изучать что-то, потому что дядя в интернете сказал, что это надо бы знать. И да, я знаю про закон протекающих абстракций. На проекте может что-то сломаться, а у тебя нет компетенции починить это. Когда что-то пойдет не так, скорее всего этим будете заниматься не вы. А даже если вы — быстро изучите и доберете знаний.
Айтишный инфомусор
Сколько статей на прочтение в ваших закладках? И сколько из них вы прочитали? С каждым днем их становится больше, выходит новый курс, новый патчноут вашего языка, новая мультиплатформ технология. Как же я не буду это изучать? Я должен быть инженером, а не кодером своей технологии. Я провел эксперимент — год изучал новое только по вышеуказанным критериям. И ничего не случилось: меня не уволили, зарплату поднимали, дали повышенную оценку на Performance Review!(Спойлер: не рекомендуется применять джунам и мидлам)
Сюда же накладывается неосознанная амбициозность: брать безразборно больше задач и перерабатывать. Стремиться стать лучшими там, где это никому не нужно. Привет выгорание 👋
Будьте умнее. Пользуйтесь критериями выше для изучения нового. Для ускоренной прокачки в зарплатный потолок идите к человеку, который столько зарабатывает и попросите довести вас до такого же уровня.
Проблема, с которой я столкнулся острее всего — снобы сеньоры. Слышали что-то в духе:
- “Ты не знаешь как устроен кэш процессор? Да какой из тебя программист…”
- “Ты не коммитил в опенсорс? Мдааа…”
- “Ты не работал в FAANG, не писал на ассемблере, не читал эту супер-ультра-важную книгу — да какой из тебя программист”.
Новички не идут в IT, а разработчики приобретают известные синдромы именно из-за такой гейткиперской позиции и навязывания всем вокруг, мол IT — это творчество, нужно работать за идею и что обязательно нужно прочитать эту книгу, ведь это база. Это херня, и вот почему.
IT — это не творчество. Нынешние бигтехи — цифровизированные заводы 21 века. У нас есть ограниченный набор языков, инструментов, архитектур и технологии. Правила, стат анализ, коммит хуки, тесты, ревью, QA, фича-тогглы, CI. Это конвейер по производству фичей и продуктов. Ваш код перепишут с выходом новой технологии. Ваш код удалят, если фича не приносит денег. Ваш код не принадлежит вам. Хороший код — тот, что не отличается от кода в соседнем модуле. Где тут творчество?
”Нужно знать Х, ведь это база“. Мне постоянно твердили: читай эту книгу — это основа. Но не объяснили, как это конвертируется в объективные метрики моей жизни (деньги/время). По достижении определенного уровня сеньорства новые знания перестают увеличивать ваш доход, но увеличивают ЧСВ. Новая статья, курс, технология, подкапотная работа композа не влияют на размер зарплаты в конце месяца. Вот мои критерии изучения новой технологии/языка:
- это больше двух раз спросили на собеседовании. Так я изучил корутины и композ;
- я натыкался на это в работе больше двух раз. Так я погрузился в фичамодульную и чистую архитектуру, а потом выкатил фреймворк по систем дизайн интервью;
- это больше двух раз спросили мои ученики — можно изучить что-то и продавать эти знания. Так я пошел на подлодку по оптимизациям UI и погрузился в CI.
Я перестал изучать что-то, потому что дядя в интернете сказал, что это надо бы знать. И да, я знаю про закон протекающих абстракций. На проекте может что-то сломаться, а у тебя нет компетенции починить это. Когда что-то пойдет не так, скорее всего этим будете заниматься не вы. А даже если вы — быстро изучите и доберете знаний.
Айтишный инфомусор
Сколько статей на прочтение в ваших закладках? И сколько из них вы прочитали? С каждым днем их становится больше, выходит новый курс, новый патчноут вашего языка, новая мультиплатформ технология. Как же я не буду это изучать? Я должен быть инженером, а не кодером своей технологии. Я провел эксперимент — год изучал новое только по вышеуказанным критериям. И ничего не случилось: меня не уволили, зарплату поднимали, дали повышенную оценку на Performance Review!
Сюда же накладывается неосознанная амбициозность: брать безразборно больше задач и перерабатывать. Стремиться стать лучшими там, где это никому не нужно. Привет выгорание 👋
Будьте умнее. Пользуйтесь критериями выше для изучения нового. Для ускоренной прокачки в зарплатный потолок идите к человеку, который столько зарабатывает и попросите довести вас до такого же уровня.
Telegram
Engineering notes | Артур Илькаев
Работа за идею
Многие компании любят распевать о том, что нужно работать за идею, а не за деньги. Но давайте будем честны: все коммерческие организации работают ради извлечения прибыли. И чтобы делать это еще лучше, они продвигают концепцию того, как этот…
Многие компании любят распевать о том, что нужно работать за идею, а не за деньги. Но давайте будем честны: все коммерческие организации работают ради извлечения прибыли. И чтобы делать это еще лучше, они продвигают концепцию того, как этот…
Съездил на мобиус в роли эксперта. Первый раз в офлайне. Что я понял:
Доклады скучные. Серьезно, умный спикер 40 минут монотонным убоюкивающим голосом втирает такие технические нюансы, которые ты никогда не будешь использовать. Однако несколько докладов мне приглянулись: ByteWeaver для патчинга байт-кода, Android-приложение без Firebase (и отдельно про Tracer). Из доклада про OzonID будем брать приемы на вооружение в VK ID. А еще про шифрование, где можно послушать мой приятный голос.
На стендах весело. Покодил на Swift, верстал вслепую и побегал на дорожке.
HR'ы окружили и пытались переманить. Яндексоидам привет.
Наконец увидился с коллегами. Вижу ребят раз в полгода.
Занетворкался и выпил на афтепати. Самая интересная часть конференции. Есть ощущение, что все активности до этого — смазка для афтепати.
Если компания оплатит вам билет и перелет — приезжайте. Иначе того не стоит.
Доклады скучные. Серьезно, умный спикер 40 минут монотонным убоюкивающим голосом втирает такие технические нюансы, которые ты никогда не будешь использовать. Однако несколько докладов мне приглянулись: ByteWeaver для патчинга байт-кода, Android-приложение без Firebase (и отдельно про Tracer). Из доклада про OzonID будем брать приемы на вооружение в VK ID. А еще про шифрование, где можно послушать мой приятный голос.
На стендах весело. Покодил на Swift, верстал вслепую и побегал на дорожке.
HR'ы окружили и пытались переманить. Яндексоидам привет.
Наконец увидился с коллегами. Вижу ребят раз в полгода.
Занетворкался и выпил на афтепати. Самая интересная часть конференции. Есть ощущение, что все активности до этого — смазка для афтепати.
Если компания оплатит вам билет и перелет — приезжайте. Иначе того не стоит.