Саша Раковский

Я полгода держался, но нет. Теперь будут регулярные разборы ахинеи от этого чувака, извините)

Или вот такое ещё. Короче, если подписаны, то фильтруйте все до каждой запятой.

Вот ещё немного ахинеи

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

Про дела

Пролетели почти полтора месяца с прошлого поста, а для меня это как в прошлом году было. Много работаю, мало пишу, а потому компенсирую: большой-большой рассказ, как у нас дела.

Продукт

Сервис сейчас и сервис полтора месяца назад - это две разных вселенных. Очень большая разница. И она измеряется не просто в новых фичах, а в изменениях, которые надежно и статистически значимо дают очень заметный прирост выручки. Это и новые большие продукты, и заметное улучшение конверсии старых, и другие маленькие трюки.

Для части продуктов мы уже нашли хорошую формулу, для части пока только подбираем ключик, но они все у нас работают в хороший плюс.

Релизы

На нашу небольшую компанию на все продукты у нас в день получается, наверное, около полутора десятка релизов, не меньше. И это поставки в прод именно с какими-то реальными изменениями, а не просто continuous deployment, где релиз есть, а изменения все за флагом. Ничего плохого о continuous deployment сказать не хочу, напротив, просто мы пока до него не доросли.

Постепенно мы приходим к все более высокой дисциплине нашей релизной культуры. Сюда относятся и приёмочные тесты в пайпе, и алерты, и канареечное развёртывание опасных изменений через 10%, и практика контроля логов глазами в течение получаса после релиза, и отказ от релизов перед обедом или окончанием рабочего дня.

Архитектура

Я в прошлый раз уже писал, что даже на таких ранних этапах видно, как новая архитектура даёт свои плоды. И в этот раз должен сказать, что она продолжает радовать все больше. Высокая скорость выкатки новых продуктов переросла в такую же высокую скорость их изменений. Команды не мешаются друг у друга под ногами и не упираются друг в друга. При этом с большим удовольствием поддерживают соседей, когда видят какую-то интересную возможность.

Платформа

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

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

Топология команд

Третий архитектурный вопрос - топология команд. Изначальная идея с одним-двумя людьми на продукт расцвела интересными вариациями: на одном продукте всего один человек, который ещё параллельно и платформенный компонент развивает; на другом команда аж на три человека; третья команда на три человека поддерживает два продукта одновременно; где-то народ работает парами. Короче, получилось и так, и сяк, и пятой точкой, простите, об косяк.

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

Продуктовые инженеры

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

Вайбкодинг и фреймворк

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

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

Говнокод

К моменту моего прошлого поста у нас было:
- четыре новеньких чистеньких продукта, у которых и до сих пор все вполне прилично в коде;
- один более-менее приличный;
- и ещё три продукта, от кода которых у нас волосы шевелились на... голове: один старый-старый и два новых навайбкоженных монстра, по полтора месяца каждый.
- Плюс платформенные модули, где все было не сильно лучше.

И вот спустя месяц на двух из трёх монструозных продуктов нам удалось построить рядом элегантное, простое и мощное решение, перевести на них всех пользователей и аккуратно удалить нафиг весь старый код.

А вот на третьем мы попробовали пойти ещё дальше: мы взяли старые аксептанс тесты и новым вариантом фреймворка переписали все с нуля. И сработало like a charm. Причём было страшно: мы все очень хорошо знали, что big bang replacement превращается обычно просто в big bang. Но в эпоху вайб-кодинга все оказалось не так и плохо.

Lean

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

Культура

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

Секрет фирмы

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

Подводя итоги

Короооче. Пока полёт уверенный: все то, о чем я пишу уже почти полтора года в блоге, внедряется и работает, как часы. Получается чудо, как хорошо. Но дальше - больше.

Ответ: если ты молодец и делаешь свою работу хорошо, а твой лидер не дурак, никто с тебя лишнего не спросит.

Итог

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

Про творческий беспорядок в процессах

Я куда ни приду лидом, меня первое время все ругают за бардак в процессах. Мол, непонятно, кто чем занят, и где границы ответственности. И я всегда говорю: вы не поймите неправильно, я это специально, так было не всегда. Щас поясню.

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

1. Максимум делегирования

Тимлид, как и любой другой член команды, которого в команде всего одна штука - это самый первый кандидат на бутылочное горлышко и single point of failure. Поэтому его ключевая задача - всю работу скидывать с себя на кого-то другого. Этакий вариант поговорки "работа-работа, перейди на Федота". Load balancer от мира команд.

2. Замкнутые ответственности

Доведенное до максимума делегирование подразумевает, в том числе, делегирование и уже традиционно лидерских задач. А именно - самостоятельная расстановка приоритетов по задачам и самостоятельный контроль прода во всех смыслах. В идеале: в продуктовом и инфраструктурном смыслах тоже.

3. Минимум координационного взаимодействия

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

Отсюда как раз моё предпочтение наиболее широкой компетенции специалиста. Несмотря на свое бэкендерское происхождение, я уже много лет всем сердцем голосую за фуллстеков, а теперь уже - за продуктовых инженеров. Именно продуктовый инженер может замкнуть на себя наиболее широкую ответственность.

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

4. Минимум процессов

Я в своей жизни насмотрелся на процессы ради процессов: дейлики, ретро, планирования. Обязательно списывайтесь, обязательно двигайте таску по трекеру, обязательно через ветку, через 2 ревью, 0 замечаний в сонаре, 80% покрытия, написать вики. Все обязательно. Человеко-дни работы команды сгорают каждую неделю на очень логичную и зачастую очень малополезную туфту.

Поэтому процессы у нас всегда строились так: если ничего не болит, то и процесса не надо. Если что-то болит, давайте найдём подходящий инструмент. Не достаёт коммуникации - давайте введем регулярные синки. Не хватает ревью кому-то - сажаем ему в пару человека. Ну и так далее. Чем меньше процесса, чем меньше людей в нём людей, тем лучше.

5. Доверие

Это прям любимая мантра аджилистов: зачем вы нанимаете людей, которым вы не доверяете.

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

6. Самоорганизация

Я в банке часто слышал вопрос-упрёк от нашего аналитика: "Я не понимаю границы своей ответственности, что конкретно от меня ожидают?!"

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

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

Результат

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

Про подводные камни

Ну и, как обещал, давайте разберём очевидные вопросы, которые у вас 100% возникли.

1. Максимум делегирования

Первый очевидный вопрос: если лид все делегировал, какова роль лидера в такой команде?

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

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

2. Замкнутые ответственности

Как доверить джуну постановку себе задач и полный контроль за продуктом? Никак. Либо не нанимайте джунов, либо сажайте их в пару к тому, кому готовы это доверить. Но будьте готовы: по джуну не всегда можно понять, сможет ли он вырасти во что-то большее, в конце концов.

3. Минимум координационного взаимодействия

Режим одиночки имеет 3 основных ограничения и, соответственно, возражения:

- Bus factor. Человек ушёл в отпуск - продукт стоит. Человек уволился - продукт сильно просел. Решается просто - всегда должен быть запасной человек, который либо работает вместе на продукте, либо когда-то на нём работал.

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

- Некоторые продукты заколебешься делать в одного - нужна куда большая пропускная способность. Порой это даже десятки и сотни человек, да? Да, но можно ли разделить их работу на небольшие независящие друг от друга подпродукты, которые могут делать 1-2 человека? Почти всегда - да.

4. Минимум процессов

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

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

Сама работа постоянно гуляет туда-сюда. Например, фронт начал делать и понял, что а аналитике есть проблемы - аналитику надо переделывать и, конечно же, бэк (и ревью снова). Тестировщик проверил и нашёл на бэке косяк: теперь бэк все переделывает, подходит ревью, фронт переделывает, проходит ревью, и задача снова уходит к тестеру, чтобы тот понял, что проблема была не в ошибке бэка, а вообще в аналитике.

5. Доверие.

Как довериться человеку, которого только нанял? Может, он балду пинает. К тому же, если ты его только что нанял, то он точно ещё долго будет въезжать, прежде чем станет действительно самостоятельным.

Ответ: нельзя довериться. Доверие нужно заслужить. Просто для этого надо не так много: дать ментора и чуть-чуть времени на вход. Уже довольно скоро будет видно, можно ли доверять или нет.

Что делать, если нельзя? В идеале - поговорить честно и разойтись по-хорошему. В реальности часто: оставить вечным подопечным на второстепенных ролях у кого-то, кто тащит.

6. Самоорганизация.

Как можно работать в процессах, где у тебя нет чётко сформированной ответственности? Ведь, тебя, получается, могут спросить вообще за все, что угодно?

Первый раз делаю повтор, но, извините, просто сейчас это болит.

Про девопс

Наша индустрия тяжело больна двумя очень близкими болячками: карго-культ и semantic diffusion.

1. Карго-культ - это, как пример, про то, что бигтех делает аджайл и они крутые, поэтому мы тоже будем делать спринты, дейлики и ретроспективы.
2. Semantic diffusion - это, например, считать, что аджайл = спринты, дейлики и ретро.

Помимо аджайла жертвами этой болезни стали такие понятия, как микросервисы, CI, CD, DevOps и ещё, на самом деле, много чего. CI и CD насколько безнадёжно путают между собой, что даже превратили в единый термин CI/CD, чтобы не разбираться чем одно отличается от другого.

И вот из этого списка я пока не касался только девопса, наверное.

Что такое опс

Девопс - составное слово, состоящее из development и operations. И, если про первое всем всё понятно, то вот откуда взялось второе, и что оно значит - это прям загадка.

Если кратко, то это просто последняя фаза waterfall-модели: аналитики анализируют, архитекторы архитектурируют, девелоперы девелопят, тестировщики тестируют, а операции оперируют. В общем, операции - это те, кто эксплуатируют софт.

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

Конфликт

Не знаю, как вы, но я с такими сисадминами в своей жизни ругался не раз. И всегда по примерно одной и той же причине: у нас, вообще говоря, разные цели.

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

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

Эта проблема называется big wall of confusion и известна уже лет двадцать.

Решение

Тут есть 2 варианта решения:
1. Запихнуть всех в одну команду и спрашивать и за стабильность, и за темпы поставки.
2. Переложить ответственность за операции на команду разработки.

В Амазоне, например, все команды разработки называются devops teams. Именно поэтому.

Каждый разработчик имеет пейджер, на который ему приходят сообщения, если в проде беда. Ну и, естественно, график дежурств, on-call, третья линия - вот это все, на самом деле, и есть настоящий девопс.

И после переезда Netflix в облако Adrian Cockroft, архитектор Netflix, даже пошутил, что наступила эра NoOps - насколько легко разработчикам стало управлять своей айти инфраструктурой. Сейчас кстати он шутит, что наступила эра NoDevs.

Итого

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

А при чем тут тогда чел с зарплатой 500к, который круглые сутки кубер ковыряет и в дженкинсе джобы пишет? Или даже команда таких ребят?

А ни при чем.

Компилируется, тесты едут, деплоится... Теперь вот новая история: агент уехал фигачить задачу.

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

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

И вот тут заметна разница между программистами. Одни воспринимают это как данность: вот такой теперь процесс, вот такое ограничение. Другие воспринимают это как препятствие к цели и меняют процесс: увидев негативный результат через 15 минут разок-другой, они меняют цикл обратной связи на сверхкороткий - чинят именно ту маленькую штучку, которая им нужна. Получают результат за 3-5 трехминутных цикла, а потом снова запускают длинный с уже починенным всем.

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

Это я просто удивился, какие крутые штуки народ делает с этой моделью. Мое использование астры, конечно, не столь креативно😁

Хотя и монтаж видео меня в своё время остановил от блога на ютубе, и квартиру свою новую по скрину планировки я пытался в HTML опусом 4.8 отрисовать безуспешно.

Глава Codex Тибо Сотьо пишет, что спрос на GPT-6 Astra оказался беспрецендетным. Компания сейчас выжимает максимум из вычислительной инфраструктуры, но рассматривает и более радикальные меры – например, на некоторое время остановить подключение новых пользователей на Pro-тарифы.

Можно списать это на рекламу, но моя X-лента в последние дни почти целиком в GPT-6. Народ подкидывает модели новые задачи, а она решает их одну за другой. Вот примеры:

— Евгений Кирилин попросил Astra сделать инструмент для просмотра молекулярной симуляции на 71 492 атома. Клеточную мембрану можно “раздвинуть” на отдельные молекулы и рассмотреть каждую поближе, не останавливая симуляцию.

— По девяти неудачным снимкам рабочей студии Роберто Никсона Astra восстановила расположение предметов и собрала трехмерную сцену, по которой можно погулять: два уровня, лестница, мебель, оборудование.

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

— Tykoo передал Codex с Astra 55 видеоклипов для ролика о Шэньчжэне и четыре варианта музыки. Попросил ориентироваться на его стиль, самостоятельно выбрать материал и смонтировать видео. Результатом автор доволен.

— Марк Ибрагим с GPT-6 добился 70–150 кадров в секунду в Age of Empires IV на Mac с Apple Silicon — вместо примерно 8 и постоянных зависаний через CrossOver. Графическому чипу на кадр требовалось около 9 миллисекунд, но целиком кадр занимал примерно 160. Astra доработала прослойку совместимости и добавила кеш для повторного использования команд, уже переведенных под процессор Mac.

Я не люблю разбрасываться термином AGI, но понимаю президента OpenAI Грега Брокмана, для которого он наступил с GPT-6: люди придумывают модели все новые нестандартные интеллектуальные задачи, а она их решает.

Разумеется, не все: в соцсетях чаще показывают успехи. Но по моему опыту с Claude Fable 5, GPT-5.6 и Астрой, даже не решив задачу, модель не отмазывается, а раскладывает по полочкам: что получилось, где застряла и что попробовать дальше. Это “взрослая” работа с ИИ и задел, к которому можно вернуться после выхода новых моделей.

При всей любви к Fable, я и сам перекинул на GPT-6 почти все свои задачи. Какое-то время мне казалось, что Claude лучше пишет и ведет диалог, но сейчас вижу, что скорее сработала моя привычка к стилю модели. Поворотной стала история с Навье–Стоксом: GPT-6 предельно понятно для моего уровня знаний объяснила задачу и то, как ее решали Бакмастер/Альпёге и OpenAI. Начала с ровного текста с красивыми аналогиями, а по просьбе оформить ответ в HTML добавила интерактивные демонстрации.

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

Понятно, что все это происходит на фоне хайпа в соцсетях и “медового месяца” с моделью с новой возможностью – поэтому от Fable я отказываться не собираюсь. Но Anthropic нужно поднажать, чтобы догнать. А OpenAI благодаря выходу GPT-6 и историческому решению задачи Навье-Стокса получает отличный аргумент к будущему IPO.

—
Опытом использования ИИ я делюсь на “Бусти”. Вот два текста, которые помогут в работе с Астрой:

👉 Гайд по вкату в ИИ-агентов – GPT-6 нормально доступна в Work и Codex, а в них надо знать хотя бы базу по агентам.
👉 Гайд по оптимизации промптов под новые модели – OpenAI и Anthropic сами советуют рефакторить старые промпты, убирая лишние инструкции.

Про компетенции

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

Где нужно объяснять, почему что-то быстро сделать без тестов - это очень плохая идея. Зачем нужен пайп, аксы, и почему все тесты обязательно должны быть зелёные. В итоге, что-то, работавшее буквально недавно, сегодня уже может не работать.

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

Где не все люди до конца ассоциируют себя со своим продуктом, пока не подозревая, что их ждёт, когда на продукт польют трафик, все увидят конверсию, и им резко станет некогда. Даже опыт соседей пока не пугает. Продукт на выходе получается соответствующий.

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

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

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