Народ таки побежал с гитхаба
https://twitter.com/gitlab/status/1003409836170547200

Кстати, помните у 1С был такой проект - nashe1c.ru Это был каталог внешних обработок, отчетов и статей. Но он не взлетел.

...А потом 1С вложилась в Инфостарт :)

Однажды Инфостарт (та часть, которая журнал) наверняка станет качественным источником ИТ-новостей, ну скажем так, сопоставимым по качеству публикаций с Т-Ж (но про 1С).

Но пока еще есть к чему стремиться :)

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

https://infostart.ru/journal/news/mir-1s/ukh-kakaya-konfiguratsiya-vypushcheno-reshenie-1s-upravlenie-kholdingom-3-0_842303/

"Нельзя просто так взять и купить Github"

По всему миру люди, сколь-нибудь имеющие отношение к разработке, обсуждают покупку Майкрософтом Гитхаба. Немного неожиданный аспект потенциальных проблем рассматривает Wired.
Любые крупные сервисы, публикующие пользовательский контент, сейчас испытывают массу проблем: Фейсбук является ярчайшим примером. Майкрософт сейчас окажется владельцем ресурса, который как раз относится к этому классу. И столкнётся с непривычными сложностями. Код ведь иногда похлеще, чем человекочитаемый контент. Вот, например, мешающие бизнесу самого Майкрософта эмуляторы Xbox. И это ещё цветочки: международные проблемы будут покруче. Например, власти Китая просили GitHub убрать материалы, связанные с расстрелом на площади Тяньяньмен, — GitHub отказался, и Китай не стал дожимать: этот источник открытого кода слишком важен китайским разработчикам. А вот Майкрософт имеет колоссальные интересы в Китае, его дожать будет намного проще при желании — ему есть что терять.
Короче, посмотрим, какие будут новые истории в стиле знаменитой Tay, которую Майкрософт по наивности выпустил в Тви ;))
https://www.wired.com/story/microsoft-github-code-moderation/

Все от Микрософта с Github'а ломанулись в облачный Gitlab, а он в ажуре :) В смысле - в облаке Microsoft Azure

Сейчас буду много ворчать. Мне нравится проект Vanessa Behavior (ну или, если угодно, его реинкарнация - ADD, https://github.com/silverbulleters/add/). Леня Паутов, Женя Сосна и команда Серебряной пули (Алексей, Артур, привет) разработали отличный инструмент, показали сообществу, что решения на 1С нужно и можно тестировать автоматизированно и используя современные промышленные подходы, катализировали разработку других отличных инструментов тестирования, причем - тоже открытых (Тестер, Тестирование 3.0, ссылки на них можно найти по тегу #Тестирование).

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

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

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

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

Приехали.

#Тестирование #1С #BDD

А вот что пишет автор Cucumber'а про сравнительную полезность использования Gherkin не по прямому назначению (BDD), оригинал: https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years

https://infostart.ru/public/844121/

Реализация поддержки HTTP-ответов с gzip-сжатием штатными средствами 1С (работает начиная с 8.9.3, используется работа с двоичными данными).

#1C

https://infostart.ru/public/842338/

Олег Филиппов как всегда на острие техологического прогресса: в этот раз рассказывает, какие задачи на проектах 1С можно решить при помощи м̶о̶д̶н̶о̶й̶̶ колоночной СУБД Яндекс.ClickHouse. (Тут была запланирована дружеская шутка про сертификат 1С:Хайпожор, но, боюсь, негативные коннотации этого слова не все правильно воспримут).

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

Например: сам запрос (INSERT INTO) можно отправлять в query-стринг, а данные - в теле запроса. Или чего только стоит поддержка INSERT'ом и SELECT'ом кучи популярных форматов: делая INSERT сами данные можно отдавать без трансляции в синтаксически правильный SQL-ный формат "VALUES", а, например, в CSV или в JSON. Также и с получением результата выборки: можно сразу указать нужный выходной формат и получить результат запроса сразу в CSV, JSON или в чем вам там еще нужно (https://clickhouse.yandex/docs/ru/formats/).

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

#1С #ClickHouse

В чатике @Unofficial1C разговорами про внедрение акселотовской WMS разбередили старые болячки, спровоцировали поделиться своей историей.

Я тоже однажды участвовал во внедрении Управления складом 3.0. В итоге не внедрили, хотя тут честно скажу, точно не по вине программного продукта, любой другой бы не внедрили, т.к., там куча противоречий было, которые нужно решить до выбора ПО (сложная топология, противоречивые требования: FPFO при отборе при стековом хранении (обусловлено топологией) и отсутствием зоны подпитки (отгрузка прямо из ячеек) + требование максимального уплотнения склада).

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

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

Сейчас в 4.0, говорят, все лучше, но я не смотрел уже.

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

Не знаю, как обстоят дела с УС 4.0, надеюсь, она действительно стала лучше.

Новости из 1С:Зазеркалья: агент конфигуратора научился сообщать о прогрессе текущей операции (для человека - просто в консоль, и в виде json-сообщений для роботов или просто ваших скриптов).

https://wonderland.v8.1c.ru/blog/razvitie-rezhima-agenta-konfiguratora/

#1С

Новости 1C:OpenSource :) - Зарелизился ADD [1] - напомню, что это новый продукт Серебряной пули, интегрирующий в себя функционал (и кодовую базу) xUnitFor1C и Vanessa Behavior.

Из существенного:
* добавлена поддержка возможности отладки тестов/сценариев штатным образом (как я понимаю, без необходимости предварительно вручную открывать отлаживаемую обработку в 1С, я пока не пробовал),
* портирована для управляемых форм гибкая настройка дымовых тестов, которую я в xUnitFor1C делал для обычных форм [2]. Документации, кстати, пока в составе ADD нет, но можно посмотреть в xUnitFor1C - см. [3].

Крутые изменения, поздравляю команду, контрибуторов и пользователей продукта!

Чайная ложка дегтя: оооочень большой объем изменений про не всегда логически связанный функционал ребята зафигачили в составе буквально нескольких PR, что заинтересованному стороннему разработчику затруднит анализ сделанных изменений (ну, например, если хочется портировать функционал настройки дымовых для УФ обратно в xUnitFor1C 😉). Понятно, что львиная доля коммитов этого релиза сделана одним разработчиком (Артур, привет). Понятно, что внешних участников проекта минимум и фактически проект сейчас развивается не сообществом, а одной конкретной компанией, но...

Ссылки:

[1] ADD - Automation Driven Development: https://github.com/silverbulleters/add/releases/tag/5.1.0.0
[2] PR с настройками дымовых тестов в xUnitFor1C https://github.com/xDrivenDevelopment/xUnitFor1C/pull/757
[3] Документация по настройкам дымовых тестов: https://github.com/xDrivenDevelopment/xUnitFor1C/tree/develop/Tests/Smoke

#1С #Тестирование #BDD

Битриксоиды запустили страницу со статусом доступности Б24, об отсутствии которой я сетовал в период падения российского датацентра, в котором
размещался Б24

https://status.bitrix24.ru/

#Битрикс24

https://infostart.ru/public/795197/

Подробная инструкция как при помощи Jenkins'а, #1Script 'а, Deplpyka'и и какой-то там матери автоматизировать обновление конфигурации тестовых баз #1С из хранилища при появлении в нем изменений.

Автор - Станислав Ганиев (@Benony0), один из соавторов канала @OneSCast

В 2016 году Станислав выступал на INFOSTART EVENT 2016 с докладом "Групповая разработка конфигураций в крупном холдинге" (видео: https://youtu.be/AUYPhLoNG4w). И с тех пор я наблюдаю заочно по публикациям Станислава на ИЭ и активностям в чатах поддержки #1Script, как процесс разработки в его команде существенно эволюционирует. И как результат на предстоящий IE 2018 им уже заявлен доклад "Git для 1С-ника и другие технологии групповой разработки".

Проголосовать за доклад Станислава можно по ссылке https://event.infostart.ru/2018/agenda/#item845261

Я проголосовал, присоединяйтесь :)

И да, голосование за доклады на INFOSTART EVENT 2018 открыто: https://event.infostart.ru/2018/agenda/