Хантинга пост.

Ко мне (прям совсем ко мне) на проект очень нужен толковый одинэсный разраб. Что-то вроде middle-to-senior (или выше) с учётом того, что требования к качеству у меня завышены :)

О чем проект: учётная/операционная система для допуска до работы всех врачей и фармацевтов страны, выпускающихся после 2016 года.
С сотнями тысяч людей в роли контингента и десятками тысяч пользователей в 1с, по всей стране.
Даже "Проект года" 1сный выиграли: https://eawards.1c.ru/projects/sozdanie-i-soprovozhdenie-informacionnoy-sistemy-obespecheniya-nepreryvnogo-medicinskogo-obrazovaniya-v-chasti-podsistemy-akkreditacii-83278/

Стек: самописка на базе свежайшей и регулярно обновляемой БСП (3.1.6 на текущий момент), веб-клиент, postgresql, СДО Moodle (php+js), часть собственных компонентов на php/java/typescript, RabbitMQ в роли брокера сообщений между внутренними компонентами, soap/http для интеграции с внешними федеральными медицинскими системами.
Всё это сдобрено вот этими нашими тестами на VA, дженкинсами, гитлабами, сонарами и прочими оскриптами с докером и кубернетисом. Ну и подсистемой мониторинга, конечно же.

Что делать: думать головой в первую очередь! :)
Под моим надзором и с технической постановкой задач пилить новую функциональность (опер учёт без бухгалтерии и прочей зарплаты), интеграции, делать тестики, исправлять найденные и вносить новые баги.

Территориально - Москва, м. Марксистская.
Удаленка возможна.
Юридически - Первый Бит.Москва.Марксисткая, бывшая Москва.Семеновская.

Писать мне или сразу нашей HR Дарье Тарасовой: @dashatarasova08

КРОК на следующей неделе проводит митап по ведению проектной деятельности:

https://promo.croc.ru/meetup07-04-22

Наверное, вы уже видели ссылку в паре других 1сных каналов, но хочу продублировать ее и тут.

Почему?

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

Так что кому близка тема управления проектом/продуктом и кто знаком с ERP/УХ/ERP УХ - заглядывайте на огонёк к ребятам.

Я часто повторяю фразу, уже ставшую моей внутренней мантрой: "BSL LS - это не только диагностики".
Да, все любят диагностики. Качественный код, ругань в сонаре/среде разработки, все прекрасно.

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

Какие-то вещи в Language Server Protocol сделаны очень хорошо и просто.

Например, запрос получения областей, которые можно свернуть
Дай области в таком-то документе? Держи области! Оттуда досюда комментарий, а оттеда доседа - #Область. Красота. Немного прикинуть мозгами, и вот сворачиваются уже не только Если/КонецЕсли, но и пакеты запросов.

Какие-то вещи сделаны удивительно, например, уведомление о закрытии документа не означает, что документ был физически закрыт в редакторе. Или что он вообще был в нем открыт. Речь лишь про владение содержимым этого документа - должен ли сервер ждать данные от клиента или может зачитать их с диска по URI.

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

К чему я это все?

В готовящейся версии протокола под номером 3.17 завезли ряд новых и крайне интересных фич. И хотя в чейнджлоге протокола это еще не отражено, т.к. они пока в состоянии proposed, уже есть черновые реализации как для ядра сервера под typescript, откуда берет свое начало LSP, так и под java, на которой базируется BSL Language Server.

Например...

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

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

Если вы работали когда-нибудь в IntelliJ IDEA или каких-то других редакторах (попродвинутее конфигуратора), то наверное могли заметить штуку под названием inlay hint. Когда прямо в тексте программы IDE добавляет какую-то информацию. О типе переменной или о имени параметра...

Вот как раз такую штуку и добавили в LSP! Пара робких попыток завести это дело, и вот уже в 1сном коде я точно могу быть уверенным, что Отказ - это таки пятый параметр в СообщитьПользователю. А вот этот пропущенный параметр - это ПутьКДанным, и его сейчас заполнять не нужно - в него по умолчанию передастся пустая строка.
А еще на такую подсказку можно навести мышкой и посмотреть описание параметра!

Да, пока это счастье работает только с методами самой конфигурации, но и Москва не сразу строилась, и BSL LS когда-нибудь таки обзаведется контекстом платформы (sigh...).

Что еще можно сделать с такими подсказочками?
Некоторые пользователи жаловались, что в VSCode неудобно смотреть данные о когнитивной/цикломатической сложностях. Да, сложность метода - 3861, но где именно зарыты эти плюсадины?
Нажимаем на линзу "Когнитивная сложность" над методом (хехе, привет, Саша!) и плюсадины и плюсдвадины рисуются прямо по коду. Согласитесь, это намного удобнее, чем глазами вычитывать длинное сообщение из сообщения от диагностики.

Пока вся эта прелесть работает только в VSCode Insider с кастомной сборкой плагина Language 1C (BSL) plugin (приложу в комменты к посту) и кастомной же сборкой BSL Language Server в виде JAR-файла. Но разве это когда-нибудь останавливало настоящего самурая?

UPD: VSCode Insiders больше не требуется, обновляйте основные установки до версии 1.66

UPD: А теперь не нужна и отдельная сборка плагина - опубликован релиз 1.26.0

Про силу опенсорса и коммьюнити.

Недавно по чатам разлетелась статья-перевод с хабра про то, что опенсорс не означает бесплатную поддержку:

https://habr.com/ru/company/dcmiran/blog/654643/

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

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

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

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

История из жизни.

Я являюсь фанатом Формулы 1. Смотрю квалификации и гонки, читаю технические разборы новинок в машинах, слежу за изменениями в регламенте и просто активно читаю новости по теме.

До самизнаетекакихсобытий в России официальными трансляциями F1 занимался "Матч" с голосом Алексея Попова (буквально из детства, он уже 30 лет её комментирует) и Натальи Фабричновой. Дуэт не без изъянов и ляпов, но милый сердцу и ушам.

Кто пытался смотреть трансляции на Матч ТВ/Матч Арене, наверное, знаком с их... Качеством.
Иногда пропадающим качеством картинки, звуком, плеером, в котором нельзя поставить трансляцию на паузу, а смотреть только live и конечно же пятью блоками рекламы (sigh).

И вроде бы уже привычно все: телевидение, рекламы, глючные плееры - если бы в 2022 году не отобрали права на трансляцию F1 в России целиком. Что по телевизору, что по формульным официальным приложениям.

К чему это привело? Конечно же к пиратству. Пиратство любого контента - это, на мой взгляд, плохо. При условии, что этот контент можно получить легально. А тут сложилась ситуация, что... Ну. Нельзя. :/

И тут сообщество показало свою силу. Силищу. Силуилищу!

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

Бесплатно. Без денег Газпрома. За спасибо и немного донатов.

Так в чем сила, брат? (с)

Сила в сообществе. Спасибо вам всем. Вы сильнее, чем вы думаете, даёте авторам продуктов больше, чем думаете, и что самое прекрасное - можете давать ещё больше.

<3

А ещё сегодня у меня "жёлтый юбилей" - ровно 10 лет со дня прихода в профессию 1сника.

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

А как начиналась ваша карьера?

Про мониторинг и немного рекламы.

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

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

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

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

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

Встречайте. Алькир.

https://digilabs.ru

Я не думаю, что мне стоит пересказывать красивые слова с сайта. Отмечу лишь, что Алькиром я пользуюсь сам, причем на своем основном проекте.

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

И конечно пара скриншотов с комментариями.

Обсуждалка: @alkir_ru

Соскучились по стримам?

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

В этот раз стрим будет про любимый мной OneScript с Артемом Кузнецовым (в кепке) в роли ведущего.

Залетай на огонек, сегодня в 19:00 по Москве!

Анонс: https://t.me/yellowclub_official/206

Трансляция: https://youtu.be/1qrw4om5kBw

Немножечко новостей про firstBitMarksistskaya/onec-docker.

В основной бранч влито два важных изменения.

1) Поддержка загрузки и установки 8.3.20! Да, сейчас поставить двадцатку (или даже недавно вышедшую 21) автоматизировано - задача не из легких, и большинство загрузчиков будут давать 403 после пары попыток загрузки. Пока не знаю, что с этим делать, Андрей Крапивин для решения этой проблемы мучает Селениум, например. И страдает.

2) download.sh умер, да здравствует oneget! Старый скрипт скачивания платформы был заменен на новый модный и молодежный, написанный на Go. Oneget уже успел хорошо себя зарекомендовать, а теперь используется и в onec-docker для скачивания дистрибутивов платформы и EDT.

Обновляемся, не стесняемся, о багах репортим прямо в репозиторий - я открыл раздел Issues.

История одного контракта.

Поотнимаю немного хлеб у Лягуха и напишу пост про джаву.

Я люблю джаву. За её строгость, за типизацию, за ООП, за огромное количество готовых разработок и за богатую стандартную библиотеку.

В частности джава славится своими коллекциями и интерфейсами (читай контрактами).

Коллекции тут на любой вкус. Есть списки (листы), карты (мапы), множества (сеты), очереди (деки) и стеки. Каждый тип коллекции имеет несколько реализаций. Например, лист может быть реализован на базе нерасширяемого массива, или, например, на основе связного списка. Часть реализаций потокобезопасные, а часть могут подкинуть приколы в мнргопоточке :)

С интерфейсами такая же ситуация, их ооочень много. Часть интерфейсов обрабатывается самой JVM. Например, Serializable разрешает виртуальной машине применять к классу штатный механизм бинарной сериализации. А Iterable разрешает перебирать объект в цикле for each (для каждого) - круто же! Реализовали один метод и теперь объект можно циклом обходить.

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

Какая может быть необходимость?

В грядущем (и долгожданном) релизе BSL Language Server под версией 0.20.0 появится важная фича - добавленный пару релизов назад механизм Reference Index, хранящий данные о вызове всех методов в коде и помогающий делать всякие "переход к определению", "поиск мест использования" и прочие всплывающие подсказки, научился хранить ещё и данные обо всех используемых переменных - где они были объявлены/им были присвоены значения и где к этим переменным было обращение. По всей кодовой базе.

Конечно же, это довольно сильно ударило по объёму занимаемой оперативной памяти. Если в релизе 0.19 данные индекса ПО вызовам методов в УХ занимали чуть меньше 100 мегабайт оперативной памяти, то загрузка в индекс всех данных об используемых переменных резко подняла этот показатель до почти 800 (!) мегабайт. Так как вопрос производительности работы с индексом не стоял (спасибо Эдуарду за несколько подходов к оптимизации), надо было попробовать снизить затраты памяти, пускай и жертвуя толикой производительности.

В качестве основного хранилища данных ссылок в индексе использовался ConcurrentHashMap - это почти как обычный HashMap, хранящий данные в хэш-таблице на основе, собственно, хэш-кода от ключа соответствия мапы, но поддерживающий работу в многопоточной среде без ошибок или адовых ожиданий на блокировках. Покурив интернетики была найдена другая штатная реализация конкурентной мапы в виде ConcurrentSkipListMap. В ней гарантируется O log(n) на операциях поиска и вставки по ключу в отличии от вообще отсутствия каких-то гарантий по сложности в ConcurrentHashMap. Ещё и внутренняя реализация в виде индексного дерева из двунаправленных связных списков позволяла предположить, что можно сэкономить сколько-то памяти. И да, сколько-то сэкономилось - целых 200 мегабайт! От исходных 800 это целых 25%, потери же производительности были прям совсем мизерными.

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

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

А потом началось странное...

Представьте примерно следующий код:

Ключ = Новый Структура("Поле1, Поле2", "123", "456");
Карта.Вставить(Ключ, 1);

Ключ2 = Новый Структура("Поле1, Поле2", "789", "987");
Карта.Вставить(Ключ2, 2);

Значение = Карта.Получить(Ключ2);

Вроде ничего сложного, да? Сделали два ключа, положили по ним значение в соответствие карту, затем получили значение по второму.

Пример утрированный, эти операции размазаны по коду, но смысл такой.

Так вот. Как думаете, что будет в переменной Значение? По идее двойка, да?

По идее да. Двойка. И так и было примерно в 99.9% случаев. А в 0.01% в Значении было... Неопределено.

НедоумевающийДжекиЧан.джпг

Что, почему, как? Херня эта ваша джава, да?

Как и в большинстве случаев в программировании проблема оказалась в программисте.

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

Но есть и еще одно требование - если А > Б, то обязательно должно выполняться Б < А. От перемены мест слагаемых и все такое прочее.

Душный Дотошный читатель мог обратить внимание, что моя на скорую руку написанная реализация compareTo сранивала хэш-коды на строгое больше и меньше и задаться вопросом: "А что будет, если хэш-коды у двух разных объектов будут одинаковыми? Это валидная ситуация?". И будет абсолютно прав в своей дотошности. Ситуация валидная, а я лопух, нарушивший контракт А > Б = Б < А

Т.к. метод сортировки применяется в ConcurrentSkipListMap для построения индекса, два объекта, которые при сравнении друг с другом с разных сторон давали разные ответы, приводили к ошибкам позиционирования в индексе. И вместо нахождения в индексе адреса нужного значения в дереве из двусвязных списков, индекс врезался в null.

Проблема решилась путем выкидывания наколеночной реализации compareTo и обычного сравнения по всем полям.

Можно было бы подумать, что это все жабо-проблемы, и в этом нашем 1С такого не может быть. Какие у нас интерфейсы, какие контракты?

А вот и нет. Есть у нас интерфейсы, и есть контракты. Не важно, какую библиотеку вы используете: Библиотеку стандартных подсистем с ее миллионом общих модулей и вязанкой "переопределяемых" методов, или, к примеру клевую библиотеку для сериализации SerLib1C от Артема Кузнецова (не реклама, честно, просто вспомнилось :) ) - автор может закладываться на какое-то ваше адекватное поведение в коде переопределяемых обработчиков. Хороший автор еще напишет об этом в документации.

Вот такое вам длиииииииинное субботнее чтиво.
Всем добра и RTFM!