Программисты пока могут не бояться ИИ.

В Росатоме работать с ИИ-агентами было нельзя, а вот тут в 2ГИС это даже поощряется, и компания сама оплачивает нужные доступы и лицензии. Практически любые модели на выбор, чаты, Copilot и так далее. Поэтому я попробовал выполнять прям настоящую энтерпрайзную работу при поддержке ИИ, и вот что скажу.

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

И тут начинаются проблемы.

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

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

#dev

Друг делал уборку у себя и обнаружил мою книжку. Двадцать лет у него хранилась. Именно с неё де-факто началось моё изучение программирования. Первые две части про то, как во флэше рисовать, а вот третья — о программировании на ActionScript 2 (тогда ещё), причем очень подробно, с самых основ.

До сих пор считаю убийство Флэша одним из наиболее деструктивных и вредных для человечества действий компании Apple.

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

Еще в комплекте с Флэшем был набор демок, и, запуская каждую из них, я думал "Хочу уметь так делать!". Одна из мечт, которые сбылись полностью.

#dev

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

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

А вот со стендами дела похуже, имхо — из известного бигтеха только Озон и Контур. Завтра второй день, пойду подробнее посмотрю, что там. И да, снова сама конференция не предложила никакие тематические наклейки, и непонятно, что клеить на ноутбук :)

#dev

Несколько лет назад на конференции TechTrain я впервые сыграл в Code in the Dark. Два разработчика параллельно садятся за компьютеры, запускается таймер. Дается картинка, которую нужно сверстать в HTML, но важный нюанс: ты не видишь результат до самого конца, пока не отправишь своё решение. Вёрстка вслепую. Если где-то поехало, можешь вообще всё сломать, но не узнаешь об этом. Мне очень понравилось, но я никак не мог придумать, как бы подобное соревнование выглядело для бэкенд-разработчиков.

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

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

Мне понравилось. Нужно на вечеринках с коллегами играть :)

#dev

Объявили результаты. Из четырёх команд мы оказались на четвёртом месте. Сказать, что это стало мягко говоря удивлением — ничего не сказать. Секрет оказался прост: мы пришли четверо разработчиков делать проект на хакатон, который был назван таковым организаторами по ошибке. А оказался конкурсом бизнес-идей. В общей шкале оценки реализация значила всего 20%. Двадцать процентов. Двухдневная работа заняла одну пятую от общей оценки (презентация делалась за пределами основного времени). Зато более половины уделялось умозрительным критериям, не имеющим никакого отношения к собственно работе, проделанной командами на самом хакатоне: например «Прогнозируемый объём аудитории», «Вирусный эффект» (ага, для B2G продукта вирусный эффект). Как в той картинке, где разных животных, включая рыбу, просят залезть на дерево, кто быстрее.

При цене реализации в 20% можно было вообще ничего не кодить два дня, прийти без проекта, но зато удачно придумать и продать комиссии маркетинговую лапшу. Хакатоны нередко ругают за возможность «выиграть одной презентацией», но в такой критике обычно речь идёт об обмане относительно степени готовности прототипа. Здесь же такие условия были с самого начала заложены в систему.

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

В ноябре будет уже более масштабный внутренний so-called-хакатон в компании. Не понимаю, хочу ли теперь участвовать или нет. #dev

Самое удивительное в энтерпрайз-разработке — необходимость специально доказывать и аргументировать объективно правильные решения. Представь, приходишь на автомобильный завод, а там выпускают бензобаки с дыркой в центре одной из стенок. Причём, это не особенность конкретного рынка или потребителя, просто исторически так процессы сложились. Ты такой: «Эээ, зачем с дыркой, давайте делать без дырки». Но тебе отвечают, что нужно аргументировать, защитить эту позицию перед бизнесом, ещё и с цифрами. Показать, что затраты ниже, чем профит. А начальник производства тебе ещё и раскладывает: на бензобаки без дырки будет уходить больше металла, так что твоё предложение приведёт к росту расходов. Ещё и у клиентов баки начнут заполняться дольше, негативный опыт.

Ты находишь инженерные книжки с описанием физики сплошных сред: «Вот гляньте что пишут, вот аргументы, вот схемы и формулы». А в ответ слышишь, что книги это идеализация, и в жизни оно всё иначе, нужно реалистично смотреть. Но самое главное: перестраивать линию на отсутствие дырки это прям очень дорого: станки переконфигурировать, персонал обучать, да и наверняка первое время будут косяки, поставки снизятся. Короче если прям не докажешь, что профит от твоего предложения принесёт миллиард за день, то иди нафиг.

Почему в разработке такого много, а на реальных автомобильных заводах всё-таки делают без дырок? Я вижу две причины:

1. Во-первых, когда бензобак еб**ёт, или там самолёт упадёт, это очень заметно. Аварии происходят с шумом, нередко с травмами. А падение какого-нибудь входящего интеграционного потока из-за отсутствия контроля состояния модели — это тихо, без фейерверков. Ну насыпется в лог ошибок, пошёл, руками поправил пару записей в БД, запустил снова.

2. Во-вторых, всё-таки у разработки низкая степень разнообразной конкуренции из-за склонности этой сферы к монополизации (которая обусловлена простотой доставки потребителю). В мире порядка тысячи автопроизводителей, а вот софт одного типа обычно выпускает едва ли десяток компаний. Сколько фирм делают, например, САПР для твердотельного моделирования? Нейросетка мне привела девять. Сколько настоящих конкурентов у какого-нибудь Майкрософт Офиса? Один: гугл документы.

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

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

В такой ситуации Яндекс делает несколько попыток, а затем присылает пользователю уведомление типа «Датчик такой-то долго не отвечает». Фокус в том, что, если нажать на уведомление, открывается карточка этого устройства, которая запрашивает его состояние уже более целенаправленно: не методом получения всех устройств, а методом запроса по конкретному устройству. На эти методы производители не забивают, и карточка успешно обновляется.

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

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

ИИ-перевод документации, например #dev

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

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

Из крутого внезапно узнал, что ESP32 двухъядерная! Не знаю, как я это пропустил в своё время. Но тут прям можно одним потоком читать сеть, а другим драйвить ленту и не делать паузы.

В целом мне всё равно нравится. Работает под управлением DeepSeek. В первой версии был GigaChat, он отвечает где-то вдвое быстрее, но слишком часто предлагает цвета совершенно мимо того, что я назвал.

Репозиторий с не слишком аккуратным кодом, если кому не лень будет возиться :) С наступающим!

#dev@clockstackwheels #gadgets@clockstackwheels #diy@clockstackwheels

Внезапно сменил работу

Кажется, буквально только что прогремела моя статья о собеседованиях, феерично завершившаяся попаданием в 2ГИС. Восемь месяцев — чертовски маленький срок. Никогда не занимался «джобхоппингом», так что и сейчас не открывал резюме, не искал работу, готовился к аттестации. Встроился в процессы, накупил корпоративного мерча, подружился с коллегами и стал регулярно ездить в офис (который при мне перенесли в другое здание и расширили). Уже прям ассоциировал себя с 2ГИС.

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

Сегодня на теперь уже старом месте работы было exit-интервью. Кстати, хорошая практика — компания обращает внимание на особенности в статистике увольнений. Задавали вопросы о том, что было хорошо, а что можно улучшить.

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

Одна из самых крутых киллер-фич 2ГИС, как работодателя — упрощённое взятие выходных и отпусков. По большей части не нужно никаких специальных согласований, если ты внезапно повёз ребёнка к врачу, или сам устал и хочешь денёк отоспаться.

Однако, в других местах отсутствие формализма порождает сложности. В Росатоме, например, процессы движения задач по жизненному циклу были зарегламентированы сильнее: нельзя передать что-то в разработку без аналитики, постановщик задачи сам следит за её статусами, задача целиком переназначается всегда на текущего одного ответственного человека (на стадии разработки на программиста, на стадии тестирования на тестировщика и т.д.). В 2ГИС иногда задачи приходили от бизнеса с необходимостью самостоятельно ходить по людям и уточнять, что на самом деле хотели. Делалось это как бы для экономии на аналитиках, что лично мне кажется большим заблуждением: бизнес таким образом платил за время более дорогого программиста, который ещё и выполнял работу аналитика дольше, потому что специализируется на другом. В итоге то, что казалось экономией, в моём понимании было скорее увеличением расходов и сроков. То же самое касалось, например, архитектуры и техдолга (но это типичная проблема подавляющего большинства бизнесов — техдолг вообще никто не умеет считать и оценивать).

Я бы сказал так: 2ГИС как бы вырос из стартапа и стал практически бигтехом, особенно после покупки Сбером. Если не бигтехом, то энтерпрайзом точно. Но в итоге оставил часть недостатков стартапа (экономия на «второстепенных» вещах, отсутствие регламентов) и получил часть недостатков энтерпрайза (слабое влияние сотрудников на конечный продукт, очень затянутое планирование и согласование новых задач, заметное количество легаси).

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

Если вы дисциплинированы, компетентны и не боитесь некоторых трудностей, то я однозначно готов советовать работу в 2ГИС. Сейчас идёт набор разработчиков на C#, Go, дата-саентистов, присоединяйтесь :) Уровни мидл и сеньор.

#dev@clockstackwheels #life@clockstackwheels

В 2023 году мы с коллегой сделали доклад на DotNext по DDD и архитектуре систем. И там, в числе прочего, показали, что устройство сложного проекта, спроектированного по определённым правилам, может иметь фрактальную структуру. Но мысль эту особо не развивали.

В 2024 году Влад Хононов — автор одной из самых известных книг по DDD — сделал доклад на DotNext по теме «Фрактальная геометрия в проектировании систем». Разумеется, он никаким образом на нашу идею не опирался, а работал над своей системой уже несколько лет к моменту доклада. У него там прям интересные научные обоснования, более серьёзный теоретический фундамент с введением новых понятий и принципов. Но факт близости хода мысли приятен. Типа, мы с коллегой делали систему, которая показала те же свойства, что и системы крутого эксперта в архитектуре.

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

#dev@clockstackwheels

Сделал в компании доклад о применении ИИ в архитектуре, давайте и вам расскажу.

Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.

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

Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.

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

#dev@clockstackwheels