Помните мы читали одну из лучших книг прошлого года? The Software Engineer's Guidebook. Тогда я делился главой про написание кастомных решений. Автор говорил, что свои велосипеды — это лучший путь для карьерного и профессионального развития. Фундамент promotion driven development.
Утверждение крайне спорное. В комментах поста крутые инженеры немного поспорили выгодно ли писать свои решения или лучше заимствовать чужие?
Недавно заметил за собой, что в канале ни разу не писал разборы чужих опенсоурсов. Дико не люблю разборы чужих библиотек и фреймворков. Своих велосипедов на работах всегда хватало
По мне лучше изучать исходники языка и нативных инструментов, чем рытаться в открытом коде, скорее всего написанном на скорую руку. Где времени на ревью и проектирование почти нет. Аккуратно подниматься по абстракциям снизу вверх. А я еще не до конца изучил даже исходников Swift, чем переходить к условному PointFree.
В FAANG’ах любят писать все свое. На то есть несколько причин:
1. Антипаттерн Vendor Lock. Используя закрытое чужое решение, становишься от него зависимым.
В Яндексе есть свой git, jira, свой teamcity. Казалось бы зачем? Помню, как у многих были проблемы с CI. А в Авито в один день отключили корпоративные учетки гугл доков, потеряв очень много ценной инфы.
Также самое и в мобилке. Если либа не обновлялась год, то значит она почти мертва. Стоит ли тащить избыточное решение целиком или лучше взять лучшую часть и адаптировать под себя?
2. Если твоя компания может позволить нанять себе лучших специалистов и у них есть все нужные ресурсы написать решения лучше, то почему этого не сделать? Так ты поможешь и продукту выполнить метрики. И создать технологичное конкурентное преимущество.
Например, на последнем конкурсе телеграм, для написания видеоплеера нужно было отказаться от AVFoundation. Задача усложнялась в разы и в итоге победителей конкурса не оказалась.
Слышал, что написать свой AVFoundation в ВК видео вроде заняло почти три года. Но объективно плеер ВК в разы лучше телеграмовского.
Конечно, писать или заимствовать вопрос многих переменных: сроков, цены, целей. Но для меня лучше всегда писать хотяб минимум, но своих решений. Улучшать или дополнять. Так мы находим боевой опыт, который дает уникальную ценность нам и нашему продукту. А также повышая техническую осознанность.
Деградация кодовой базы, инфляция стандартов и циркуляция новых решений в ит сравнится как негде. Вечные патчи, апдейты, обновления — все требует бесконечного обновления. В этих условиях невозможно жить без своих велосипедов и инхаус решений.
Мораль. Использовать готовые решения можно и иногда даже необходимо, но если у тебя есть ресурсы и возможности создать свое — то преступление этими возможностями не пользоваться.
Но все же иногда стоит помнить, что инженер оценивается не потому сколько прочитал, а сколько написал сам.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
iOS Makes Me Hate
🤔🤔🤔
Почему обучение это не лестница, а круг
Одной из основных моих причин ухода с других компаний это желание расти. Я не могу долго находиться в застое и покоя. Как ветераны боевых действий, вернувшиеся на гражданку.
Бывало что я даже уходил на зп ниже потому, что видел перспективы для роста больше. Иногда даже уходил на должности ниже.
Вчера я учился. Сегодня — менторю. Завтра опять учусь.
Когда перестаешь учиться — начинаешь отставать. Сначала ты ничего не знаешь, потом избыточно самоуверен.
Путь роста — не лестница, где есть вверх. Это круг, где ты всё время переходишь между ролями:
ученик, ментор, исследователь.
Каждый новый уровень — не про «знаю всё», а про «теперь знаю, как мало знаю».
Ты растёшь — когда снова чувствуешь себя джуном
Одной из основных моих причин ухода с других компаний это желание расти. Я не могу долго находиться в застое и покоя. Как ветераны боевых действий, вернувшиеся на гражданку.
Бывало что я даже уходил на зп ниже потому, что видел перспективы для роста больше. Иногда даже уходил на должности ниже.
Вчера я учился. Сегодня — менторю. Завтра опять учусь.
Когда перестаешь учиться — начинаешь отставать. Сначала ты ничего не знаешь, потом избыточно самоуверен.
Путь роста — не лестница, где есть вверх. Это круг, где ты всё время переходишь между ролями:
ученик, ментор, исследователь.
Каждый новый уровень — не про «знаю всё», а про «теперь знаю, как мало знаю».
Ты растёшь — когда снова чувствуешь себя джуном
Многие встречаются с проблемой сервиса бусти: не проходит/продлевается оплата; разные цены в разных регионах 🤯 и другие приколы.
Поэтому делаю отдельный пост для истории со всеми подписками трибьюта. Там в целом удобнее и для вас дешевле.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Tribute
This bot helps content creators receive financial support from their followers directly in the app.
Два главных заблуждения начинающих разрабов:
- Достаточно выучить только SwiftUI и можно будет сделать любое приложение на нем
- Изучение SwiftUI это изучение только UI компонентов и API фреймворка
Но старые концепции и принципы требуют адаптации для SwiftUI тоже.
И то и другое заблуждение легко разбиваются на практике.
- SwiftUI это дополнение, а не замена. У него есть плюсы, и минусы.
- Чем больше кодовая база и сложнее код, тем больше новых архитектурных решений требует приложение. Верстка вьюшек это только маленькая часть.
Лучший блог для архитектур уже разобрал множество крутых идей для дизайна приложений на SwiftUI. Одна из них Composition Root.
Composition Root — это центральное место в приложении, где создаются и связываются все зависимости. По сути это очень простая концепция. Вместо того чтобы компоненты (например, ViewModel) напрямую создавали свои зависимости, они получают их извне, обычно через инициализатор.
В отличие от Service Locator или Singleton он помогает явно распределять зависимости в точке входа приложения, где они явно создаются в одном месте (SceneDelegate, @main, App). А также использует Dependency Injection через init injection.
Все это лучше помогает тестировать и масштабировать код.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
SwiftUI по умолчанию делает многое автоматически — это удобно, но без DI ты быстро начнёшь жёстко связывать View, ViewModel, сервисы, хранилище, API и т.д.
А значит тестировать, переиспользовать, изменять, рефакторить код — страшно и больно
С DI легко заменяешь зависимости на моки:
let mock = MockUserService()
let vm = ProfileViewModel(userService: mock)
Чистое разделение ответственности c помощью DI помогает разделить на компоненты:
View — Отображение
ViewModel — Логика UI
Service — Данные/API
Гибкость для разных окружений:
#if DEBUG
let service = MockUserService()
#else
let service = RealUserService()
#endif
Лёгкий переход к модульной архитектуре
С DI ты можешь:
- выносить модули в отдельные фреймворки,
- управлять зависимостями централизованно,
- добавлять фичи, не ломая всё остальное.
В следущем посте разберем в чем главное отличие работы с DI в SwiftUI и UIKit
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Все про Hash Table для интервью, работы и алгоритмов (Хеш Таблица, map, dict, table)
Опять ультимативный гайд, который нам точно поможет прокачать навыки. Я уже делился контентом автора, где он дает полный гайд как и зачем решать литкод. Целых 4,5 часов. Пост набрал 11к просмотров.
Теперь он выложил гайд конкретно про хэш-таблицы на почти 4 часа.
Но главное важно помнить, что после просмотра ютуба, нужно потратить еще х5 времени на практику
Опять ультимативный гайд, который нам точно поможет прокачать навыки. Я уже делился контентом автора, где он дает полный гайд как и зачем решать литкод. Целых 4,5 часов. Пост набрал 11к просмотров.
Теперь он выложил гайд конкретно про хэш-таблицы на почти 4 часа.
Но главное важно помнить, что после просмотра ютуба, нужно потратить еще х5 времени на практику
YouTube
Все про Hash Table для интервью, работы и алгоритмов (Хеш Таблица, map, dict, table)
Telegram post: https://www.group-telegram.com/koduryem/51
Это видео будет полезно тем, кто хочет понять:
1) что такое хеш таблицы
2) что такое хеш
3) как использовать хеш таблицы
4) какие бывают виды хеш таблиц и как они устроены
5) какие варианты и когда применять
6) как…
Это видео будет полезно тем, кто хочет понять:
1) что такое хеш таблицы
2) что такое хеш
3) как использовать хеш таблицы
4) какие бывают виды хеш таблиц и как они устроены
5) какие варианты и когда применять
6) как…
Вопросы для собеседований SwiftUI: Layout Engine
После каждого блока теории и практики я всегда стараюсь закреплять этим блоком для самопроверки. Собирая все важные вопросы и акценты, которые помогут лучше понять или вернуться к пройденному материалу.
Это стандартная методика которая используется в любой классической школе. Но при этом и отличный способ подготовиться к собесам, ведь они работают по такой же схеме.
Мы с ребятами уже собрали более 300 задач и вопросов. Были уже прецеденты, когда ребята и я использовали многие задачи для проведения собесов и наполнения банка задача.
Я считаю, что качество собесов — общая ответственность. Поэтому всегда в каждой компании был заинтересован в улучшении этого процесса и обучении себя и других интервьюеров.
В этой подборке вы встретите > 20 вопросов:
🌟 Вопросы о пройденных темах: AttributeGraph, view & render trees
🌟 Чем отличается жизненный цикл SwiftUI от UIKit
🌟 Что такое концепция Source of Truth
🌟 Тонкости property wrapper'ов, отложенный рендеринг и многие другие вопросы
🧬 Получить доступ к разделу и другой контент можно 💰 тут или ⭐️ тут
После каждого блока теории и практики я всегда стараюсь закреплять этим блоком для самопроверки. Собирая все важные вопросы и акценты, которые помогут лучше понять или вернуться к пройденному материалу.
Это стандартная методика которая используется в любой классической школе. Но при этом и отличный способ подготовиться к собесам, ведь они работают по такой же схеме.
Мы с ребятами уже собрали более 300 задач и вопросов. Были уже прецеденты, когда ребята и я использовали многие задачи для проведения собесов и наполнения банка задача.
Я считаю, что качество собесов — общая ответственность. Поэтому всегда в каждой компании был заинтересован в улучшении этого процесса и обучении себя и других интервьюеров.
В этой подборке вы встретите > 20 вопросов:
Please open Telegram to view this post
VIEW IN TELEGRAM
Разбор багов и решений Swift Concurrency
Главная мысль приходящяя с опытом — нет идеальных решений и инструментов. Все можно похвалить и покритиковать. Инструменты не будут приносить только пользу, а их разработчики не смогут расчитать все варианты использований. Не смогут не допускать баги.
На фоне прошлого поста с багами SwiftUI собрал известные и неочень баги Swift Concurrency.
🤢 ConcurrencyRecipes от Matt Massicotte
Этот репозиторий на GitHub содержит практические решения и описания проблем, таких как: Проблемы с изоляцией (actor isolation); Ошибки порядка выполнения; Проблемы с Sendable; Блокировки потоков и зависания; Сложности с async-вирусностью (когда async распространяется по коду); и другие
👎 Статья “Swift Concurrency – Things They Don’t Tell You”
Автор делится наблюдениями о том, как async/await может привести к неожиданным проблемам, особенно при работе с UI и @MainActor. Основные моменты:
🔘 async функции могут выполняться на любом потоке, даже если они вызываются с главного потока.
🔘 await может приостановить выполнение и позволить другим задачам выполняться, что может привести к неожиданным изменениям состояния.
🔘 Использование @MainActor не гарантирует, что весь метод будет выполняться на главном потоке, особенно если внутри есть await.
🤢 Проблемы с Sendable и предупреждения компилятора
Обсуждение на GitHub: “thoughts on Sendable and swift 5.10 concurrency warnings?”
Разработчики обсуждают предупреждения компилятора, связанные с Sendable, и как они могут повлиять на существующий код. Основные моменты:
🔴 Предупреждения о том, что определённые типы не соответствуют Sendable, могут быть сложными для устранения.
🔴 Некоторые предупреждения связаны с ограничениями языка, которые ещё не полностью решены.
🤢 Сбои при высокой нагрузке
Даже простые задачи с TaskGroup могут часто аварийно завершаться при высокой нагрузке на систему. Проблема связана с повреждением памяти при параллельном выполнении задач.
Главная мысль приходящяя с опытом — нет идеальных решений и инструментов. Все можно похвалить и покритиковать. Инструменты не будут приносить только пользу, а их разработчики не смогут расчитать все варианты использований. Не смогут не допускать баги.
На фоне прошлого поста с багами SwiftUI собрал известные и неочень баги Swift Concurrency.
Этот репозиторий на GitHub содержит практические решения и описания проблем, таких как: Проблемы с изоляцией (actor isolation); Ошибки порядка выполнения; Проблемы с Sendable; Блокировки потоков и зависания; Сложности с async-вирусностью (когда async распространяется по коду); и другие
Автор делится наблюдениями о том, как async/await может привести к неожиданным проблемам, особенно при работе с UI и @MainActor. Основные моменты:
Обсуждение на GitHub: “thoughts on Sendable and swift 5.10 concurrency warnings?”
Разработчики обсуждают предупреждения компилятора, связанные с Sendable, и как они могут повлиять на существующий код. Основные моменты:
Даже простые задачи с TaskGroup могут часто аварийно завершаться при высокой нагрузке на систему. Проблема связана с повреждением памяти при параллельном выполнении задач.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - mattmassicotte/ConcurrencyRecipes: Practical solutions to problems with Swift Concurrency
Practical solutions to problems with Swift Concurrency - mattmassicotte/ConcurrencyRecipes
App Store в США потерял монополию на оплату,
но во всём остальном мире 30% комиссия, а также контроль над пейволами, A/B тестами, трекингом всё ещё сохраняется.
Web2App - решение, которое возвращает контроль уже сегодня.
🍏 Простыми словами:
Вместо того чтобы сразу вести пользователей в App Store, вы направляете их на веб-воронку, где они:
— понимают, зачем им ваш продукт
— оплачивают подписку на вебе без ограничений и контроля со стороны Apple или Google
— устанавливают приложение через диплинк с уже активной подпиской
👌 Это выгодно:
Вы не просто экономите на комиссиях сторов (платите всего 2-5% вместо 30%), но и получаете:
— точную атрибуцию и аналитику через webhooks даже на iOS
— прогретых пользователей которые понимают ценность продукта, что повышает LTV и снижает CAC
— собранную email-базу для повторного маркетинга
Запустить за 2 дня:
web2wave это готовый топовый конструктор веб воронок, где вам не нужно ничего программировать. Просто подключаете к своему приложению и запускаете.
👀 Хотите потестить? Зарегистрируйтесь на web2wave.com
P.S. Кстати, ребята из web2wave также предлагают интеграцию внешних оплат прямо в iOS приложения для рынка США (благодаря решению суда Epic vs. Apple). Сейчас ищут 3 приложения для бесплатной интеграции. Интересно? Напишите @igor_lyu
но во всём остальном мире 30% комиссия, а также контроль над пейволами, A/B тестами, трекингом всё ещё сохраняется.
Web2App - решение, которое возвращает контроль уже сегодня.
🍏 Простыми словами:
Вместо того чтобы сразу вести пользователей в App Store, вы направляете их на веб-воронку, где они:
— понимают, зачем им ваш продукт
— оплачивают подписку на вебе без ограничений и контроля со стороны Apple или Google
— устанавливают приложение через диплинк с уже активной подпиской
👌 Это выгодно:
Вы не просто экономите на комиссиях сторов (платите всего 2-5% вместо 30%), но и получаете:
— точную атрибуцию и аналитику через webhooks даже на iOS
— прогретых пользователей которые понимают ценность продукта, что повышает LTV и снижает CAC
— собранную email-базу для повторного маркетинга
Запустить за 2 дня:
web2wave это готовый топовый конструктор веб воронок, где вам не нужно ничего программировать. Просто подключаете к своему приложению и запускаете.
👀 Хотите потестить? Зарегистрируйтесь на web2wave.com
P.S. Кстати, ребята из web2wave также предлагают интеграцию внешних оплат прямо в iOS приложения для рынка США (благодаря решению суда Epic vs. Apple). Сейчас ищут 3 приложения для бесплатной интеграции. Интересно? Напишите @igor_lyu
Как АИ заменяет карьерных менторов и коучей. И заменит ли?
Перед тем как уходить с Авито, я обновил свое резюме с помощью чатгпт. Не накручивал опыт (в моем случае его уже надо скручивать), а попросил упаковать в емкую и четкую формулировку все что там написано. Это уже давно все делают на перфоманс ревью.
Сделать текст, так скажем, продающим. И конверсия на довольно хорошие позиции сильно увеличилась. Получается, не нужно платить процент от зп или кучу бабок тем, кто учит писать продающие резюме?
Я уже писал много раз, что большинство услуг менторов и других карьерных коучей — скам и это заменит чагпт. У меня было 3 года опыта менторства до того, как это стало мейнстримом. И я ушел тупо потому, что мне надоела рутина. Запросы в 80% одни и те же. И как бы вам не говорили про индивидуальные подходы, но в 2/3 случаях их нет.
Из интересного и относительного благородного дела это становится рутиной, где ты повторяешь одно и то же. Как персональный тренер в фитнес зале, его помощь нужна только на первых этапах. А дальше, если он сам не достиг хороших высот и результатов, то он быстро становится бесполезным. Поэтому фуллтайм менторством лучше заниматься, когда решил отказаться от профессионального забега и ушел на пенсию.
В отличие от спортзала it-физруков ИИ идельно заменяет. В ит не требуется стоять рядом и следить за каждым движением. Или это не всегда так? Тех, кто поверхностно обучает одной и той же методичкой. Но не все так гладко. В вопросе серьезного карьерного развития роль менеджера или высоко-квалифицированного наставника остается все также важной.
Вот и в статье пишется:
- зумеры уже доверяют чат ботам и АИ больше, чем менеджерам
- эффективное карьерное развитие все также требует вовлечение менеджеров
- ИИ может предоставить обобщённую информацию и помочь в саморазвити. Однако он не способен заменить персонализированную поддержку и контекстуальные советы, которые может дать опытный наставник или менеджер.
Перед тем как уходить с Авито, я обновил свое резюме с помощью чатгпт. Не накручивал опыт (в моем случае его уже надо скручивать), а попросил упаковать в емкую и четкую формулировку все что там написано. Это уже давно все делают на перфоманс ревью.
Сделать текст, так скажем, продающим. И конверсия на довольно хорошие позиции сильно увеличилась. Получается, не нужно платить процент от зп или кучу бабок тем, кто учит писать продающие резюме?
Я уже писал много раз, что большинство услуг менторов и других карьерных коучей — скам и это заменит чагпт. У меня было 3 года опыта менторства до того, как это стало мейнстримом. И я ушел тупо потому, что мне надоела рутина. Запросы в 80% одни и те же. И как бы вам не говорили про индивидуальные подходы, но в 2/3 случаях их нет.
Из интересного и относительного благородного дела это становится рутиной, где ты повторяешь одно и то же. Как персональный тренер в фитнес зале, его помощь нужна только на первых этапах. А дальше, если он сам не достиг хороших высот и результатов, то он быстро становится бесполезным. Поэтому фуллтайм менторством лучше заниматься, когда решил отказаться от профессионального забега и ушел на пенсию.
В отличие от спортзала it-физруков ИИ идельно заменяет. В ит не требуется стоять рядом и следить за каждым движением. Или это не всегда так? Тех, кто поверхностно обучает одной и той же методичкой. Но не все так гладко. В вопросе серьезного карьерного развития роль менеджера или высоко-квалифицированного наставника остается все также важной.
Вот и в статье пишется:
- зумеры уже доверяют чат ботам и АИ больше, чем менеджерам
- эффективное карьерное развитие все также требует вовлечение менеджеров
- ИИ может предоставить обобщённую информацию и помочь в саморазвити. Однако он не способен заменить персонализированную поддержку и контекстуальные советы, которые может дать опытный наставник или менеджер.
Business Insider
Some Gen Z workers are turning to AI for career advice and it's actually not a bad idea
Many Gen Zers are turning to AI for career advice but managers still have a key role to play in guiding workers.
Goodbye Code Reviews, Hello Harmonize
В прошлом посте мы поговорили про рефакторинг и закинули удочку на возможное обсуждение разных инструментов для улучшение кода.
Начнем с самых современных :) стартер пак любого проекта — это линтеры, которые задают принятую стилистику проекта. Думаю объяснять что это не сильно нужно.
С развитием же AI начинают развиваться более интересные инструменты.
Вместо того чтобы полагаться на ручные код-ревью для проверки соблюдения архитектурных соглашений, Harmonize позволяет автоматизировать эти проверки, превращая их в юнит-тесты.
Например:
1 Проверка наследования ViewModel
Убедиться, что все классы, заканчивающиеся на ViewModel, наследуются от BaseViewMod
2. Проверка захвата self в замыканиях
Убедиться, что self захватывается слабо в замыканиях внутри ViewModel
И многие другие штуки
Возможно, когда-нибудь я напишу как проводят код ревью с помощью AI в крупных компаниях. Но если мне это разрешат🥲
В прошлом посте мы поговорили про рефакторинг и закинули удочку на возможное обсуждение разных инструментов для улучшение кода.
Начнем с самых современных :) стартер пак любого проекта — это линтеры, которые задают принятую стилистику проекта. Думаю объяснять что это не сильно нужно.
С развитием же AI начинают развиваться более интересные инструменты.
Вместо того чтобы полагаться на ручные код-ревью для проверки соблюдения архитектурных соглашений, Harmonize позволяет автоматизировать эти проверки, превращая их в юнит-тесты.
Например:
1 Проверка наследования ViewModel
Убедиться, что все классы, заканчивающиеся на ViewModel, наследуются от BaseViewMod
2. Проверка захвата self в замыканиях
Убедиться, что self захватывается слабо в замыканиях внутри ViewModel
И многие другие штуки
Возможно, когда-нибудь я напишу как проводят код ревью с помощью AI в крупных компаниях. Но если мне это разрешат
Please open Telegram to view this post
VIEW IN TELEGRAM
Medium
Goodbye Code Reviews, Hello Harmonize: Enforce Your Architecture in Swift
Enforce architecture and best practices in your iOS apps as unit tests, with a modern, open-source linter for Swift.
На очереди у нас еще много контента по SwiftUI (пара мок собесов по систем дизайну и лайфкодингу, разбор кишков и тп). Поэтому чуть отвлекемся.
Один из частых запросов сделать подборку вопросов и задач для UIKit. А именно по производительности. По SwiftUI мы уже сделали парочку, а по UIKit ни одного. Нас за это справедливо пнули.
Такие вопросы любят задавать на сеньорные уровни в Авито, Яндексе, Сбере. А еще эти знания помогли мне занять призовое место в конкурсе телеграма. Без них никуда.
Удивлен, что толком не говорил об этом раньше. Многим часто дают такие задачи на собесах. Они помогают определить степень экспертности кандидата и насколько он может сделать плавным UI. Это логично и адекватно, ведь мобильный разработчик чаще всего работает с UI, а здесь знание кишков максимально оправдано.
Еще более удивлен, как много кандидатов валит эту секцию.
Я люблю копать в эту тему. Сейчас объясню почему) В одной из команд нам пришлось оптимизировать чат. Это сложная задача с которой не справлялось множество прошлых разрабов. Во-первых, никто не хотел копаться в легаси 10летней давности, а во-вторых код был очень запутанный и сложный. Но мы справились и улучшили перфоманс чата. Для директоров это было супер важно и так мы получили хорошую надбавку по зп.
Что мы сделали? Много чего, но одна из сложных задач была переход с Auto Layout на Frame Based, что увеличило перфоманс в 2,5 раза. Я уже кстати раньше делал материал и гайд. Ставь лайк, если нужно больше постов про производительность в UIKit.
Собрал все важные вопросы, которые помогут вам выстроить план и найти нужные акценты по производительности. В общем, крутая подборка, одна из моих самых любимых.
Будет несколько частей.
Please open Telegram to view this post
VIEW IN TELEGRAM