Горячие топ-темки в айтишке: системный аналитик и 1C. В октябре уже наверное с десяток разных каналов написали про вкат в это. Менторство-шменторство с нуля за месяц на 300k/s, классика.

Про 1C ничего не могу сказать, помню ещё смешные случаи на их первых презентациях на ИТ-конференциях в 90-е ("а не застрелят за баги в бухгалтерии?" без шуток), ну разве что кроме очевидных вещей, что это не универсальный фреймворк разработки, а система автоматизации деятельности предприятий, и как минимум надо уверенно разбираться в соответствующих доменах (бухгалтерия финансы склад производство логистика, mrp/erp...). Ну а безусловные (и большие) плюсы, что это в России абсолютно стабильная темка + будете хорошо разбираться в соответствующих бизнес-процессах + в силу некоторой эээ неидеальности платформы 1C огромное поле для инди-хакерства.

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

Если это ещё 2-3 года назад была отдельная профессия, на которую сбрасывали постановку задач (на входе тупой заказчик который сам не знает что хочет, а на выходе ТЗ и спецификации, которые ленивый мидл может кое-как понять и что-то такое зарелизить), то сегодня спрос совершенно реально вырос ровно по той очевидной причине, что от СисА как раз не требуется умение программировать. Тогда это было скорее минусом и ограничивающим фактором, но сегодня из-за искусственного кодера стало большим плюсом и реально востребовано. Я собственно про это уже давно пишу, что вот поэтому сегодня и надо срочно расти в техдира; ну ок, или в системного аналитика.

Далее раскрою тему СисА более подробно (хорошие новости реально) => ...

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

Вот ещё до массового распространения нейронок хороший разбор на хабре, кто такой СисА: первое второе
Что хочут, знания и скиллы =>

Цикл разработки
Требования
Интеграции. REST. Очереди.
Базы данных. Связи. NoSQL.
SQL
Архитектура. Монолит-микросервисы.
Безопасность. Аутентификация, авторизация.

=

И: С какими интеграциями вы сталкивались?
К: Много работала с REST и интеграцией через очереди.
И: Давайте поговорим про REST. Расскажите про выбор методов, заголовки, тело запроса.
К: … (рассказываю)
И: Как реализовать асинхронное взаимодействие через http?
К: Вебхуки, более древний способ — long/short polling.
И: Расскажите про вебхуки? Какое отличие long от short polling? В чём минус polling?
К: …(рассказываю)
И: Хорошо, какие ещё инструменты для асинхронного взаимодействия знаете?
К: Веб-сокеты, очереди сообщений.

=

Стандартный набор задач:
Написание SQL-запроса.
Проектирование БД.
Проектирование API.
Проектирование системы (несколько микросервисов).
Описание процесса с помощью sequence-диаграммы.

=

Уметь выявлять требования с помощью разных техник
Описывать пользовательские и функциональные требования
Владеть моделированием процессов и данных
Понимать, как устроены приложения
Разбираться в процессе программирования
Ориентироваться в коде


Вчера например на нн с ходу нашёл свежую вакансию (удалёнка) на 200-250k =>

Умение выстраивать взаимодействие и совместную работу с заказчиками, командой, экспертами и другими участниками процесса создания, развития и сопровождения проектов;
Уметь принимать участие в проработке архитектурных решений;
Уметь планировать процесс разработки фичи, декомпозировать сложные процессы и задачи, ставить задачи другим участникам;
Навыки моделирования системы и умение описывать их с помощью разных нотаций и разных способов;
Опыт работы по описыванию бизнес-процессов, поведения пользователей и отклика системы, системных функций;
Уметь:
Проектировать модель данных БД;
Проектировать интеграционные взаимодействия;
Проектировать и описывать интеграции REST API, Ореп API, Kafka;
Проводить анализ данных, находить инсайты, аномалии. Формировать дашборды, визуализировать данные;
Принимать участие в написании тест-кейсов и тестировании (приемке разработки).

Как раньше под сисадмином-аникейщиком понимали мастера на все руки, да и от кодеров требовали настроить принтер ("тыжпрограммист"), так сегодня просто поднялись по абстракциям.
(Постепенно так и придём к теории типов, теоркату и математике)

Да, и вот что следует полезное прозаическое для нас с вами => ...

Несмотря на кучу архитектурных тем, в системной аналитике практически полностью выпал скилл программирования, причём практически официально. А так-то он был реально самый тяжёлый и самый долгий для изучения в ИТ, и который давался далеко не всем на профессиональном уровне.
 
А вот то что сейчас требуется (ну или совсем скоро будет) массово, буквально в десятки раз больше, чем раньше обычные программисты, как манагеры распробуют вайбкодинг -- это  пресловутый системный аналитик. Фактически системный аналитик - это чел на которого можно за копейки полностью спихнуть создание продукта, которым раньше занимался коллектив из десятков разработчиков :)
 
И что классно, что совершенно реально СисА сегодня может стать едва ли не каждый сообразительный, это по сути чистая инженерия, даже думать особо не надо. Ну может с десяток доменных терминологий/DSL изучить -  буквально по статьям на хабре/вики, и сотню классических архитектурных паттернов, которые давно известны и хорошо разобраны, и надо просто уметь грамотно их комбинировать, причём вполне достаточно логики первого порядка.
 
Я кстати  именно эти моменты по сути и разбираю на Last Principles Framework, только формально - через теорию категорий; постепенно и все онлайн-школы к ней придут (а я тем временем уйду ещё дальше :).
 
Сеньорам и техлидам выросшим из сеньоров, вообще можно не париться, ну разве что поактивнее качать AI-инженерию, дабы загонять в неё под автономию как можно больше рабочих процессов (ментатам тут помогаю по мере возможности), и главное конечно, профессиональная работа со спецификациями, буквально "думать спеками" (готовлю тут особую фишку).
 
А тем, кто реально планировал/планирует, ну или просто ещё искренне хочет "войти войти", порекомендую всё же это не бросать. Но если вы на данный момент изучаете программирование, вот его пока лучше отложить (хотя конечно минимальный скилл "написать/понять скрипт на питоне/пыхе/баше" всё равно будет востребован, но второстепенно), а взяться за system design, devops, и, очень важно, изучить базы данных и особенно SQL, потому что реляционная модель это база моделирования данных. Без её знания никаких нормальных спецификаций не получится.
 
Что как изучать в целом в каком порядке? Вбейте в поиске

"системный аналитик" курсы

походите по рекламным ссылкам, скачайте силлабусы, забросьте в бесплатный дипсик и попросите "начни со мной заниматься по этой схеме по шагам".
 
Вот например
 
4 месяца обучения
Нагрузка ~10 часов в неделю
5 проектов
2 промежуточных тестирования
Большая итоговая работа
9 воркшопов
Программная архитектура системы, стили архитектуры, микросервисная архитектура, системная интеграция, проектирование REST API, проектирование RPC, Query‑Based, Async APIs
 
Стоит 120-150 тысяч рублей :)
 
[чёта я ооооочень сильно недооцениваю свои курсы и проекты для ментатов, хм...]
 
Короче, резюме, что системный аналитик - это резко взлетевшая с явлением AI профессия, которая по сути станет новой массовой базой в ИТ, а спрос на неё превысит прежний спрос на программистов в сотни раз!!1 А по доступности она станет наоборот в сотни раз доступнее.
 
Но только "в сотни раз доступнее" в том смысле, что, да, потенциально её сможет освоить вообще любой человек, закончивший условный технический вуз, а не то что раньше жёстким фильтром были например алгоритмы и структуры данных-кодинг, над которыми приходилось реально сильно ломать голову, и давалось далеко не каждому.
 
Но при этом сам порог входа ощутимо вырастает, так как изучать всё же надо реально дофига. 4x4x10 = за 160 часов? Ну хз, вряд ли, хотя базу условного аналитика-джуна можно получить, да.
 
Зато СисА можно реально хорошо вытаскивать чисто на зубрёшке и софтах. А я в этом традиционно помогу.

Крайне доволен эпик багом в PHP. Ну а с какого фига скачиваешь бесплатно мощную платформу разработки, за качество которой никто никакой ответственности не несёт по определению потому что халява и опенсорс, и доверяешь ей критически важные для твоего бизнеса проекты? Ты дурак?
 
Вообще, тренд на обесценивание инструментов и платформ разработки, начавшийся лет 20 назад, вот сегодня и приносит закономерные результаты. Когда-то ведь за IDE и компилятор на одно рабочее место приходилось платить 500-1000 долларов, я сам бегал покупал в МГУ лицензии Borland C++ в коробке. Крайне поучительный урок для айтишки, из которого никаких выводов сделано не будет, и это тоже хорошо.
 
Потому что, говорю уже не один год, как не выкручивайся, в конечном итоге всё сведётся к формально верифицированному стеку, от железа и ОС до компиляторов и IDE, а постепенно полноценная верификация будет требоваться вообще от любого продукта. Но темка эта ещё долго будет сильно дорогостоящей. Представьте если бы 60 миллиардов направить не на разрушение Рунета, а на верификацию российских продуктов? Вот это действительно была бы взрослая кибер-защита национальных ИТ-интересов.
 
Что же касается самого бага, всё что я прочитал даже в уважаемых пабликах, ну просто какой-то примитивный уровень истеричных белок и ноль критического мышления, "70% сайтов работает на пыхапы" и прочий бред. По дефолту session.upload_progress.cleanup включён например и это уже норм, и в целом требуется с десяток предварительных нестандартных условий (обход ASLR, утечка памяти, нестрогий режим сессий) плюс весьма сложная цепочка эксплойта. Многие десятки популярных сайтов были просканированы, и ни на одном этот баг не сработал. Ну а если тебя взломали, значит просто твой вебмастер лох (а скорее всего вайб-кодер), гони его нафиг.
 
Ну и в целом, количество 0day с явлением AI никак особо не увеличилось, никаких эпических мировых сбоев не будет, потому что над серьёзными проектами работают профессиональные безопасники; а если пользуетесь халявным опенсорсом, так это чисто ваши проблемы. На какое-то время возможно критических  багов будет чуть побольше, потому что просто теперь можно забросить большой проект в нейронку и она его почистит, но никаких "всё пропало" точно не будет.
 
А вот мелких багов станет в сотни раз больше из-за вайб-кодинга, поэтому кибербез однозначно будет расти.

Мой подход к кибербезу кстати стратегический, а не эти ваши SOC GRC DFIR/TH/MA ... Нормально делай - нормально будет ) Качественное проектирование, формальные методы, по определению снижают количество багов, особенно критических - и соответственно общее время разработки - во многие разы.

Вначале необходимость продумывания архитектуры вас замедляет. Но по мере того, как ваш проект растёт, вас начинает замедлять отсутствие продуманной архитектуры.
Создайте Big Ball of Mud, и агенты с радостью продолжат копаться в говнокоде.
Создайте структурированную систему с разделением задач и чёткими контрактами (типами) между модулями, и агенты будут продуктивно следовать такому шаблону.

Если AI продолжает и продолжает ошибаться в коде, прекратите давать ему больше и больше инструкций, что нужно сделать. Давайте ему наоборот больше информации о том, что должно оставаться неизменным, а что вообще нельзя/не надо делать.

Думайте инвариантами и safe-паттернами на формальных языках, которые нейронке сложно сломать ("Функциональные архитектуры" в помощь).

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

Засада в том, что проект состоит из сотен/тысяч мелких решений: как работают экранные формы, что делать при той или иной ошибке, как вести себя в "редких" случаях (коих всегда воз и маленькая тележка), что важнее - скорость или надёжность. Если их не указать явно, нейронка примет такие решения сама, и далеко не всегда так, как вы представляли себе, т.к. читать мысли пока не умеет.

Кроме того любой проект - это всегда множество внутренних компромиссов, например между откликом и надёжностью; теоремы CAP, FLP (Fischer–Lynch–Paterson), что разбирал на Функциональных архитектурах, доказаны математически. Заложишься на "поскорее сделать", и проект через месяц заткнётся на 50 юзерах или будет лагать по 10 секунд. Ну или бот РКН штрафанёт на миллиончик за утечку персданных :)

=

Ведь по сути полное и точное описание продукта и есть программирование :) только на условно естественном языке. Карпатый недаром недавно рекомендовал упрощённые технические языки вроде ASD-STE100; я за более формальные подходы, потому что порог входа с ними выше, но зато и эффект куда мощнее.

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

Короче, роль чела сильно смещается к продвинутому системному аналитику: тестировщику с качественным фидбеком + продакту + архитектору. Собственно, заказчик всегда "словами описывал" желаемый продукт команде разработчиков, и работало это только при постоянном общении, бесконечных уточнениях и формальной приёмке. С AI всё это и остаётся, только быстрее (и дешевле?).

В любом случае, всегда требуйте в таких процессах от AI задавать уточняющие вопросы "до понимания на 90%", и писать хотя бы регрессионные тесты. Жертвовать ими можно, только если не планируете развивать проект вдолгую.

...Но есть маааленький нюанс: на длинной дистанции проект, созданный AI, ломается более чем полностью. Без проектной дисциплины он деградирует на порядки быстрее обычного.

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

Без тестов любая правка может незаметно сломать что-то в логике в другом месте (особенно это страшно в асинхронщине; помните "Незримые механизмы логики"?). На проекте в сотни тысяч строк никто не заметит этого вообще, да и кому замечать-то?

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

Архитектура постепенно расползается: AI хорошо дописывает новое, но слабо переделывает старое, потому что нету никакого понимания. В итоге код стремительно раздувается и запутывается, и технический долг растёт на порядки быстрее, чем в проектах, которые пишут люди.

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

Документация: ТЗ, спецификации, описание архитектуры, записи, почему приняты те или иные ключевые решения.

Модульность: мелкие независимые части с понятными границами, чтобы AI мог работать с куском кода, не видя всё целиком (DDD в помощь).

СисА :) Тот, кто отвечает за архитектуру, и имеет целостное её понимание.

=

Короче, запустить весьма приличный проэкт просто "словами в микрофон" реально уже сейчас (если есть баблишко, сотня килорублей на токены :). Даже 100 тысяч строк кстати это очень приличный размер, для сравнения, типовая мобильная игра - это 5, максимум 10 тысяч строк ручного кода. Правда, и AI код раздувает очень сильно, в разы точно, а в сравнении с функциональщиной, так и на порядки.

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

И вот база айтишки с аишкой на годы вперёд: одним из главных навыков, а скорее всего, и самым главным, станет мышление спецификациями. Спеки теперь -- это основной рабочий инструмент архитектора (разработчика в целом), которым раньше был код как главный артефакт, а документация обычно отставала. Но теперь код можно перегенерировать заново, и (вероятно) точное описание того, а что вообще нужно, остаётся единственным источником истины в проекте.
 
AI делает то, что вы описали, а не то, что вы подразумевали и имели в виду. Даже небольшая неточность в спецификации сразу превращается в неправильный код, причём в больших объёмах; цена нечёткого мышления сильно растёт (а откуда чёткое мышление взять-то? :).
 
Спецификация и есть тест! Чётко заданные контракты (в идеале, системой типов), инварианты и граничные случаи легко превратить в тесты, ведь без них нечем оценить, правильно ли нейронка всё сделала.
 
Спеки -- память проекта. Как говорил выше, на длинной дистанции спецификации и записи о ключевых архитектурных решениях единственные дают AI контекст, без которого он просто ничего не сможет сделать.
 
База =>
 
Думать контрактами: что модуль принимает, что гарантирует, что запрещено. Это собственно тип модуля, только в математическом смысле, о чём подробно пояснял Роберт Харпер, формализовавший языки ML и подготовивший кучу курсов для Карнеги-Меллона, в книге "Модули важнее всего" (в СИ делал выжимку из неё; на бусти скоро будет гайд).
 
Явно задавать инварианты и граничные случаи, то есть то, что "очевидно" человеку, но не сетке.
 
Уметь проводить границы (На "Функциональных архитектурах" у меня есть большой модуль "Математика DDD"): делить систему на части, каждую из которых можно описать и проверять отдельно.
 
Записывать, почему принято то или иное решение, а не только что решили.
 
Видеть, что не описано: уметь находить дыры и неоднозначности в требованиях.
 
Теория категорий очень в помощь для тотальной композиционности всего и на всех уровнях.
 
=
 
И, да, если системный аналитик - самозванец после онлайн-курсов, который не понимает, как подобные системы работают на деле, то он выдумает красивую, но нереализуемую или тормозную спецификацию; то есть инженерная экспертиза хотя бы на уровне крепкого мидла обязательна.
 
Короче, ценность разработчика-27 быстро смещается от умения написать код к умению точно сформулировать спецификации и умению грамотно проверить результаты. Кто умеет ясно и чётко думать спеками и формализовать требования, только и останется в айтишке!

=
 
...Это всё был прогрев на мой новый курс "Стань системным аналитиком с нуля на зп 512k за 4 недели всего за 128 тысяч рублей можно в кредит"!!1

Шутка.

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

Продолжаю работу с ментатами 🤓

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

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

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

выяснилось, что около 40% сессий пользователей покрываются двумя сценариями, а остальные 60 еще несколькими тысячами...

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

(и заодно хочу поблагодарить за сайд-квест с ИИ-разработкой, спасибо, было очень полезно, сам бы долго еще полз к этим темам)

В целом концепция логичная и понятная, стараюсь аналогично делать в повседневной практике.
Регулярно сталкиваюсь с прямо противоположными ситуациями от коллег :)

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

Так приятно, когда ребята уже сами замечают твои мета-схемы )

ФА ещё для меня была крайне интересна потому, что я сразу начал её прикладное применение. Уже и разобрался с value objects, почему они независимы от api моделей, как и почему не делать двойных одинаковых валидаций и т.д. Та мозаика, которую я сам нащупывал (я писал о предыдущем проекте в [...]), теперь после ФА сложилась в цельную непротиворечивую систему.
Я в неё реально погрузился с головой просто забыв обо всём остальном.
Кстати, хорошо что ФА закрыто для начинающих, мне кажется не познав болей на реальном проекте, невозможно по достоинству оценить саму ФА...

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

Первое впечатления от курса по теории категорий великолепное. Понимаю что треком «как понять в программировании все» вы мне заложили свинцовый фундамент. Помою тогда я еще плохо умел учиться и просто материалы из подготовительных постов в ВК конспектировал в тетрадку.

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

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

Я ровно с этой проблемой столкнулся на проекте [...], где мы пилили агентов (по СИ "156) First principle для внедрения AI в проект").
Так там ещё они постоянно пытались свои недоделанные приляпки заставлять использовать, вместо того же OpenTelemetry, но хотя бы да, двигались в правильную сторону.
Действительно, для недетерминированной системы старые методики наблюдаемости неприменимы.
Да более того, один из агентов как раз по метрикам был в полном порядке, но по факту нёс околесицу и дальше одного инструмента не уходил (а должен был минимум 3 использовать из 5).
Но тогда я чётко для себя понял что без тотального контроля что куда и почему разбирать поведение системы на проде, да и на тестовых контурах, невозможно.
Ещё заметил, что бизнес часто пытается внедрить GenAI туда, где бизнесово детерминированное поведение, которое можно однозначно посчитать, но вот требует потом точно такого же детерминированного поведения от недетерминированной системы.

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

Вообще за последнее время столько новой информации, что "голова" пухнет =)
Вроде только начал разбираться с SDD, а уже вижу spdd, openprose и что лучше пока не понятно.
Хочется попробовать всё, но время ограничено и не успеть (несмотря на то, что использование агентов пока позволило автоматизировать часть ручного труда и успеваю в рабочий день изучать новое) =)
С одной стороны - появилось забытое чувство радости от изучения нового, когда только начинал путь в айти.
С другой стороны - понимание, что каждая новая версия будет обесценивать часть проделанной работы за счёт того, что станет умнее. Но кажется здесь и нужно находить и сосредоточиваться как раз на том, что не зависит от модели (в частности о чём пишется в ФА).
Вообщем здесь ещё работать и работать, но хотя бы появилось некоторое начальное понимание...

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

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

Код весь hand made 100% (windows), задачки готовлю по заветам Теренса Тао в процессе тесного чатинга с продвинутыми модельками. Наверное можно и навайбкодить, но всё равно придётся редактировать и перепроверять, в каких-то случаях только SAT-солвер поможет (например, семантика Крипке), а в более тяжёлых логиках нужны более мощные модел чекеры (например TLA+ для темпоральной логики), а то и пруф-ассистанты.

Кстати с удивлением выяснил, что и в Lean4 и в Coq/Rocq и в Isabelle/HOL нишево формализованы лишь базовые логики (пропозициональная, классическая предикатов...), а едва например появляется фикс-поинт, автоматика исчезает, и надо много думать ручками интерактивно. Поэтому особо тут фиг навайбкодишь если не PhD (ну ладно, если не мехмат:), и это радует. Возможно придётся пилить свой прувер )

Название не придумал пока, например хорошо SATisfactory :) но занято.

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

Да, 80% пользы вы получите за 20% усилий: строгая система типов, функциональная архитектура, контракты в коде, property-based тесты. И логиком становиться совсем не обязательно, но мыслить спеками -- в терминах инвариантов, кванторов, состояний, переходов, живучести и безопасности, станет ценным навыком, потому что именно на языках логики точнее всего можно поставить задачу сетке, и проверить результат.

Я дал ребятам первые задачки потестить =>

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

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

Самое бесценное, а именно что из №... вообще не следует, что надо (агенту) бэкапы делать, мне пришло только вечером лежа в кровати :))
Спасибо огромное, 10 системных аналитиков из 10, мне прямо очень понравилось !!!

=

Из тренажёра:

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

— А как же они договорились о спецификации?
— Никак. Каждый вписывал свои пункты ночью, пока другой спал. Поэтому там "ровно одним способом" и рядом "неверно, что одновременно обоими".

На вторую неделю Олега допустили к продовой корзине. В «ОблакоСофте» корзина была местной легендой: товары в ней иногда исчезали, а иногда появлялись чужие. Пользователи писали в поддержку: "Кто положил мне в корзину шесть пылесосов?"...

Ещё там был спор про релизы: blue-green или canary. Одна фраза говорила "canary только с Prometheus и алертами", другая — "если есть Prometheus и алерты, то canary".
— Это же одно и то же, — сказал Олег.
— Вот и наш прошлый стажёр так сказал, — ответил тимлид. — Подправил спеку. Мы потом месяц катили релизы через blue-green при полностью настроенном мониторинге. Без резервного окружения.
— И как?
— Пылесосы...

ex falso quodlibet

.

Облако драгоценностей за неделю.

Во Вселенной впервые обнаружен Зеленый Фонарь!!1


Приватный клуб.

Молодой выскочка-начальник отчитывает тебя за то, что ты пишешь код старомодным способом, без нейронки? Так это справедливо!
Сегодня во многих компаниях, особенно стартапах, программисты работают со скоростью, которая считалась немыслимой всего два года назад. Сегодня же AI пишет 30-60-98% кода, и это нормально...

Уже 3 часа дня, и у вас открыто 7 запросов на доработку. Вы смотрите на быстрые исправления, объединяющие одно, и понимаете, что AI совершенно неправильно понял другое. Пробовать снова и снова. Большие задачи, над которыми вы поручали AI поработать в фоновом режиме, выглядят "почти выполнимыми", но это "почти" тянется часами...


Для донов-начинающих:

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

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

+ Начинаем качать темку "войти в ИТ системным аналитиком с ИИ без знания программирования"

Для донов-неначинающих:

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

Продолжаю набор на занятия для неначинающих (миддлы сеньоры), 3 места закончились за 1:18 минуты...

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

(все старые материалы для донов быстро сгорают)

=

Новые материалы для ментатов Лаборатории.

В раздел "Элитный программист" добавлен материал
104) Вглубь потока: прекрати борьбу (база)
Медленная, думающая часть мозга (S2 по Канеману) следит за вами во время работы: рассказывает о том, что вы делаете, сверяет это с правилами, пытается управлять каждым действием "вручную" (микро-менеджмент). Это ваша префронтальная кора осуществляет сознательный контроль, требующий усилий...
Вторая система S1 - автопилот: само по себе отработанное умение писать код без вашего участия. Он знает, как реализовать тот или иной проект, гораздо лучше, чем я могу себе представить...
Проблема заключается в том, что наблюдатель не хочет расставаться с ролью управляющего, и вот что с этим делать...

В курс карьеры добавлен 149-й материал "Инди-хакерство: финал".
Засада в том, что если вы прислушаетесь к типовым бизнес-советам, то снова окажетесь в очередном положении "с 9 до 18", работая над чужими проектами (если вы фрилансер/консультант), которые вы не любите, с людьми, которых вы не любите, за исключением того, что вы работаете теперь по 12 часов в день вместо 8, и всё равно не можете оплачивать счета за квартиру...

=

"Функциональные архитектуры" 183(+2) топиков.
Мета-рекомендации: CQRS для SDLC. Agile, Jira и Confluence в эпоху AI умерли, что теперь становится исполнительной системой, и почему бэклог перестаёт быть главным.

LPF закончен, куда и как дальше => тренажёр спецификаций (первая часть готово ~80%)

=

"ЛаМПовое":

AI-бизнес на засланных казачках, полиморфные типы в C++26, харнес база

=

Мы здесь, потому что это трудно. 💪🏻

=

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

"Охотники Дюны"

Айтишка сдохла, все программисты сошли с ума, переквалифицировываюсь в психиатры. В 90-е моей настольной книжкой была "Игры, в которые играют люди" Эрика Берна, а теперь её технологии можно мощно забустить теоркатом.
 
Родитель, Взрослый, Ребёнок - это объекты, трансакции - морфизмы.
Стимул-ответ похож на изоморфизм, т.е. по первому правилу коммуникации сценарий общения может продолжаться бесконечно.
Соответственно, два уровня игры (социальный и психологический) -- это два функтора из категории сценария, между которыми нету естественного преобразования. То есть вроде как социальный уровень выглядит согласованным, но в целом диаграмма-то не коммутирует.
 
Поглаживания -- это моноид, тогда взаимодействие - категория над этим моноидом, когда каждая стрелка имеет свой выигрыш, и отсюда мы напрямую попадаем в композиционную теорию игр. Имеем морфизмы в симметричной моноидальной категории, где скрытые выигрыши идут в обратную сторону через линзы (поэтому работает отказ "выплатить" обиду или вину).
 
В какой точке сценария то, что говорится на социальном уровне, перестаёт предсказывать то, чем это всё закончится?
База теорката: достаточно понимания чисто на уровне формы. То есть социальная диагностика эго-состояния (вспомогательная и ненадёжная по Берну) однако по лемме Йонеды полна! Например, выйти из текущей позиции в треугольнике Карпмана вполне можно, осознанно задав вопрос из Взрослого или пошутив из Ребёнка.
 
Ну а так как сопряжённый функтор единственен с точностью до изоморфизма, мы всегда можем вычислить игру партнёра.
 
А через категорию Клейсли мы можем увидеть, что антисценарий "делать наоборот" по-прежнему оплачивается старым выигрышем, пока мы остаёмся в этой категории (для выхода спросить например "чем это для меня закончится, и кому я это доказываю?"). И т.д.
 
Короче говоря, берновская игра -- это всегда отсутствие естественного преобразования, когда подтекст не согласован с текстом, и чем дальше они расходятся, тем жёстче игра.

Как быть? Заставить диаграмму коммутировать. Либо общение становится согласованным (не игра), либо игра разваливается, потому что выигрыш оппонента возникал только из рассогласования, и "выплачивать" ему больше нечего.
 
Если я отвечу на подтекст, а не на текст, сценарий пойдёт туда же? Если нет, против вас началась игра.
 
Если играете в подобные игры, заходите ко мне на консультацию )))

1. "Незаменимый"
— Вась, когда в отпуск?
— Был в 2019-м. Прод упал.
— Так ты же был в отпуске.
— Поэтому и упал.

2. "Пожарный"
— Давай настроим алерты, чтобы ночью не падало?
— А кто тогда будет героем в три часа ночи?

3. "Вечная миграция"
— Мы же переехали на Kubernetes?
— Почти. Сейчас съезжаем с него.
— Куда?
— Обратно на bash, но с AI.

4. "Вот разгребу техдолг"
— Когда в архитекторы?
— Вот разгребу техдолг.
— Тебе 52.
— Техдолгу 53.

5. "Крайний"
— Кто уронил прод?
— Я.
— Тебя тогда ещё в компании не было.
— Должен был предвидеть.

Пятница, 18:47. Гена, дежурный системный аналитик и по бесплатному совместительству девопс, уже взялся за куртку, когда в чате всплыло: «Бабушка из Сызрани заказала сорок семь чайников. Клянётся, что нажала один раз».

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

— Давайте просто сделаем доставку "строго один раз", — предложил продакт Артём тоном человека, который чинит интернет перезагрузкой.

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

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

— А что тогда можно?

— Выбор небогатый. Отправили и забыли - бабушка без чайника. Шлём, пока не подтвердят - бабушка с сорока семью чайниками. Третьего не дано, хоть все SLA перепиши.

Артём вздохнул.

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

— То есть надёжность мы не чиним, а переносим?

— Именно. С транспорта на алгебру. Транспорт у нас из кафки, балансировщиков и молитв, а вот алгебра из математики. Угадай, чему я доверяю больше.

Гена тем временем смотрел на дашборд, где три реплики показывали три разных числа чайников.

— А реплики почему расходятся?

— Сообщения приходят в разном порядке и разными пачками. Одна реплика сначала свернула A с B, потом добавила C. Другая сложила B с C, а A прилетел позже, через Франкфурт пешком. Если операция ассоциативна, а лучше ещё и коммутативна, то неважно, как сгруппировали. Это независимость от топологии вычислений. По сути, ассоциативность и решает, можно ли это вообще параллелить: раздал куски по узлам, собрал как угодно, ответ тот же.

— Звучит как магия.

— Магия — это когда вы говорите «давайте ещё раз ретрайнем». А тут просто свойства. Смотри: путей, которыми реплика могла прийти к своему состоянию, бесконечно много. Дубли, перестановки, задержки, разрывы сети, Гена, случайно перезапустивший под. Бесконечное множество путей исполнения. А нам на них плевать! Нас интересует одно: в конце состояния одинаковые.

— Это как… убывание ранговой функции? — неуверенно спросил Гена, который недавно осилил полстатьи по линейной алгебре.

Палыч посмотрел на него с уважением, которого Гена не видел со времён собеседования.

— Ровно так. Сжимаем бесконечные чередования, ретраи, сообщения до конечных состояний (просто натуральные числа). Ранг работает как абстракция - число оставшихся шагов/раундов, приоритет/дедлайн... Строгое убывание доказывает завершимость и отсутствие "голодания". А ассоциативность, коммутативность и идемпотентность гарантируют, что при сжатии мы ничего не потеряли и лишнего не придумали.

К 21:58 счётчики переписали на идемпотентный мерж. Реплики сошлись. Бабушке отправили один чайник и промокод с извинениями.

Сеть продолжала дублировать сообщения, но теперь это никого не волновало.

Артём написал в общий канал: «Инцидент закрыт. TODO: изучить задачу двух генералов».

Палыч дописал: «И перестать быть третьим генералом, который бесконечно жмёт "отправить ещё раз"».

Гена надел куртку. Было 22:22. Пятница почти не пострадала.