Я долго размышлял на данную тему и наконец решил изложить.

Вся эта история с оценкой кода по количеству написанных строк или другие попытки оценить объем работы мне всегда не давали покоя.

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

Придешь утром в офис и начинаешь что-то писать. А вечером мне нравилось иногда нажать ctrl+z и смотреть в ускоренном темпе, пусть и в обратном порядке, как бегал курсор, как выделялись, появлялись и исчезали какие-то блоки кода. Сначала условие и цикл появились в одном месте, потом кусок кода из цикла перешел в процедуру, цикл вообще исчез и т.д.

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

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

Здесь не будет инструкций как я это сделал. Здесь будет просто рассуждение вокруг да около.

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

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

Тема ИИ — это какая-то золотая лихорадка 21 века. Каждый стремится не упустить волну хайпа. ИИ пытаются внедрить везде, где только можно и нельзя.

Одно из популярнейших направлений — разработка. Заменить дорогостоящих разработчиков. Разве может быть что-то более привлекательным?

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

Даже появился отдельный термин — вайб-кодинг. Но опасность кроется не в самом ИИ, а в способе его применения из-за непонимания природы.

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

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

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

Осторожно, статья-детектор.

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

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

Если вы один из счастливчиков, у кого каталог действительно взлетел, можете дальше не читать. Однако что-то мне подсказывает, что таких будет не много.

Осторожно, статья-детектор.

Однажды я заехал в гости к знакомому — владельцу цеха по металлообработке и невольно оказался свидетелем скандала. Произошло это в день зарплаты.

Чтобы был понятен контекст, немного опишу суть процесса.

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

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

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

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

Продолжаю цикл статей из серии давно минувших дней.

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

2010г: по семейным обстоятельствам я оказался в глубоком финансовом кризисе. У меня не было денег даже на бензин. Один знакомый мне предложил поработать у них в отделе 1с-ником. Оплата была небольшая (по сравнению с рынком). Я согласился поработать у них несколько месяцев, пока не найду нормальное место, такой и был изначальный уговор. В отделе 1С было 3 человека, я стал четвертым.

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

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

В том отделе 4 человека. Одна из их задач была подбирать копейки для счетов-фактур. Чтобы строки с итоговой суммой сходились. Ну вы знаете про округление. Для этого у них был целый инструмент - документ в 1С аж с десятитысячными долями в ценах! Они там сидели вручную подбирали десятые доли копеек. Этот процесс был легендарным. Считалось, что его нельзя автоматизировать - кто ни пробовал, ни у кого не получалось, так мне сказал начальник.

Да как так? Не может такого быть! Я-не-ве-рю! Покажите!

Вы видели такие токарные автоматы? Это шестишпиндельный 1Б240-6 револьверного типа. Очень старый девайс, полностью механический, на концевиках и реле. Никаких тебе ЧПУ, лазеров и шаговых двигателей, только хардкор. Это просто потрясающая механическая симфония.

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

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

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

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

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

Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.

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

В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.

Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.