Кстати, первую таску с эриксом я сделал ну так себе. Лид посмотрел, покачал головой и подсказал, как лучше переделать, чтоб сайдэффекты бизнес-логики в doOnError не надавали мне по башке.
А через год я уже захреначил офигительные поллинги на эриксе, которыми пользуемся до сих пор. Rx-логика там ппц какая сложная, и ничего подобного я в интернете не нашёл, пришлось велосипедить самому, и я блестяще справился.
Однажды переведём их на корутины, вот будет веселье!
Когда-нибудь я настрочу про эти поллинги на хабр статью, словлю кучу хейта, и моя бедная карма упадёт с -8 до -38, и улечу я навечно в ридонли. Но карме не стать помехой годному контенту!
А через год я уже захреначил офигительные поллинги на эриксе, которыми пользуемся до сих пор. Rx-логика там ппц какая сложная, и ничего подобного я в интернете не нашёл, пришлось велосипедить самому, и я блестяще справился.
Когда-нибудь я настрочу про эти поллинги на хабр статью, словлю кучу хейта, и моя бедная карма упадёт с -8 до -38, и улечу я навечно в ридонли. Но карме не стать помехой годному контенту!
🔥6👏5❤2😁2
🚀 Скидка 15% на менторство новым ученикам на https://androidmentor.ru/ 🚀
Если вы ощущаете, что слишком закапываетесь, процесс обучения разработке идёт слишком долго или нервно, или вы боитесь, или не понимаете, с чего начать, и как дойти до конца – я могу помочь.
Сам таким был, сам таких учил, и хорошо знаю, как поставить вас на правильные рельсы и поддать жару.
🔥 До конца 2024 года я даю всем новым ученикам скидку 15% на все свои тарифы менторства.🔥
✨ Что вас ждёт:
1️⃣ Начнём с собеседования и составим индивидуальную программу обучения
2️⃣ Много практики: я даю вам задания, вы делаете пулл-реквесты в github, я делаю код-ревью и комментирую
3️⃣ Я регулярно отвечаю на вопросы в чате, делюсь полезными ссылками и лайфхаками
✅ Результат:
Вы максимально быстро и безболезненно достигаете своей цели
Подробнее о менторстве на моём сайте.
Записаться на менторство со скидкой можно сейчас, а начать в следующем году.
Если вы готовы начать Новый 2025 Год продуктивно вместе со мной – приходите в личку.
#android #менторство
Если вы ощущаете, что слишком закапываетесь, процесс обучения разработке идёт слишком долго или нервно, или вы боитесь, или не понимаете, с чего начать, и как дойти до конца – я могу помочь.
Сам таким был, сам таких учил, и хорошо знаю, как поставить вас на правильные рельсы и поддать жару.
🔥 До конца 2024 года я даю всем новым ученикам скидку 15% на все свои тарифы менторства.🔥
✨ Что вас ждёт:
1️⃣ Начнём с собеседования и составим индивидуальную программу обучения
2️⃣ Много практики: я даю вам задания, вы делаете пулл-реквесты в github, я делаю код-ревью и комментирую
3️⃣ Я регулярно отвечаю на вопросы в чате, делюсь полезными ссылками и лайфхаками
✅ Результат:
Вы максимально быстро и безболезненно достигаете своей цели
Подробнее о менторстве на моём сайте.
Записаться на менторство со скидкой можно сейчас, а начать в следующем году.
Если вы готовы начать Новый 2025 Год продуктивно вместе со мной – приходите в личку.
#android #менторство
👍6🔥3❤2
Обновил для вас пост-навигацию по каналу.
Обо мне:
– Моя история. Часть 1
– Моя история. Часть 2
Обучение начинающих:
– С какими запросами работаю на консультациях
– Подробно о помесячном менторстве
Отзывы учеников:
– Отзыв на менторство 1
– Отзыв на менторство 2
– Отзыв на менторство 3
– Отзыв на консультацию 1
– Отзыв на консультацию 2
Android-разработка для начинающих:
– С чего начать андроид-разработку
– 3 лучших книги для начинающего андроид-разработчика
– 8 удобных хоткеев в Android Studio
– Подкаст о джунах, стажировках и начинаюших разработчиках
– Как выглядит работа android-разработчика в продуктовой команде
Поиск работы:
– Как устроиться на работу
– Как писать тестовое задание / пет-проект в резюме. Часть 1
– Как писать тестовое задание / пет-проект в резюме. Часть 2
– Поиск первой работы: Часть 1: подготовка.
– Поиск первой работы: Часть 2: способы поиска.
– Ошибки в резюме
– Как вести профиль гитхаба
Лайфхаки разработки:
– Видео: как парсить API
– Видео: 5 простых лайфхаков для крутого кода
– Видео: 3 простых способа сделать разную вёрстку для смартфонов и планшетов
– Видео: делегаты адаптера
– Видео: Clean Architecture
– Видео: коллекции и экстеншны
– Аудио: Как правильно настраивать обфускацию
– Работа с системными разрешениями android
– Как делить ответственность между вьюмоделями и репозиториями?
– LiveData vs Flow: одноразовые ивенты и стейты
– Два простых способа сохранить данные при перезапуске приложения
– Виды кэширования
– RecyclerView: несколько ViewType
– Lateinit vs by lazy
– Тренируемся с корутинами
– Полезные ссылки
Стримы «Лайвкодинг: пишем приложение с нуля»:
– 1 часть
– 2 часть
– Репозиторий с кодом со стримов
Автотесты:
– Зачем их писать
– Юнит-тесты
– Интеграционные тесты
– UI-тесты
#android #навигация
Обо мне:
– Моя история. Часть 1
– Моя история. Часть 2
Обучение начинающих:
– С какими запросами работаю на консультациях
– Подробно о помесячном менторстве
Отзывы учеников:
– Отзыв на менторство 1
– Отзыв на менторство 2
– Отзыв на менторство 3
– Отзыв на консультацию 1
– Отзыв на консультацию 2
Android-разработка для начинающих:
– С чего начать андроид-разработку
– 3 лучших книги для начинающего андроид-разработчика
– 8 удобных хоткеев в Android Studio
– Подкаст о джунах, стажировках и начинаюших разработчиках
– Как выглядит работа android-разработчика в продуктовой команде
Поиск работы:
– Как устроиться на работу
– Как писать тестовое задание / пет-проект в резюме. Часть 1
– Как писать тестовое задание / пет-проект в резюме. Часть 2
– Поиск первой работы: Часть 1: подготовка.
– Поиск первой работы: Часть 2: способы поиска.
– Ошибки в резюме
– Как вести профиль гитхаба
Лайфхаки разработки:
– Видео: как парсить API
– Видео: 5 простых лайфхаков для крутого кода
– Видео: 3 простых способа сделать разную вёрстку для смартфонов и планшетов
– Видео: делегаты адаптера
– Видео: Clean Architecture
– Видео: коллекции и экстеншны
– Аудио: Как правильно настраивать обфускацию
– Работа с системными разрешениями android
– Как делить ответственность между вьюмоделями и репозиториями?
– LiveData vs Flow: одноразовые ивенты и стейты
– Два простых способа сохранить данные при перезапуске приложения
– Виды кэширования
– RecyclerView: несколько ViewType
– Lateinit vs by lazy
– Тренируемся с корутинами
– Полезные ссылки
Стримы «Лайвкодинг: пишем приложение с нуля»:
– 1 часть
– 2 часть
– Репозиторий с кодом со стримов
Автотесты:
– Зачем их писать
– Юнит-тесты
– Интеграционные тесты
– UI-тесты
#android #навигация
🔥7👍4⚡3❤2😍1
Next Level Dev pinned «Обновил для вас пост-навигацию по каналу. Обо мне: – Моя история. Часть 1 – Моя история. Часть 2 Обучение начинающих: – С какими запросами работаю на консультациях – Подробно о помесячном менторстве Отзывы учеников: – Отзыв на менторство 1 – Отзыв на менторство…»
Читал тут недавно книгу от создателя Nike Фила Найта.
Очень советую: Фил искренне и без приукрашиваний рассказывает о своих косяках, страхах и случайных стечениях обстоятельств в процессе создания своего бизнеса.
Одна из главных мыслей: ты точно будешь много косячить, если будешь делать что-то хоть мало-мальски важное для мира. И главное – вовремя понимать ошибки и хоть как-нибудь их исправлять, чтобы хоть немного лучше становилось, чем было.
Он почти всё делал неправильно, но тем не менее как-то выкарабкался =)
Тут, конечно, сразу приходит на ум ошибка выжившего, но у нас тут не бизнес-паблик, не хочу в это вдаваться)
И была там цитата персидского поэта: «Не спи хотя бы ночь одну. Тобой желаемое страстно само к тебе придет».
И чот меня пробила эта фраза прям до слёз, наложившись на мои мысли, витавшие в последнее время.
И я пошёл, посмотрел, во сколько закат и рассвет, и решил, что в ближайшую ночь от заката до рассвета не буду спать, а буду сидеть с большой тетрадью и ручкой и писать, что в голову придёт.
Интересное упражнение, советую. Сначала шло туговато, несколько часов вообще ничего не писал. А примерно за полчаса до рассвета я резко настрочил несколько инсайтов =)
А вы какие книги в последнее время читали?
Очень советую: Фил искренне и без приукрашиваний рассказывает о своих косяках, страхах и случайных стечениях обстоятельств в процессе создания своего бизнеса.
Одна из главных мыслей: ты точно будешь много косячить, если будешь делать что-то хоть мало-мальски важное для мира. И главное – вовремя понимать ошибки и хоть как-нибудь их исправлять, чтобы хоть немного лучше становилось, чем было.
Он почти всё делал неправильно, но тем не менее как-то выкарабкался =)
И была там цитата персидского поэта: «Не спи хотя бы ночь одну. Тобой желаемое страстно само к тебе придет».
И чот меня пробила эта фраза прям до слёз, наложившись на мои мысли, витавшие в последнее время.
И я пошёл, посмотрел, во сколько закат и рассвет, и решил, что в ближайшую ночь от заката до рассвета не буду спать, а буду сидеть с большой тетрадью и ручкой и писать, что в голову придёт.
Интересное упражнение, советую. Сначала шло туговато, несколько часов вообще ничего не писал. А примерно за полчаса до рассвета я резко настрочил несколько инсайтов =)
А вы какие книги в последнее время читали?
❤7👍1
Окей гугл chatGPT, как работать, если до отпуска неделя, а ты мысленно уже ешь тапасы и запиваешь гарначей в каком-нибудь баре Барселоны…
👏3😁1
Днём сидишь думаешь про Барселону, ночью сидишь прислушиваешься к звукам, похожим на одиночные салюты, и думаешь, а салюты ли это… Вайбы современной России)
А учитывая, что к нам в Жуковский «подарки» уже прилетали… Спокойной ночи, Илья, как говорится
А учитывая, что к нам в Жуковский «подарки» уже прилетали… Спокойной ночи, Илья, как говорится
❤🔥4👍1
Заметил тут интересную закономерность:
1) когда работника сокращают и выставляют "на мороз", при определённых навыках всегда можно выторговать компенсацию в размере зарплаты за 5 месяцев
2) средний срок "от нуля до иду на собесы" у моих менти составляет 5 месяцев
Я, канеш, ни на что не намекаю , но... 😏
1) когда работника сокращают и выставляют "на мороз", при определённых навыках всегда можно выторговать компенсацию в размере зарплаты за 5 месяцев
2) средний срок "от нуля до иду на собесы" у моих менти составляет 5 месяцев
Please open Telegram to view this post
VIEW IN TELEGRAM
androidmentor.ru
Главная
Главная cтраница
🤯4👀2😁1🤔1🌚1
Как охуенно быть разработчиком
Что сделает обычный человек, столкнувшись с вылетом на одном из диалогов побочного квеста в игре? Забьёт и пойдёт дальше, ну ломаный квест, да и хрен бы с ним.
А вот я нашёл и открыл файл диалога, который написан не то на C++, не то на C. Засучил рукава и пошёл смотреть, где там накриворучили разработчики.
Будет ещё эта чёртова машина мне указывать, какие квесты проходить, а какие нет, хрен ей!
Потом правда жена вернулась и мы пошли ужинать, так что продолжу в следующий раз.
И это – не случайность, это – парадигма мышления. Решить можно любую проблему, если достаточно хорошо изучить причину. Нет никакой магии, со всем можно разобраться. Ты устанавливаешь правила, а не подчиняешься магическим чёрным ящикам.
Делаем ставки, господа. Кто победит, я или Корсары 2? 🌚
Что сделает обычный человек, столкнувшись с вылетом на одном из диалогов побочного квеста в игре? Забьёт и пойдёт дальше, ну ломаный квест, да и хрен бы с ним.
А вот я нашёл и открыл файл диалога, который написан не то на C++, не то на C. Засучил рукава и пошёл смотреть, где там накриворучили разработчики.
Будет ещё эта чёртова машина мне указывать, какие квесты проходить, а какие нет, хрен ей!
Потом правда жена вернулась и мы пошли ужинать, так что продолжу в следующий раз.
Делаем ставки, господа. Кто победит, я или Корсары 2? 🌚
😁17🔥5💯3❤1
Короче. Сижу я тут, в Бильбао, остались последние несколько дней охеренного отпуска.
Отпуска, в котором я впервые увидел океан, и охренел, насколько он отличается от моря.
Отпуска, в котором я погрузился в колорит страны Басков, который я, как оказалось, органически не переношу (но после второго бокала чаколи ваще норм).
И я максимально старался оградить себя от всего, что бы связывало меня с работой в Белке или телеграм-каналом (второй работой) или менторством (третьей работой).
Зачем? Чтобы максимально отдохнуть. И, если честно, меня заебала эта мысль про максимизацию отдыха. Я хочу отдыхать так, как отдыхается, и тогда, когда мне этого хочется. А не 28 дней в году.
И меня изнутри точит одна мысль: я недостаточно реализовался. Я мало пользы приношу. Мало стараюсь. Слишком дохуя хочу и слишком недостаточно отдаю.
Хотя вроде я хреначу по максимуму, как могу. Но всё недостаточно эффективно что ли. Хотя положительная динамика налицо, но хочется сильно больше и быстрее.
Я пиздец как хочу сделать какую-то активность или продукт, которые:
а) отсортируют реально заряженных начинающих разрабов от тех, кого занесло сюда ветром популярности индустрии
б) докажут всем, что начинающий разработчик, прошедший менторство Ильи Попова – это не говнарь со скиллбокса, а охуенная боевая единица, готовая выстоять в схватке с реальным миром андроид-разработчика. И это реально тот самый «разраб с горящими глазами», который быстро станет приносить бизнесу пользу.
Даже если он на ваших супертрумегатехсобесах от волнения перепутал single с observable. Да блять, куда важнее то, что у него в голове чёткая картина того, в какую сторону ему копать при возникающих проблемах.
Когда я слышу от своих учеников «ну вот тут на собесе я ошибся несколько раз, но быстро додумал, где-то догадался, где-то докрутил, и собеседующий сказал, что в правильную сторону», и после этого им отказывают, я хочу собеседующих головой об стол побить, и влить им в горло калимочо.
Вать машу, один тот факт, что они на собесах (а это весьма волнительное мероприятие, ю ноу) смогли вырулить в правильную сторону после того, как запутались или что-то забыли, стоит пятидесяти вызубренных учебников.
Потому что PM’у и вашему лиду будет насрать на то, что там было в учебниках.
P.S.: буду продолжать думать, как нам с вами победить нынешнюю ситуацию с рынком найма, безо всяких идиотских накруток. Если вам это близко – оставайтесь со мной и помогайте, своей активностью, лайками и комментариями.
А, да. С Новым Годом, друзья!
Отпуска, в котором я впервые увидел океан, и охренел, насколько он отличается от моря.
Отпуска, в котором я погрузился в колорит страны Басков, который я, как оказалось, органически не переношу (но после второго бокала чаколи ваще норм).
И я максимально старался оградить себя от всего, что бы связывало меня с работой в Белке или телеграм-каналом (второй работой) или менторством (третьей работой).
Зачем? Чтобы максимально отдохнуть. И, если честно, меня заебала эта мысль про максимизацию отдыха. Я хочу отдыхать так, как отдыхается, и тогда, когда мне этого хочется. А не 28 дней в году.
И меня изнутри точит одна мысль: я недостаточно реализовался. Я мало пользы приношу. Мало стараюсь. Слишком дохуя хочу и слишком недостаточно отдаю.
Хотя вроде я хреначу по максимуму, как могу. Но всё недостаточно эффективно что ли. Хотя положительная динамика налицо, но хочется сильно больше и быстрее.
Я пиздец как хочу сделать какую-то активность или продукт, которые:
а) отсортируют реально заряженных начинающих разрабов от тех, кого занесло сюда ветром популярности индустрии
б) докажут всем, что начинающий разработчик, прошедший менторство Ильи Попова – это не говнарь со скиллбокса, а охуенная боевая единица, готовая выстоять в схватке с реальным миром андроид-разработчика. И это реально тот самый «разраб с горящими глазами», который быстро станет приносить бизнесу пользу.
Даже если он на ваших супертрумегатехсобесах от волнения перепутал single с observable. Да блять, куда важнее то, что у него в голове чёткая картина того, в какую сторону ему копать при возникающих проблемах.
Когда я слышу от своих учеников «ну вот тут на собесе я ошибся несколько раз, но быстро додумал, где-то догадался, где-то докрутил, и собеседующий сказал, что в правильную сторону», и после этого им отказывают, я хочу собеседующих головой об стол побить, и влить им в горло калимочо.
Вать машу, один тот факт, что они на собесах (а это весьма волнительное мероприятие, ю ноу) смогли вырулить в правильную сторону после того, как запутались или что-то забыли, стоит пятидесяти вызубренных учебников.
Потому что PM’у и вашему лиду будет насрать на то, что там было в учебниках.
А, да. С Новым Годом, друзья!
👍23❤6❤🔥5🍾4😍2
Простой способ определить, стоит ли использовать найденную технику
Сам знаю, как соблазнительно инфоцыгане зазывают:
"Я дам вам технику, используя которую раз в день, вы получите такие-то результаты"
И сам знаю, к каким дерьмовым результатам это может приводить.
Вплоть до психологической травмы, которая может испортить часть жизни.
Поэтому важно не бросаться исполнять все подряд "техники миллионеров" или "модели мышления", а задаться сперва важным вопросом:
а указал ли автор ограничения этой техники? Для кого она работает, для кого нет? Какие у неё принципы работы, как приспособить под себя?
Если всего этого нет, и автор говорит, что техника работает для всех в 100% случаев – это буллшит, бегите от этого дерьма подальше.
Пример: если чувствуете, что у вас загружена голова, мало энергии – значит в голове слишком много варится: идите и просто выгрузите на бумагу всё то, что в голове есть, и освободите голову и энергию!
Проблемка тут, например, в том, что если просто выгрузить всё из головы близкого к депрессивному состоянию человека – есть большой риск только усугубить состояние. Выгружать ему можно, но не хаотично, а в заранее правильно составленную табличку – тогда техника сработает.
И это лишь один подводный камень. А сколько их там ещё?
Поэтому когда в следующий раз услышите что-то в духе "дисциплина всегда ебёт мотивацию", или "мотивация всегда ебёт дисциплину", "просто возьми и сделай, тряпка", и в ограничениях этих спорных утверждений не пахнет даже простейшим Майерс-Бриггс – забейте на этот буллшит и даже не пытайтесь корить себя за то, что у вас оно не работает.
Сам знаю, как соблазнительно инфоцыгане зазывают:
"Я дам вам технику, используя которую раз в день, вы получите такие-то результаты"
И сам знаю, к каким дерьмовым результатам это может приводить.
Вплоть до психологической травмы, которая может испортить часть жизни.
Поэтому важно не бросаться исполнять все подряд "техники миллионеров" или "модели мышления", а задаться сперва важным вопросом:
а указал ли автор ограничения этой техники? Для кого она работает, для кого нет? Какие у неё принципы работы, как приспособить под себя?
Если всего этого нет, и автор говорит, что техника работает для всех в 100% случаев – это буллшит, бегите от этого дерьма подальше.
Пример: если чувствуете, что у вас загружена голова, мало энергии – значит в голове слишком много варится: идите и просто выгрузите на бумагу всё то, что в голове есть, и освободите голову и энергию!
Проблемка тут, например, в том, что если просто выгрузить всё из головы близкого к депрессивному состоянию человека – есть большой риск только усугубить состояние. Выгружать ему можно, но не хаотично, а в заранее правильно составленную табличку – тогда техника сработает.
И это лишь один подводный камень. А сколько их там ещё?
Поэтому когда в следующий раз услышите что-то в духе "дисциплина всегда ебёт мотивацию", или "мотивация всегда ебёт дисциплину", "просто возьми и сделай, тряпка", и в ограничениях этих спорных утверждений не пахнет даже простейшим Майерс-Бриггс – забейте на этот буллшит и даже не пытайтесь корить себя за то, что у вас оно не работает.
❤5👌5💯4🔥2
Полезные ссылки для подготовки к собеседованию на junior
Продолжаем полюбившуюся вам рубрику.
Пишите в комментариях, если есть, что улучшить, будем с вами вместе собирать базу знаний.
📍 Концепция многопоточности 📍
Чёткого знания и понимания контента из трёх статей ниже для джуна будет вполне достаточно.
Дисклеймер: речь именно о концепции многопоточности. Понятно, что нужно ещё знать о куче реализаций типа корутин, залуперов, сервисов и прочего.
📚 Введение в многопоточность очень простым языком. Важно, что там нормально объяснён volatile и synchronized
📚 Более углубленно и исчерпывающе, но не упарываясь
📚 И на закуску концепция атомарности на базовом уровне и понятных примерах
Если такой контент вам полезен, ставьте лайк!
#android #БазаЗнаний
@andrdevnotes | Обучение android
Продолжаем полюбившуюся вам рубрику.
Пишите в комментариях, если есть, что улучшить, будем с вами вместе собирать базу знаний.
📍 Концепция многопоточности 📍
Чёткого знания и понимания контента из трёх статей ниже для джуна будет вполне достаточно.
📚 Введение в многопоточность очень простым языком. Важно, что там нормально объяснён volatile и synchronized
📚 Более углубленно и исчерпывающе, но не упарываясь
📚 И на закуску концепция атомарности на базовом уровне и понятных примерах
Если такой контент вам полезен, ставьте лайк!
#android #БазаЗнаний
@andrdevnotes | Обучение android
👍22❤7🔥4🙏2😍2
Как правильно страдать хернёй
Когда мы с женой приехали после офигенного отпуска, в первые же пару дней стала очевидна разница между нашими типами мышления.
Жена, после почти месяца полного расслабления и отключения головы, со свежими силами принялась за дела, и начала делать всякое полезное, как пчёлка.
А я приехал и практически слёг в кровать под тяжестью невидимого груза. С удивлением взирая на порхающую вокруг жену.
Из-за перегруженной префронталки (по крайней мере я так это называю, могу быть не прав) я несколько дней не мог делать ничего, кроме как пырить в стену.
Потому что вся голова была занята обдумыванием того, чем бы я хотел заняться дальше. В этом году и в целом по жизни. И пока эта куча мыслей не доварилась, пока я её не упорядочил, не выложил на бумагу и не осознал, я нихрена толкового делать не мог.
Но я себя знаю давно, и доверяю себе в таких случаях. "Если у меня нет никаких осознанных мыслей, но есть ощущение забитой головы – значит оно варится глубже, и надо просто ждать и не мешать, занимаясь какой-нибудь рутиной, не задействующей голову." – к этой мысли я приходил почти лет 30.
А вы себе верите?
Даёте себе часами и днями "страдать хернёй" (так это видят окружающие, на самом деле вы делаете огромную работу, просто не осознаёте. Но устаёте вы от этого как и от физического труда) ?
Когда мы с женой приехали после офигенного отпуска, в первые же пару дней стала очевидна разница между нашими типами мышления.
Жена, после почти месяца полного расслабления и отключения головы, со свежими силами принялась за дела, и начала делать всякое полезное, как пчёлка.
А я приехал и практически слёг в кровать под тяжестью невидимого груза. С удивлением взирая на порхающую вокруг жену.
Из-за перегруженной префронталки (по крайней мере я так это называю, могу быть не прав) я несколько дней не мог делать ничего, кроме как пырить в стену.
Потому что вся голова была занята обдумыванием того, чем бы я хотел заняться дальше. В этом году и в целом по жизни. И пока эта куча мыслей не доварилась, пока я её не упорядочил, не выложил на бумагу и не осознал, я нихрена толкового делать не мог.
Но я себя знаю давно, и доверяю себе в таких случаях. "Если у меня нет никаких осознанных мыслей, но есть ощущение забитой головы – значит оно варится глубже, и надо просто ждать и не мешать, занимаясь какой-нибудь рутиной, не задействующей голову." – к этой мысли я приходил почти лет 30.
А вы себе верите?
Даёте себе часами и днями "страдать хернёй" (так это видят окружающие, на самом деле вы делаете огромную работу, просто не осознаёте. Но устаёте вы от этого как и от физического труда) ?
😁8👍7👏3🌚1😎1
🤔 Однажды мы с коллегами плотно зарубились на вопросе: "А как нам назвать юзкейс?"
Сначала мы холиварили, является ли логика ретрая запроса частью юзкейса, или же ей место в презентейшне.
📌 С одной стороны, один и тот же юзкейс может понадобиться ретраить по-разному в разных случаях. Где-то надо бесконечно запрос повторять no matter what, где-то надо в какой-то момент ошибку показать, где-то вообще не надо ретраить. И если во всех юзкейсах будет разная логика ретраев, то по обычному названию юзкейса GetUserUseCase будет совершенно непонятно, ретраится ли он внутри – тогда мы теряем атомарность юзкейса, а это его важная часть. Получается, логичнее выносить ретрай из юзкейса в presentation-слой, из которого он вызывается.
📌 С другой стороны, ретрай может быть частью бизнес-логики, и тогда где ж ему ещё быть, как не в юзкейсе.
В итоге пришли к тому, что если уж помещаем ретрай в юзкейс – надо точно указать это в его названии.
И вот как назвать юзкейс, в котором делается бесконечный перезапрос? GetUserWithInfiniteRetryUseCase как-то долго, сложно и не метко.
😏 В итоге пришли к названию GetUserOrDieTryingUseCase и, довольные, разошлись. С тех пор нейминг так и живёт уже 3 года =)
Сначала мы холиварили, является ли логика ретрая запроса частью юзкейса, или же ей место в презентейшне.
📌 С одной стороны, один и тот же юзкейс может понадобиться ретраить по-разному в разных случаях. Где-то надо бесконечно запрос повторять no matter what, где-то надо в какой-то момент ошибку показать, где-то вообще не надо ретраить. И если во всех юзкейсах будет разная логика ретраев, то по обычному названию юзкейса GetUserUseCase будет совершенно непонятно, ретраится ли он внутри – тогда мы теряем атомарность юзкейса, а это его важная часть. Получается, логичнее выносить ретрай из юзкейса в presentation-слой, из которого он вызывается.
📌 С другой стороны, ретрай может быть частью бизнес-логики, и тогда где ж ему ещё быть, как не в юзкейсе.
В итоге пришли к тому, что если уж помещаем ретрай в юзкейс – надо точно указать это в его названии.
И вот как назвать юзкейс, в котором делается бесконечный перезапрос? GetUserWithInfiniteRetryUseCase как-то долго, сложно и не метко.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁15🔥7✍4❤2
Мои трудовыебудни:
Надо было вместо вертикального списка с элементами во всю ширину сделать список, в котором у каждого элемента ширина по контенту, а в каждой строке списка должно быть столько элементов, сколько влезает по ширине.
Реализован старый список был на RecyclerView, так что я решил его и переделать. Решил, что надо найти решения двух разных задач: динамическая ширина элемента и динамическое количество элементов в строке, а потом смёрджить два решения в новый SuperAdapter и дело в шляпе.
Сказано – сделано.
Да хрен там, в итоге я понял, что если делать это вручную, то я в рамки этой таски точно не умещусь, и пошёл искать другое решение.
В итоге я наткнулся на гугловский FlexboxLayoutManager, казалось бы, предназначенный как раз для этой задачи. Довольный, затащил его в проект и реализовал.
А потом на ревью мне коллега покрутил пальцем у виска и сказал, что для этой задачи куда проще и удобнее сделать через ChipGroup, который как раз для этой цели и создан.
Но этот чёртов ChipGroup мне на мой запрос в гугле ни разу не вылез =)
Век живи, век учись. Оказалось, реально удобная штука, возьмите на заметку.
Особенно радует, что в ChipGroup можно с помощью addView добавлять не только наследников Chip, а любые вьюхи, и они все равно будут норм выстраиваться. Но часть методов / атрибутов правда перестанет работать, например singleSelection – потому что он работает только на Chip.
А вот к FlexboxLayoutManager есть вопросики: странновато он настраивается, странноватые дефолтные отступы между элементами, и сходу тоже непонятно, как их настраивать.
А вы бы как пошли эту задачу решать?) Я один такой тугой?)
Надо было вместо вертикального списка с элементами во всю ширину сделать список, в котором у каждого элемента ширина по контенту, а в каждой строке списка должно быть столько элементов, сколько влезает по ширине.
Реализован старый список был на RecyclerView, так что я решил его и переделать. Решил, что надо найти решения двух разных задач: динамическая ширина элемента и динамическое количество элементов в строке, а потом смёрджить два решения в новый SuperAdapter и дело в шляпе.
Сказано – сделано.
В итоге я наткнулся на гугловский FlexboxLayoutManager, казалось бы, предназначенный как раз для этой задачи. Довольный, затащил его в проект и реализовал.
А потом на ревью мне коллега покрутил пальцем у виска и сказал, что для этой задачи куда проще и удобнее сделать через ChipGroup, который как раз для этой цели и создан.
Но этот чёртов ChipGroup мне на мой запрос в гугле ни разу не вылез =)
Век живи, век учись. Оказалось, реально удобная штука, возьмите на заметку.
Особенно радует, что в ChipGroup можно с помощью addView добавлять не только наследников Chip, а любые вьюхи, и они все равно будут норм выстраиваться. Но часть методов / атрибутов правда перестанет работать, например singleSelection – потому что он работает только на Chip.
А вот к FlexboxLayoutManager есть вопросики: странновато он настраивается, странноватые дефолтные отступы между элементами, и сходу тоже непонятно, как их настраивать.
А вы бы как пошли эту задачу решать?) Я один такой тугой?)
😁10👍7👏2🌚2😈1
Вы ж помните, я был самоучкой, а на первой серьёзной работе через 3 месяца уволился лид и оставил меня одного. На 4 года =) Ну как, команда у меня была, но из бэкендеров-фронтендеров-дизайнеров-тестировщиков. Ни одного мобильщика больше не было всё это время.
И хотя я не то, чтобы дофига социально активный, мне все равно сильно не хватало общения "со своими". У меня были какие-то потуги это общение найти, но кроме каких-то англоязычных форумов я ничего не увидел, в итоге взгрустнул, да и забил.
И одним из главных пунктов, которые я называл при собеседовании в Белку, было "чтоб была команда разрабов, с которыми можно перетереть за андроид, походить на конференции и вот это вот всё".
И эти слова шли реально от души, как сейчас помню =)
Так вот – однажды, когда мы сплавлялись с друзьями по Тверце, один знакомый айосер мне сказал, что есть такое сообщество – КофеКод, на котором мобильные разрабы встречаются попить кофейку и потереть за жизу.
Крутой проект, как по мне. 10 лет назад мне бы это сильно помогло, хотя бы психологически. А если вы прямо сейчас ищете работу – вы, думаю, в курсе, что "по знакомству" устроиться куда проще, особенно если вы джун.
Так что советую сходить к кофекотовцам на встречи: заведёте полезные знакомства, ну или просто поболтаете в кругу своих =) 👇
И хотя я не то, чтобы дофига социально активный, мне все равно сильно не хватало общения "со своими". У меня были какие-то потуги это общение найти, но кроме каких-то англоязычных форумов я ничего не увидел, в итоге взгрустнул, да и забил.
И одним из главных пунктов, которые я называл при собеседовании в Белку, было "чтоб была команда разрабов, с которыми можно перетереть за андроид, походить на конференции и вот это вот всё".
И эти слова шли реально от души, как сейчас помню =)
Так вот – однажды, когда мы сплавлялись с друзьями по Тверце, один знакомый айосер мне сказал, что есть такое сообщество – КофеКод, на котором мобильные разрабы встречаются попить кофейку и потереть за жизу.
Крутой проект, как по мне. 10 лет назад мне бы это сильно помогло, хотя бы психологически. А если вы прямо сейчас ищете работу – вы, думаю, в курсе, что "по знакомству" устроиться куда проще, особенно если вы джун.
Так что советую сходить к кофекотовцам на встречи: заведёте полезные знакомства, ну или просто поболтаете в кругу своих =) 👇
🔥9💯5❤4
🤖 Android | 📱 Mobile | 🍏 iOS
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤4⚡2👌2
Кого куда зачем делить, нормально же общались((
Чем крупнее и сложнее приложение, и чем больше над ним работает команд и разработчиков разного уровня, тем важнее уметь изолировать части кода друг от друга, и тем важнее становится скорость сборки приложения.
Если у вас 2 разработчика, то увеличение скорости сборки на 5 минут будет выигрывать компании пару часов в день, а если у вас 50 разработчиков – то у компании дневной КПД вырастет в несколько раз. Stonks! 📈
С этим и помогает многомодульность (если правильно организована🌚). Задумка такая: делим приложение на несколько мелких независимых частей, и тогда изменения в одной части не потребуют пересборки всего проекта для запуска – потребуется пересобрать только изменённую часть и её зависимости. Так мы и время сэкономим, и сможем отдать какую-нибудь новую часть новому джуну, не боясь, что он в процессе разработки пол-проекта нам поменяет. Пусть сидит там чудит себе на здоровье, на код-ревью посмотрим 😎
Есть два способа деления:
– по слоям Clean-архитектуры (модули app, domain, data и presentation)
– core-feature деление.
С первым всё понятно: тут главное удобство в том, что ты учишься жить по клину, и прям на уровне модулей можешь прописать, что в domain нельзя тащить android-классы, и что domain не зависит от остальных модулей-слоёв. Удобно для начинающих и для тренировки, но в плане масштабирования не очень удобная история: в какой-то момент вам захочется делить на более мелкие части, чем 4 модуля, захочется выносить отдельные фичи в отдельные модули, и приложение начнёт постепенно превращаться в кавардак.
Core-feature деление – более удобная история: в core пихаем всё общее и используемое всеми модулями, а в feature... Тут опять 2 варианта:
– либо один экран – одна feature, либо один флоу – одна feature. Флоу – группа экранов, объединённых общим смыслом – например флоу авторизации или флоу покупки. Чаще всего делят по флоу.
И внутри каждая feature живёт своей жизнью: если там нет работы с данными, а только презентейшн-логика, то там из клин-слоёв только presentation, а если есть и работа с данными, и своя бизнес-логика – то в feature будут все 3 своих clean-слоя. Под каждый слой своя папка внутри фичи.
Во "взрослом" core-feature делении к feature-модулю, в котором лежит вся логика фичи, делают ещё feature-api модуль – это модуль-прослойка, состоящий только из интерфейса модуля, отражающего то, что от этого модуля нужно всем остальным. Если модуль состоит из одной активити и всей сопутствующей логики – значит, скорее всего, апи фичи будет состоять из старта этой активити. И все остальные модули не будут ничего знать о том, что происходит в самой фиче – а будут только использовать апи этой фичи.
Звучит всё это заманчиво, но на деле и в реальной компании вас все равно ждёт кавардак, это я вам обещаю. У вас точно часть общего будет в core, часть в каком-нибудь "временном" common, а часть вообще "временно" рассована по отдельным фичам с задачей по рефакторингу в бэклоге, которую однажды вечером пятницы наконец закэнселят и примут неизбежную бренность бытия.
Готов поспорить, что ни у кого не найдётся идеального мультимодульного проекта в проде, и чтоб у него было хотя бы тыщ 50 активных юзеров😏
Чем крупнее и сложнее приложение, и чем больше над ним работает команд и разработчиков разного уровня, тем важнее уметь изолировать части кода друг от друга, и тем важнее становится скорость сборки приложения.
Если у вас 2 разработчика, то увеличение скорости сборки на 5 минут будет выигрывать компании пару часов в день, а если у вас 50 разработчиков – то у компании дневной КПД вырастет в несколько раз. Stonks! 📈
С этим и помогает многомодульность (если правильно организована🌚). Задумка такая: делим приложение на несколько мелких независимых частей, и тогда изменения в одной части не потребуют пересборки всего проекта для запуска – потребуется пересобрать только изменённую часть и её зависимости. Так мы и время сэкономим, и сможем отдать какую-нибудь новую часть новому джуну, не боясь, что он в процессе разработки пол-проекта нам поменяет. Пусть сидит там чудит себе на здоровье, на код-ревью посмотрим 😎
Есть два способа деления:
– по слоям Clean-архитектуры (модули app, domain, data и presentation)
– core-feature деление.
С первым всё понятно: тут главное удобство в том, что ты учишься жить по клину, и прям на уровне модулей можешь прописать, что в domain нельзя тащить android-классы, и что domain не зависит от остальных модулей-слоёв. Удобно для начинающих и для тренировки, но в плане масштабирования не очень удобная история: в какой-то момент вам захочется делить на более мелкие части, чем 4 модуля, захочется выносить отдельные фичи в отдельные модули, и приложение начнёт постепенно превращаться в кавардак.
Core-feature деление – более удобная история: в core пихаем всё общее и используемое всеми модулями, а в feature... Тут опять 2 варианта:
– либо один экран – одна feature, либо один флоу – одна feature. Флоу – группа экранов, объединённых общим смыслом – например флоу авторизации или флоу покупки. Чаще всего делят по флоу.
И внутри каждая feature живёт своей жизнью: если там нет работы с данными, а только презентейшн-логика, то там из клин-слоёв только presentation, а если есть и работа с данными, и своя бизнес-логика – то в feature будут все 3 своих clean-слоя. Под каждый слой своя папка внутри фичи.
Во "взрослом" core-feature делении к feature-модулю, в котором лежит вся логика фичи, делают ещё feature-api модуль – это модуль-прослойка, состоящий только из интерфейса модуля, отражающего то, что от этого модуля нужно всем остальным. Если модуль состоит из одной активити и всей сопутствующей логики – значит, скорее всего, апи фичи будет состоять из старта этой активити. И все остальные модули не будут ничего знать о том, что происходит в самой фиче – а будут только использовать апи этой фичи.
Готов поспорить, что ни у кого не найдётся идеального мультимодульного проекта в проде, и чтоб у него было хотя бы тыщ 50 активных юзеров
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥4👏2🌚1💯1
Любопытной Варваре на ревью нос оторвали
В одном из проектов, над которым я работаю, я нашёл баг во внешней библиотеке. Я выяснил, что баг появился в конкретном релизе библиотеки.
Что нужно сделать? Правильно, залезть в их мердж-коммит с этим релизом и попытаться понять, а чо они там сломали =)
Параллельно я, разумеется, общался с самими разрабами по поводу бага, и они выкатили фикс в следующем релизе.
И знаете что? Когда я смотрел их код, который я видел впервые в жизни, я за 5 минут предположил возможный источник проблемы и путь её решения.
И их мердж-коммит с новым релизом мою гипотезу подтвердил =)
Лишнее подтверждение тому, что если ты шаришь в computer science и сеньоришь в одном из нормальных ООПшных языков, тебе в целом уже пофиг, на каком языке и что писать – онбординг 5 мин и погнали =)
Ну 5 мин на любой язык это я конечно загнул, но суть вы думаю уловили :)
А у вас было такое, что бэкендеры или айосеры что-то наворотили, а потом ушли в отпуск / уволились, и вам пришлось за ними баги фиксить?)
В одном из проектов, над которым я работаю, я нашёл баг во внешней библиотеке. Я выяснил, что баг появился в конкретном релизе библиотеки.
Что нужно сделать? Правильно, залезть в их мердж-коммит с этим релизом и попытаться понять, а чо они там сломали =)
Параллельно я, разумеется, общался с самими разрабами по поводу бага, и они выкатили фикс в следующем релизе.
И знаете что? Когда я смотрел их код, который я видел впервые в жизни, я за 5 минут предположил возможный источник проблемы и путь её решения.
И их мердж-коммит с новым релизом мою гипотезу подтвердил =)
Лишнее подтверждение тому, что если ты шаришь в computer science и сеньоришь в одном из нормальных ООПшных языков, тебе в целом уже пофиг, на каком языке и что писать – онбординг 5 мин и погнали =)
А у вас было такое, что бэкендеры или айосеры что-то наворотили, а потом ушли в отпуск / уволились, и вам пришлось за ними баги фиксить?)
👍7🔥3👏3🌚2👀1
Наткнулся на странную дичь.
В http-логах вижу, что запрос заканчивается в X, при этом в rx / корутине результат запроса я получаю через X + 1 секунду.
Я канеш понимаю, запрос тяжёлый, респонс там почти на 5 Мб. Но ё-маё, целую секунду на этом терять ваще не круто. К тому же, потом наткнулся на кейс, когда респонс в 10 раз меньше, а простой почти такой же, 0.9с.
При этом я пробовал мокать в проксимене респонс на маленький, больше ничего не меняя – и запрос отдаётся сразу, то есть причина простоя точно в размере респонса.
Пока в раздумьях, что с этим делать. Нашёл старую статью со старым костылём на rx, мб попробую. Но хотелось бы и на уровне корутин решение найти.
Ставь 👻, если понятия не имеешь, как замокать респонс в проксимене, или даже не знаешь значение этой фразы.
В http-логах вижу, что запрос заканчивается в X, при этом в rx / корутине результат запроса я получаю через X + 1 секунду.
Я канеш понимаю, запрос тяжёлый, респонс там почти на 5 Мб. Но ё-маё, целую секунду на этом терять ваще не круто. К тому же, потом наткнулся на кейс, когда респонс в 10 раз меньше, а простой почти такой же, 0.9с.
При этом я пробовал мокать в проксимене респонс на маленький, больше ничего не меняя – и запрос отдаётся сразу, то есть причина простоя точно в размере респонса.
Пока в раздумьях, что с этим делать. Нашёл старую статью со старым костылём на rx, мб попробую. Но хотелось бы и на уровне корутин решение найти.
Ставь 👻, если понятия не имеешь, как замокать респонс в проксимене, или даже не знаешь значение этой фразы.
👻26👍4🔥2🤔2👀2