Никита Федькин - мысли, заметки, анонсы

Внаглую тизерю

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

Каждую из этих реализаций можно сделать в виде обработок с идентичным интерфейсом или вообще закрыть за Фасадом (https://refactoring.guru/ru/design-patterns/façade), предоставив удобный и гибкий API как для подмены реализаций CB между собой так и добавления новых.

Если Circuit Breaker объединить с Retry Pattern (https://learn.microsoft.com/en-us/azure/architecture/patterns/retry) с ощутимо большой задержкой (он и реализуется заметно проще), то можно обеспечить достаточно стабильный и самовосстанавливающийся обмен с другими системами.

Пробовали ли применять что-то из данных шаблонов на работе? Как реализовывали?

Знакомясь с новыми (для себя) технологиями и подходами, невольно начинаешь оценивать их применимость на своей текущей или прошлой работе. Готовясь к техническим интервью, помимо прочего я разбирал архитектурный шаблон под названием Circuit Breaker.

Представьте достаточно типовую ситуацию: вы вызываете стороннее API, и тут сторонний сервис падает. Если вы вызываете его редко или вообще разово, то ничего страшного, попробуем как-нибудь ещё раз и потом. Но ситуация становится критической, когда вызовы идут часто, например, небольшими порциями или вообще по активному потоку событий из вашей системы. Часто ошибка не доступности сервиса не будет отдана мгновенно, придётся повисеть на таймауте вашего соединения или дождаться 502 Gateway Timeout от промежуточного сервиса. На выходе получаем резкое увеличение времени обработки одного события, поток исполнения, висящий на бесполезных ожиданиях и ползующие вверх метрики.

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

Что делать?

Такую ситуацию и призван решить шаблон Circuit Breaker.

https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker

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

В его основе лежит простенькая машина состояний, через которую должен пройти код, прежде чем вызвать сторонний сервис. Состояний всего три:
1) Закрыт - в этом состоянии CB находится после начала своей работы. Выполнение запроса действительно идёт на сторонний сервис. Если сторонний сервис начинает возвращать ошибки с  превышением некоего порога (количество ошибок в диапазон времени или просто по счётчику ошибок), CB переводится в состояние "Открыт". Дополнительно запускается таймер, после которого CB переводится в состояние  "Приоткрыт".
2) Открыт - в этом состоянии вместо вызовов реального внешнего сервиса CB возвращает вызывающему коду заранее заготовленную ошибку. Выигрыш здесь в быстроте обработки каждого события (просто бросить исключение намного быстрее, чем дожидаться таймаута от сервиса или соединения), плюс вы даёте возможность стороннему спокойно восстановится.
3) Приоткрыт - в этом состоянии CB позволяет небольшому и ограниченному количеству запросов пойти на реальный сервис, тогда как большая часть запросов все ещё "быстро" получает заранее подготовленную ошибку. Если все (или какой-то процент) запросы, пропущенные до реального сервиса, выполняются успешно, CB переводится в состояние "Закрыт", а счётчик ошибок сбрасывается. Если же внешний сервис продолжает возвращать ошибки, то CB переводится в состояние "Открыт" и снова запускается таймер на перевод в состояние "Приоткрыт".

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

Как это реализовать в 1С? Так как для реализации нужно хранить некое состояние (как входящие параметры, так и внутренние счётчики), то имеет смысл в качестве рабочего объекта использовать обработку. А дальше зависит от потребностей.

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

Если же обработка распределенная и многопоточная, то промежуточные данные придётся хранить в служебном регистре сведений (или в быстром внешнем key-value хранилище, например Redis), аккуратно расставив блокировки на данные, к которым будет осуществляться конкурентный доступ. >>

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

Другое дело HQ9+ - https://ru.m.wikipedia.org/wiki/HQ9%2B
Лёгкий и забавный :)

Но автор следующего языка пошёл дальше. И кажется, осенью перло не только Пушкина.

https://github.com/TodePond/DreamBerd

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

На правах пятницы.

Можно перестать писать на 1с, но нельзя перестать быть 1сником.

Под эгидой GitHub публикуется The ReadME Project - истории разработчиков, статьи, гайды и даже подкаст.

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

https://github.com/readme/featured/how-open-is-open-source

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

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

Напоследок отдельно оставлю ссылку на статью под названием How to communicate the state of your open source project, в которой предложена статусная модель/жизненный цикл опенсорс-проекта с точки зрения его "готовности" и намерений разработчиков. Было бы здорово, если бы чего-то такому придерживались все проекты на GitHub.

Ну и баджики! Баджиков много не бывает. :)

Уставшая, но довольная рожа после первого рабочего дня :)

Для меня драйвером знакомства со спрингом стал BSL Language Server, сложность которого на тот момент (на коленочном DI и забористой мешанине инфраструктурного и полезного кода) перестала умещаться в голове. На этом этапе очень помог все тот же Baeldung, документация по Spring и Spring Boot (она действительно блестящая) и множество видео Евгения Борисова. Многие скажут, что современная джава - это spring boot driven development, но мне кажется важным хоть примерно понимать, как там под капотом все устроено хотя бы на уровне концепции (привет, ОСень!).

В качестве докладчиков как источников знаний могу порекомендовать Евгения Борисова, Алексея Шипелева, Ивана Углянского и Владимира Ситникова. Они регулярно выступают на Joker/JPoint и не только. И конечно же Тагир Валеев. Ня.

В 2018 году у меня было острое желание перейти в джаву, но сейчас ретроспективно я понимаю, что уровень знаний и опыт, который мне дал BSL Language Server за первые годы его разработки, оказался необходимым для текущего успешного перехода, по крайней мере на таких условиях и позициях. Не утверждаю, что нужно потратить три+ года на подготовку к такому переходу, у меня все же львиную долю времени занимала работа и оскрипт. Очень и очень многое зависит от бэкграунда, целевой позиции и готовности поглощать кучу новой информации. Под рукой есть примеры, когда человек из шарпа перешёл в джаву на позицию сеньора, имея не очень большой джавовый опыт. Просто ему были знакомы концепции языка и работа с тулингом.
А синтаксис - дело привычки.

Таков путь.

Про обучение джаве.

В институте, как и у многих технарей, у меня был TurboPascal 7.1, Deplhi 7 и C образца книжки Кернигана и Ритчи. Ну, сами понимаете, какой в институте даётся уровень языка на непрофильных программированию кафедрах. Бонусом была экзотика в виде "Максима" и менее экзотичный mathcad.

В школе были короткие курсы по Visual Basic и HTML. Показанный мне тогда паскаль показался странным и неудобным (и это я ещё джаву не видел на тот момент!).

В общем, в 1с я пришёл уже с некоторым пониманием не только циклов и условий, но и с небольшим опытом визуального "программирования форм" на VB/VBA и Deplhi.

После начала работы с 1С я продолжил знакомиться с другими языками, например, проходил туториалы по R и Haskell, и вносил в опенсорс проекты небольшие правки на JavaScript и CoffeeScript, который на тот момент выглядел очень перспективно. Где-то в тоже время был небольшой экскурс в Python и перевод precommit1c с питона на оскрипт (кто-то вообще помнит, что он был на питоне? :)).

С подачи Жени Сосны и Вики Дорохиной и их работы над плагином поддержки 1С в VSCode я познакомился с TypeScript и однозначно убедился в том, что я сторонник статической типизации в языка программирования. И чем строже, тем лучше. После динамической слабой типизации в 1С это было глотком свежего воздуха.

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

Моей первой джава-задачей стало не Фибоначчи или сортировка строк в файле, а вполне конкретное прикладное решение - нужно было написать с нуля плагин для поддержки 1С в SonarQube. И кода для нулевого опыта в джаве надо было написать достаточно много. Да, у меня было примерное понимание того, что должно получиться на выходе, был опыт разработки плагина для vscode, но все равно с многими концепциями языка и экосистемы вы столкнетесь только после начала активной работы с языком.

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

В плане источников получения информации в джаве все очень хорошо. Есть огромное количество кода, который можно исследовать. Хорошо бы при этом понимать, какой код хороший, а какой плохой, но это дело наживное.
Есть туториалы от Oracle с разбором решения различных задач, используя стандартную библиотеку джавы. Хорошим источником информации являются и спецификации - как самого языка, так и различных частей экосистемы - например, Java Persistence API, которая легла в основу библиотеки entity.
До сих пор очень много вводной информации по той или иной библиотеке я подчерпываю с сайта Baeldung. Он является отличной точкой входа с быстрым how-to для использования, и понимания, нужно ли углубляться в чтение документации.
Я начинал проходить несколько видеокурсов, но кажется, это не мой формат поглощения информации (мне ближе статьи и референсная документация). Могу отметить хороший курс от Tim Buchalka на Udemy.
Специализированных книг по джаве я пока не читал, хотя и там есть из чего выбрать. Ну, разве что книгу Егора Бугаенко "Элегантные объекты. Java edition", от которой у меня жопа горит до сих пор. Но то Бугаенко.

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

Лямбды в этом нашем оскрипте

Кирилл Черненко (@sfaqer) недавно запилил новую библиотеку под названием lambdas. Там вообще много чего наверчено, но основное - можно делать вот так:

Заменить(Массив, "Элемент -> Элемент + 1");

Почти как в исполнителе, не правда ли?

Изначально Кирилл развлекался с другой своей новой библиотекой (collectionos).
Если вы матёрый и упоротый пользователь оскрипта, то скорее всего помните про fluent - библиотеку по обработке коллекций, в которой и применялся прародитель лямбд на базе notify.

Кирилл добрался и до fluent! И сегодня выпущен новый релиз, в котором добавлена поддержка lambdas, ленивый проход конвейера, захват контекста и ещё улучшений по мелочи. И даже дока обновлена под современные реалии.

Ну не чудо ли? :)

Обновляйтесь, пробуйте, оставляйте фидбэк в @oscript_library, а Кирилл пока продолжит скрещивать fluent, lambdas, optional и collectionos для обеспечения плавного преобразования объектов библиотек между собой.

https://github.com/nixel2007/oscript-fluent/tree/develop

#какэтоесть

Новый дом, новая работа.

Я много раз получал вопрос: "почему ты все ещё в 1С?". Наконец-то, у меня есть что ответить.

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

Один из любимейших городов, красивейший и интереснейший, мой новый дом - Амстердам.

Моя карьера 1сника подошла к концу. Она началась со стажерской позиции 11 лет назад и дошла до тим/тех лида и системного архитектора.
17 апреля же начнётся новая рабочая глава в виде Software Engineer, но уже в виде (ту-ду-дууууум!) джависта.

Не могу сказать, что я тут часто писал именно про 1С, так что может быть тематика канала сильно и не изменится :)
Я продолжу заниматься BSL Language Server, ОСенью, планирую возродить стримы на Весёлом1с, но вероятно самого 1сного контента тут будет меньше.

Такие вот новости почти одной строкой.

Наткнувшись в блоге GitHub на анонс выпуска расширения для работы с GitHub Actions в VSCode, вспомнил про недавнюю статью Антона Литвинова про настройку редактора для удобной работы с проектом:

https://habr.com/ru/company/ruvds/blog/717110

В статье рассмотрены такие сущности как workspace, файлы launch.json/settings.json конкретного проекта и каталог .devcontainer, позволяющий описать окружение для работы с проектом в парадигме infrastructure as code - dockerfile + конфигурационные файлы.

Вообще Microsoft в последнее время радует шагами в развитии VSCode. Да, этот редактор все ещё сложно назвать полноценной и главное цельной IDE, но количество и качество плагинов (в том числе официальных и/или от крупных вендоров) уже достигло той точки, когда себе можно собрать удобный и приятный самолёт.

P.S. Руки чешутся потыкать новый плагин на ОСени или BSL Language Server!

1сный митап от Ozon!

Я в последнее время немного потерялся в проводимых 1сных событиях. Кажется, что их в эту весну прям много. И здорово, что активно встречаться начали не только старички "Жёлтый Клуб" и &На1С, но появились эвенты в других городах и от других компаний.

Ozon 30 марта зовёт на митап в Москве. Судя по комментам в канале Ozon, это не первый их 1сный митап. И тем лучше это для сообщества! Больше встреч, больше тем, больше опыта.

https://ozontech.timepad.ru/event/2361868

Будут много рассказывать про различного вида интеграции (интеграции в ЗУП это всегда интересно) и тестирование.
Можно будет посмотреть на модный Allure TestOps! И вообще погрузиться в тему функционального и нагрузочного тестирования, если вы ещё не.
А в завершение дня выступит Пётр Грибанов и расскажет про новинки в платформе.

Участие бесплатное, а если не успеваете/не можете прийти на встречу лично, то будет организована онлайн-трансляция.

Заглядывайте на огонёк :)

Полтора года назад я писал про подключение BSL Language Server к NeoVim и с тех пор никак не могу из него выйти.

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

Небольшой коммит (зацените авторский комментарий к коммиту, кстати) и в NeoVim появляется возможность автоматом установить, обновлять (!) BSL LS и автоматом настроить все нужные связки LSP-клиента и сервера.

Просто viva le opensource какой-то!

https://github.com/williamboman/mason.nvim/commit/40f533260581794a19e6f9c87fbcb434ea4e36f6

GitHub опубликовал сборник инструкций и рекомендаций по ведению OpenSource-проектов.

https://opensource.guide

(есть перевод на русский)

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

Если вы давно хотели начать свой небольшой (?) проект или мечтаете присоединиться к уже существующему проекту, этот сайт может помочь сориентироваться в удивительном мире опенсорса и как можно скорее начать наносить добро :)

Заходили ли вы уже на сайт? Нашли что-то полезное для себя?

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

Поддержку этой технологии для OneScript периодически запрашивали и в голом OneScript, и в OneScript.Web и в молодом winow.

Что ж, с помощью изоленты и разводного ключа можно сделать многое, а у Никиты Иванченко изоленты много, и она праведно синяя!

Выпущен winow 0.4.0, в котором добавлена поддержка веб-сокетов. Автор скромно указывает на экспериментальный статус, но это ж околоодинэсный опенсорс - сплошной эксперимент в каждом пакете :)

Ниже демонстрация работы новой фичи на примере симпатичного чЯтика.

Тем временем, у нас новый ролик. Оказывается, очень тяжело писать видео после длительного перерыва, а потом еще и вырезать все оговорки. Надо делать это почаще https://youtu.be/IDNoe_-fg_Y

Вот так суббота! Айда смотреть новое творение!

Как-то пропустил я этот любопытный доклад на прошлом Infostart Event.

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

https://infostart.ru/1c/articles/1800927

Worth reading.