IT Makes Me Hate

Я тут немного поспамлю. Тк пришел на YoungConf.

Все одна самая масштабная конфа про IT

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

еще актуально....

А удалили только на российском апсторе же. Кто-то вообще там еще сидит?

⚡️Из российского AppStore исчезли приложения VK — Музыка, Мессенджер и Видео.

VIPER/TCA — это вам не архитектуры

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

Дело в реальных вещах. Например в перформансе. Если бы я собирал такой компонент на типовом шаблонном решении, это бы только навредило: красиво по схеме, но медленно и негибко на деле.

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

Раздробить на атомы и связать их между собой паттернами проектирования, DI и другими невидимыми нитями.
Управлять каждым по отдельности как марионеткой.

Как раз в этом и суть архитектуры и систем дизайна. Знать правила чтобы их нарушать. А не слепо следовать. Находить трейдоффы и компромиссы.

Помним классику и статью из крутейшей книги про переоценивание важности шаблонных схем

AI Native Engineer Roadmap

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

АИ Нэйтив инженер — это не вайбкодер, а оркестратор и AIOps эксперт. Он настраивает и выжимает из иишки максимум.

Тут @temptempest сделал замеры и в итоге вышло так:

Mutex: 1000000 sec: 0.116029959
os_unfair_lock: 1000000 sec: 0.102539708
ManagedAtomic: 1000000 sec: 0.102818583
Actor: 1000000 sec: 0.158358416

вот на 100 млн более наглядно

Mutex: 100000000 sec: 9.159649958
os_unfair_lock: 100000000 sec: 11.101984375
ManagedAtomic: 100000000 sec: 10.523804291
Actor: 100000000 sec: 14.740539375

Удивлен, что >50% проголосовало за Actor

Эта задача из книги AI Swift Driven Development. Автор опрашивал несколько нейронок и считает, что Mutex подходит лучше всего.

Операция синхронная, состояние тривиальное. Mutex создан ровно под этот сценарий: короткая read-modify-write секция, которая завершается мгновенно. withLock { $0 += 1 } захватывает лок, выполняет замыкание, освобождает лок — без индирекции. Инкремент счётчика — это архетипичный пример, для которого лок и придуман.
У actor каждый вызов метода — это await, то есть потенциальная точка приостановки: хоп на executor актора, постановка задачи в очередь, планирование. На 2000 инкрементов — 2000 таких хопов. Mutex синхронный: нет suspension point, нет планировщика, нет async-контаминации вызывающего кода (await не расползается вверх по стеку вызовов). Для горячего счётчика это решающий фактор.

Ну все, 51% заменяет нейронка?

WatchDog Director’s Cut

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

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

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

1. Одних серверных метрик мало. Во-первых, они подгружаются не сразу. Во-вторых, не всегда есть смысл гнать туда весь стектрейс целиком.

2. Ватчдог дал диагностику из коробки. Тестировщик мог включить режим диагностики, записать весь лог операций на главном потоке и сразу прислать мне нужную инфу одним файлом.