Середина лета. Время отпусков и скидок в стиме. Тут просто грех не делать также скидки.
Что вы найдете:
Спасибо всем вам. Вы мотивируете и даете поддержку придумывать еще более прикольные штуки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Эстетика сырого текста в эпоху AI
Поговорим о важном культурном сдвиге. Я заметил, что в эпоху, когда ИИ умеет делать красиво, правильно и гладко это тупо перестаёт быть ценностью. Люди начинают искать неидеальность, трушность, эмоцию.
Очередной пересказ статьи, факт из доки, спор про интерпретации — перестали быть интересными. Люди начали искать живой опыт. Грубый, без ретуши и спецэффектов. Домашний, знакомый и понятный.
80% контента стало стерильным. Все утомились от «слишком правильного», которое не отличаешь от сотен других. Сырые же текста и контент стали более живыми.
Даже с играми и фильмами. Мне стали нравятся твердые четверки, кто не идеален. The Alters, expedition 33, tainted grail. Эти игры имеют уйму минусов, багов, но в них есть много плюсов, которые перевешивают. Они пахнут потом и любовью, а не пугающе белыми стенами больниц.
Я стал любить простоту. Ходить в самые обычные места. Есть самую обычную еду. Пить просто воду.
Мы стали будто жить по правилу «слишком идеально, чтобы быть настоящим».
Возможно, скоро неотредактированный текст станет новым жанром. Как raw photo в инсте или живой звук в музыке.
Люди захотят читать не идеальные тексты, а тексты с дыханием.
Поговорим о важном культурном сдвиге. Я заметил, что в эпоху, когда ИИ умеет делать красиво, правильно и гладко это тупо перестаёт быть ценностью. Люди начинают искать неидеальность, трушность, эмоцию.
Очередной пересказ статьи, факт из доки, спор про интерпретации — перестали быть интересными. Люди начали искать живой опыт. Грубый, без ретуши и спецэффектов. Домашний, знакомый и понятный.
80% контента стало стерильным. Все утомились от «слишком правильного», которое не отличаешь от сотен других. Сырые же текста и контент стали более живыми.
Даже с играми и фильмами. Мне стали нравятся твердые четверки, кто не идеален. The Alters, expedition 33, tainted grail. Эти игры имеют уйму минусов, багов, но в них есть много плюсов, которые перевешивают. Они пахнут потом и любовью, а не пугающе белыми стенами больниц.
Я стал любить простоту. Ходить в самые обычные места. Есть самую обычную еду. Пить просто воду.
Мы стали будто жить по правилу «слишком идеально, чтобы быть настоящим».
Возможно, скоро неотредактированный текст станет новым жанром. Как raw photo в инсте или живой звук в музыке.
Люди захотят читать не идеальные тексты, а тексты с дыханием.
Систем дизайн в деле
Есть огромное минное поле заблуждений по систем дизайну. От "это про нарисовать схему из интернета" до "это про знание паттернов проектирование и архитектур". От "бэкенд систем дизайн отличается от мобильного" до "весь систем дизайн можно зазубрить".
Грамотное проектирование — это впервую очередь диалог. Он не должен быть по шаблону и идет оценка условий. Их нужно менять. Как с ремонтом. Вот вроде решил поменять пол и стены, а вышло тысяча нюансов и мелочей.
У всех компаний свой процесс сисдиза, так он еще и отличается от интервьюера, его опыта, компетентности и задач. Ну невозможно только по статьям и пересказам учесть и сформулировать все нюансы. Даже недавно в чате мы обсуждали, что зацикленность на схеме и спам вопросами — это ред флаг для кандидата. Важна их уместность и точность. Иногда одним точным вопросом можно пройти все собеседование.
Нашел полезное видео, которое пусть и для бэкенда, но очень крутое.
Есть огромное минное поле заблуждений по систем дизайну. От "это про нарисовать схему из интернета" до "это про знание паттернов проектирование и архитектур". От "бэкенд систем дизайн отличается от мобильного" до "весь систем дизайн можно зазубрить".
Грамотное проектирование — это впервую очередь диалог. Он не должен быть по шаблону и идет оценка условий. Их нужно менять. Как с ремонтом. Вот вроде решил поменять пол и стены, а вышло тысяча нюансов и мелочей.
У всех компаний свой процесс сисдиза, так он еще и отличается от интервьюера, его опыта, компетентности и задач. Ну невозможно только по статьям и пересказам учесть и сформулировать все нюансы. Даже недавно в чате мы обсуждали, что зацикленность на схеме и спам вопросами — это ред флаг для кандидата. Важна их уместность и точность. Иногда одним точным вопросом можно пройти все собеседование.
Нашел полезное видео, которое пусть и для бэкенда, но очень крутое.
YouTube
Системный дизайн в деле. Выпуск 1.
Друзья, запускаю новую рубрику на канале - "Системный дизайн в деле"
В первом выпуске разбираем кейс эволюции платежной системы FakePaymentSystemFlow: от монолита до микросервисов.
Разберем:
— Почему монолит начал тормозить развитие
— Какие проблемы вылезли…
В первом выпуске разбираем кейс эволюции платежной системы FakePaymentSystemFlow: от монолита до микросервисов.
Разберем:
— Почему монолит начал тормозить развитие
— Какие проблемы вылезли…
Туториал по Container
Пока одни блогеры утверждают, что контейниризация — это не важно для иос-разрабов... Аудитория же с критическим и аналитическим мышлением уже делает туториалы и использует это в своих приложениях.
Мы уже разбирали в чем разница software developer vs software engineer. А также подробно проходили по виртуализации.
Инженер — это не только про покраску кнопок. Один ограничевается только в своей платформе, а другой использует любые инструменты за ее границами. Автор статьи рассказывает как Containter помогает настроить свое окружение. Статья чуть упрощенная, поэтому я добавлю от себя.
Когда это поможет:
- Ускоряет и упрощает CI/CD-процессы для ios‑разрабов. например, сразу fastlane, swiflint и тп с другими версиями
- изолировать версии в разных окружениях
- тестировать пуши, авторизацию, базы данных с быстрым запуском нужных сервисов.
- настраивать ручные и автотесты за счет мок-сервисов
- проще подготавливать окружение для новичков
- если баги воспроизводятся только на конкретной версии окружения, то ты можешь легко ее собрать
- запуск новых либ или сдк в "чистом" окружении
Полезно выходить за границы мобильных приложений, особенно когда это требует изменчивый рынок.
Пока одни блогеры утверждают, что контейниризация — это не важно для иос-разрабов... Аудитория же с критическим и аналитическим мышлением уже делает туториалы и использует это в своих приложениях.
Мы уже разбирали в чем разница software developer vs software engineer. А также подробно проходили по виртуализации.
Инженер — это не только про покраску кнопок. Один ограничевается только в своей платформе, а другой использует любые инструменты за ее границами. Автор статьи рассказывает как Containter помогает настроить свое окружение. Статья чуть упрощенная, поэтому я добавлю от себя.
Когда это поможет:
- Ускоряет и упрощает CI/CD-процессы для ios‑разрабов. например, сразу fastlane, swiflint и тп с другими версиями
- изолировать версии в разных окружениях
- тестировать пуши, авторизацию, базы данных с быстрым запуском нужных сервисов.
- настраивать ручные и автотесты за счет мок-сервисов
- проще подготавливать окружение для новичков
- если баги воспроизводятся только на конкретной версии окружения, то ты можешь легко ее собрать
- запуск новых либ или сдк в "чистом" окружении
Полезно выходить за границы мобильных приложений, особенно когда это требует изменчивый рынок.
swifttoolkit.dev
The New Container Tool: Docker-free Swift on Linux?
WWDC 2025 brings news also outside Apple platforms
Окей, все посты выше мы говорили о работе SC в общих мазках. Сейчас подойдем к более привычным и простым снарядам. Мы ведь говорили о каких-то компилятарах, ядрах и тп. Но не дошли до самой сути. Так как мой код исполняет на доступной мне абстракции? Зачем были эти прелюдии если мы так и не затронули common сущности и прикладной уровень?
Ну если простыми словами, то у нас есть три ключевых механизма, которые нужно хорошо понимать рядовому работяги:
🎶 Task — это задача, которую нужно выполнить. Я далек от музыки, но допустим это какая-то песня.
🎤 Actor — это объект для работы с задачами. Или же музыкант отдельного инструмента, который играет песню. Например, гитарист.
🧑⚖️ Executor — это механизм, который управляет порядком и исполнением задач. В той же аналогии это дирижер, который управляет, кто и когда играет. В какой момент подключится вокалист, гитарист, басист и тп.
И так: Task — это контейнер для асинхронного кода. Он создаёт фоновую задачу, которая не блокирует основной поток. Actor же это специальный тип изоляции и безопасности, который может гарантировать, что данные не будут меняться из разных задач.
actor Counter {
var value = 0
func increment() {
value += 1
}
}
А вот Executor — это внутренний механизм, который решает где и в каком порядке исполнять таски и акторы. Каждый actor имеет свой serial executor, то есть он выполняет задачи по очереди, одну за одной. Допустим у тебя 3 таски и каждая хочет что-то сделать внутри одного актора. Executor ставит их в очередь и выполняет по одной, даже если все они вызваны одновременно.
Вроде все понятно. Но так ли на самом деле просто и идеально? Не совсем. В след постах поговорим про Reentrancy, hops'ы и перфоманс, nonisolated и другие приколы, которые могут вам сломать исполнение
3/5
Please open Telegram to view this post
VIEW IN TELEGRAM
Блин, за ленивый пост извиняюсь. Набросал пост про «концентрированный опыт» и отдал его чатгпт, решил узнать че скажет. В целом получилось интересно и по содержанию почти так, как я хотел донести, но по подаче конечно супер пресно. Поделюсь ответом с вами, а нормальный пост как-нибудь позже напишу:
——————-
——————-
«Концентрированность опыта важнее количества лет и суммы в оффере»
или
«Где вырастает настоящий сеньор? В деньгах или в деле?»
⸻
💡 Ключевые идеи, которые можно раскрыть:
1. Концентрированность опыта vs Количество лет
• Пример: у двух людей по 5 лет опыта. Один — писал UI-фичи и фиксил баги, другой — запускал 3 проекта с нуля, внедрял CI/CD, строил архитектуру.
• 👉 Первый “набрал время”, второй — сжал опыт в концентрат.
• Формулировка: “Опыт – это не часы, проведённые в коде. Это задачи, которые требовали от тебя расти.”
⸻
2. Цена опыта и окупаемость
• Вставь понятие «опыт как инвестиция»:
• Проект без вызовов = “депозит под 2%” (низкий рост).
• Проект с болью, сложностями и ростом = “венчур” — сначала тяжело, потом x3.
Метафора: «Ты не на зарплату работаешь, а на апгрейд себя.»
⸻
3. Короткие фичи vs Большие системы
• Проекты на 1 спринт не дадут тебе знания работы с техническим долгом, масштабированием, поддержкой, интеграциями.
• Проекты на кварталы формируют скиллы, которые не прочитать в туториале.
👉 Задай вопрос читателю: «Вы когда-нибудь доживали до последствий собственных решений через 6–12 месяцев?»
⸻
4. Что такое “бесперспективный оффер”
• Деньги — не всегда сигнал “ты хорош”.
• Иногда это компенсация за рутину, токсичность, отсутствие роста, или необходимость “заткнуть дыру”.
• Идея: “Не каждая высокая зарплата — это признание. Иногда — это капкан.”
⸻
5. Продажа себя дороже
• Опиши идею: если сейчас ты работаешь на то, чтобы через год стоить дороже — ты на правильном пути.
• Пример: ты изучаешь GraphQL, учишь DevOps-практики, внедряешь архитектурные подходы — всё это капитал.
⸻
6. Роль ментальности и амбиций
• Некоторые “работают в IT”, а другие — “строят карьеру в инженерии”.
• Покажи разницу: первые просто кодят задачи, вторые — растут стратегически.
⸻
🧩 Завершающая мысль
Можно закончить вот так:
“Концентрированность опыта — это когда ты идёшь не по количеству строк кода, а по качеству вызовов, которые ты принял. Не каждый год делает тебя сильнее. Но каждый проект может — если ты выбрал его осознанно.”
This media is not supported in your browser
VIEW IN TELEGRAM
Кстати, завтра будет репортаж корпоратива Яндекса из БАНИ
Неоспоримая база от любимого автора
Наш любимый блогер, а также автор лучшей книги 2024 года для инженеров, дал инфу о базе базовой.
1. Чем больше кода, тем больше багов. Чем больше приложение, тем сложнее делать его качественно.
2. Код - это для людей. Писать код сложнее там, где его читают. Чем больше разрабов в проекте, тем важнее его читабельность и понятность.
3. Архитектура - это про удобство. Чем сложнее, тем хуже.
Даже во времена AI эти правила не меняются
Наш любимый блогер, а также автор лучшей книги 2024 года для инженеров, дал инфу о базе базовой.
1. Чем больше кода, тем больше багов. Чем больше приложение, тем сложнее делать его качественно.
2. Код - это для людей. Писать код сложнее там, где его читают. Чем больше разрабов в проекте, тем важнее его читабельность и понятность.
3. Архитектура - это про удобство. Чем сложнее, тем хуже.
Даже во времена AI эти правила не меняются
X (formerly Twitter)
Gergely Orosz (@GergelyOrosz) on X
"Fundamental" truths about software:
- Code is liability
- The more code you have, the more bugs you tend to have
- The more complex a system, the more important architecture becomes
- Writing maintainable code is a lot more effort than just getting it…
- Code is liability
- The more code you have, the more bugs you tend to have
- The more complex a system, the more important architecture becomes
- Writing maintainable code is a lot more effort than just getting it…
This media is not supported in your browser
VIEW IN TELEGRAM
Save the date: 29 июля, 19:00
Очень советуем сходить на Avito Mobile meetup в московский офис Авито (для тех, кто не в столице, будет опция онлайна). В программе 2 доклада и дискуссия со спикерами из Авито, Яндекса и Озона. Что собираются рассказывать и обсуждать:
➡️ Профит и риски от кэширования для приложений;
➡️ Quality-атрибуты, на которые кэширование влияет;
➡️ Как писать на BDUI, как на полноценном языке;
➡️ Нужно ли лимитировать разработчиков в рамках дизайн-системы или же позволять делать всё;
➡️ Когда нужно использовать native, а когда – BDUI.
❗️ Не забудьте зарегистрироваться по ссылке, ближе к дате может не остаться мест.
Очень советуем сходить на Avito Mobile meetup в московский офис Авито (для тех, кто не в столице, будет опция онлайна). В программе 2 доклада и дискуссия со спикерами из Авито, Яндекса и Озона. Что собираются рассказывать и обсуждать:
Please open Telegram to view this post
VIEW IN TELEGRAM
Гонка за концентрированностью опыта
У одного тимлида в блоге я увидел пост в стиле
Этого менеджера можно легко понять, когда понимаешь что в их компании зафризили найм... Изменится ли риторика в фазе активного роста и активных запусков? Время покажет. Но у меня другой вопрос что скажут их деврелы, когда их работу по привлечению лучших так легко обесценили? Или это хитрый пост для конкурентов?
Почему я думаю что в ит такой путь развития не выгоден? Давайте по пунктам:
1. Знания быстро устаревают, и ценность на рынке падает. Вот я пишу про SUI и Async/Await сейчас не просто так, а потому что людей, кто решает задачи на собесах с помощью GCD разворачивают по причине "знает слишком архаитчный стэк". Ценят не твой опыт на пет-проектах, а реальный и боевой. Особенно, если он помог твоему продукту принести бизнес ауткамы и выгоду.
2. Пересмотр зарплаты. Окей, возможно ты не хочешь уходить. Тогда может быть рост зарплаты внутри компании быстрее чем инфляция на рынке? Сомневаюсь. Даже если тебе сейчас комфортно текущий менеджер с текущей политикой может уйти через 2-3 года и придет более голодный и амбициозный менеджер, который может посчитать что вы "слишком тихие".
Я понимаю, почему такие сотрудники удобны менеджерам: они стабильны, не спорят, не увольняются. Но с точки зрения самого инженера это путь к невидимости. В IT растет тот, кто проявляет инициативу: пробует новое, предлагает решения, прокачивает навыки. Без этого легко застрять на одном уровне, пока мир идёт вперёд. Рынок любит тех, кто развивает глубину или ширину но не тех, кто стоит на месте.
Что я хочу сказать?
Расти не нужно всем. Это нормально, что мы этого не хотим. Но:
1. Если ты инженер, то ты должен понимать все риски
2. А если ты менеджер, то должен понимать риски, когда даешь людям советы "сидеть тихо, не рисковать, не проявлять инициативу и не выделяться". Ведь спустя пару лет твои подчиненные не смогут найти работу, когда ты скорее всего найдешь себе новую.
Остаться в IT без роста — это как стоять на эскалаторе, который едет вниз. Да, стабильные, тихие инженеры удобны в фазе стагнации. Но рынок, технологии и команды выигрывают от тех, кто растет. И инженер выигрывает тоже. Если твой продукт приносит больше, то и твои условия улучшаются.
Это Win-Win стратегия
У одного тимлида в блоге я увидел пост в стиле
"не нанимайте звезд, берите тех, кто не хочет х2 зп и не ищет челенджи, не выступает на конфах и не придумывает новые архитектуры. Инженера, кто не хочет расти и молча делает свою работу на одном грейде без амбиций роста — сложнее найти"
Этого менеджера можно легко понять, когда понимаешь что в их компании зафризили найм... Изменится ли риторика в фазе активного роста и активных запусков? Время покажет. Но у меня другой вопрос что скажут их деврелы, когда их работу по привлечению лучших так легко обесценили? Или это хитрый пост для конкурентов?
Почему я думаю что в ит такой путь развития не выгоден? Давайте по пунктам:
1. Знания быстро устаревают, и ценность на рынке падает. Вот я пишу про SUI и Async/Await сейчас не просто так, а потому что людей, кто решает задачи на собесах с помощью GCD разворачивают по причине "знает слишком архаитчный стэк". Ценят не твой опыт на пет-проектах, а реальный и боевой. Особенно, если он помог твоему продукту принести бизнес ауткамы и выгоду.
2. Пересмотр зарплаты. Окей, возможно ты не хочешь уходить. Тогда может быть рост зарплаты внутри компании быстрее чем инфляция на рынке? Сомневаюсь. Даже если тебе сейчас комфортно текущий менеджер с текущей политикой может уйти через 2-3 года и придет более голодный и амбициозный менеджер, который может посчитать что вы "слишком тихие".
Я понимаю, почему такие сотрудники удобны менеджерам: они стабильны, не спорят, не увольняются. Но с точки зрения самого инженера это путь к невидимости. В IT растет тот, кто проявляет инициативу: пробует новое, предлагает решения, прокачивает навыки. Без этого легко застрять на одном уровне, пока мир идёт вперёд. Рынок любит тех, кто развивает глубину или ширину но не тех, кто стоит на месте.
Что я хочу сказать?
Расти не нужно всем. Это нормально, что мы этого не хотим. Но:
1. Если ты инженер, то ты должен понимать все риски
2. А если ты менеджер, то должен понимать риски, когда даешь людям советы "сидеть тихо, не рисковать, не проявлять инициативу и не выделяться". Ведь спустя пару лет твои подчиненные не смогут найти работу, когда ты скорее всего найдешь себе новую.
Остаться в IT без роста — это как стоять на эскалаторе, который едет вниз. Да, стабильные, тихие инженеры удобны в фазе стагнации. Но рынок, технологии и команды выигрывают от тех, кто растет. И инженер выигрывает тоже. Если твой продукт приносит больше, то и твои условия улучшаются.
Это Win-Win стратегия
Следите за пальцами.
- Я родился в семье учителей и обучать мне всегда нравилось. Так почти 5 лет назад я стал ментором на solvery (сейчас эта страница чисто для сео-оптимизации)
- после был преподом в нескольких школах программирования как яндекс.практикум, грейд и цифровые привычки
- дальше я запустил этот канал
- после я создал приложение "симулятор иосника" и мы стали в топ 5 апстора.
- после мы создали бусти с закрытым комьюнити, потому что до этого было открытое и много флуда. Мы закрылиьс и за 1,5 года мы собрали сотни задач, материалов и знаний от реальных практикующих экспертов.
- Стали самым большим комьюнити реальных практиков, где разбирают не вход в ит и собесы, а реальные практики.
Что дальше? Спустя два года после релиза симулятора я решил сделать апгрейд. По последним постам о челенджах и разнице между software developer vs software engineer мы пришли — что инженер не ограничивается одной платформой. Мобильное приложение и бусти, пусть это и копируют конкуренты, имеют ряд существенных минусов. Во-первых, это низковисящие фрукты, додуматься и сделать это не нужно много скилла. Во-вторых, банально в мобильном приложении никто не кодит, это плохой UX/UI. Никто не проводит собесы через телефон, никто не кодит через телефон.
Поэтому я решил расти и уже год вынашиваю идею эволюционировать. Сделать не просто то, что может сделать другой. А выйти на новый уровень. Бустануться и апгрейднуться.
Я хочу запустить свой сайт для:
И многое другое
Во многом я подсмотрел идеи у neetcode и литкод, но это будет про наш рынок и наши правила. Я хочу сформулировать то, что копилось годами и обрело максимально практичную форму.
Это конечно не быстрый путь, но точно полезный.
Please open Telegram to view this post
VIEW IN TELEGRAM
Что мотивирует сильнее: Сильная команда, сильный продукт или высокий оффер?
Июль. Год перевалил за экватор. Середина года - это такой мидлпоинт, где у многих начинаются вопросы к своей карьере. Ко мне уже пришло пару человек с вопросами менторства и у всех один запрос "Я не знаю как развиваться. У меня нет мотивации". (напомню, менторством я не занимаюсь)
Какой бы у тебя не был крутой ИПР и продукт, но этого мало для развития. Все зависит не только от нас, но и среды, где мы находимся. Из сотен миллиард планет жизнь зародилась на земле из-за миллионов случайных событий.
Мое менторство вам не нужно) Перечитываю отдельные главы любимой книги прошлого года The Software Enginner's Guidebook. Почитайте эту книгу. Есть отличная главая про поиск и развитие себя. Я уже писал про эту главу и Саша Сычев верно подметил про роль руководителя в комментах.
Давайте чуть глубже разберем важность внешних обстоятельст и как правильно их оценивать:
1️⃣ Как выбирать команду. Сильная команда > сильный продукт. Хорошая команда слаженно справляется даже с трудными задачами. Плохая команда может утопить даже отличный проект и заруинить все бюджеты с ресурсами. Обращай внимание на культуру: доверие, открытость к обратной связи, поддержка роста.
Ты будешь развиваться быстрее в команде, где работают сильные инженеры и здоровая культура
2️⃣ Как выбирать руководителя. Менеджер — это важнейший фактор твоего роста. Хороший руководитель помогает прокладывать путь к новым уровням, дает полезную обратную связь, защищает тебя от лишней политики.
Я всегда стараюсь осознанно подходить к выбору менеджера и чаще матч с ним важнее плюсов к офферу.
3️⃣ Внешние обстоятельства: стек, продукт, контекст. Даже сильная команда не спасёт, если продукт скучный, не вызывает интереса. В компании нет зрелых процессов и всё горит и рушится. Вокруг недоделанные вечные мвп-решения, которые хрупкие и рушатся. А никто вокруг не понимает что делает и зачем.
Все эти пункты очень неочевидны. Иногда высокий оффер затмевает другие сигналы. Через пол года оффер перестанет мотивировать и тогда остается только искусственно поднимать усталость и вялость. Чтобы этого не произошло стоит осознанно подходить к выбору своей работы.
Июль. Год перевалил за экватор. Середина года - это такой мидлпоинт, где у многих начинаются вопросы к своей карьере. Ко мне уже пришло пару человек с вопросами менторства и у всех один запрос "Я не знаю как развиваться. У меня нет мотивации". (напомню, менторством я не занимаюсь)
Какой бы у тебя не был крутой ИПР и продукт, но этого мало для развития. Все зависит не только от нас, но и среды, где мы находимся. Из сотен миллиард планет жизнь зародилась на земле из-за миллионов случайных событий.
Мое менторство вам не нужно) Перечитываю отдельные главы любимой книги прошлого года The Software Enginner's Guidebook. Почитайте эту книгу. Есть отличная главая про поиск и развитие себя. Я уже писал про эту главу и Саша Сычев верно подметил про роль руководителя в комментах.
Давайте чуть глубже разберем важность внешних обстоятельст и как правильно их оценивать:
1️⃣ Как выбирать команду. Сильная команда > сильный продукт. Хорошая команда слаженно справляется даже с трудными задачами. Плохая команда может утопить даже отличный проект и заруинить все бюджеты с ресурсами. Обращай внимание на культуру: доверие, открытость к обратной связи, поддержка роста.
Ты будешь развиваться быстрее в команде, где работают сильные инженеры и здоровая культура
2️⃣ Как выбирать руководителя. Менеджер — это важнейший фактор твоего роста. Хороший руководитель помогает прокладывать путь к новым уровням, дает полезную обратную связь, защищает тебя от лишней политики.
Я всегда стараюсь осознанно подходить к выбору менеджера и чаще матч с ним важнее плюсов к офферу.
3️⃣ Внешние обстоятельства: стек, продукт, контекст. Даже сильная команда не спасёт, если продукт скучный, не вызывает интереса. В компании нет зрелых процессов и всё горит и рушится. Вокруг недоделанные вечные мвп-решения, которые хрупкие и рушатся. А никто вокруг не понимает что делает и зачем.
Все эти пункты очень неочевидны. Иногда высокий оффер затмевает другие сигналы. Через пол года оффер перестанет мотивировать и тогда остается только искусственно поднимать усталость и вялость. Чтобы этого не произошло стоит осознанно подходить к выбору своей работы.
Modern Mutex
Я уже писал, что пару моих знакомых сеньоров заворачивали на собесах за "несовременность".
Им отказывали ответами "решил классическую задачу архаичным GCD". Комментировать адекватность таких решений я не могу, но это говорит, что нужно тратить немного своего внимания на хайповые и зумерские штуки. Даже если вы никогда их не затроните в проде из-за тяжести легаси🫣
Из-за чего могут посчитать GCD критически вредным легаси и архаичным? Мы не будем пока глубоко погружаться в Swift 6 и Sendable, но попробуем вкратце, что использование очередей GCD и объявления типов как @unchecked Sendable может часто работать, но смешение GCD с Swift Concurrency — потенциальный источник проблем.
Для этого многие авторы в сети предлагают использовать swift-concurrency-ориентированный подход. С использованием Synchronization Framework. Относительно недавно вот вышел новый Mutex. Чем он отличается от привычного нами Lock? Ну там нет прямого lock()/unlock(), а вместо этого withLock
Зачем он нужен и когда поможет?
- он более совместим с легаси кодом. Он сам является Sendable, поэтому можно безопасно оборачивать не‑Sendable типы, такие как NSBezierPath, Array и т.п.
- Дает синхронный доступ без async/await
- Меньше накладных расходов по сравнению с actor
Полезные ссылки:
- Modern Swift Lock: Mutex & the Synchronization Framework
- Synchronous Mutual Exclusion Lock 🔒
- Mutex in Swift Lang
Я уже писал, что пару моих знакомых сеньоров заворачивали на собесах за "несовременность".
Им отказывали ответами "решил классическую задачу архаичным GCD". Комментировать адекватность таких решений я не могу, но это говорит, что нужно тратить немного своего внимания на хайповые и зумерские штуки. Даже если вы никогда их не затроните в проде из-за тяжести легаси
Из-за чего могут посчитать GCD критически вредным легаси и архаичным? Мы не будем пока глубоко погружаться в Swift 6 и Sendable, но попробуем вкратце, что использование очередей GCD и объявления типов как @unchecked Sendable может часто работать, но смешение GCD с Swift Concurrency — потенциальный источник проблем.
Для этого многие авторы в сети предлагают использовать swift-concurrency-ориентированный подход. С использованием Synchronization Framework. Относительно недавно вот вышел новый Mutex. Чем он отличается от привычного нами Lock? Ну там нет прямого lock()/unlock(), а вместо этого withLock
private let count = Mutex<Int>(0)
count.withLock { $0 += 1 }
Зачем он нужен и когда поможет?
- он более совместим с легаси кодом. Он сам является Sendable, поэтому можно безопасно оборачивать не‑Sendable типы, такие как NSBezierPath, Array и т.п.
- Дает синхронный доступ без async/await
- Меньше накладных расходов по сравнению с actor
Полезные ссылки:
- Modern Swift Lock: Mutex & the Synchronization Framework
- Synchronous Mutual Exclusion Lock 🔒
- Mutex in Swift Lang
Please open Telegram to view this post
VIEW IN TELEGRAM
Apple Developer Documentation
Synchronization | Apple Developer Documentation
Build synchronization constructs using low-level, primitive operations.
What is Mobile System Design?
В чем ключевое отличие мобильного сисдиза от бэкенда? Я не сразу стал мобильным разрабом. До этого я писал пару лет сайты на php, node.js, немного на go. Потом был react и react native разрабом и только потом стал iOS. Сюда я пришел по любви и здесь мне нравится.
Насмотренность и опыт мне помогает сравнить несколько платформ на разных уровнях. И часто я вижу многие заблуждения когда инженеры живут только в одной платформе и в своем вакууме. Одно из таких заблуждений "Что такое System Design?".
Хороший ответ дает второй мой любимый автор Tjeerd in 't Veen, автор книги Mobile System Design, регулярно генерит отличный контент. В своей статье он разбирает отличную тему "что такое мобильный систем дизайн?".
Я много раз писал, что вокруг неё много заблуждений. Системный дизайн - это отдельная дисциплина, которую невозможно понять без реальной практики на крупных проектах. Это как отдельная категория водительских прав.
Все нюансы не соберешь. Чтение статей и просмотр видосов — полезно, но недостаточно. Это как учить язык только по книгам и видеоурокам. Без разговорной практики ты не начнёшь по-настоящему понимать носителей и хорошо звучать.
В отличие от бэкенд архитектур — мобильные имеют ряд ключевых отличий:
🟣 оффлай, синхронизация данных, пуши, диплинки, модульные кодовые базы, кроссплатформенность, постоянные изменения продукта и операционной системы.
🟣 UI фреймворки. Мы уже знаем что выбираем SwiftUI для простых экранов, а UIKit для сложных.
🟣 Релизы и раскатки. Мобильная апка — это один бинарник на устройствах, который нельзя быстро отменить после установки (либо заранее сильно проработав этот момент). Это требует высокого качества перед релизом, тк ты не откатишь предыдущую сборку.
🟣 Архитектура растет не по числу пользователей, а по количеству фич и команд, участвующих в проекте. Это приводит к необходимости модуляризации и новой организационной координации
🟣 При большом количестве пользователей даже мелкая ошибка может повлиять на сотни тысяч человек
Мобильный сисдиз — это впервую очередь проектирования работы приложения под его особенности и жизненный цикл. Это другая дисциплина. Она фокусируется на нюансах релиза, ресурсов, работы мобильных приложений. И чем больше ваше приложение, тем больше нужно учитывать и тем больнее ошибки.
В чем ключевое отличие мобильного сисдиза от бэкенда? Я не сразу стал мобильным разрабом. До этого я писал пару лет сайты на php, node.js, немного на go. Потом был react и react native разрабом и только потом стал iOS. Сюда я пришел по любви и здесь мне нравится.
Насмотренность и опыт мне помогает сравнить несколько платформ на разных уровнях. И часто я вижу многие заблуждения когда инженеры живут только в одной платформе и в своем вакууме. Одно из таких заблуждений "Что такое System Design?".
Хороший ответ дает второй мой любимый автор Tjeerd in 't Veen, автор книги Mobile System Design, регулярно генерит отличный контент. В своей статье он разбирает отличную тему "что такое мобильный систем дизайн?".
Я много раз писал, что вокруг неё много заблуждений. Системный дизайн - это отдельная дисциплина, которую невозможно понять без реальной практики на крупных проектах. Это как отдельная категория водительских прав.
Все нюансы не соберешь. Чтение статей и просмотр видосов — полезно, но недостаточно. Это как учить язык только по книгам и видеоурокам. Без разговорной практики ты не начнёшь по-настоящему понимать носителей и хорошо звучать.
В отличие от бэкенд архитектур — мобильные имеют ряд ключевых отличий:
Мобильный сисдиз — это впервую очередь проектирования работы приложения под его особенности и жизненный цикл. Это другая дисциплина. Она фокусируется на нюансах релиза, ресурсов, работы мобильных приложений. И чем больше ваше приложение, тем больше нужно учитывать и тем больнее ошибки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Mobilesystemdesign
What is Mobile System Design?
What is Mobile System Design? Learn how system design applies to modern mobile apps, why it matters, and what makes it different from backend system design.
В какой момент вы обсуждаете аналитику при разработке?
Anonymous Poll
31%
Обязательно до начала разработки. Это очень важно как для продукта, так и для тех.решений
27%
Стараемся до начала разработки, но важность исключительно продуктовая
8%
Когда как. Нам без разницы
12%
Чаще в конце разработки, но хотим в начале
11%
Чащк в конце и норм
7%
Вообще не думаем об аналитике
3%
Другое
Небольшой ликбез по терминологиями. Часто слышу "другой контекст, изоляция", и поэтому хочется этот момент убрать.
Одна из ключевых концепций Swift Concurrency — это изоляция. Впервые о ней сказали с темой акторов в SE-0306:
Actors protect their state through data isolation, ensuring that only one task can interact with that state at a time.
Что это значит? Isolation — это механизм, с помощью которого акторы защищают состояние, и дают доступ к нему только одной таске в момент времени. Это и есть основа потокобезопасности в новой модели.
Каждый актор имеет serial очередь из тасок. Любые async-методы актора автоматически ставятся в очередь и выполняются по одному. Мы уже помним, что в рантайме при вызове await создается таска и кладется в очередь актора. Рантайм гарантирует, что только одна задача исполняется внутри актора в любой момент времени. Это делается через Cooperative Task Scheduler.
isolated контекст — это когда мы внутри актора. non-isolated context — это все за границами актора: код вне, статические методы, любые другие акторы и тп. Чтобы попасть внутрь другого контекста нужно дождаться очереди через await. Условно как охраник, которые требует пропуск перед входом.
Есть еще специальная пометка nonisolated. такой метод не зависит от изоляции. Он может вызываться из любого потока, без await, не выполняется через очередь актора и не имеет доступа к изолированным свойствам.
Но использовать nonisolated нужно аккуратно если :
В следующем посте поговорим про чекеры и Swift 6
Полезные ссылки:
- SE-0306 – Actors
- Isolation, actors, sendable… a concurrency deep dive
4/5
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM