Software 3.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

💎 Swift Concurrency: Теоретические основы и дизайн

Разбирая SC vs GCD многие берут теоритический минимум. Есть заблуждение, что разрабы сразу предложили Swift Concurrency, но эволюция была несколькими фазами.

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

Начнем по порядку с пропосалов:

1️⃣ Фаза 1: Основы и Memory Model (2019-2020)

SE-0282: Clarify the Swift memory consistency model. В этом пропосале говорится, что Swift с SE‑0176 действует так называемый Law of Exclusivity, который запрещает одновременный доступ к одной и той же памяти. Но атомарные операции этот закон нарушают. На практике они всегда работали, но формально Swift этого не разрешал.

В этом предложении нет конкретного апи, но неофициально оно стало основной для дальнейшего развития.

We propose to adopt a C/C++-style concurrency memory model for Swift code:

Concurrent write/write or read/write access to the same location in memory generally remains undefined/illegal behavior, unless all such access is done through a special set of primitive atomic operations.

The same atomic operations can also apply memory ordering constraints that establish strict before/after relationships for accesses across multiple threads of execution. Such constraints can also be established by explicit memory fences that aren't tied to a particular atomic operation.

SE-0282 опередил время - memory model был готов задолго до async/await. был первопроходцем и заложил фундамент для всей экосистемы Swift Concurrency

2️⃣ Фаза 2: Core Concurrency Features (2021)

SE-0296: Async/await. Ранее в Swift асинхронный код реализовывался через колбэки и тп, что делало код менее читаемым. Цель добавить понятную и безопасную модель асинхронности, встроенную прямо в язык — как в JavaScript, C#, Kotlin и других.

This design introduces a coroutine model to Swift. Functions can opt into being async, allowing the programmer to compose complex logic involving asynchronous operations using the normal control-flow mechanisms. The compiler is responsible for translating an asynchronous function into an appropriate set of closures and state machines.

Дальше пошли SE-0298: Async/Await: Sequences, SE-0297: Concurrency Interoperability with Objective-C, SE-0298: Async/Await: Sequences, SE-0300: Continuations, SE-0302: Sendable and @Sendable closures

И только потом был SE-0304: Structured concurrency и SE-0306: Actors

Здесь как раз и произошла полная формулировка и композиция. До этого задачи создавались вручную и жили своей жизнью, было сложно отследить их завершение, отмену, ошибки. Теперь Structured Concurrency стало +/- управляемым и безопасным.

Task, TaskGroup стали помогать управлять понятной иерархией задач.

Можно сказать SE‑0304 основа Swift Concurrency.

Цикл статей про 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