Журнал инженера-программиста

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

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

Пара примеров для наглядности:

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

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

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

Попробовал найти ранние упоминания выражения:

Автоматизация неэффективной операции увеличивает неэффективность (с) Билл Гейтс, книга "Бизнес со скоростью мысли", 1999 год

Истоки реинжиниринга лежат во фразе, которую один из нас сформулировал еще в конце 1980-х годов: "Автоматизация бардака дает лишь автоматизированный бардак" (с) Майкл Хаммер, книга "Реинжиниринг корпорации: Манифест революции в бизнесе", 1993 год

Таким образом истоки фразы и ее активное применение были даже не в начале 90х, а в 80х или даже в 70х. А что мы знаем про ИТ прошлого века? Верно - методология водопада! Т.е. ранее действительно нужно было написать всю документацию, а потом выполнять разработку буква-к-букве как в ТЗ.

Но старый ватерфлоу не выдержал проверку временем. Подходы начали меняться сначала как раз в ИТ, а далее гибкие методики планирования и проектирования подхватили другие сферы. Даже в ультраконсервативном PMI сдались в 2017 году и включили Agile-практики в 6-ю редакцию PMBOK. А суть гибких подходов как и заключается в том, что нужно перестать пытаться делать сразу идеально, а лучше сделать упор на анализ результатов и в следующую итерацию исправлять ошибки предыдущих подходов.

Так стоит или нет автоматизировать хаос?

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

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

#методология #проектирование #холивары

Уже второй проект на работе делаю в методике "парного программирования" с Claude Code. И сразу хочу отметить, что последние модели Sonnet 5, Opus 5, Opus 5.5 и Fable 5.1 уже превосходно знают платформу 1С и им для работы не нужны никакие дополнительные MCP со справкой.

Но пусть Claude и стал "программистом 1С", но он при этом самый настоящий джуниор и требует менторского присмотра. Чесно говоря, я так много не разжёвывал материал даже когда был наставником для сотрудников-людей.

Очень важно при ревью не исправлять самостоятельно ошибки логики, оформления кода или структуры элементов на форме, а каждый раз говорить ЧТО не так и ПОЧЕМУ это не правильно. Мы с Claude каждую ошибку рассматривает, описываем ее в правилах, а далее агент проходит по ранее сделанному и вносит правки во все похожие места.

Я слышал от коллег и читал в обсуждениях, что многие жалуются на говнокод от ИИ и потому отказываются с ним работать (не важно какая модель). Но ведь и живой студент-стажер без присмотра вам в базе может такого понаписывает, прикрываясь красивыми словами про SOLID и YAGNI, что потом поседеете.

#работа #ИИ #1C

За последний месяц произошло много событий, но наиболее интересным является использование LLM для программирования на платформе 1С.

В августе я активировал бесплатную неделю для Claude от Antropic и не успел отменить подписку в последний день - так у меня для тестов появился оплаченный месяц Pro.

Итак к интересному.

У меня есть два параллельных проекта на разработку примерно одинаковых по размеру подсистем, но использую LLM я немного по разному. Для первого проекта у меня выгрузка в файлы, где модель по моим указаниям вносит правки, после чего я делаю загрузку из файлов. Во втором проекте у меня конфигурация с расширением развернуты в EDT, куда подключен EDT-MCP с полным доступом.

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

1) Если править файлы на диске, то Sonnet 5 показывает себя крепким мидлом с задатками сеньора - минимум ошибок, интересные предложения для улучшения эффекта от выполнимых задач. Ранее в рамках Google Pro у меня в Antigravity были доступны модели Sonnet 4.6 и Opus 4.6 - так тут просто небо и земля, Sonnet 5 намного-намного превосходит в интеллекте Opus 4.6. И самое восхитительное, что теперь для качественного 1С кода больше не нужно ни доступа к Синтаксис-Помощнику, ни к платформенной проверке на ошибки. Мелкие ошибки быстро исправляются, я о них сообщаю ИИ и тот фиксирует их в памяти сессии и специальном служебном файлике на диске, который я подключаю между сессиями.

2) При редактировании через MCP я использовал сначала Sonnet 5, а потом Opus 5 - не смотря на доступ к документации платформы и продвинутым внутренним механизмам контроля из ядра EDT, у меня стойкое ощущение, что работаю с глуповатым джуном. Я даже попробовал этот же проект на Fable от корпоративной учетки - не сильно лучше.

3) По данным Claude Code из расхода первого проекта 88% уходило на файловые операции, а все остальное на понимание и обсуждение проекта. Во втором проекте на выполнение MCP-вызовов ушло 97%

4) Задачи все же немного разные в проектах и потому некорректно прямое сравнение по токенам, но перерасход в проекте с MCP минимум в 10 раз больше. Я воспользовался встроенным скиллом "/anthropic-skills:explain-usage" и получил ответ: Большая выгрузка метаданных или скриншот формы остаётся в памяти беседы и перечитывается на каждом следующем шаге. Чем длиннее сессия, тем дороже каждый новый шаг.

В принципе логично. Отредактировать форму прямой заменой XML в файле и ее же отредактировать серией вызовов точечных инструментов через MCP с проверкой получаемого результата через снятие и анализ скриншотов - подобное просто безумно сравнивать и второе очевидно будет прожорливым до токенов.

Итоговый вывод.

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

Уже есть понимание, что "золотая середина" будет как раз в разумной комбинации подходов. Когда в работу попадет третий проект, то я через MCP оставлю только справку, корневое редактирование метаданных и финальный линтер с анализом ошибок конфигурации, а все остальное будет только по прямому редактированию файлов из каталога проекта EDT.

#1с #edt #llm #mcp #vibecode

Самая обычная бумажная книга учета - это пока лучший инструмент фиксации проектных изменений из всех, с которыми я сталкивался за свои более чем 20 лет стажа в ИТ!

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

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

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

===

Только один раз все было ясно и понятно! Тогда я обслуживал бухгалтерские досовскими программами на Foxpro и у нас был один клиент, к которому за Киев нужно было ехать на автобусе. Бухгалтерия там состояла из классических Марьивановних, которые только-только сняли меховые шапки и едва начали экспериментировать с новыми понтами в виде накладных ногтей и выщипанных бровей. Рабочие машины были с маленькими пузатыми мониторами и клацающими механическими клавиатурами, а для печати - огромный матричный принтер. А еще нужно было каждый визит фиксировать в специальной книге учета модернизации ПО.

Да, это та самая волшебная книга!

По договору обслуживания каждый приходящий специалист был обязан зафиксировать в специальном журнале учета: ФИО, дату, цель визита, обнаруженные проблемы, перечень вносимых улучшений, какие именно правки в каких модулях и с какой целью выполнялись. Дополнительно мы в этот журнал вписывали теоретически возможные проблемные ситуации и как их решить в будущем. Эту книгу читали сами пользователи и пытались самостоятельно разобраться перед вызовов специалистов (так как вызовы были платными). По прибытию специалист сперва всегда брал этот журнал и смотрел кто какие правки недавно вносил и не могут ли они быть причинами проблем. И обычно информации из журнала было более чем достаточно даже для джуниоров (кем я был, когда приехал к ним в первый раз и увидел этот спасительный гросбух). А в самых сложных случаях можно посмотреть кто в базе ранее работал с подобной проблемой и позвонить за советом.

===

Согласен - немного слукавил 😅

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

Вся магия там была не в инструменте, а в процессе!

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

Очень показательная причина моей нелюбви реализации сравнения/объединения конфигураций в 1C:EDT - постоянно вылазят изменения внутренней XML-структуры, которую без внешнего редактора никогда не увидишь.

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

P.S. В ситуации на скрине из EDT была полной загрузкой обновлена конфигурация подключенной базы, в базе выполнены некоторые правки в режиме Конфигуратора, после чего выполнена попытка загрузки изменений назад в EDT

#будни #1с #edt

О концепции LLM-Wiki я впервые прочитал на X (Twitter). Чтобы позже ознакомится детальнее, я заложил в закладки и... так там эта заметка до сих пор лежит непрочитанной 😅

Но чуть позже на DOU я прочитал не еще раз про эту концепцию, а уже про ее конкретную реализацию от Андрея Богдановича (некий чиновник одной из госинспекций) с ссылкой на GitHub - а этот материал уже можно было брать за основу 💡

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

Но тратить время на выгрузку всех статей в читаемом виде в inbox не хотелось и потому первым моим улучшением концепции стало добавление служебного \inbox\urls.txt , в который можно было закидывать пачки ссылок и они далее самостоятельно выгружались в базу в виде документов. На днях еще улучшил механизм - добавил склеивание результатов нескольких ссылок в единый документ для многостраничных статей, а для X добавил механизм выгрузки связанных твиттов для постов-тредов.

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

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

В реализации от Богдановича оригинальные материалы из inbox/ в raw/ переносились самим ИИ на этапе импорта. Но мне это показалось странным - недетерминированное поведение самого агента плюс трата токенов. Поэтому у меня перед импортом добавлен этап подготовки, где Python скрипт скачивает статьи по ссылкам, вытаскивает содержимое мультимодальных файлов и так далее, а потом сам все размещает в raw/. В результате, для ИИ остается только проанализировать новое и записать в базу.

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

Поскольку проект LLM-Wiki перестал быть просто коротким набором скриптов и скилов для ИИ и определенная база знаний уже набралась (которую было бы жать потерять), поэтому возникла необходимость в инструменте обновления. К проекту был добавлен файл манифеста с указанием всех служебных файлов и их хеши, чтобы при обновлении все файловые операции были максимально прогнозируемыми и безопасными (у скрипта обновления даже предусмотрен холостой запуск для предварительного просмотра плана обновления). Теперь обновление максимально простое - из каталога проекта запустить скрипт scripts\update.bat на вход которого подать путь к zip-архиву нужной версии с Github

====
Даже не знаю, что мне во всем этом больше принесло удовольствия - создание и развитие собственного ИИ-агента для ведения базы знаний, или что я наконец-то стал разгребать свои залежи ссылок и наконец-то закрыл большую часть закладок в своей браузере 😂

Если интересно ознакомится с результатом:
https://github.com/DementorAK/llm-wiki/

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

Я - обычный человек, который не обладает ни скорочтением, ни фотографической памятью, ни прочими тайными суперсилами обладателей кубков ЧГК. А следовательно вокруг всегда намного больше материалов, которые я хотел бы изучить, чем времени на изучение. Да что там "изучить" - иногда не хватает времени даже просто бегло ознакомится.

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

Но с ссылками было несколько проблем: 1) для их чтения все равно нужно было выделять время, 2) теперь нужно было выделять время на просмотр кучи ссылок и выбор "чего бы почитать", 3) материал по ссылкам перемещался или удалялся. Последнее вообще обидно, так как в разделе изучения иностранных языков у меня до сих пор десятки ссылок на интересные материалы на форуме Duolingo, который закрыли более десяти лет назад (((

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

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

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

В конце-концов я просто перестал сохранять ссылки, раз я их вообще не читаю. Я просто в браузере стал держать открытыми закладками страницы, которые хотел бы посмотреть. А если новые закладки переставали помещаться, то выборочно открывал видимые и или читал, или принимал решение о закрытии без чтения (всего же не прочитаешь). Казалось бы, что времени жизни страниц на закладках должно было хватать для чтения, но даже так временами открываемые страницы вели на отозванные ДНС или на закрытые проекты с постмортем и прощанием.

Собственно мой интерес к #Zettelkasten и #Obsidian был именно в этом контексте - т.е.еще одна попытка каталогизировать информацию и выработать систему, чтобы перестать терять интересные материалы и иметь к ним быстрый доступ. И первые попытки вновь оказались не особо удачными...

...А потом я услышал про концепцию LLM-Wiki от Андрея Карпаты и пазлики наконец-то сложились!

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

Но по настоящему интересным моментом прошлого поста был вопрос: почему я в Хмельницком???

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

В связи с усилением обстрелов Киева баллистикой, от которой не умеет смысля прятаться и которая уничтожает цель в течении минуты после объявления тревоги (а иногда и вовсе без тревоги), в связи с анонсами скорого применения "Орешника" и заявление о вероятности использования ТЯО, а так же в связи с признанием руководства страны и столицы о неготовности встретить зиму, мы на семейном совете решили начать беречь нервы и сменить место пребывания на более мирную локацию.

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

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

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

#offline #irl

Не угадаете где я сегодня был и сделал этот кадр.
Нет не в компьютерном городе 🤓

Это был блошиный рынок, который собирается каждое воскресенье в парке имени Ивана Франка в Хмельницком. Нигде и никогда (даже в Киеве) я не видел настолько огромную барахолку.

Такое ощущение, что это одновременно филиал Петровки (старые книги, виниловые диски), Кардач (радиотехника, старые фотики и мобилки), Нивок (монеты и медали) и Андреевки (картины, бусы, керамика). Ощущение музея под открытым небом - униформа различных служб и их же служебные удостоверения, рядом боевые топоры и мечи, далее швейные Зингеры и прочие прялки, за которыми бесконечные альбомы с марками и значками, после которых ряды столового серебра. Продавцы музыкальных инструментов тут же дают живой концерт на своих баянах и барабанах. Ящики со старыми игрушками, среди которых Трансформеры, Барби и даже Тетрис. Финалочкой легендарный графинный набор "Рыбки" )))

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

#offline #irl

У Сергея Сыпачева вышло очередное вдохновляющее интервью - Конец эпохи 1С? Один промт — и готовая конфигурация за вечер

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

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

#1С #ИИ #AI

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

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

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

#offline #irl

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

Зафиксирую текущие события:

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

В следующий раз такой накладки не будет, так как сегодня ночью во время самого массовой баллистической атаки (41 ракета в течении 40 минут) ее торговую точку сравняло с землей и она теперь снова безработная и может ждать комиссию в любое время.

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

3) Моя отсрочка от призыва вернулась в Резерв+ и вероятность стать учасником "бусификации" стала существенно ниже (хотя в наше время ни от чего нельзя зарекаться).

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

5) Мои анализы существенно не изменились и все далеки от нормы, но имеют тенденцию к стабилизации. Например тромбоциты (норма 150-400) в течении месяца у меня по чуть-чуть уменьшаются: 723 -> 702 -> 667. Всего 10 показателей далеки от нормы. Даже если я месяц ел фальсификат вместо лекарств, то последствия хотя бы обратимы.

#войнаимир #offline #irl

Поучаствовал в дискуссии на Линкидин с одной участницей, которая написала пост про "Не верю людям, которые говорят, что работают по 8 часов в день - проверено собственным опытом и у меня так никогда не получается".

Там было упущено сразу два важных момента:

1) если ты никогда не работал по 8 и более часов в день, то для тебя действительно такая нагрузка является неподъемной. Это как прийти в спортзал и в первый день пытаться жать сотку, если ранее даже гантели десятки не пробовал поднимать. К нагрузкам нужно постепенно привыкать. Если бы авторка поста как я одновременно ходила в обычную школу и музыкальную, после занятий ездила работать на дачу и перед сном помимо уроков успевала читать интересные книги, то просто не существовало вопроса о непосильной сложности 8 часов кликать мышкой.

2) нельзя ничего мерять по своим силам и даже по силам своего окружения. Ведь так можно сказать, что все олимпийский призеры на допинге, ведь ты без допинга не сможешь достичь тех же результатов (да и допингом тоже не сможешь - значит все состязания подстроены). Если у тебя вдохновения хватает лишь написать парочку постов в интернете, так значит все эти Гюго, Дюма, Джеки Лондоны и Стивены Кинги на самом деле тоже не писали свои романы, а нанимали армии литературных рабов для титанического труда в сотню страниц.

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

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

Снова заметил ощущение "скрытой шизофрении".

В то время, как Нуралиев и его "апостолы" утверждают, что EDT должен быть основным инструментом разработки вместо Конфигуратор, развитие которого остановлено много лет назад, в это же самое время сама EDT-команда считает, что делает только инструмент для вендоров тиражируемых решений. Поэтому потребление памяти не является проблемой, так как запуск EDT планировался лишь на оборудовании разработчиков, системные требования к которому на голову выше чем требования к оборудованию для запуска 1С:Конфигуратора. Поэтому годовое (иногда больше) отставание по поддерживаемым версиям платформы - ведь вендорам не важно на новые функции и исправления ошибок, если они должны поддерживать свои решения на старых платформах, а значит с поддержкой новых версий в EDT нет повода спешить. Работать в EDT должны не все подряд, а только лучшие из лучших, а следовательно нет смысла делать юзер-френдли интерфейс и понятную документацию, а поиск причин возникающих при сборке конфигураций в гигантских java-stacktrace никого не смутит.

Чтобы лично я сделал по другому?

1) Если хватает людей, то я бы поменял отношение к командам, которые уже используют EDT - это не должны быть враги, которые закидывают багами и портят планирование бэклогов. Это должны быть друзья, которые делятся уникальным опытом. Нужно "навести" мосты с разнообразными командами, которые ежедневно применяют EDT в своей работы - это море опыта, неочевидных лайвхаков и свежего взгляда.

2) Если людей в команде нет, то сделать акцент на доработке системы плагинов. Текущая документация не актуальная, не полная и содержит ошибки; стандартная установка среды разработки плагинов содержит ошибки и по факту не отличается от обычного Eclipse for RCP and RAP Developers (в котором уже можно подключить ИИ). Все работает крайне не стабильно - пока я сам пробовал разрабатывать плагин, то у меня трижды слетали файлы платформы и их нужно было заново закачивать с сервера 1С, что занимало почти сутки (у меня тогда еще свет часто отключали); а так же при работе было множество мистических ошибок, победить которые можно было лишь магическими ключиками для конфигов, которыми делились в чате разработчиков. А ведь это могла быть золотая жила! Если бы каждый с легкостью мог создавать плагины для облегчения своей работы, то это лучше всяких опросов показало бы вектор будущего развития EDT и самые популярные идеи можно было бы постепенно включать в вендорскую сборку.

#разработка #1С #EDT

❓ Почему так мало постов?

Мои старые читатели помнят, что ранее я не мог сдержаться и писал почти каждый день (иногда по несколько заметок в день). Неужели у меня пропало вдохновение? Нет, причины лежат в оффлайне.

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

2) Накануне годовщины с квартирой тещи несколько реактивных беспилотников влетели в соседний дом бабушки моей жены. Бабушка не пострадала, так как успела умереть месяцем ранее. А вот теще не повезло - она как раз приехала посмотреть на ущерб после первого прилета, когда произошла новая атака со взрывом, ударная волна которого довыбивала остатки окон и засыпала тещу осколками стекла. В доме ОСББ и жильцы сразу подали коллективный запрос на компенсацию, который сразу отклонили - денег нет!

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

3) Рейды ТЦК по Киеву ужесточились. Буквально вчера услышал крики из окна и выглянув увидел классическую картину. "Группа оповещения" схватила в парке парня, который выгуливал собаку. "Добровольца" вместе с его собакой силой засунули в серебристый фиат на глазах продавцов и покупателей нашей сельскохозяйственной ярмарки, и те попытались отбить парня - кричали, стучали по стенам машины, пытались перекрыть дорогу выезда из парка. Но видимо премии за поимку были важнее и бусик начал газовать прямо на протестующих, так смог вырваться из окружения и уехал с добычей.

4) Моя отсрочка от призыва действует до 30 июня (т.е. прекратится через три дня). Следующую должны были дать автоматически по моему запросу через Резерв+, но на днях Минообороны сообщили, что отключили связь с госреестрами и получение отсрочек онлайн не будет работать какое-то неопределенное время...

5) Моя болезнь крови обострилась и последние три недели все анализы очень плохие. Пытаемся с моим семейным врачом и гематологом понять причину, но пока безрезультатно отмели две гипотезы с сопутствующими заболеваниями. Видимо проблема сложнее. Чтобы сдерживать болезнь, я принимаю дорогие препараты по тысяче баксов в месяц - покупать с рук у перекупщиков на 10-20% дешевле чем в аптеках, но есть риск попасть на подделку. Если я ел подделки месяц или два, то это очень плохо и болезнь имела время адаптировать к лекарствам...

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

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

#войнаимир #offline #irl

Просто знать о факте существования технологий не достаточно. Без практики любое знание ничего не стоит!

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

Прекрасный и вдохновляющий пример - Владимир Харин (@vladimir_kharin), который рассказывал о применении Cursor для 1С, задолго до того как благодаря Олегу Филиппову это стало мейнстримом.

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

Все, что Владимир описал в своем докладе логично и каждый мог сам догадаться до конкретных элементов. Магия приходит, когда все это применить в едином системном подходе. Именно так и должен работать ИИ в 1С, а не вот это вот всё со сборкой в Cursor очередной одноразовой обработки.

#1С #ИИ #AI

В комментариях к предыдущей записи @Cryptabuser888 спрашивал почему в Украине до сих пор не написали аналог 1С.

Как мы видим, наличие огромного штата разработчиков, и еще большего количества внедряющих партнеров, и сотни тысяч клиентов за несколько десятилетий так и не сделали решения 1С идеальными. До сих пор "Шаг влево, шаг вправо" => баги сразу во все стороны как тараканы в общем вагоне.

Мало кому хочется быть подопытной свинкой, чтобы своими деньгами оплачивать отладку на своем бизнесе экспериментов от ноунеймов. А лицензии от SAP, Oracle и Microsoft неплохо кусаются и никто почему-то не хочет проспонсировать переход украинского бизнеса с 1С на "западные аналоги".

🟡 Соскучились по ошибкам из мира 1С?

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

[ОшибкаВоВремяВыполненияВстроенногоЯзыка]
kaynağı:
{(30, 2)}: Sözdizim hatası "İç"
<<?>>İç СОЕДИНЕНИЕ РегистрСведений.ГражданствоФизическихЛиц КАК РегистрСведений

Проблемы, как вы уже догадались из текста ошибки, только у пользователей с турецким языком системы (сам ЗУП на русском).

Стеки вызовов ошибок ни о чем не говорят. Где-то внутри ЗУП его 100500 функций формируют текст запроса согласно настроек, функциональных опций и прав доступа, а на выходе в результирующем запросе вместе строки "ВНУТРЕННЕЕ СОЕДИНЕНИЕ" почему-то "İç СОЕДИНЕНИЕ". Но при этом в моем англоязычном интерфейсе все работало, а включать ради тестирования турецкий язык системы я не решался...

Подсказкой для поиска стало то, что во всех ошибках в строке псевдоним задавался как "РегистрСведений". Я выполнил поиск по конфигурации и нашел все 6 мест, где для присоединяемой таблицы задавался такой алиас - это были шаблоны запросов, которые далее скармливались в ЗарплатаКадрыПериодическиеРегистры.ОписаниеЗапросаПоТексту(), а там шаблон передавался схеме запроса и на базе этого объекта делалась верстка нового запроса:

Для Каждого ИсточникСхемы Из Оператор.Источники Цикл
Для Каждого Соединение Из ИсточникСхемы.Соединения Цикл
ОписаниеСоединения = СтруктураОбъединяемогоЗапроса.Соединения.Добавить();
ОписаниеСоединения.ВедущаяТаблица = ИсточникСхемы.Источник.Псевдоним;
ОписаниеСоединения.ПрисоединяемаяТаблица = Соединение.Источник.Источник.Псевдоним;
ОписаниеСоединения.ТипСоединения = Строка(Соединение.ТипСоединения);
ОписаниеСоединения.Условия = Новый Массив;
ОписаниеСоединения.ПорядокСоединения = ПорядокСоединения;
КонецЦикла;
КонецЦикла;

По листингу видно, что в свойство ТипСоединения для описания нового соединения закидывалось представление, которое получено из ТипСоединенияСхемыЗапроса.Внутреннее (QuerySchemaJoinType.Inner) с помощью функции Строка(), которая возвращает представление согласно региональных настроек пользователя (для турецкого это "İç"). Платформа 1С поддерживает 23 языка для отображения представлений внутренних значений, но язык запросов поддерживает только русский и английский.

#1С #баги

При работе с платформой 1С есть три типа ошибок: 1) ошибки пользователей, 2) ошибки платформы и 3) ошибки обстоятельств 🧐

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

===

Ко мне обратилась наш аналитик посмотреть проблему на форме договора с исчезновением одного старого поля, которое давно никто по задачам не трогал. При чем у записанных договоров поле показывается и отсутствует лишь для новых, что в купе с "обязательностью для заполнения" заблокировало создание элементов справочника.

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

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

Подобное поведение очень похоже на работу расширения, но расширений в базе не было. Хотя может кеш? На всякий случай для промежутка вызова проблемной процедуры запустил "Замер производительности", но в отчете были только шаги внутри процедуры с явной установкой видимости в Истина. Т.е. некая сверхъестественная сила решила менять видимость у элемента, но только при условии, что Объект.Ссылка указывает на пустую ссылку, а иначе не мешает 👻

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

Открываю XML формы, нахожу новый элемент, смотрю его айдишник, делаю поиск по форме и БИНГО - это тот же айдишник, что и у группы, которая внезапно начала терять видимость. Истинной причиной паранормального поведения формы было, что при тестировании фичевых пулл-реквестов образовалась небольшая очередь, в результате которой было паралельно создано два пулл, в первом из которых добавлена новая группа, а во втором с тем же айдишником добавлено новое поле. Каждая из двух веток сама по себе работала верно, но их мерж в основной проект испортил форму (не в первый раз). После исправления задублированного айдишника все заработало 👍

===

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

#1С #полтергейст #баги