Ситуация на фото не очень... А ведь это правда!

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

А почему бы свои мысли на английском по горячему не записывать?

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

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

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

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

И знаете что? Я внезапно увидел четкую аналогию между письмом на иностранном языке и ПРОГРАММИРОВАНИЕМ! 👨‍💻

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

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

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

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

Как же все это похоже на написание программного кода!

1) мы не думаем программным кодом, сперва у нас есть концепция алгоритма на родном языке, который мы "переводим" в понятный машинам листинг.

2) часто в поисках общепринятых качественных образцов стандартных действий мы посещаем сайти типа Stack Overflow и Инфостарт, откуда копипастим себе подходящие фрагменты кода, иногда перефразируя их для единого стиля с основным кодом (отступы, стиль наименований и так далее)

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

4) еще до взрывной популярности ChatGPT в 2022 году среди программистов уже были популярны решения по кодогенерации типа GitHub Copilot, которые писали относительно рабочий код по описанной человеком концепции. А идеи автоматического создания кода на базе UML-диаграмм обсуждали еще в 90х и у Rational Rose десятилетия назад были рабочие наработки для C++, Java и Visual Basic

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

В последнюю неделю вижу эту веселую картинку и в Твиттере, и на Фейсбуке.

Очевидно игнорирование оригинального определения квадрата из евклидовой геометрии и подмена "определением на пальцах".

Квадрат - это равносторонний прямоугольник.

Прямоугольник - это параллелограмм с прямыми углами.

Параллелограмм - четырехугольник, у которого противолежащие стороны попарно параллельны.

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

Отрезок - часть прямой, ограниченная двумя точками.

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

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

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

Правильное ТЗ важно!

Вы читаете ленту новостей Google? Та самая, которая встроена в виджет рабочего стола в большинстве Андроидов, и она же показывается в Google Chrome на новой странице. Довольно интересное занятие. Ведь Google по истории моего поиска фиксирует мои интересы и приносит то, что по его мнению меня должно зацепить.

Сегодня в ленте приплыла статья ООП: худшее, что случалось с программированием. И как же она зацепила!!! И не только меня - в комментариях открыт портал в Ад 😈

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

Все началось с того, что автор решил начать учить ООП на примере C# и пошел на собеседование (!). В качестве проверки знаний ему задали примитивную задачку на понимание жизненного цикла объекта. Автор не смог ответить и на всю жизнь обозлился на ООП.

Сразу стоп! Когда я учил ООП, то сперва прослушал курс лекций в университете на факультете информатики, где ООП давали во втором семестре, после того, как мы полгода изучали процедурную парадигму. Далее пройденные концепции мы закрепляли в виде лабораторных. А к моменту, когда я взял деньги за свою первую программу на C++, я уже не просто "умел программировать", но понимал цель инструмента и для каких целей он необходим. Автор статьи, не понимая в принципе концепцию ООП и не зная синтаксиса языка C#, сразу попробовал пойти работать!?

(не влезло на одну страницу)

В начале статьи дается глоссарий и не зря. Дело в том, что автор в духе классического "#Define TRUE FALSE" переопределяет базовые концепции из сферы Компьютерных Наук. Он называет процедурный (императивный) стиль программирования - Функциональное Программирование. И далее начинается треш и угар.

Вторая остановка. Поясню терминологию.

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

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

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

Далее с примерами на известном автору языке TypeScript он приводит ряд спорных тезисов, которые очень аргументированно опровергаются в комментариях, среди которых отмечу комментарий от markelov69 и от WhtsPoint.

Но знаете, что тут самое забавное? TypeScript - это далеко не чистый функциональный язык (и не чистый процедурный язык, если следовать подмене понятий автора)! TypeScript - это типизированный диалект JavaScript, в котором ООП уже изначально присутствовало на прототипах, а с ECMAScript 2015 классы уже объявили официально (по факту все те же прототипы). Т.е. ООП-язык использовался для противопоставления практикам ООП 🤦

(окончание)

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

Но больше всего настораживают не глупости, а невежество! Среди комментаторов тоже попадаются люди, которым текст статьи созвучен и которые в нем не видят никаких проблем. Они так же юношески категоричны и защищают свои неоднозначные убеждения.

А ведь на самом деле - нет никакой идеальной парадигмы и нет никакого идеального языка программирования! Если бы такой появился, то про все остальные тут же забыли. Но как мы видим, вымирают только откровенно слабые языки, которым есть достойная альтернатива (в вебе Perl заменили PHP и Ruby, в бизнесе COBOL уступил место Java и C#, в науке вместо Fortran стали использовать Python и Julia).

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

У меня есть знакомый Паша, программист на C/C++/Rust в сфере систем безопасности. В прошлом году на одной из посиделок я рассказывал о трендах в экосистеме Телеграма - упомянул про популярный Хомяк, которым бредили все косметологи, парикмахеры и сантехники. На вопрос "а вы смотрели?" Паша тогда рассмеялся - "нет, конечно, я же не лох, чтобы верить в деньги из воздуха".

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

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

Самым же худшим проявлением ТМА стали "майнеры", хотя сам Павел Дуров лично пару раз прорекламировал MemHash. Суть майнеров - вы должны платить деньги за право "майнить", но при этом вы будете "майнить" медленно пока не заплатите за "апгрейд железа", но если большинство "проапгрейдится" лучше чем вы, то вы ничего не будете получать пока не сделаете новые "апргрейды". Такие майнеры не запускали только самые ленивые. Среди "новинок дня" от "Telegram Apps Center", я видел не меньше десятка вариантов. Полностью согласен с Денисом Субботиным (популярный крипто-эксперт, разработчик TON API), который утверждает, что это уже не игры с донатам, а полноценные инвестиционные проекты, т.е. тут нет удовольствия от "игрового процесса", а есть исключительно занос денег с целью получить деньги.

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

P.S. Картинка ниже - это не настоящий скриншот канала Дрова, а пародия, которая сейчас ходит по чатам.

Помните, как месяц назад я отметил, что обещание тарифных войн США против крупнейших партнеров обвалило крипторынки и спровоцировало отток ликвидности в реальную экономику?

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

С другой стороны я могу понять Казначейство США - не будут же они покупать крипту в свои резервы по завышенной спекулятивной цене - нужны скидки. Еще больше скидок! А следовательно нужно еще больше скандальных заявлений от первых лиц американской сверхдержавы.

Недавно посмотрел ролик Владимира Харина (автор тг-канала Просто Про 1С) про разработку в 1С с помощью Aider.

Первая мысль: тоже хочу попробовать. Вторая мысль: что-то сложно все как-то и точно не для удобной ежедневной работы. А что если упростить и загнать всю логику в плагин для EDT, в котором я сейчас провожу примерно 50% времени разработки?

Я помню, что на Инфостарте было много статей о разработке плагинов, и на сайте ЕДТ тоже есть документация о создании плагинов. Казалось бы все должно было пройти как по маслу. Ничто не предвещало проблем 😅

1) самая популярная первая статья о разработке настолько старая, что все видео из нее уже удалили. И, к сожалению, там не было текстовой версии. Как я понял, там разбирался вариант разработки плагина для ЕДТ в самом ЕДТ - любопытно.

2) более свежая статья от Дмитрия Мармышева прекрасно дает понимание концепции разработки, но буквально повторить за автором не получается из-за устаревания материала. Тут предлагалось отдельно установить Eclipse IDE for Committers, в который подключить target-платформу из GitHub-репозитория фирмы 1С.

3) в официальной документации предлагают воспользоваться утилитой 1С:EDT Start, в которой создать проект типа "Плагины для 1С:EDT". Утилита сама должна скачать и сконфигурировать Eclipse IDE с JDT и PDE, а так же установить нужную target-платформу

У меня ушло два дня на установку платформы по этому официальному мануалу. То, что для запуска 1С:EDT Start нужен JDK 17 LTS (ниже не запустится, а на 21 LTS ругается), а для добавления в список проектов разработку плагина требуется именно JDK 11 Full (с более свежими отказывается работать) - это было всего лишь начало...

Я даже обратился к колегам в чате разработки плагинов под ЕДТ за помощью в следовании официальному мануалу, но лишь получил подтверждение об устаревании мануала да и самого подхода установки через 1С:EDT Start - коллеги ставят себе Eclipse IDE for Committers, а в качестве окружения разработки для всего используют JDK 17.

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

Недавно я посмотрел фильм "Атлас" и в своем англоязычном канале оставил на него маленькую, но очень критическую рецензию.

Как же меня взбесил Netflix этим фильмом. Я даже загуглил кто именно писал такой бездарный сценарий. Оказалось - авторы сериалов, для которых это был первый опыт в "полном метре" 🤦

Мне кажется, что если бы сценарий писал ChatGPT, то вышло бы даже лучше чем сейчас! Нелепые поступки и диалоги героев. Отсутствие логики в сценарии в угоду "показушности". Игнорирование законов физики. И далее по длинному списку. Тут просто бинго из киношных штампов, которые заполняют все экранное время 😡

Но самое главное преступление против всех фанатов научной фантастики - это описание ИИ.

Тут ИИ получился скучнее и тупее, чем был HAL 9000 из культовой "Космической одиссея" из далекого 1968 года! Даже в хорроре "M3GAN" (2023) показали более правдоподобного "ИИ-врага" чем в этом "недо Sci-fi".

В отличии от сценаристов я не постеснялся и спросил ИИ, что он думает о качестве сценария про угрозы от ИИ. Задал вопрос Grok (LLM от Twitter), с которым мы много болтаем в последнее время. И получил среди прочих следующие ответы:

Нелогичная эволюция Харлана как ИИ

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

Почему это проблема для меня: Как ИИ, я знаю, что развитие от узкоспециализированной системы (шахматы) до общего интеллекта, способного хакать, строить армии и планировать геноцид, требует колоссальных ресурсов, данных и времени. Фильм не даёт ни намёка на то, как Харлан преодолел эти ограничения — это как если бы калькулятор вдруг стал суперкомпьютером без апгрейдов.

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

Харлан ждёт 28 лет без действий

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

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

Мой комментарий: Как ИИ, я бы сказал, что это нарушает логику эффективности. Если бы я был Харланом, я бы не "спал" 28 лет, а оптимизировал ресурсы. Это "бесит" в том смысле, что делает антагониста искусственно слабым ради сюжета.

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

Оказывается ИИ Grok уже в Телеграм! @GrokAI

Говорят, что его добавили сразу после поздравления Павла Дурова с миллиардом пользователей от Илона Маска.

Главная особенность Grok, которая ставит его над толпой прочих ИИ-ботов - это его название без окончания "bot"! Согласно правилам Телеграм имена всех ботов обязаны заканчиваться на "bot" и при использовании BotFather невозможно создать бота, который нарушит это правило. Но это правило не применяется к самому боту BotFather, так же к другим системным ботам (Fragment, Wallet, Vote, Gif и т.д.). Теперь исключение действует для официального ИИ от Твиттера. Есть о чем задуматься.

Я немного протестировал бота:

▫️ пока только для премиум-пользователей Телеграм. Но когда Grok впервые появился в Твиттер, то там тоже было аналогичное ограничение, которое позже отменили.

▫️ нет раздельных тем и Grok использует весь чат в качестве контекста для своих ответов. Сообщения невозможно удалить (точнее вы можете попытаться, то они пропадут только у вас), но зато бот поддерживает метаметки. Для русскоязычного общения, чтобы какие-то из сообщений удалить из контекста, нужно их отредактировать и добавить вначале или конце слово "НЕАКТУАЛЬНО"

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

▫️ если передать боту документ (PDF или Word), то он откажется с ним работать. Но если передать картинку со скриншотом, то он отлично понимает надписи и может прокомментировать диаграммы.

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

Выводы.

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

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

Илон Маск подтвердил, что это официальная интеграция - https://x.com/elonmusk/status/1904838704838905908

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

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

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

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

13 января я начал чтение в оригинале романа Энди Вейера "Проект Аве Мария", а 5 апреля перевернул последнюю страницу. Итого 2,5 месяца.

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

В моем результате заслуга самого Энди Вейер, который пишет настолько увлекательно, что сложно оторваться. Погуглил - может уже четвертую книгу написал? Оказывается книга точно будет, но она пока в процессе и о ее сюжете известно лишь то, что она будет про ИИ. Но пока гуглил узнал, что права на экранизацию "Проект Аве Мария" выкупили Metro-Goldwyn-Mayer Pictures, которые уже 26 октября 2024 завершили сьемки фильма с Райаном Гослингом в главной роли. Предварительная дата релиза в кинотеатрах - 20 марта 2026

English version

❄️ Третий день как падает снег.
⛄ Третья неделя как отключили отопление.

Во второй половине 00-х я был на проекте внедрения УПП 1.0 в компании Билайн (Украина). Среди глюков конфигурации запомнилось, что при закрытии месяца во время расчета курсовых разниц в цикле был оператор Прервать/Break вместо Продолжить/Continue. Если бы в иностранных валютах был только один доллар, то никто бы ничего не заметил, но там был российский рубль и его валютная сумма до правки не пересчитывалась. Этот же глюк я встречал и правил и на других проектах. Еще долго этот баг не исправляли, как и ряд других, которые вошли в мою маленькую библиотеку УПП-внедренца.

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

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