Ну что, я полноценно переехал в Москву.

Можете поздравить счастливого обладателя IT-ипотеки на 30 (28) лет 🥲

Для меня это большой шаг, который точно повлияет и на жизнь, и на контент.

Я переезжал уже много раз. Но именно в Москву готовился лет восемь. Из маленького посёлка в Казахстане с населением 900 человек, самостоятельно мигрировал поэтапно, пройдя путь трех столиц (Тюмень - столица деревень). Мне всегда было интересно насколько далекий будет путь от стартовой точки.

Он был длинным и непростым. Чаще «вопреки», чем «благодаря». Никогда не брал кредитов, не просил денег у родителей и не занимал у друзей. Поэтому ипотека на много лет это серьёзная ответственность, которую сполна чувствую.

Удивляет, что среди некоторых инфоцыган бытует мнение, если у тебя ипотека, то ты лох. Типа, вот тебе чудокурс по заработку, и никакие кредиты не нужны. Только заплати мне и вылезешь из проблем.

Бред. Не стоит стесняться своей ответственности и решительности. Взять на себя обязательство и дисциплинированно выплачивать долг. Это требует мужества.

А не как в недавних твитерских новостях: блогеры берут деньги у друзей, не отдают, но зато гордо заявляют — «зато не в ипотеке и кредитах» 🤡 не ведитесь на поводу у инфантильных блогеров, которые на грани уголовного дела.

У меня есть обязательства и я этого не стесняюсь. не покупаю чудо-курсы, не верю в лёгкий путь. просто понимаю, что теперь придётся пахать ещё больше.

Это и мотивирует потому что отступать уже некуда.

И вы не стесняйтесь своих ипотек:) Ответственность это не слабость, а сила

Финальная ли это точка? Я думаю стартовая

Software 3.0

Сорок минут базы.

Короче, вся эта тема с промтпрограммированием обсуждается еще с 2014 иконой для AI инженеров — Андреем Карпатовым, ex-директор AI в тесла и фаундер крутых продуктов.

О чем пост? Чувак прославился скиллом уметь объяснять сложные вещи простым языком. Ввел такие понятия:

🟣Software 1.0 — люди пишут код вручную.

Минус такого подхода в тяжелой формализации сложных задач.

🔘Software 2.0 — программирование через данные.

Например мы вместо написания кода отдаем нейросети кучу инфы и она сама учится писать код.

Минусы: обучать модели очень дорого самому. И не понятно как мыслит модель.

🔴Software 3.0 - программирование с помощью нейросети

Тут находимся мы. Появились уже обученные нейросети.

Представь, ты уже написал руку на рядовых задачах сотни раз. Устал придумывать что-то новое. Вот в это время нейросеть просто экономит рутину. А еще у открытой нейросети можно спросить как она сделала выводы.

Программист уже вместо очередной рутинной задачи, где не нужно думать и изобретать велосипеды, экономит время всем. Выделяя время на задачи, с которыми не справится нейросеть.

Вас это не делает тупыми. Вас это просто избавляет от лишней нагрузки.

P.S. Заметил забавную вещь:
Те, кто бездумно читают статьи и принимают все на веру, часто обвиняют «вайбкодеров» в том, что они бездумно доверяют коду от ИИ.

Но сама идея «слепо верить» для меня странная. Неважно, откуда приходит информация от нейросети, из статьи или с твиттера… это все всегда нужно проверять.

Кажется, проблема не в ИИ, а в том, что некоторые люди просто не привыкли проверять и практиковаться. Они просто сменили источник веры: раньше блог, теперь нейросеть.

Вера — лишнее слово в разработке. Нельзя на вере построить дом или заставить самолет летать. Есть только доверие в команде, у которого должна быть высокая цена.

У практикующих инженеров недоверие развито с опытом. Начиная от использования чужих библиотек, заканчивая всякими договоренностями 😂 о нем не нужно напоминать

Цикл статей про Swift Concurrency: Введение

Начинаю новый цикл статей с разбором Swift Concurrency в доступном для новичков и полезным продвинутым. В нем по традиции хочется собрать самому практически полезные вещи.

Регулярно в чате мы штормим самые интересные и важные технические вопросы. Фильтруем мусор и пользу. Хочется самый полезный набор статей, задач и материалов, которые не просто копипаст из чужих статей. А сконцентрированный и отревьюинный опыт сотни практикующих инженеров.

Другие циклы:
- Цикл про систем дизайн
- Цикл про память
- Цикл про SwiftUI

🧬 Получить доступ к разделу и тонны другого контента от сообщества можно 💰тут или ⭐️ тут

📺 Swift Concurrency: В каком порядке смотреть WWDC

Проблема всех телеграм каналов, блогов, твитторов — отсутствие системы. Чаще это посты, которые по рефлексу или по реакциям пишут интересные им темы, пересказывают чужие посты, реагируют на новости первыми ради репостов. Это хорошо работает как медиа, но не работает как источник обучения.

В такой методике легко получить клиповое мышление и отрафировать скилл композиции материала. Где старт и где финал особо не поймешь в ленте постов. Вся усвоенная инфа становится калейдоскопом рандомных фактов. Моя же цель делать изучение структурным и понятным (прям как Structured Concurrency 🤤). Последовательным. С понятным началом и концом...

Любые методики обучения учат, что не важно как ты круто сияешь подкопотными знаниями и неизвестными трюками. Если в этом нет системы, то это просто гонка теориков блеснуть эрудицией без крепкого фундамента и понимания границ практики. Такое может забрать время и внимание с по-настоящему полезных на работе вещей. Как говорится, сила в простоте, а ненужный шум лишь отвлекает от главного. Всю сложность нужно упрощать, инкапуслировать, а наружу отдавать понятное апи.

Продолжаем погружаться системно в изучение Swift Concurrency. В прошлом посте мы поняли какие proposals нам читать, а теперь идем в сторону WWDC. Че же надо посмотреть и в каком порядке?

1️⃣ Фаза 1: Hello, Swift Concurrency

Meet async/await in Swift. Самый первый видос про эпоху SC. Тут вкратце рассказывают про проблемы кода на GCD и как async/await помогает избежать забытые completion (кстати, забытыми completion в guard часто подлавливают на собесах)

Explore structured concurrency in Swift. Тут можно хорошо понять почему и для чего вообще вся эта движуха. Мне больше нравится не попсовая формулировка "это просто лучше читать", а что "теперь мы лучше знаем время жизни потока управления, памяти функций и переменных". Звучит осознанней и практичней.

Protect mutable state with Swift actors. Ну тут нам конкретно помогают понять проблемы Data Race на примере всем известного Counter'а, ImageLoader'а. Вы ищите хорошие формулировки для чего же нам акторы, изоляции, Actror Reentrancy, Main Actor.

В отдельных постах пройдемся по практическим точкам каждых секций.

How to measure productivity part 2

Время перфоманс ревью и начало следующего полугодия. Тут есть отличный шанс понять что улучшить за прошлый период и начать планировать следующий.

Мы уже обсуждали очень важную статью про output’ы и outcome’ы. Но правила перфоманс ревью каждую калибровку меняются. Они не стоят на месте.

Вкратце, коммерческая разработка сильно изменилась в оценке инженеров:
- перестали оцениваться только колличественные метрики как пуллреквесты, коммиты и часы
- каждая техническая цель должна аргументироваться с позиции пользы для бизнеса
- разрабы стали более осознанны в следующих шагах

Это очень важно. Помню как в одной компании ребята внедряли KMP и у них вроде было много работы, но ауткамов не было. В итоге их работы чуть ли не приняли за вредную и не поставили «ниже ожиданий». Поэтому нужно понимать ясно туда ли вы гребете.

Я тоже начал планировать следующие полгода. Идей очень много, но фильтровать их помогают разные метрики. Вот интересные статьи:

🌟Как измерять качество. Очень важная статья про метрики качества. Автор статьи говорит про повышения тимлидам и сеньорам благодаря им:)

🌟Результаты 25000 перфоманс ревью. Интересные наблюдения и выводы на основе многих данных.

🌟Perfomance review в Microsoft. Интересный опыт про эксперименты с перфоманс ревью в майкрософт

Типичные списки 75 задач из Литкода

Нашел в сети пост про список интересных задач.

В интернетах есть куча разных списков задач, которые все ОБЯЗАНЫ прорешать перед тем как идти на интервью. Опять же, решать наугад задачи — не иметь структуры и плана, а значит терять время. Think about it 😏

Самые известные из них:

Top Interview 150
Blind 75
LeetCode 75
NeetCode 150

Эти списки охватывают основную часть паттернов, алгоритмов и структур данных необходимых для алгособесов. Считается, что начинать с этих задач — правильная стратегия.

Задачи из списков выше — хорошая база. Можно хорошо их миксовать с курсами и теорией.

📺 Асинхронный Layout: AsyncDisplayKit

Решил перед выпусками наваливать ЛОРа за темы, которые будем обсуждать. Так и весь контекст обсуждений можно понять, и экспозицию доклада сделать шире.

Не секрет, что мессенджеры — это отдельный вид приложений, не похожий ни на что. Модные SwiftUI, SC или CMP туда не запихнешь, тк он требует высокой производительности от очень старых устройств и версий. Здесь нужно уходить глубже, чем документации смузи штук. Обсуждать все сложности можно часами.

Поговорим про забытую многими технологию. Но оставившую свой след в индустрии.

Либа, AsyncDisplayKit aka Texture, знакома многими по исходникам телеграма. Много боли она принесла с конкурсами, когда нужно работать с исходной кодовой базой. Такие конкурсы на понимание и чтение исходников телеграма имели повышенную сложность. Именно в таком участвовал наш гость Паша.

В чем ее плюсы?

1️⃣ Асинхронный рендеринг — Рендеринг и layout происходят в фоновом потоке (да да), что уменьшает нагрузку на мейнтред. Вы думаете почему телеграм такой быстрый? Ну, потому что он эффективно работает с лайаутом.

Фейсбук* (запрещенная организация в РФ) создавала его для приложений с большим количеством контента (Pinterest, Facebook Paper).

2️⃣ Декларативный стиль через ASLayoutSpec еще до SwiftUI

3️⃣ Прерасчет лайаута до отображения.

В чем же минусы?

1️⃣ Сложность. Если вы где либо видите сложность — это плохой дизайн. Будь это текста авторов в телеграме, книги, кино, все что угодно. А уж тем более software engineering. Закон жанра: то, что остается сложным — умрет.

Асинхронный лайаут, при его очевидных плюсов на бумаге, стал мертворожденной идеей. Сами разрабы телеграма говорят, что было ошибкой затаскивать AsyncDisplayKit. А разрабы этой библиотеки давно отказались от поддержки в пользу своих более простых внутренних библиотек.

Советую ознакомиться в любом случае, тк это отличная зарядка для ума и опыт, который поможет понять проблемы UIKit.

Полезные ссылки:
- Using AsyncDisplayKit to Develop Responsive UIs in iOS
- Build Timeline View with AsyncDisplayKit

1/3