В прошлых постах мы немного прошлись с критикой REDUX-based архитектур. Их принципиальный недостаток в отличие от WEB — это то, что в мобилке мы сохраняем навигационный стэк. А в WEB архитектуры редакс лучше прижились, тк он не держит в памяти предыдущие экраны. Там вообще нет стэка экранов, а только одна html страница.
В бОльшей степени это связано с binding'ом. Все события предыдущих экранов прослушиваются и измененяются от глобального стора. Из-за ограниченности мобилок с каждым следующим открытым экраном накопление редьюсеров и обсерверов сильно влияет на CPU, батарею и память. Проще говоря, чем глубже дерево открытых экранов — тем больше изменений в приложении.
В этом посте мы лучше изучим механизм состояний и почему это важно, чтобы не допускать проблемы с перфомансом и стабильностью.
🌀 Вспомним как работает цикл обновления в SwiftUI?
1. Строится View Tree.
2. Создаётся или обновляется Render Tree, которое хранит стейт
3. Изменение стейта
4. Всё повторяется
После iOS 17 пришли серьезные изменения — к чертям выпилили ненужный Combine (я сразу говорил что он юзлес).
Вместо этого теперь работает механизм на макросах (@Observable), благодаря чему @StateObject и @ObservedObject стали не обязательны.
Теперь @State можно использовать и для структур, и для объектов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Demeter — новый инструмент для Android-разработчиков
Это библиотека, которую выложила в опенсорс команда мобильной разработки Яндекса. Она помогает измерять производительность Android-приложений, подробнее можно почитать в статье.
Почему это важно и зачем это в iOS канале?
Ни один инструмент на рынке не умеет сразу анализировать ВСЕ методы в коде. Обычно надо самому указать нужный метод, собрать проект и только потом получить данные. iOS'ерам можно вдохновиться.
Demeter решает эту проблему. Он автоматически показывает, сколько времени занимают методы прямо во время работы приложения и как долго инициализируются зависимости в Dagger. Также Demeter позволяет сделать подсчет количества рекомпозиций в Composable функциях, работать со сторонними библиотеками и писать свои плагины, расширяя функционал под задачи команды.
А в чём польза для бизнеса? Скорость — это деньги. Долгая загрузка экрана = потерянный пользователь. Я об этом писал еще пару лет назад.
Инструмент может работать через модификацию байткода и/или через плагин Kotlin компилятора. По итогу, Demeter помогает понять, какие функции тормозят приложение, показывает, как ведёт себя интерфейс при действиях юзера, генерирует подробные отчёты и позволяет отлавливать проблемы в коде еще до релиза.
Репозиторий на GitHub — тут
Это библиотека, которую выложила в опенсорс команда мобильной разработки Яндекса. Она помогает измерять производительность Android-приложений, подробнее можно почитать в статье.
Почему это важно и зачем это в iOS канале?
Ни один инструмент на рынке не умеет сразу анализировать ВСЕ методы в коде. Обычно надо самому указать нужный метод, собрать проект и только потом получить данные. iOS'ерам можно вдохновиться.
Demeter решает эту проблему. Он автоматически показывает, сколько времени занимают методы прямо во время работы приложения и как долго инициализируются зависимости в Dagger. Также Demeter позволяет сделать подсчет количества рекомпозиций в Composable функциях, работать со сторонними библиотеками и писать свои плагины, расширяя функционал под задачи команды.
А в чём польза для бизнеса? Скорость — это деньги. Долгая загрузка экрана = потерянный пользователь. Я об этом писал еще пару лет назад.
Инструмент может работать через модификацию байткода и/или через плагин Kotlin компилятора. По итогу, Demeter помогает понять, какие функции тормозят приложение, показывает, как ведёт себя интерфейс при действиях юзера, генерирует подробные отчёты и позволяет отлавливать проблемы в коде еще до релиза.
Репозиторий на GitHub — тут
В прошлых постах мы поговорили про State & Binding. А именно что дает нам SwiftUI для отслеживания изменения состояний. Мы определили, что Observable выглядит как самый рабочий вариант на 2025.
Хоть Observable работает только с iOS 17, но нет проблем написать свою реализацию для совместимости с версиями ниже. В интернете полно реализаций как можно сделать свой Observable. Но лучше всего подкапотную логику разобрали в книге "Thinking in SwiftUI". Мы будем много брать оттуда примеров.
Понимание подкапотной логики сильно поможет написать свой бэкпорт и не тащить библиотеки, которые недопустимы для крупных проектов
- Ты подписываешь класс под макрос @Observable
- Компилятор превращает его в нужный код
- Когда SwiftUI рендерит body он опрослушивает его через withObservationTracking
- Всё, что ты читаешь в body, становится наблюдаемым.
В итоге. Всё работает автоматически. Без @Published, @ObservedObject, objectWillChange. Наблюдение за объектами стало чище, проще и точнее.
Детальней разберем традиционно на картинках.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Подборки книг для инженеров от разраба Spotify
Пока я в небольшом отпуске перед выходом на новую работу, ищу себя чем занять. Прошел две части Ori (одна из лучших игр ever), посмотрел пару сериалов, походил в бани и зал. Даже с женой посмотрели пару выпусков "Беремена в 16". И узнал что такое мемы про italian brainrot, мой любимый это crocodilo bombardino.
Но пора потихоньку выходить из такого отпуска. Начинать разминать мозг. Вот подборка крутых книг от сеньора иосера и нашего любимого блогера:
🟣 Write Great Code: Understanding The Machine (Randall Hyde)
Лучшая альтернатива Танненбауну. Понятное введение в то, как работают современные компьютеры. Книга не перегружена техническими деталями, но помогает глубже понять, что происходит “под капотом”.
🟣 *OS Internals Trilogy (Jonathan Levin)
Отдельная рекомендация автора. Подробное руководство по внутреннему устройству платформ Apple. Рекомендуется опытным разработчикам, интересующимся такими темами, как загрузчики и ядра. Книги объемные и не подходят для новичков.
🟣 Hacking: The Art of Exploitation
Первая часть книги посвящена C и ассемблеру, что может быть устаревшим. Однако вторая часть предлагает полезное введение в сетевую безопасность и основы реверс-инжиниринга.
Пока я в небольшом отпуске перед выходом на новую работу, ищу себя чем занять. Прошел две части Ori (одна из лучших игр ever), посмотрел пару сериалов, походил в бани и зал. Даже с женой посмотрели пару выпусков "Беремена в 16". И узнал что такое мемы про italian brainrot, мой любимый это crocodilo bombardino.
Но пора потихоньку выходить из такого отпуска. Начинать разминать мозг. Вот подборка крутых книг от сеньора иосера и нашего любимого блогера:
Лучшая альтернатива Танненбауну. Понятное введение в то, как работают современные компьютеры. Книга не перегружена техническими деталями, но помогает глубже понять, что происходит “под капотом”.
Отдельная рекомендация автора. Подробное руководство по внутреннему устройству платформ Apple. Рекомендуется опытным разработчикам, интересующимся такими темами, как загрузчики и ядра. Книги объемные и не подходят для новичков.
Первая часть книги посвящена C и ассемблеру, что может быть устаревшим. Однако вторая часть предлагает полезное введение в сетевую безопасность и основы реверс-инжиниринга.
Please open Telegram to view this post
VIEW IN TELEGRAM
Swiftrocks
Software engineering book recommendations
Bruno's personal list of recommended books about software engineering and iOS development.
Роадмапы и шпаргалки "100 вопросов на собесах в компанию N" — вымерли как формат обучения. EdTech не стоит на месте. Индусы засыпали линкедин топ 1к вопросов, их даже можно посмотреть в наших ресурсах. А чатгпт дает всю базу сразу в лоб.
Рекрутеры ищут самых любопытных. Теперь среди кандидатов выигрывает не тот, кто знает ответ. А тот, кто знает самый полный и глубокий. Чей ресерч был лучше, подходящей и практичней. А мысли сформулированней
Если у вас все еще остались вопросы и хочется структурировать знания по прошлым темам, то я все фиксирую в цикле статей про SwiftUI. Где все в разы детальней разбираю в ноушене. Ведь телеграм не подходит для лонгридов с кодом.
В этой статье я разобрал:
Please open Telegram to view this post
VIEW IN TELEGRAM
Разработка стала командным видом спорта
Этот пост глубже чем кажется
Вы часто слышали эти слова. Время соло контрибьюторов почти закончилось. Компании, которые оценивают тебя за импакт в одной платформе, почти вымерли.
Им уже не важно какой крутой код ты пишешь. Какую архитектуру придумываешь. Сколько юнит-тестов напишешь. Какие алгоритмы используешь.
Она оценивает тебя по командному результату. Как ты помогаешь команде и какой результат приносишь. Представь, что ты играешь в футбол. В нем есть 11 игроков. И каким бы ты лучшим нападающим сезона не был, но тебе не дадут призовые, если твоя команда проигрывает. А ты гонишься только за своей выгодой и мешаешь ей. Тебя не похвалят за митапы, доклады и блоги, если твой продукт вымер.
Это большое заблуждение среди разработчиков — тянуть на себя все одеяло. Опыт доты 2 показывает, что тимплей в снг у нас слабый. Мы все хоть раз разбивали шмотки и фидили курьерами когда были новичками. Но адекватное ли это поведение и станешь ли ты most valuable player? Или же наоборот и ты можешь быть самым расфармленным персонажем, но вам снесли трон. Жиза?
Сила команды сейчас решает больше, чем никогда.
Что мы можем тут сделать? Стараться быть MVP и искать крутые команды.
Поэтому я ставлю доверие и тимплей впереди всего. А ложь всегда сыграет команде в убыток. Не играй на себя в командной игре. Не будь единоборцем в процессе, где важны командные усилия.
Ты можешь закрывать и перезакрывать матрицы компетенций, но их вес аннулируется, если продукт или цели команды не будут впечатляющими
Вы часто слышали эти слова. Время соло контрибьюторов почти закончилось. Компании, которые оценивают тебя за импакт в одной платформе, почти вымерли.
Им уже не важно какой крутой код ты пишешь. Какую архитектуру придумываешь. Сколько юнит-тестов напишешь. Какие алгоритмы используешь.
Она оценивает тебя по командному результату. Как ты помогаешь команде и какой результат приносишь. Представь, что ты играешь в футбол. В нем есть 11 игроков. И каким бы ты лучшим нападающим сезона не был, но тебе не дадут призовые, если твоя команда проигрывает. А ты гонишься только за своей выгодой и мешаешь ей. Тебя не похвалят за митапы, доклады и блоги, если твой продукт вымер.
Это большое заблуждение среди разработчиков — тянуть на себя все одеяло. Опыт доты 2 показывает, что тимплей в снг у нас слабый. Мы все хоть раз разбивали шмотки и фидили курьерами когда были новичками. Но адекватное ли это поведение и станешь ли ты most valuable player? Или же наоборот и ты можешь быть самым расфармленным персонажем, но вам снесли трон. Жиза?
Сила команды сейчас решает больше, чем никогда.
Что мы можем тут сделать? Стараться быть MVP и искать крутые команды.
Поэтому я ставлю доверие и тимплей впереди всего. А ложь всегда сыграет команде в убыток. Не играй на себя в командной игре. Не будь единоборцем в процессе, где важны командные усилия.
Ты можешь закрывать и перезакрывать матрицы компетенций, но их вес аннулируется, если продукт или цели команды не будут впечатляющими
О важности производительности
Приступая к углубленному изучению SwiftUI я много затрагивал такие вещи как производительность и память. Ведь именно они являются бутылочными горлышками. Инженерный подход к обучению сразу помогает подходить к станку и лучше его изучать на реальных проблемах.
Многие начинающие, а иногда и даже опытные, почему-то опускают вопрос важности перфоманса. Они думают, что любой инструмент идеальный и если он допускает просадку или баги — то так и задумано. Ведь разрабатывают эти инструменты разработчики умнее и лучше. А иногда даже делают спорные технические решения и пишут об этом статьи или даже доклады.
Допуская такие серьезные ошибки как запуск приложения после подкачки фичатоглов, что увеличивает время запуска. Избыточную нагрузку на Main Thread. Не следят за расходом батареи и памяти.
Я считаю, что профессионалы высокого уровня должны задумываться об этом почти сразу. Это отличает хорошие решения от плохих. Во многих крупных компаниях даже есть специальные команды Perfomance, которые могут заблокировать раскатку вашей фичи, если вы заметно просадили метрики.
Споры о важности перфоманса мне кажутся довольно таки бесполезными и для меня чаще это очевидная вещь, тк сам я пользуюсь тем приложением, что более быстрее откликается. Но вот автор статьи решил круто разобрать оправдания инженеров, кто не думает о перфомансе и дать контр-аргументы:
🟣 Производительность влияет на такие аспекты, как время отклика, энергопотребление, использование сетевых и дисковых ресурсов. Это напрямую влияет на кол-во лидов и лояльность юзеров.
🟣 Даже крупные компании, такие как Facebook, инвестируют в оптимизацию, поскольку это позволяет сократить расходы на оборудование и улучшить пользовательский опыт.
🟣 Игнорирование производительности может привести к необходимости масштабных переработок в будущем. В прошлой компании даже почти отказались от фреймворка BDUI для WEB, потому что сильно проседал перфоманс.
🟣 Разработка с учётом производительности (performance-aware programming) не требует глубоких знаний ассемблера, но помогает принимать обоснованные решения при проектировании и реализации.
Приступая к углубленному изучению SwiftUI я много затрагивал такие вещи как производительность и память. Ведь именно они являются бутылочными горлышками. Инженерный подход к обучению сразу помогает подходить к станку и лучше его изучать на реальных проблемах.
Многие начинающие, а иногда и даже опытные, почему-то опускают вопрос важности перфоманса. Они думают, что любой инструмент идеальный и если он допускает просадку или баги — то так и задумано. Ведь разрабатывают эти инструменты разработчики умнее и лучше. А иногда даже делают спорные технические решения и пишут об этом статьи или даже доклады.
Допуская такие серьезные ошибки как запуск приложения после подкачки фичатоглов, что увеличивает время запуска. Избыточную нагрузку на Main Thread. Не следят за расходом батареи и памяти.
Я считаю, что профессионалы высокого уровня должны задумываться об этом почти сразу. Это отличает хорошие решения от плохих. Во многих крупных компаниях даже есть специальные команды Perfomance, которые могут заблокировать раскатку вашей фичи, если вы заметно просадили метрики.
Споры о важности перфоманса мне кажутся довольно таки бесполезными и для меня чаще это очевидная вещь, тк сам я пользуюсь тем приложением, что более быстрее откликается. Но вот автор статьи решил круто разобрать оправдания инженеров, кто не думает о перфомансе и дать контр-аргументы:
Please open Telegram to view this post
VIEW IN TELEGRAM
Computerenhance
Performance Excuses Debunked
There are many legitimate arguments to be had about performance, but there are also plain old excuses. It's time to end the excuses.
Топ 3 бесячих приложения
Мнение автора может отличаться от вашего*
У меня iPhone 15 Max, но даже с этим устройством некоторые приложения либо долго загружаются, либо подвисает FPS. Что меня дико триггерит.
Этим постом не пытаюсь поставить чью-то компетентность под сомнения, но просто делюсь тем, что дико не нравится.
1. На первом месте меня бесит выдача в hh.ru. Даже на моем не слабом устройстве есть ощущение при скролле, что кадры куда-то теряются. Все обрывисто и дергано
Кстати, есть слух что это сделано на SwiftUI. Апрувните?
2. Дальше Яндекс Го. Тут конечно скидка на то, что это суперапп и все они неповоротливые и неудобные, но все же очень не хватает скорости, когда нужно заказать такси. Машины у меня нет, и такси я пользуюсь часто, но вот пара секунд на дергания или запуск — часто раздражают
3. Тут я не знал между чем выбрать: мегамаркет, самокат или Яндекс маркет. Записал видео с мегамаркетом, тк иногда он просто не загружает страницу.
К маркету можно подойти снисходительно, его и так ругают часто (возможно из-за BDUI). А самокат вообще сделан на React Native достойно. Но все же отсутствие плавности, фреймдроп, долгая загрузка на мощных устройствах бросается сильно в глаза
Делитесь своими бесячими моментами
Мнение автора может отличаться от вашего*
У меня iPhone 15 Max, но даже с этим устройством некоторые приложения либо долго загружаются, либо подвисает FPS. Что меня дико триггерит.
Этим постом не пытаюсь поставить чью-то компетентность под сомнения, но просто делюсь тем, что дико не нравится.
1. На первом месте меня бесит выдача в hh.ru. Даже на моем не слабом устройстве есть ощущение при скролле, что кадры куда-то теряются. Все обрывисто и дергано
Кстати, есть слух что это сделано на SwiftUI. Апрувните?
2. Дальше Яндекс Го. Тут конечно скидка на то, что это суперапп и все они неповоротливые и неудобные, но все же очень не хватает скорости, когда нужно заказать такси. Машины у меня нет, и такси я пользуюсь часто, но вот пара секунд на дергания или запуск — часто раздражают
3. Тут я не знал между чем выбрать: мегамаркет, самокат или Яндекс маркет. Записал видео с мегамаркетом, тк иногда он просто не загружает страницу.
К маркету можно подойти снисходительно, его и так ругают часто (возможно из-за BDUI). А самокат вообще сделан на React Native достойно. Но все же отсутствие плавности, фреймдроп, долгая загрузка на мощных устройствах бросается сильно в глаза
Делитесь своими бесячими моментами
Пост мотивации с утра написать про дисциплину
С самого первого дня канала я пишу как фокус и как дисциплина дала мне больше, чем вдохновение и мотивация.
В эпоху клипового мышления и зумерских болезней успех на долгосрочной дистанции достигают те, кто просто может лучше сопротивляться навязанным желаниям.
Удивлен, что чаще многого и не нужно. Просто придерживаться планов и своим словам.
Банально, мы с женой ходим в зал уже 6 месяцев регулярно. 3 раза в неделю с тренером, в 8 утра. И какого же наше было удивление как сложно найти тренера который дисциплинировано приходит в 8 утра и не переносит под глупыми отговорками. Казалось бы, режим и методичные упражнения лучше всего воспитывают самоконтроль, но нет. Три тренера подряд начали сачковать, хотя красиво стелили и клялись что они "не такие как предыдущий(ая)" и с их стороны не будет пропусков.
Эти тренера сами себе враги. Они потеряли деньги просто потому, что сами пообещали одно, но не смогли выполнить план. Выигрыли те, кто банально просыпается раньше, тверд в своих словах и поступках. У них и клиентов больше, и их ученики добиваются результатов быстрее.
Мотивация заканчивается на третьей тренировки. На десятом посту в блоге. На пятой задаче в литкоде. На двадцатой странице в книге. На третьем спринте на работе.
Также в ит, в блогерстве и тп. Каждый поставит себе цель «попасть в компанию X» или какую-нибудь другую, но его очередная цель внезапно перебилась другой внезапной целью. Забрасывают на старте, или сдуваются. 80% громких обещаний в СМИ тихо умирают, потому что «появились более важные дела». В итоге, ни одно дело до конца не доведено. А воздух сотрясен.
В эти моменты понимаешь всю силу слов «выполняй обещания и умей доводить дело до конца». Ну и более народное «мужик познается верностью слова»😐
В ит выработать дисциплину ума и защиту от очередной смены фокуса мне сильно помогает литкод или чтение. Конечно, собесы я лучше проходить не стал, так как подготовка к собесам это другая спортивная дисциплина. Но лучше держать фокус при ментальной активности стал.
В многозадачности дисциплина помогает от инверсии приоритетов и гонки данных.
С самого первого дня канала я пишу как фокус и как дисциплина дала мне больше, чем вдохновение и мотивация.
В эпоху клипового мышления и зумерских болезней успех на долгосрочной дистанции достигают те, кто просто может лучше сопротивляться навязанным желаниям.
Удивлен, что чаще многого и не нужно. Просто придерживаться планов и своим словам.
Банально, мы с женой ходим в зал уже 6 месяцев регулярно. 3 раза в неделю с тренером, в 8 утра. И какого же наше было удивление как сложно найти тренера который дисциплинировано приходит в 8 утра и не переносит под глупыми отговорками. Казалось бы, режим и методичные упражнения лучше всего воспитывают самоконтроль, но нет. Три тренера подряд начали сачковать, хотя красиво стелили и клялись что они "не такие как предыдущий(ая)" и с их стороны не будет пропусков.
Эти тренера сами себе враги. Они потеряли деньги просто потому, что сами пообещали одно, но не смогли выполнить план. Выигрыли те, кто банально просыпается раньше, тверд в своих словах и поступках. У них и клиентов больше, и их ученики добиваются результатов быстрее.
Мотивация заканчивается на третьей тренировки. На десятом посту в блоге. На пятой задаче в литкоде. На двадцатой странице в книге. На третьем спринте на работе.
Также в ит, в блогерстве и тп. Каждый поставит себе цель «попасть в компанию X» или какую-нибудь другую, но его очередная цель внезапно перебилась другой внезапной целью. Забрасывают на старте, или сдуваются. 80% громких обещаний в СМИ тихо умирают, потому что «появились более важные дела». В итоге, ни одно дело до конца не доведено. А воздух сотрясен.
В эти моменты понимаешь всю силу слов «выполняй обещания и умей доводить дело до конца». Ну и более народное «мужик познается верностью слова»
В ит выработать дисциплину ума и защиту от очередной смены фокуса мне сильно помогает литкод или чтение. Конечно, собесы я лучше проходить не стал, так как подготовка к собесам это другая спортивная дисциплина. Но лучше держать фокус при ментальной активности стал.
В многозадачности дисциплина помогает от инверсии приоритетов и гонки данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
Воскресная рекомендация
Просиживаю последние дни своего «отдыха». Решил все же перепройти весь The Last of Us.
Освежить память перед выходом второго сезона. Мне первый не понравился. Я не назову его плохим сериалом. Просто игра намного кинематографичней сериала (кек?). Где по опыту интимности и сопереживания могут превзойти только книги.
Начинал я свой «отпуск» с веселой и волшебной Ori. А заканчиваю одним из лучших драматических произведений гениального Дракманна.
Конечно, не последнюю роль играет МУЗЫКА. О ней и этот пост.
https://youtu.be/FzbKCYjoShU?si=9ffins_wiR3TQjNJ
Просиживаю последние дни своего «отдыха». Решил все же перепройти весь The Last of Us.
Освежить память перед выходом второго сезона. Мне первый не понравился. Я не назову его плохим сериалом. Просто игра намного кинематографичней сериала (кек?). Где по опыту интимности и сопереживания могут превзойти только книги.
Начинал я свой «отпуск» с веселой и волшебной Ori. А заканчиваю одним из лучших драматических произведений гениального Дракманна.
Конечно, не последнюю роль играет МУЗЫКА. О ней и этот пост.
https://youtu.be/FzbKCYjoShU?si=9ffins_wiR3TQjNJ
YouTube
О ЧЁМ НА САМОМ ДЕЛЕ THE LAST OF US
А поддержать выход роликов можно сюда: https://boosty.to/dmitryburdukov
Сотрудничество/реклама — [email protected]
Last of Us две части рассказывала нам о том, что у каждого человека есть скелет в шкафу. Даже за самыми благими намерениями зачастую стоят…
Сотрудничество/реклама — [email protected]
Last of Us две части рассказывала нам о том, что у каждого человека есть скелет в шкафу. Даже за самыми благими намерениями зачастую стоят…
This media is not supported in your browser
VIEW IN TELEGRAM
Мы продолжаем инженерно изучать SwiftUI. Мне не нравится тупо читать доки или книги, ведь в них чаще всего не написано и 2/3 всех подводных камней. Никто не будет критиковать свой товар или рассказывать о багах.
А багов в SwiftUI очень много. За 6 лет накопилось столько, сколько хватит на пару недель ежедневных постов. Их все важно знать, чтобы не обосраться при релизе.
Вот и в прошлом посте я, как ворчливый дед, пожаловался на ленту hh.ru. А именно на ее неприятный скролл. В комментах скинули интересный пост.
В нем говорится, что при использовании LazyVGrid внутри LazyVStack в ScrollView в iOS 16 возникают проблемы с отображением и поведением.
Причины проблем:
Скидывайте свои интересные и не очень баги.
Please open Telegram to view this post
VIEW IN TELEGRAM
Метафора технического долга
Всё новое — хорошо забытое старое.
В этом канале я еще не дошел до обсуждения некоторых тем, которые интересны мне и которые мало кто освещал в паблике. Одна из них — это работа с тестами и техническим долгом.
Чем больше команда разработки —> чем больше производство кода —> тем больше нужно процессов для работы с приоритетностью и стабильностью. Объемы некоторой рутины становятся настолько большими, что обычным наймом доп рук сильно не улучшишь картину.
Чем больше компания, тем больше вещей нужно учитывать. На одних крутых анимашках и метале далеко не уедешь. Корпоративный инженер — это высококвалифицированный универсал, который задумывается как сдерживать хаос, экономить на рутине и сократить объемы ручного труда.
В этом вопросе тесты и техдолг отлично помогают.
1. Тема тестов с развитием LLM набирает обороты, но о ней так мало написано в контексте крупной корпоративной разработки. Это очень важный инструмент, который впервую очередь ускоряет время регрессов, а значит релизов и time-to-market.
2. Техдолг. Уметь оставлять важное и убирать второстепенное — один из важнейших навыков. Запуск и формулировка MVP это отдельный скилл. Но в погоне за избыточным упрощением или неуместным усложнением не стоит забывать про такой мощный инструмент как работа с техдолгом.
Вот и в этом видео отличная непопулярная метафора про техдолг (хотя прошло уже 16 лет).
Всё новое — хорошо забытое старое.
В этом канале я еще не дошел до обсуждения некоторых тем, которые интересны мне и которые мало кто освещал в паблике. Одна из них — это работа с тестами и техническим долгом.
Чем больше команда разработки —> чем больше производство кода —> тем больше нужно процессов для работы с приоритетностью и стабильностью. Объемы некоторой рутины становятся настолько большими, что обычным наймом доп рук сильно не улучшишь картину.
Чем больше компания, тем больше вещей нужно учитывать. На одних крутых анимашках и метале далеко не уедешь. Корпоративный инженер — это высококвалифицированный универсал, который задумывается как сдерживать хаос, экономить на рутине и сократить объемы ручного труда.
В этом вопросе тесты и техдолг отлично помогают.
1. Тема тестов с развитием LLM набирает обороты, но о ней так мало написано в контексте крупной корпоративной разработки. Это очень важный инструмент, который впервую очередь ускоряет время регрессов, а значит релизов и time-to-market.
2. Техдолг. Уметь оставлять важное и убирать второстепенное — один из важнейших навыков. Запуск и формулировка MVP это отдельный скилл. Но в погоне за избыточным упрощением или неуместным усложнением не стоит забывать про такой мощный инструмент как работа с техдолгом.
Вот и в этом видео отличная непопулярная метафора про техдолг (хотя прошло уже 16 лет).
YouTube
Debt Metaphor
Ward Cunningham reflects on the history, motivation and common misunderstanding of the "debt metaphor" as motivation for refactoring.
Кстати, почти забыл. Тут 14 число и я обещал что-то важное публиковать в этот день.
Решил, что это будет перезалив в телеграм канал старого выпуска про поиск себя в иженерном мире. Целых полтора часа мы вайбово общались на первой встречи комьюнити почти год назад и кажется нужно ее скоро повторить.
Тема очень важная и актуальная. За год набролось и поменялось многое. Летом я наконец переезжаю в Москву и можем попробовать собраться на первую оффлайн сходку. Как раз соберу к ней обновленный материал.
А пока можете получить доступ по скидке.
Решил, что это будет перезалив в телеграм канал старого выпуска про поиск себя в иженерном мире. Целых полтора часа мы вайбово общались на первой встречи комьюнити почти год назад и кажется нужно ее скоро повторить.
Тема очень важная и актуальная. За год набролось и поменялось многое. Летом я наконец переезжаю в Москву и можем попробовать собраться на первую оффлайн сходку. Как раз соберу к ней обновленный материал.
А пока можете получить доступ по скидке.
📐SwiftUI: Перестраиваем мышление под Layout
Одна из самых частых проблем у начинающих — это понимание Layout'а. Особенно часто с этим сталкиваются те, кто верстал только на UIKit. Ведь переходя на SwiftUI тебе нужно перестроиться и учитывать много новых вводных. Верстка становится больше похоже на WEB, чем на привычную нам мобилку.
Одна из причин следовать совету "Выходи за рамки iOS" 😏
Собрал пару важных советов, которые помогут перестроить мышление:
🌟 Не думай в координатах, думай в контейнерах.
В UIKit ты часто думаешь так: “Кнопку нужно поставить на 20pt ниже текста и выровнять по центру.” Ты буквально “рисуешь на экране”.
В SwiftUI: “Я хочу вертикально разместить текст и кнопку, а между ними немного пространства.” SwiftUI сам решит, где поставить, если ты правильно укажешь что с чем и как они вложены.
🌟 Пиши, будто ты описываешь структуру HTML.
Представь, что это не координаты, а вложенные блоки. HTML работает по тем же принципам:
- Элементы вложены друг в друга.
- Есть блочные (div, section) и встроенные (span, img) элементы.
- Размеры и поведение управляются контейнерами и стилями.
🌟 Изучай, как контейнеры взаимодействуют.
Например, Spacer растягивается и заполняет пространство, а frame может его ограничить. Контейнеры (HStack, VStack, ZStack) — это строительные блоки. Но каждый ведёт себя по-своему, особенно при нехватке или избытке места.
Одна из самых частых проблем у начинающих — это понимание Layout'а. Особенно часто с этим сталкиваются те, кто верстал только на UIKit. Ведь переходя на SwiftUI тебе нужно перестроиться и учитывать много новых вводных. Верстка становится больше похоже на WEB, чем на привычную нам мобилку.
Собрал пару важных советов, которые помогут перестроить мышление:
В UIKit ты часто думаешь так: “Кнопку нужно поставить на 20pt ниже текста и выровнять по центру.” Ты буквально “рисуешь на экране”.
В SwiftUI: “Я хочу вертикально разместить текст и кнопку, а между ними немного пространства.” SwiftUI сам решит, где поставить, если ты правильно укажешь что с чем и как они вложены.
Представь, что это не координаты, а вложенные блоки. HTML работает по тем же принципам:
- Элементы вложены друг в друга.
- Есть блочные (div, section) и встроенные (span, img) элементы.
- Размеры и поведение управляются контейнерами и стилями.
Например, Spacer растягивается и заполняет пространство, а frame может его ограничить. Контейнеры (HStack, VStack, ZStack) — это строительные блоки. Но каждый ведёт себя по-своему, особенно при нехватке или избытке места.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Как я использую ИИ для повышения производительности труда (и почему он не украдет у вас работу)
Наш любимый братишка Bruno Rocha, сеньор из Spotify, рассказывает как юзает AI для увеличения своего перфоманса. Вот несколько тезисов:
🌟 ИИ как помощник, а не замена
Я полностью согласен со многими коллегами, что AI полноценно нас не заменит. Развиваться технически все еще надо. Потому что AI не замена, а множитель нашего скилла. А те, кто говорит про полную замену — далеки от практической разработки.
🌟 Хорошо решает очень простые и конкретные задачи
Сейчас Cursor выполняет много рутины. Да, пусть не идеально, но это уже экономит кучу времени даже с патчингом и правками кода. Это отличная замена StackOverflow
🌟 Хорошо помогает при ресерче неизвестности
Когда например гуглинг помогает при четких и конкрентых целях, то AI помогают при работе с неопределенностью. Если вы не знаете, что ищете, вы можете объяснить ему свою ситуацию, и он укажет вам правильное направление
🌟 Поиск БЫСТРЫХ ответов
Автору становится все труднее и труднее получать быстрые ответы на свои вопросы с помощью Google. Поскольку SEO-оптимизация стала все более важной для выживания в Интернете. Этой проблемы нет в AI агентах. Нет ни вступление для спонсоров, ни раздутый текст с ключевыми словами. Четкий и быстрый ответ
Наш любимый братишка Bruno Rocha, сеньор из Spotify, рассказывает как юзает AI для увеличения своего перфоманса. Вот несколько тезисов:
Я полностью согласен со многими коллегами, что AI полноценно нас не заменит. Развиваться технически все еще надо. Потому что AI не замена, а множитель нашего скилла. А те, кто говорит про полную замену — далеки от практической разработки.
Сейчас Cursor выполняет много рутины. Да, пусть не идеально, но это уже экономит кучу времени даже с патчингом и правками кода. Это отличная замена StackOverflow
Когда например гуглинг помогает при четких и конкрентых целях, то AI помогают при работе с неопределенностью. Если вы не знаете, что ищете, вы можете объяснить ему свою ситуацию, и он укажет вам правильное направление
Автору становится все труднее и труднее получать быстрые ответы на свои вопросы с помощью Google. Поскольку SEO-оптимизация стала все более важной для выживания в Интернете. Этой проблемы нет в AI агентах. Нет ни вступление для спонсоров, ни раздутый текст с ключевыми словами. Четкий и быстрый ответ
Please open Telegram to view this post
VIEW IN TELEGRAM
Swiftrocks
How I'm using AI to improve my software engineering productivity (and why it will not steal your job)
AI has become an important part of my daily software engineering work. Here's how I used it and why it will not steal your job.