Коллега в типовой подсистеме БиблиотекаЭлектронныхДокументов наткнулся на прикольный пример нейминга: ИППДОИПУПДУКД (аббревиатура "Извещение о получении подтверждения даты отправки информации покупателя").
Смущает тут не столько смешное и длинное сокращение, а непоследовательность: по-каким-то причинам, часть имен значений перечисления "свернуты" в аббревиатуры , причем многие вполне по меркам 1С короткие, например, ИОП (Извещение о получении), а часть имен оставлены как есть.
Например, есть значение с именем СоглашениеОбИзмененииСтоимостиПолучатель. Почему тогда не СОИСП?
Именно ради этой фишки я и начал использовать SQLPad - мне нужны были быстрые скриншоты - чтобы обосновывать изменения в параметрах SQL. А с помощью диаграммы это делать удобней
Лучи добра сегодня летят Юрию Былинкину - радостно что мы все вместе потихоньку Докером в голову людям меняем мышление
Крутой ход: конференция от 1С про системную разработку (т.е. не использование платформы 1С, а про то, технологии, которые используются в том числе под капотом платформы 1С).
Чем круто? Тем, что это выглядит как эволюционный, я бы даже сказал, "естественный" способ интегрировать бренд "1С" в сообщество true-разработчиков и размыть ассоциацию "1С — это бухгалтерия".
Пока конференция выглядит камерной и в духе "1С для 1Сников" и я не видел (пока?), чтобы она пиарилась за пределами сообщества 1С (например, на хабре), но все равно круто.
Программа еще официально не опубликована, но, например, в пригласительном письме темы были обозначены так (цитирую):
...мы расскажем как устроен наш кластер, балансировка и обеспечение отказоустойчивости. Или зачем нам вдруг понадобилась NoSQL DB при разработке IDE? Еще расскажем про генерацию интерфейсов и про облака.
Есть довольно популярный пиратский канал по теме 1С. На нем есть все курсы от самых разных авторов за копейки. Именно по этой причине я в свое время передумал делать авторский курс "C# для 1С-ников" для тех, что хотел бы выучить другой технологический стек, с детальным объяснением как работает сама 1С и как можно было бы сделать тот или иной ее компонент самому.
Я даже пробовал написать в 1С по поводу пиратов и получил ответ, что они знают про канал, но ничего с ним сделать не могут.
Вот так потратишь сотню часов над контентом, а потом его возьмут и выложат по 100 рублей и спасибо на скажут. А ты год мудохался, ночей не спал. Подумал я, подумал и не стал делать курс. Оставайтесь в 1С.
P.S. как считаете, сколько должен стоить такой курс, если бы он существовал?
☠️ Казалось бы, тема пиратства в последние годы притихла, по крайней мере я в своем круге общения долгое время ни от кого не слышал, что с вот-де с торрентов что-то скачали. Все уже давно подписаны на сериальчики в нетфликсах, покупают софт в плей-маркетах и эппл сторах, электронные книжки заказывают на букмейтах и учатся во всевозможных курсэрах.
Но внезапно в течение этого года стал резко чаще сталкиваться с пиратством в среде онлайн-образования. На фоне огромной популярности всевозможных онлайн-курсов появились новые формы пиратства: от сервисов покупки курсов вскладчину до верезных тусовок в почти олдскульном формате nnm.ru, перебравшихся в телеграм.
Особенно доставляют сайты-каталоги с платными (!) подписками на доступ в каталог со спираченными курсами. Причем каталоги сделаны так, что не всем и не всегда понятно, что это варезник.
Грустно, что те, кто с целью экономии рубля здесь и сейчас платят пиратам и не думают о том, что из-за этого хороших и действительно стоящих курсов будет появляться меньше. Вдвойне грустно от того, что решение заплатить пирату принимает твой же товарищ ИТ-цеху.
Лет десять назад у меня был коллега из Ульяновска, тоже звали Никитой, кстати. Устроился он тогда в компанию, у которой несколько лет уже работал большой, живой, высоконагруженный продукт, приносивший достаточно денег, чтобы платить команде в России. Продукт активно дорабатывался прямо по живому, а чтобы не сойти с ума, функциональность была покрыта интеграционным тест сьютом. Все бы хорошо, но фичи приоритезировались больше, чем тесты, которые в результате начали подгнивать, перестали отражать реальную ситуацию, и в какой-то момент превратились из инструмента безопасного релиза в театр безопасности. Никто не знал, можно ли им верить, они падали в рандомные моменты времени даже на работающем коде, CI перезапускал тест сьют трижды (!) и считал тест успешным, если он прошел хотя бы один раз из трех. Ситуация быстро кульминировала в пик outages (несколько штук в неделю), невыспавшуюся команду и дерганый менеджмент. Дошло до того, что по общему соглашению разработку вообще всех новых фич остановили на полгода (!), которые посвятили исключительно техдолгу, починке тестов и настройке нормальных процессов релиза. Довольно беспрецендентный шаг, по моему опыту, который тем не менее завершился ощутимым успехом (тоже, кстати, редкость, чтобы такие большие планы ожидаемо сбывались) — работать снова стало возможно. Потом, правда, деньги кончились, но это другая уже история.
Никита тогда занимался как раз починкой тест сьюта и вынес несколько патентованых афоризмов™.
Зачем тесты:
- Тесты помогают двигаться вперед, не оглядываясь назад. - Тесты не делают программу лучше или надежнее. Код самой программы делает программу лучше и надежнее. Акцент всегда на коде! Тесты всегда средство. - Тесты пишутся только из острой необходимости, когда нет других способов обеспечить надежность (простота, гарантии компилятора, БД, ОС). - Смысл тестов в том, чтобы падать. - Прошедший/упавший тест — это сигнал, единица информации. - Тест, падающий всегда, плох. Он ничего не показывает. - Также плох и тест, не падающий никогда. - Мигающий тест не несет информации, это шум.
Что тестировать:
- Ровно то, что программа обеспечивает де факто. - Про каждый (каждый!) тест должно быть понятно, почему он написан, что проверяет, почему это нужно проверять. - Не должно быть тестов «на всякий случай», «просто». - Нет смысла тестировать простые, предсказуемые вещи. - Юнит-тесты тестируют то, что удобно, вместо того, что требует тестирования. - Погоня за 100% покрытием (или любым другим — 90%, 85%) бессмысленное дрочево^W^W формализм.
Как тестировать:
- Тесты не должны отнимать больше усилий, чем код. - Тесты должны быть гибкими и податливыми, не быть обузой, когда надо изменить код. - Не запускать тесты в отдельных, специально создаваемых условиях. Эмуляция окружения, БД, mock-и дают уверенность, что волшебные феечки в волшебной стране работают нормально, а интересно должно быть, как работает реальность. - Асинхронность — не проблема. Надо признать ее существование и тестировать ровно то и ровно так, как оно на самом деле происходит. - Тестирование sleep-ами, фиксированные взятые с потолка задержки, retry тестов — прямая дорога к моргающим тестам, дергающемуся глазу, неврозу, дурке. - Тесты должны быть быстрыми, чтобы запускаться как можно чаще. Duh. - Тесты должны работать локально так же просто, как и на CI. - Кажется, что это сложно или невозможно? Только кажется. Обычно фундаментальных препятствий к этому нет, надо лишь один раз заморочиться. - Править код, архитектуру и даже инфраструктуру (например, взять другую БД!), чтобы написать тесты хорошо — нормально. Тесты тоже часть архитектуры.
От себя добавлю, что главное в тестах — понимание. Когда вы берете в руки отвертку, вы точно знаете, какой именно шуруп вы хотите подкрутить, кто здесь цель, кто средство, какие критерии успеха. Так же должно быть, когда вы садитесь писать тест. Осознанность, епта!
Интересно читать ход мысли по диагностике ошибки, полученной в Конфигураторе. Оформлено уже как (почти) универсальное руководство к действию.
Ну и да, увидев какую-то ошибку, которая не выглядит прикладной, тем более в конфигураторе, на автомате хочется свалить все на разработчиков платформы, но по факту если посмотреть внимательнее, с включённой головой, то можно найти решение самостоятельно.
За прошедший год про SonarQube на митапах и докладах не рассказывал только ленивый. И я (хотя одно другому не мешает).
Оффлайновый Инфостарт Эвент 2020 отменился, заменившись на серию онлайн-митапов по аналогии с теми, что проводились летом.
На ближайшем митапе "Путь к идеальному коду", который будет проходить в эту пятницу (06.11.2020), я таки "поговорю" про SonarQube, но на этот раз больше с точки зрения практики начального использования. Как развернуть под столом, как обойти детские шишки, как залить туда свою конфигурацию. Показывать буду в режиме online, тыкая кнопочки и вводя буквы в терминал.
Конечно же, что-то может пойти не так, но в этом есть отдельный интерес :)
Присоединяйтесь, постараюсь сделать познавательно.
Недавно меня спросили в инстаграме, как я наказываю авторов за сорванные дедлайны. И мне это кажется важной темой, поэтому здесь тоже это расскажу.
🌕🌖 Главная мысль — кто я такая, чтобы кого-то наказывать. У меня просто нет этого права, и я его не хочу. Я уважаю людей, с которыми работаю, мы на равных, а наказание предполагает, что у меня есть какая-то особенная власть. Но поскольку власть и равенство друг другу противоречат, я, пожалуй, выберу равенство.
🌗🌘 Другая мысль в том, что автор сам уже переживает. Даже если бы я хотела наказать, то это наказание было бы плевочком по сравнению с чувством вины, которое уже испытывает автор. То есть мне можно ничего не делать. Это ж классно, когда кто-то делает за меня мою работу, да еще и лучше меня. Зачем я буду вмешиваться?
Если автор не переживает, продолжает срывать сроки и ничего не предпринимает, нам с ним не по пути. Мне пока такие не попадались.
🌑🌒 Если автор переживает, срывает сроки, снова переживает, снова срывает, то это уже не случайность. Автор может объяснять это внешними факторами, типа «эксперт подвел и не смог созвониться», «у меня другой материал занял слишком много времени», «тема оказалась сложнее, чем я думала». Но если внешние факторы мешают систематически, то это уже не внешние факторы.
Может быть, есть какой-то страх облажаться, а может, автора в детстве всё время везде подгоняли, и теперь его физически тошнит от идеи вписываться в какие-то дедлайны. В любом случае я с этим не смогу разобраться, а наказание не поможет, зато поможет психотерапевт.
🌓🌔 Моя задача, как менеджера и руководителя, — выстроить такую систему, при которой мы не будем зависеть от одного сорванного срока. Например, если у нас должно выходить пять статей в неделю, и вот одна сорвалась, то мы ставим вместо нее другую статью, а эту дорабатываем.
🌙 Вообще мне нравится идея «не наказывать, а поддержать». Если у автора систематическая проблема со сроками или с качеством текста, я стараюсь поддерживать.
Поддержка — это не «чувак, соберись, у тебя всё получится!» а просто нормальное человеческое отношение: не устраивать разборки в чатах, а написать в личку; и приходить не с претензией, а с заботой:
— Слушай, я вижу, что у нас уже с третьей твоей статьей проблема, она не выходит вовремя. Давай попробуем понять, в чём дело? Как тебе помочь? Если тебе тяжело сразу сдавать хороший черновик, можем попробовать делать первую итерацию с тезисами. А хочешь, будем созваниваться и проговаривать голосом, как выстроить содержание?
✅ В этом году мне все-таки удалось завершить челлендж и сделать достаточное для получения заветной футболки количество pull request'ов даже немного с запасом.
Но после всего этого индусского флешмоба, превратившего Hacktoberfest в комичный #shitoberfest я предпочел посадить деревце.
p.s. Надеюсь, дерево будет настоящее, а не виртуальное в каком-нибудь виртуальном лесу, как сейчас модно.
p.p.s. Нет, дерево мне не должны прислать ))), его посадят в каком-то специальном парке.
— Ребята из КраудСекьюрити под митап опубликовали кучу небольших решений https://github.com/KraudSecurity/1C-Exploit-Kit и в целом у них крутое исследование было и на своем докладе Алексей Старев показал много интересной статистики.
— По защите был наикрутейший мастер-класс Антона Дорошкевича (загуглите на ютубе другие его доклады). Антон по полочкам все разложил и показал, как нужно настроить сервер 1С с точки зрения безопасности.
— Владимир Бондаревский на мастер-классе показал, как опасно бездумно ставить флаг "Вызов сервера" у общих модулей 1С.
* Иногда там выдаются имена пользователей (если включено) в автодополнении, либо можно попробовать обратиться на /ru_RU/e1cib/users. * Пароли из коробки не чувствительны к регистру. "Пароль" и "пАрОль" - одно и тоже, что уменьшает количество для брута (особенно классно вместе с предыдущим пунктом). * Внутри часто есть выполнение произвольного кода.
