🔥 GitRules — мерж правил обмена КД2 без боли
На прошлой неделе в чатике @ssl1c был бурный спор КД3 vs КД2 и среди прочих аргументов против Конвертации данных 2 была также названа сложность коллективной разработки. Да, когда-то это действительно было проблемой прежде всего из-за того, что XML-файлы сложно мержить инструментами для мержа исходного кода.
Так вот, на самом деле проблема относительно давно решена, но многие об этом еще не знают. Рассказываю.
Есть крутой инструмент — GitRules (ссылка ниже), написанный конечно же на OScript и который разбирает xml-дерево правил обмена на атомарные составляющие и сохраняет их в виде иерархии каталогов и файлов. Естественно, умеет и обратно собирать разобранные в структуру файловой системы правила. Благорадя этому разные версии можно легко сравнивать/объединять без боли универсальными инструментами типа kdiff3, WinMerge, Meld и т.п. и в строенный в git алгоритм мержа отлично будет работать.
Не используете Git и не знаете, нужен ли GitRules вам? Меня он очень сильно выручал не раз в ситуациях, когда нам заказчик возвращал правила "вот мы тут кое-что сами запилили, но не смогли полностью, пожалуйста, помогите доделать". Сравнение/объединение правил встроенными средствами Конвертации данных 2.0 не удобно, не все изменения видит, да еще и не умеет объединять исходный код скриптов, а с GitRules + любой из перечисленных выше инструментов для мержа это вообще не проблема.
Очень рекомендую, а авторам и контрибуторам GitRules и ExchangeRules1C (см. ниже *), огромное спасибо и большущий респект!
Ссылка на инструмент: https://github.com/otymko/gitrules
В readme репозитория исчерпывающая инструкция, но к этому есть еще и статьи про организацию процесса разработки и версионирование правил обмена:
— Версионирование правил обмена в Git — статья на ИС от автора ExchangeRules1C (Никита Коротаев aka bf0rce)
— Повышаем эффективность разработки правил обмена — статья от разработчика GitRules, Олега Тымко (aka @otymko)
* https://github.com/bf0rce/ExchangeRules1C — я точно не знаю, но, вероятно, это прародитель GitRules. Пытаясь решить проблему объединения правил первый раз я нашел и использовал сначала именно его. GitRules, судя по дате публикации, появился позже, но рекомендую к использованию именно GitRules в виду того, что это - полноценный инструмент командной строки, в то время как ExchangeRules1C это не один скрипт, а набор скриптов, без командного интерфейса (нужно файл правил размещать в исполняемой директории скрипта) и работает только под Windows (использует Microsoft XML Parser).
#Инструменты
На прошлой неделе в чатике @ssl1c был бурный спор КД3 vs КД2 и среди прочих аргументов против Конвертации данных 2 была также названа сложность коллективной разработки. Да, когда-то это действительно было проблемой прежде всего из-за того, что XML-файлы сложно мержить инструментами для мержа исходного кода.
Так вот, на самом деле проблема относительно давно решена, но многие об этом еще не знают. Рассказываю.
Есть крутой инструмент — GitRules (ссылка ниже), написанный конечно же на OScript и который разбирает xml-дерево правил обмена на атомарные составляющие и сохраняет их в виде иерархии каталогов и файлов. Естественно, умеет и обратно собирать разобранные в структуру файловой системы правила. Благорадя этому разные версии можно легко сравнивать/объединять без боли универсальными инструментами типа kdiff3, WinMerge, Meld и т.п. и в строенный в git алгоритм мержа отлично будет работать.
Не используете Git и не знаете, нужен ли GitRules вам? Меня он очень сильно выручал не раз в ситуациях, когда нам заказчик возвращал правила "вот мы тут кое-что сами запилили, но не смогли полностью, пожалуйста, помогите доделать". Сравнение/объединение правил встроенными средствами Конвертации данных 2.0 не удобно, не все изменения видит, да еще и не умеет объединять исходный код скриптов, а с GitRules + любой из перечисленных выше инструментов для мержа это вообще не проблема.
Очень рекомендую, а авторам и контрибуторам GitRules и ExchangeRules1C (см. ниже *), огромное спасибо и большущий респект!
Ссылка на инструмент: https://github.com/otymko/gitrules
В readme репозитория исчерпывающая инструкция, но к этому есть еще и статьи про организацию процесса разработки и версионирование правил обмена:
— Версионирование правил обмена в Git — статья на ИС от автора ExchangeRules1C (Никита Коротаев aka bf0rce)
— Повышаем эффективность разработки правил обмена — статья от разработчика GitRules, Олега Тымко (aka @otymko)
* https://github.com/bf0rce/ExchangeRules1C — я точно не знаю, но, вероятно, это прародитель GitRules. Пытаясь решить проблему объединения правил первый раз я нашел и использовал сначала именно его. GitRules, судя по дате публикации, появился позже, но рекомендую к использованию именно GitRules в виду того, что это - полноценный инструмент командной строки, в то время как ExchangeRules1C это не один скрипт, а набор скриптов, без командного интерфейса (нужно файл правил размещать в исполняемой директории скрипта) и работает только под Windows (использует Microsoft XML Parser).
#Инструменты
GitHub
GitHub - otymko/gitrules: Библиотека разбора xml правил конвертации (правил обмена / правил регистрации) на файлы и каталоги
Библиотека разбора xml правил конвертации (правил обмена / правил регистрации) на файлы и каталоги - otymko/gitrules
🤓 Дублирование кода vs dependency hell
Призываю прекратить споры о дублировании кода. Мы убеждаем молодых разработчиков и инженеров в том, что это худшая вещь, когда время учит всех нас, что в подавляющем большинстве случаев предпочтительнее дублирование, чем зависимость.
Особенно, когда мы создаем огромную сложность, абстрагируя код, который просто похож на другой.
— Sam Ferree
Зачастили последнее время подобные высказывания разработчиков в соцсетях.
Создается впечатление, что маятник качнулся в обратную сторону: еще вчера они же убеждали в том, что нужно стремиться к повторному использованию кода, избегать дублирования, максимально используя внешние зависимости.
Сегодня это часто приводит к dependency hell, что является другой крайностью. Правда, конечно же, посередине, а рулит к ней, как всегда, здравый смысл, но есть ли он у юных падаванов?
Let's the holywar begin! 😈
Призываю прекратить споры о дублировании кода. Мы убеждаем молодых разработчиков и инженеров в том, что это худшая вещь, когда время учит всех нас, что в подавляющем большинстве случаев предпочтительнее дублирование, чем зависимость.
Особенно, когда мы создаем огромную сложность, абстрагируя код, который просто похож на другой.
— Sam Ferree
Зачастили последнее время подобные высказывания разработчиков в соцсетях.
Создается впечатление, что маятник качнулся в обратную сторону: еще вчера они же убеждали в том, что нужно стремиться к повторному использованию кода, избегать дублирования, максимально используя внешние зависимости.
Сегодня это часто приводит к dependency hell, что является другой крайностью. Правда, конечно же, посередине, а рулит к ней, как всегда, здравый смысл, но есть ли он у юных падаванов?
Let's the holywar begin! 😈
Forwarded from Deleted Account
Давайте попробуем еще раз прогуляться по истории
FuncTest 7.7 - 2003+ год
FuncTest 8 - 2006+ год
xUnitFor1C 3-тья редакция - 2010+
xUnitFor1C 4-тая редакция 2012+
cuke4onec - vanessa-behavior - 2012+
vanessa-automation-driven-development (ADD) - 2016+
Поэтому Vanessa Automantion Driven Development имеет 5-тую редакцию - это прямая отсылка к исходным продуктам.
Вопрос - когда появились дымовые тесты ? Ответ: На мой взгляд в 2003 году, потому как я первый раз их увидел еще в проекте FuncTest 7.7
Другой вопрос - текущая реализация - кто её автор ? Во первых - дымовых тестов существует 2 реализации: в TDD и BDD стиле - кто их автор. Точно кто-то из контрибьюторов
Однажды я уже писал это в статье на Хабре.
Просьба всем кто не в курсе - на досуге изучить историю развития. Тогда не будет непонимания.
Статья на Хабре - вот эта https://habr.com/post/252473/
Скриншот оттуда
FuncTest 7.7 - 2003+ год
FuncTest 8 - 2006+ год
xUnitFor1C 3-тья редакция - 2010+
xUnitFor1C 4-тая редакция 2012+
cuke4onec - vanessa-behavior - 2012+
vanessa-automation-driven-development (ADD) - 2016+
Поэтому Vanessa Automantion Driven Development имеет 5-тую редакцию - это прямая отсылка к исходным продуктам.
Вопрос - когда появились дымовые тесты ? Ответ: На мой взгляд в 2003 году, потому как я первый раз их увидел еще в проекте FuncTest 7.7
Другой вопрос - текущая реализация - кто её автор ? Во первых - дымовых тестов существует 2 реализации: в TDD и BDD стиле - кто их автор. Точно кто-то из контрибьюторов
Однажды я уже писал это в статье на Хабре.
Просьба всем кто не в курсе - на досуге изучить историю развития. Тогда не будет непонимания.
Статья на Хабре - вот эта https://habr.com/post/252473/
Скриншот оттуда
Habr
Адаптируем BDD для разработки на 1С совместно с cucumber и 1Script
Кто платит за тестирование решений? Особенно в случаях если заказчик (внутренний или внешний) просит запустить систему учета, и не указывает насколько плохая...
Forwarded from Александр Кунташов
Хз, кому это надо, но для потомков немного уточню, а тут чат протестирование, так что в тему :-), тем более 1СUnit/xUnitFor1C — первый популярный репозиторий на 1С на github'е.
В интервале с 2010-2011 был SnowTest Федора Езеева, написанный во времена его работы в Яндексе.
В начале 2012 года я взял из него модуль утверждений и с нуля написал TestRunner для ОФ, так им и пользовался на двух проектах, функционально было это минимальное MVP. Потом в развитии инструмента была пауза до первого лампового Инфостарт Эвента, где я обмолвился в личной беседе о сделанном Артуру. Меньше чем через месяц ровно в ДР Артура я написал ему, и у нас завязался разговор, в результате которого я выложил на github первую публичную версию, которую назвал 1CUnit, потихоньку начали пилить вместе ОФ, а в декабре того же года присоединился Григорий Пташко и прикрутил первую версию поддержки УФ.
В 2013 фирма 1С официально всех предупредила, что 1С в названии можно использовать только если ты партнер и только специальным образом, и Андрей Аристархов, если не ошибаюсь, на ИЭ 2013 в мае (а может и раньше в Г+), намекнул нам, что надо бы переименоваться и этот вопрос начали кулуарно обсуждать. Алексей общался с Андреем лично, он посоветовал использовать суффикс "For1C" + была переписка в G+, в итоге два основных варианта было - xUnitFor1C и OpenUnitFor1C. В результате победил xUnitFor1C. Тогда же я передал репозиторий вновьсозданной организации на github с названием xddDrivenDevelopment (вместо буквы x в начале могла быть буква y, привет Жене Сосне 😊). Приблизительно тогда же, кажется, Женя Сосна прикрутил в проект precommit1C и разрабатывать стали в исходниках.
В 2015 г (я точной даты тут уже не знаю, т.к. я уже активного участия на тот момент не принимал) Женя Павлюк переписал полностью ядро xUnitFor1C в тот вид, какой мы его знаем сейчас, с поддержкой плагинов и т.п. Об этом была отличная статья на хабре https://habr.com/post/270061/
Ну и дальше уже все так, как написал Алексей.
Формально в проекте поучаствовало 31 разработчик: https://github.com/xDrivenDevelopment/xUnitFor1C/graphs/contributors
В интервале с 2010-2011 был SnowTest Федора Езеева, написанный во времена его работы в Яндексе.
В начале 2012 года я взял из него модуль утверждений и с нуля написал TestRunner для ОФ, так им и пользовался на двух проектах, функционально было это минимальное MVP. Потом в развитии инструмента была пауза до первого лампового Инфостарт Эвента, где я обмолвился в личной беседе о сделанном Артуру. Меньше чем через месяц ровно в ДР Артура я написал ему, и у нас завязался разговор, в результате которого я выложил на github первую публичную версию, которую назвал 1CUnit, потихоньку начали пилить вместе ОФ, а в декабре того же года присоединился Григорий Пташко и прикрутил первую версию поддержки УФ.
В 2013 фирма 1С официально всех предупредила, что 1С в названии можно использовать только если ты партнер и только специальным образом, и Андрей Аристархов, если не ошибаюсь, на ИЭ 2013 в мае (а может и раньше в Г+), намекнул нам, что надо бы переименоваться и этот вопрос начали кулуарно обсуждать. Алексей общался с Андреем лично, он посоветовал использовать суффикс "For1C" + была переписка в G+, в итоге два основных варианта было - xUnitFor1C и OpenUnitFor1C. В результате победил xUnitFor1C. Тогда же я передал репозиторий вновьсозданной организации на github с названием xddDrivenDevelopment (вместо буквы x в начале могла быть буква y, привет Жене Сосне 😊). Приблизительно тогда же, кажется, Женя Сосна прикрутил в проект precommit1C и разрабатывать стали в исходниках.
В 2015 г (я точной даты тут уже не знаю, т.к. я уже активного участия на тот момент не принимал) Женя Павлюк переписал полностью ядро xUnitFor1C в тот вид, какой мы его знаем сейчас, с поддержкой плагинов и т.п. Об этом была отличная статья на хабре https://habr.com/post/270061/
Ну и дальше уже все так, как написал Алексей.
Формально в проекте поучаствовало 31 разработчик: https://github.com/xDrivenDevelopment/xUnitFor1C/graphs/contributors
Хабр
Эволюция автоматического тестирования в среде 1С: Предприятие
До релиза новой версии фреймворка по тестированию “xUnitFor1C” осталось совсем немного, а значит пришло время рассказать о проделанной работе и о том, что ожидае...
Forwarded from Экстраполяция IT
Сегодня просто цитата из рабочей переписки:
«Я год работал над собой, прежде чем смог сменить чувство, что я подвёл чьи-то ожидания, не сделав задачу в срок, на чувство "какой дебил написал здесь "два часа".»
«Я год работал над собой, прежде чем смог сменить чувство, что я подвёл чьи-то ожидания, не сделав задачу в срок, на чувство "какой дебил написал здесь "два часа".»
🥳 Вредные советы по юнит-тестированию
На хабре отличная саркастическая статья-исследование юнит-тестов в открытых проектах на java с кучей примеров со ссылками на реальные репы на github'е. Цитата для привлечения внимания:
Написание тестов отнимает много времени, за которое вы могли бы сделать что-то более полезное. Если тест неожиданно начинает падать, ломается сборка на сервере непрерывной интеграции, не выкатывается вовремя релиз, бизнес теряет деньги и крайним оказываетесь вы, автор упавшего юнит-теста. При рефакторинге тесты причиняют головную боль, потому что начинают падать и приходится с этим разбираться.
Комментарии к статье тоже отличные и практически полезные.
Ссылка: https://habr.com/post/434972/
На хабре отличная саркастическая статья-исследование юнит-тестов в открытых проектах на java с кучей примеров со ссылками на реальные репы на github'е. Цитата для привлечения внимания:
Написание тестов отнимает много времени, за которое вы могли бы сделать что-то более полезное. Если тест неожиданно начинает падать, ломается сборка на сервере непрерывной интеграции, не выкатывается вовремя релиз, бизнес теряет деньги и крайним оказываетесь вы, автор упавшего юнит-теста. При рефакторинге тесты причиняют головную боль, потому что начинают падать и приходится с этим разбираться.
Комментарии к статье тоже отличные и практически полезные.
Ссылка: https://habr.com/post/434972/
Хабр
Как писать юнит-тесты, если совсем не хочется
Всех нас на работе то и дело пытаются заставить писать юнит-тесты. Многие уже поняли, что от них один вред. Написание тестов отнимает много времени, за которое в...
Forwarded from Никита Федькин - мысли, заметки, анонсы
Потрясающая вводная статья по сценарному тестированию/bdd и применению инструментов от Владимира Литвиненко https://infostart.ru/public/969637/
Владимир проходил курс по промышленной разработке, подробно разобрался в предмете и имеющейся документации, а сейчас очень структурированно изложил основные принципы сценарного тестирования в 1с, BDD, имеющиеся сложности и подходы.
Настоятельно рекомендую к прочтению всем, кто интересуется темой и по каким-то причинам ещё не начал применять соответствующие методики и инструменты в своей работе.
С нетерпением жду продолжения цикла статей.
Владимир проходил курс по промышленной разработке, подробно разобрался в предмете и имеющейся документации, а сейчас очень структурированно изложил основные принципы сценарного тестирования в 1с, BDD, имеющиеся сложности и подходы.
Настоятельно рекомендую к прочтению всем, кто интересуется темой и по каким-то причинам ещё не начал применять соответствующие методики и инструменты в своей работе.
С нетерпением жду продолжения цикла статей.
infostart.ru
Разработка и сценарное тестирование с Vanessa-ADD. Концепция, теория и сквозной пример создания сценария
Первая часть цикла публикаций, посвященных Vanessa-ADD
❓Эффект разбитых окон при доработке легаси-кода
Представьте ситуацию: разработчику Васе (имя вымышленное, но ситуация реальная) предстояло изменить некий существующий функционал. По факту оказалось, что за последний год до него там была пара итераций доработок, выполненных другими подрядчиками.
В результате этих доработок изначально неплохо написанный механизм два разработчика довели до смердящего 💩 состояния. (Оценку "неплохо" даю по фрагментам незатронутого доработками смежного кода.)
На ревью я с удивлением обнаружил, что неплохо программирующий Вася мимикрировал под своих коллег, оставивших след до него. И я задумался 🤔.
Заказчик в код не смотрит, а новый функционал соответствует его ожиданиям. Ограничения по бюджету и сроку соблюдены. Сам Вася комплексов, как я понял, не испытывает. Код в этом модуле изменяется относительно редко и от него ничего серьезного не зависит. Это так мой внутренний голос эффективного (зачеркнуто) менеджера 😈 убеждает меня, что все ок.
А моя технарская душонка 👼 не спокойна и все равно требует сказать Васе, что так нельзя и что нужно было хотя бы поднять вопрос о рефакторинге. А еще лучше, заставить его в назидание все хорошенько прибрать.
Как бы поступили вы на месте разработчика? Зарефакторили молча? Или все-таки сначала обсудили бы явно с руководителем/заказчиком, а уже в случае отрицательного решения — наговнокодили? Или, может быть, забили бы на окружающий старый код, но сами постарались бы написать чисто?
Нормально ли, когда разработчик, видя говнокод, который ему предстоит доработать, вместо того, чтобы прибрать, подбрасывает в него свеженького? Или это проявление непрофессионализма?
Кажется, неплохая тема для пятничной дискуссии. Предлагаю обсудить в @ssl1c :-)
#codesmells #говнокод
Представьте ситуацию: разработчику Васе (имя вымышленное, но ситуация реальная) предстояло изменить некий существующий функционал. По факту оказалось, что за последний год до него там была пара итераций доработок, выполненных другими подрядчиками.
В результате этих доработок изначально неплохо написанный механизм два разработчика довели до смердящего 💩 состояния. (Оценку "неплохо" даю по фрагментам незатронутого доработками смежного кода.)
На ревью я с удивлением обнаружил, что неплохо программирующий Вася мимикрировал под своих коллег, оставивших след до него. И я задумался 🤔.
Заказчик в код не смотрит, а новый функционал соответствует его ожиданиям. Ограничения по бюджету и сроку соблюдены. Сам Вася комплексов, как я понял, не испытывает. Код в этом модуле изменяется относительно редко и от него ничего серьезного не зависит. Это так мой внутренний голос эффективного (зачеркнуто) менеджера 😈 убеждает меня, что все ок.
А моя технарская душонка 👼 не спокойна и все равно требует сказать Васе, что так нельзя и что нужно было хотя бы поднять вопрос о рефакторинге. А еще лучше, заставить его в назидание все хорошенько прибрать.
Как бы поступили вы на месте разработчика? Зарефакторили молча? Или все-таки сначала обсудили бы явно с руководителем/заказчиком, а уже в случае отрицательного решения — наговнокодили? Или, может быть, забили бы на окружающий старый код, но сами постарались бы написать чисто?
Нормально ли, когда разработчик, видя говнокод, который ему предстоит доработать, вместо того, чтобы прибрать, подбрасывает в него свеженького? Или это проявление непрофессионализма?
Кажется, неплохая тема для пятничной дискуссии. Предлагаю обсудить в @ssl1c :-)
#codesmells #говнокод
Вам поставили задачу доработать некий существующий функционал. Его текущая реализация: 💩-код. Как вы поступите? (подробнее ситуация описана в https://t.iss.one/kuntashov_devnotes/315)
anonymous poll
2. 😷 Свой код напишу чисто, чужой постараюсь не трогать – 113
👍👍👍👍👍👍👍 50%
4. 👔 Предложу сначала провести рефакторинг. Откажутся - см. п. 2 – 80
👍👍👍👍👍 35%
3. 💩 Напишу в стиле предыдущих авторов (для единообразия) – 20
👍 9%
1. 💪 Перепишу все с нуля – 8
▫️ 4%
5. 😎 Другое (расскажу в чате @ssl1c) – 6
▫️ 3%
👥 227 people voted so far.
anonymous poll
2. 😷 Свой код напишу чисто, чужой постараюсь не трогать – 113
👍👍👍👍👍👍👍 50%
4. 👔 Предложу сначала провести рефакторинг. Откажутся - см. п. 2 – 80
👍👍👍👍👍 35%
3. 💩 Напишу в стиле предыдущих авторов (для единообразия) – 20
👍 9%
1. 💪 Перепишу все с нуля – 8
▫️ 4%
5. 😎 Другое (расскажу в чате @ssl1c) – 6
▫️ 3%
👥 227 people voted so far.
👋 Всем привет!
За последнюю неделю количество подписчиков приятно увеличилось на 150+ человек (судя по всему благодаря упоминанию на Geekbrains). Добро пожаловать!
Я профессионально занимаюсь разработкой и управлением проектами вокруг да около 1С и Битрикс/Битрикс24 и публикации в этом чате так или иначе являются отражением моей рабочей деятельности.
В личке меня уже несколько раз спросили, где в Телеграме можно задать вопрос и пообщаться по тематике 1С. Вот список чатов в Телеграме, где я время от времени бываю и в которых почти каждый день идут интересные обсуждения с участием крутых разработчиков 1С:
@ssl1c — чат для обсуждения 1С:Библиотеки стандартных подсистем и в целом по разработке на 1С и смежным темам, например по DevOps'у в мире 1С и архитектуре, по стандартам разработки (в контексте 1С и не только). Чат администрируется одним из разработчиков БСП.
@testspro1c — чат для обсуждения вопросов тестирования в 1С. Там админствует Леонид Паутов (PrMex), в прошлом ведущий разработчик Vanessa Behavior, а сегодня - автор ее форка Vanessa Automation.
@edt1c — чат по 1C:Enterprise Development Tools, новому средству разработки 1С, который когда-нибудь заменит конфигуратор 1С (не сочтите за сарказм).
@oscript_library — чат по OneScript — опенсорсной, кросс-платформенной реализации встроенного языка программирования 1С. Там обсуждают практику использования ванскрипта и библиотек, написанных на нем. Администраторы чата: ведущий разработчик OneScript Андрей Овсянкин и автор огромного количества библиотек на этом языке — Никита Грызлов.
@silvernation — чат команды Серебряная пуля (знаменитые в сообществе 1С Алексей Лустин, Артур Аюханов, Андрей Овсянкин). Эти ребята на передовой: авторы и разработчики/ментейнеры ведущих open-source проектов на 1С, таких как xUnitFor1C и Vanessa-ADD. Цитирую Артура: "Мы и тестированием активно занимаемся, и DevOps, и статический анализ кода и вообще одни из главных и первых практиков применения инженерных практик для мира 1С".
@unofficialC1 — это самый неформальный из перечисленны выше чатов, в котором общаются специалисты по 1С (не только разработчики). Обсуждения там бывают и на профессиональные темы, и не очень. Осторожно: там ругаются матом, грубо шутят и уровень флуда там часто переходит границы разумного.
@bit24dev — чат для внедренцев и разработчиков CRM Битрикс24. Там есть в том числе разработчики из самого Битрикса (даже Востриков собственной персоной периодически появляется и отвечает).
Кому нужно больше, посмотрите список каналов и чатов по 1С и управлению проектами по ссылке https://www.yellowbathrobes.com/blog/tgchannels
Продуктивного и приятного общения!
За последнюю неделю количество подписчиков приятно увеличилось на 150+ человек (судя по всему благодаря упоминанию на Geekbrains). Добро пожаловать!
Я профессионально занимаюсь разработкой и управлением проектами вокруг да около 1С и Битрикс/Битрикс24 и публикации в этом чате так или иначе являются отражением моей рабочей деятельности.
В личке меня уже несколько раз спросили, где в Телеграме можно задать вопрос и пообщаться по тематике 1С. Вот список чатов в Телеграме, где я время от времени бываю и в которых почти каждый день идут интересные обсуждения с участием крутых разработчиков 1С:
@ssl1c — чат для обсуждения 1С:Библиотеки стандартных подсистем и в целом по разработке на 1С и смежным темам, например по DevOps'у в мире 1С и архитектуре, по стандартам разработки (в контексте 1С и не только). Чат администрируется одним из разработчиков БСП.
@testspro1c — чат для обсуждения вопросов тестирования в 1С. Там админствует Леонид Паутов (PrMex), в прошлом ведущий разработчик Vanessa Behavior, а сегодня - автор ее форка Vanessa Automation.
@edt1c — чат по 1C:Enterprise Development Tools, новому средству разработки 1С, который когда-нибудь заменит конфигуратор 1С (не сочтите за сарказм).
@oscript_library — чат по OneScript — опенсорсной, кросс-платформенной реализации встроенного языка программирования 1С. Там обсуждают практику использования ванскрипта и библиотек, написанных на нем. Администраторы чата: ведущий разработчик OneScript Андрей Овсянкин и автор огромного количества библиотек на этом языке — Никита Грызлов.
@silvernation — чат команды Серебряная пуля (знаменитые в сообществе 1С Алексей Лустин, Артур Аюханов, Андрей Овсянкин). Эти ребята на передовой: авторы и разработчики/ментейнеры ведущих open-source проектов на 1С, таких как xUnitFor1C и Vanessa-ADD. Цитирую Артура: "Мы и тестированием активно занимаемся, и DevOps, и статический анализ кода и вообще одни из главных и первых практиков применения инженерных практик для мира 1С".
@unofficialC1 — это самый неформальный из перечисленны выше чатов, в котором общаются специалисты по 1С (не только разработчики). Обсуждения там бывают и на профессиональные темы, и не очень. Осторожно: там ругаются матом, грубо шутят и уровень флуда там часто переходит границы разумного.
@bit24dev — чат для внедренцев и разработчиков CRM Битрикс24. Там есть в том числе разработчики из самого Битрикса (даже Востриков собственной персоной периодически появляется и отвечает).
Кому нужно больше, посмотрите список каналов и чатов по 1С и управлению проектами по ссылке https://www.yellowbathrobes.com/blog/tgchannels
Продуктивного и приятного общения!
👔 Взгляд среднего бизнеса на инновации vs 🤓 взгляд молодого ИТшника. Утрировано и однобоко, но основной конфликт отражает.
Оригинальный тред: https://mobile.twitter.com/karbonio/status/1085996541482070016
Оригинальный тред: https://mobile.twitter.com/karbonio/status/1085996541482070016
📚 Что почитать на выходных — 6
🎓 Будущее программирования, Роберт Мартин [25 мин]
Владимир Литвиненко сделал транскрипт/перевод интересного выступления Дядюшки Боба с размышлением о том, как развивалась, развивается и будет развиваться наша отрасль. Видео оригинального доклада здесь.
😎 The Four Keys To Rapid Response Software Development [15 мин]
Энди Хант, один из авторов Agile Manifesto, кратко и по делу пишет о 4 ключевых принципах на которые должна опираться современная разработка ПО. Зацепило: "...if you have long-running feature branches that have to be re-integrated to Master at some point in the future, then congratulations! You’ve just re-invented “waterfall.”"
🐒 Пользователи нелогичны, а инновации нужны не всем: ожидания и реальность дизайнеров при разработке продуктов [20 мин]
В статье систематизированы основные ошибки, которые аналитики, дизайнеры UI и разработчики допускают, пытаясь понять, чего хотят пользователи. Ничего нового для тех, кто читал фундаментальные книжки по анализу требований и проектированию UX, но в качестве конспекта-напоминалки хорошо подойдет.
🤓 Things I don't know as of 2018 [10 мин]
Ведущий разработчик React Дэн Абрамов признается в том, что он знает гораздо меньше технологий, чем многие думают о нем ("тыжпрограммист"). Статья бурно обсуждалась в твиттере, в результате автор написал продолжение: The Elements of UI Engineering, в которой написал, что же он все-таки знает. Общие идеи публикаций в том, что полезнее не знание каких-то конкретных технологий, а понимание проблем, которые они решают и принципов, на которых они построены.
🔔 Комбинаторика британского колокольного звона [10 мин]
Статья для гиков, любящих комбинаторику, а также для тех, кому интересны истории любопытных устройств. К слову, любителям всего странного около-ИТшного и около-математического рекомендую канал @pathetic_low_freq целиком.
📖 Бонус-трек: Для чтения на всю грядущую неделю рекомендую Яндекс.Книгу — история становления и развития Яндекса, построенная в виде множества интервью с ключевыми персонажами, связанными с Яндексом. Мне чтение подарило несколько инсайтов на тему стартапов, управления персоналом, (само)мотивации. Ну и в целом история интереасная, написано не скучно. Вот вам одна из классных цитат книги для затравки (слова Леонида Богуславского):
У меня есть вообще такая теория. У каждого человека в течение жизни возникает некоторое количество уникальных для него возможностей. И люди делятся на три категории. Одни эти возможности не замечают, просто не видят. Вторая категория — это те, кто видит эти возможности, но не готов ничего изменить в своей жизни. Я их называю люди-трамваи, они ездят по рельсам, видят, что вот там что-то такое светит, что-то хорошее, интересное, но как-то вот на рельсах тоже неплохо, надежно — ну и едем дальше. А третья категория — это те, кто видит эти возможности и всегда готов к переменам, чтобы их постараться реализовать.
#ЧтоПочитатьНаВыходных
🎓 Будущее программирования, Роберт Мартин [25 мин]
Владимир Литвиненко сделал транскрипт/перевод интересного выступления Дядюшки Боба с размышлением о том, как развивалась, развивается и будет развиваться наша отрасль. Видео оригинального доклада здесь.
😎 The Four Keys To Rapid Response Software Development [15 мин]
Энди Хант, один из авторов Agile Manifesto, кратко и по делу пишет о 4 ключевых принципах на которые должна опираться современная разработка ПО. Зацепило: "...if you have long-running feature branches that have to be re-integrated to Master at some point in the future, then congratulations! You’ve just re-invented “waterfall.”"
🐒 Пользователи нелогичны, а инновации нужны не всем: ожидания и реальность дизайнеров при разработке продуктов [20 мин]
В статье систематизированы основные ошибки, которые аналитики, дизайнеры UI и разработчики допускают, пытаясь понять, чего хотят пользователи. Ничего нового для тех, кто читал фундаментальные книжки по анализу требований и проектированию UX, но в качестве конспекта-напоминалки хорошо подойдет.
🤓 Things I don't know as of 2018 [10 мин]
Ведущий разработчик React Дэн Абрамов признается в том, что он знает гораздо меньше технологий, чем многие думают о нем ("тыжпрограммист"). Статья бурно обсуждалась в твиттере, в результате автор написал продолжение: The Elements of UI Engineering, в которой написал, что же он все-таки знает. Общие идеи публикаций в том, что полезнее не знание каких-то конкретных технологий, а понимание проблем, которые они решают и принципов, на которых они построены.
🔔 Комбинаторика британского колокольного звона [10 мин]
Статья для гиков, любящих комбинаторику, а также для тех, кому интересны истории любопытных устройств. К слову, любителям всего странного около-ИТшного и около-математического рекомендую канал @pathetic_low_freq целиком.
📖 Бонус-трек: Для чтения на всю грядущую неделю рекомендую Яндекс.Книгу — история становления и развития Яндекса, построенная в виде множества интервью с ключевыми персонажами, связанными с Яндексом. Мне чтение подарило несколько инсайтов на тему стартапов, управления персоналом, (само)мотивации. Ну и в целом история интереасная, написано не скучно. Вот вам одна из классных цитат книги для затравки (слова Леонида Богуславского):
У меня есть вообще такая теория. У каждого человека в течение жизни возникает некоторое количество уникальных для него возможностей. И люди делятся на три категории. Одни эти возможности не замечают, просто не видят. Вторая категория — это те, кто видит эти возможности, но не готов ничего изменить в своей жизни. Я их называю люди-трамваи, они ездят по рельсам, видят, что вот там что-то такое светит, что-то хорошее, интересное, но как-то вот на рельсах тоже неплохо, надежно — ну и едем дальше. А третья категория — это те, кто видит эти возможности и всегда готов к переменам, чтобы их постараться реализовать.
#ЧтоПочитатьНаВыходных
Попытка - не пытка?!
p.s.
А вообще здесь "прекрасно все":
1. Вложенные попытки
2. Закомментированный код
3. Цикл без тела цикла
4. Сравнение константы булева типа с литералом булева типа
4. Копипаст
5. В условной конструкции
6. Неиспользуемая переменная
#codesmells 💩 #говнокод
p.s.
А вообще здесь "прекрасно все":
1. Вложенные попытки
2. Закомментированный код
3. Цикл без тела цикла
4. Сравнение константы булева типа с литералом булева типа
4. Копипаст
5. В условной конструкции
Если Константы... 4 экрана программного кода6. Неиспользуемая переменная
#codesmells 💩 #говнокод
Все любят истории про ПервыйБит. Вот твиттер свеженького принес. Оригинал: https://twitter.com/_jeck/status/1087353614979481605
Ссылка на тест из твита:https://hr-portal.ru/pages/hu/logika.php
Ссылка на тест из твита:https://hr-portal.ru/pages/hu/logika.php
Бодренький обзор событий 2018 года в мире 1С от @iwangoff aka Yellow robe man, автора канала @yellow1c
https://www.yellowbathrobes.com/blog/itogi2018
https://www.yellowbathrobes.com/blog/itogi2018
Прикольная вакансия в Битрикс24 с релокацией в Калининград под крыло к Сергею Вострикову aka @brainmixer
Forwarded from Иван
Аттеншен, плиз :)
Регулярно местные пишут что в доке по RESTу "не все так гладко как бы хотелось".
Так вот что мы (битрикс) на эту тему надумали.
Хочется сделать так, чтобы разработчик с самым разным уровнем получал исчерпывающий ответ - как ему решить задачу клиента, создать приложение. Именно это и нужно будет организовать новому человеку в нашей команде. @brainmixer набирает себе помощника. Ответственная и интересная задача.
Обычно даже в небольшой команде разработчиков выделяется человек, которому искренне интересно разобраться "как оно устроено" и объяснить другим. Ведуться блоги, пишутся мануалы. А тут документация, "туториалы" для огромного сообщества.
Тысячи (и я не утрирую) разработчиков работает с Б24, с нашей докой по всему миру! Представляете какую уважуху от сообщества можно получить на этой позиции! Не подумайте плохого, зарплату тоже платят :)
Подробное описании вакансии по ссылке https://kaliningrad.hh.ru/vacancy/29646728
Элеонора Золошкова наш HR, ей писать отклики +7 (911) 4669958, [email protected]
Знаю что и с релокацией мы помогаем, а уж сколько про жизнь в Калининграде написано :)
---
p.s.
Если вы знаете подходящего кандидата - поделитесь с ним ссылкой пожалуйста!
Кажется всем разработчикам в этом чатике интересно чтобы такой человек нашелся быстрее :)
Регулярно местные пишут что в доке по RESTу "не все так гладко как бы хотелось".
Так вот что мы (битрикс) на эту тему надумали.
Хочется сделать так, чтобы разработчик с самым разным уровнем получал исчерпывающий ответ - как ему решить задачу клиента, создать приложение. Именно это и нужно будет организовать новому человеку в нашей команде. @brainmixer набирает себе помощника. Ответственная и интересная задача.
Обычно даже в небольшой команде разработчиков выделяется человек, которому искренне интересно разобраться "как оно устроено" и объяснить другим. Ведуться блоги, пишутся мануалы. А тут документация, "туториалы" для огромного сообщества.
Тысячи (и я не утрирую) разработчиков работает с Б24, с нашей докой по всему миру! Представляете какую уважуху от сообщества можно получить на этой позиции! Не подумайте плохого, зарплату тоже платят :)
Подробное описании вакансии по ссылке https://kaliningrad.hh.ru/vacancy/29646728
Элеонора Золошкова наш HR, ей писать отклики +7 (911) 4669958, [email protected]
Знаю что и с релокацией мы помогаем, а уж сколько про жизнь в Калининграде написано :)
---
p.s.
Если вы знаете подходящего кандидата - поделитесь с ним ссылкой пожалуйста!
Кажется всем разработчикам в этом чатике интересно чтобы такой человек нашелся быстрее :)
kaliningrad.hh.ru
Вакансия Веб-разработчик на направление "Маркетплейс" в Калининграде, работа в 1C-Битрикс (вакансия в архиве)
Вакансия Веб-разработчик на направление "Маркетплейс". Зарплата: не указана. Калининград. Требуемый опыт: 1–3 года. Полная занятость. Дата публикации: 30.01.2019.