❄️ Вышла долгожданная триал-версия Снегопата с поддержкой платформы 8.3.17!

https://infostart.ru/public/102065/

Полнофункциональная версия на 3 месяца, пока не работает x64 (в разработке), но зато поддерживаются все версии платформы вплоть до 8.3.17.

Кто, возможно, не в курсе — Снегопат добавляет в конфигуратор функции современных IDE (видео с примерами — в статье по ссылке выше) и кроме того, позволяет самому автоматизировать работу в конфигураторе при помощи скриптов на JavaScript/TypeScript (при этом можно для скриптов создавать формы на базе обычных форм 1С, как при создании обработок в обычном приложении).

Рекомендую разработчикам посмотреть обзор функционала и попробовать самим.

Если что не получится, вопросы можно задать в чате поддержки Снегопата — @snegopat_chat

☁️ Codespaces — облачная среда разработки от Github

Еще одна попытка сделать облачную IDE, теперь от GitHub и на базе VS Code.

https://github.com/features/codespaces/

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

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

p.s. Вспомнил, как, кажется, в ноябре 2015 (или 2014?) после вечеринки Infostart Event шумной толпой обсуждали "облачный конфигуратор" 😊. Поддержку языка 1С на гитхабе впилили, расширение для VS Code с поддержкой 1С есть, так что в какой-то степени появление codespaces должно приблизить и появление облачной среды разработки для 1С, для OneScript — точно. 😉

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

Настоящее и будущее компании "Серебряная Пуля"

Последнее время очень много спекуляций на тему настоящего и будущего компании Серебряная пуля. Хочется расставить все точки над "i".
Основное - все изменения в компании это инициатива Алексея Лустина.
Последние несколько лет, Алексей выполнял в компании три абсолютно разные роли:
- собственник
- оперативный управленец
- сотрудник
Каждая из этих ролей требует огромного количества времени и энергии. Как результат Алексей "выгорел" и решил восстановиться.
Было два пути:
- закрыть компанию и потерять все, что она делала и делает;
- оставить компанию, но дать Алексею возможность отойти, на время, от дел.
В результате, партнер Алексея по компании Антон Долгов, согласился выкупить долю и стать единственным собственником и выполнять только эту роль.
Чтобы продукты и идеи компании продолжали развиваться, в компанию вернулись некоторые сотрудники и были привлечены новые. На данный момент все существующие продукты компании активно развиваются, а также появляются новые. Компания успешно выполняет все свои текущие обязательства перед клиентами.

С уважением,
Команда Серебряной Пули.

⤴️ Онлайн-митап "Безопасность и 1С" 11 сентября

11 сентября Инфостарт проводит онлайн-митап по теме "Безопасность и 1С", и меня позвали модератором.

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

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

— Решения основных прикладных задач, связанных с обеспечением безопасности: как в 1С:БСП настраивать ограничения доступа к данным на уровне записей (RLS), как надо и как не надо разрабатывать HTTP-сервисы 1С (в контексте обеспечения безопасности), как защитить сервер 1С от взлома.

— Безопасность сервера приложений 1С с точки зрения администратора, и с точки зрения злоумышленника (чтобы понимать, как защищаться).

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

— Около-криптографические вопросы: применение блокчейна для организации безопасности данных в 1С.

Приглашаю присоединиться, мы постараемся, чтобы было интересно и полезно! И, пожалуйста, проголосуйте за доклады:

https://infostart.ru/events/1269292/

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

🛠 Триальная версия Снегопата сейчас на 3 месяца доступна в полном функционале, без каких-либо ограничений — отличный повод изучить его возможности для принятия решения, а нужно ли оно вам. Наделал кучу скриншотов процесса установки триала и опубликовал на Инфостарте 👇. Во второй половине статьи я перечислил основные скрипты, которые можно попробовать "здесь и сейчас", без каких-либо дополнительных настроек и т.п.

Я почти с момента первого анонса "перезагрузки" проекта начал его использовать. На текущий момент падений конфигуратора практически нет и в большей степени они связаны с ограничениями 32-разрядной версии платформы на больших конфигурациях (KA2, ERP), которые и без Снегопата происходили.

Время от времени находятся мелкие баги, которые Александр оперативно исправляет, но в целом проект становится стабильнее. Рекомендую попробовать в работе. Навигация по метаданным (Ctrl + ~) и анализ модуля при помощи BSL Language Server — 🔥

Вчера открылась регистрация на очередной Хактоберфест.

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

Причем тут 1С, скажете вы?

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

Короче, присоединяйтесь )

Выбрать себе проект по душе можно из списка опенсорсных проектов, который собрала Вика Дорохина: https://infostart.ru/journal/news/news/obzor-open-source-proektov-dlya-raboty-s-1s-na-github-chast-i_1256756/

Чеклист и примеры задач — 🔥

Чеклист хорошей задачи

Для меня курс «Стать тимлидом» — это новый уровень в систематизации знаний. Процесс очень сильно отличается от постинга в канал — сюда я пишу короткие заметки: одна мысль — один пост. С курсом всё по-другому — там я сажусь и формирую целые системы из знаний:

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

Всё это хочется выкладывать прямо сюда — польза же! Но я пока держусь. Одной штукой Марьяна меня всё-таки уговорила поделиться — это чеклист из 7 пунктов о том, как должна выглядеть хорошая задача. Чеклист важен для всех, кто имеет отношение к постановке задач — к менеджерам, тимлидам, QA и просто программистам, которые любят сами себе ставить задачи. Выложил его на страницу курса, заходите и скачивайте.

Налил чаю и открыл первую попавшуюся статью на хабре из хаба "Ненормальное программирование" — "Жизнь на PostgreSQL". В первом же комментарии — "Мы на 1С такое еще в 2011 году делали". 🥳

Про безопасность 1С начинают говорить чаще в том числе на каналах по ИБ.

Что нужно знать, при пентесте 1С

* Иногда там выдаются имена пользователей (если включено) в автодополнении, либо можно попробовать обратиться на /ru_RU/e1cib/users.
* Пароли из коробки не чувствительны к регистру. "Пароль" и "пАрОль" - одно и тоже, что уменьшает количество для брута (особенно классно вместе с предыдущим пунктом).
* Внутри часто есть выполнение произвольного кода.

А мы недавно очень подробно безопасность 1С обсуждали на митапе https://infostart.ru/courses/1292838/

Из наиболее яркого:

— Ребята из КраудСекьюрити под митап опубликовали кучу небольших решений https://github.com/KraudSecurity/1C-Exploit-Kit и в целом у них крутое исследование было и на своем докладе Алексей Старев показал много интересной статистики.

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

— Владимир Бондаревский на мастер-классе показал, как опасно бездумно ставить флаг "Вызов сервера" у общих модулей 1С.

✅ В этом году мне все-таки удалось завершить челлендж и сделать достаточное для получения заветной футболки количество pull request'ов даже немного с запасом.

Но после всего этого индусского флешмоба, превратившего Hacktoberfest в комичный #shitoberfest я предпочел посадить деревце.

p.s. Надеюсь, дерево будет настоящее, а не виртуальное в каком-нибудь виртуальном лесу, как сейчас модно.

p.p.s. Нет, дерево мне не должны прислать ))), его посадят в каком-то специальном парке.

Не про 1С и даже не совсем про ИТ, но заметка очень правильная и полезная 👇

Наказание за сорванный дедлайн

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

🌕🌖
Главная мысль — кто я такая, чтобы кого-то наказывать. У меня просто нет этого права, и я его не хочу. Я уважаю людей, с которыми работаю, мы на равных, а наказание предполагает, что у меня есть какая-то особенная власть. Но поскольку власть и равенство друг другу противоречат, я, пожалуй, выберу равенство.

🌗🌘
Другая мысль в том, что автор сам уже переживает. Даже если бы я хотела наказать, то это наказание было бы плевочком по сравнению с чувством вины, которое уже испытывает автор. То есть мне можно ничего не делать. Это ж классно, когда кто-то делает за меня мою работу, да еще и лучше меня. Зачем я буду вмешиваться?

Если автор не переживает, продолжает срывать сроки и ничего не предпринимает, нам с ним не по пути. Мне пока такие не попадались.

🌑🌒
Если автор переживает, срывает сроки, снова переживает, снова срывает, то это уже не случайность. Автор может объяснять это внешними факторами, типа «эксперт подвел и не смог созвониться», «у меня другой материал занял слишком много времени», «тема оказалась сложнее, чем я думала». Но если внешние факторы мешают систематически, то это уже не внешние факторы.

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

🌓🌔
Моя задача, как менеджера и руководителя, — выстроить такую систему, при которой мы не будем зависеть от одного сорванного срока. Например, если у нас должно выходить пять статей в неделю, и вот одна сорвалась, то мы ставим вместо нее другую статью, а эту дорабатываем.

🌙
Вообще мне нравится идея «не наказывать, а поддержать». Если у автора систематическая проблема со сроками или с качеством текста, я стараюсь поддерживать.

Поддержка — это не «чувак, соберись, у тебя всё получится!» а просто нормальное человеческое отношение: не устраивать разборки в чатах, а написать в личку; и приходить не с претензией, а с заботой:

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

#InfostartMeetup

За прошедший год про SonarQube на митапах и докладах не рассказывал только ленивый. И я (хотя одно другому не мешает).

Оффлайновый Инфостарт Эвент 2020 отменился, заменившись на серию онлайн-митапов по аналогии с теми, что проводились летом.

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

Конечно же, что-то может пойти не так, но в этом есть отдельный интерес :)

Присоединяйтесь, постараюсь сделать познавательно.

https://infostart.ru/journal/news/news/gotovo-raspisanie-onlayn-mitapa-put-k-idealnomu-kodu_1319152

Интересно читать ход мысли по диагностике ошибки, полученной в Конфигураторе. Оформлено уже как (почти) универсальное руководство к действию.

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

https://kostyanetsky.ru/notes/designer-error-investigation/

Лет десять назад у меня был коллега из Ульяновска, тоже звали Никитой, кстати. Устроился он тогда в компанию, у которой несколько лет уже работал большой, живой, высоконагруженный продукт, приносивший достаточно денег, чтобы платить команде в России. Продукт активно дорабатывался прямо по живому, а чтобы не сойти с ума, функциональность была покрыта интеграционным тест сьютом. Все бы хорошо, но фичи приоритезировались больше, чем тесты, которые в результате начали подгнивать, перестали отражать реальную ситуацию, и в какой-то момент превратились из инструмента безопасного релиза в театр безопасности. Никто не знал, можно ли им верить, они падали в рандомные моменты времени даже на работающем коде, CI перезапускал тест сьют трижды (!) и считал тест успешным, если он прошел хотя бы один раз из трех. Ситуация быстро кульминировала в пик outages (несколько штук в неделю), невыспавшуюся команду и дерганый менеджмент. Дошло до того, что по общему соглашению разработку вообще всех новых фич остановили на полгода (!), которые посвятили исключительно техдолгу, починке тестов и настройке нормальных процессов релиза. Довольно беспрецендентный шаг, по моему опыту, который тем не менее завершился ощутимым успехом (тоже, кстати, редкость, чтобы такие большие планы ожидаемо сбывались) — работать снова стало возможно. Потом, правда, деньги кончились, но это другая уже история.

Никита тогда занимался как раз починкой тест сьюта и вынес несколько патентованых афоризмов™.

Зачем тесты:

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

Что тестировать:

- Ровно то, что программа обеспечивает де факто.
- Про каждый (каждый!) тест должно быть понятно, почему он написан, что проверяет, почему это нужно проверять.
- Не должно быть тестов «на всякий случай», «просто».
- Нет смысла тестировать простые, предсказуемые вещи.
- Юнит-тесты тестируют то, что удобно, вместо того, что требует тестирования.
- Погоня за 100% покрытием (или любым другим — 90%, 85%) бессмысленное дрочево^W^W формализм.

Как тестировать:

- Тесты не должны отнимать больше усилий, чем код.
- Тесты должны быть гибкими и податливыми, не быть обузой, когда надо изменить код.
- Не запускать тесты в отдельных, специально создаваемых условиях. Эмуляция окружения, БД, mock-и дают уверенность, что волшебные феечки в волшебной стране работают нормально, а интересно должно быть, как работает реальность.
- Асинхронность — не проблема. Надо признать ее существование и тестировать ровно то и ровно так, как оно на самом деле происходит.
- Тестирование sleep-ами, фиксированные взятые с потолка задержки, retry тестов — прямая дорога к моргающим тестам, дергающемуся глазу, неврозу, дурке.
- Тесты должны быть быстрыми, чтобы запускаться как можно чаще. Duh.
- Тесты должны работать локально так же просто, как и на CI.
- Кажется, что это сложно или невозможно? Только кажется. Обычно фундаментальных препятствий к этому нет, надо лишь один раз заморочиться.
- Править код, архитектуру и даже инфраструктуру (например, взять другую БД!), чтобы написать тесты хорошо — нормально. Тесты тоже часть архитектуры.

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

Вот это я понимаю Long Term Support!

https://wonderland.v8.1c.ru/blog/drayver-hasp-s-podderzhkoy-windows-xp/