Я уже наглядно показал выше, что чаще всего обновления оказываются вообще не нужны компаниям, которые используют 1С. Если оно уже подключено и работает, зачем что-то обновлять?
А потому не обновляться вы не можете. По сути, успешно и до конца 1С внедрить невозможно, т.к. она постоянно обновляется.
И вот вышло обновление. И вот, выходят обновления. выходит обновление Вышло обновление, в котором так как обновление вышло Вы скачиваете обновления конфигурации Давайте заглянем в любое из обновлений
Больше обновлений богу обновлений! Люблю запах напалма обмазываться обновлениями по утрам, каждый день ИТС проверяю, как бы чего не вышло без меня.
Представьте себе, что имеется завод, который работает круглосуточно и пользуется ERP-системой. Вышло обновление, в котором работают далеко не все. Например, это может быть обновление какой-нибудь консолидированной отчетности для бухгалтерии. И пользуется ими только бухгалтерия.
Ну так поставьте отдельно бухгалтерию и отдельно заводскую конфигурацию, вплоть до ТОИР и MES. Релизные циклы разделены, интеграций между системами - ворох. Или злые php-шники забрали себе все интеграции и запрещают вам изучать новое? Вообще, это талант - выворачивать ситуацию наизнанку, когда преимущество оперативной реакции на актуальные изменения законодательства превращается в "плак-плак, я усталь обновляться".
В 1С отсутствует профессиональный рост
Лол. С 1С-ки легко перейти и на шарп, и на флаттер, и на питон, и на чистый SQL, и на много чего еще. У меня прям живые примеры есть. И внутри самой 1С-ки непаханное поле технологий: шины, интерфейсы, интеграции, тестирование и много чего еще. Было бы желание. Кстати, про желание:
В итоге, на что-либо новое у вас не остается времени. Вы занимаетесь, по сути, одним и тем же.
Здорово, правда?) Не хочешь напрягаться по жизни и сидеть на относительно тепленьком местечке - колупай себе формы и макеты. Хочешь нормально разрабатывать - изучай исполнитель, архитектуру, гитхаб, брокеры, метапрограммирование, нейросети, - всему найдется применение внутри экосистемы.
я даже рекламирую в их среде свои разработки на Drupal
я стал специалистом и официальным представителем Zoho
А впрочем, ничего нового. Самим то не надоело пиарить очередную CMS/CRM через неубедительную эфемерную критику одинэски? Оставляя в стороне реально существующие недостатки платформы и непомерные аппетиты вендора, каждая подобная статья отвратительна тем, что автор стабильно за рекламную копейку канонично обесценивает труд всех тех людей, кто строит одинэсную экосистему и автоматизирует, ну наверное, половину финансового учета и товародвижения в стране.
До сих пор не понимаю, почему так популярен оперативный учет в статической среде. Для ведения тех же задач система, кроме списков и вложений, должна удовлетворять требованиям ссылочной целостности, помнить историю изменений, предоставлять совместный доступ с разграничением прав. Оптимальный максимум обсидиана в этом плане – журнальный подход: личный дневник, дневник снов, агрегация новостей, где информация только добавляется. Задачи и канбаны как будто явно лишние.
Хотя лейтмотив статьи в целом правильный – в роли конструктора под индивидуальные нужды вещь шикарная. Если бы только не приходилось учить JS.
участвовали в обсуждени
Наверное, хотелось бы увидеть в статье чуть более развернутое упоминание гита именно в свете закономерного этапа развития принципа простоты и использования нативных возможностей файловой системы, которые усиляют позиции идеи "Docs as Code". Что сам обсидиан не обязан брать ответственность за версионирование и синхронизацию, хотя последняя в нем и есть в облачном формате.
практические задачки, которые вам хотелось бы решать с помощью Obsidian
Мой второстепенный сценарий – быстренько спарсить миллион сохраненных закладок с того же хабра скриптом из .html в .md, создать из них хранилище и задействовать полнотекстовый поиск по ключевым словам, чтобы найти ту намертво засевшую в памяти статью про кофе и эволюцию технологии его приготовления, которая не ищется ни через родной поиск, ни через гугловый. А по пути залипнуть на случайно попавшие в выборку статьи про ОКР, СДВГ, гештальты и прочие профессиональные болезни цифровых инженеров. Как говорится, современные проблемы требуют современных решений!
поэтому можно дополнительно попросить Cursor не трогать код рабочего функционала, чтобы он не сгаллюцинировал и все не испортил
Как быть, если исправление требует стратегического, архитектурного рефакторинга по существующим модулям? Утрированно, - по сигнатурам методов прокинуть дополнительный параметр?
я создал слишком много запросов кода и Телеграм меня забанил. Тоже учтите этот момент и заранее спросите у Cursor как этого избежать.
Есть еще моменты, которые нужно учесть? Что еще я могу потенциально повесить, если их не учту?
С учетом этих моментов и платы за запросы навык разработки выглядит просто как перекладывание когнитивной сложности на фоне инволюции обратно из науки в шаманство. Из области, где есть непротиворечивая теория, логика, законы, гайды, документация и дорожные карты происходит откат в область, где требуются все те же мысленные усилия, но не обеспеченные никакой жесткой структурированной основой и результатом. Ближайшая аналогия - производство семян, когда ГМО, хирургически точную технологию с целевым результатом, покрытую тестами и исследованиями, избегают, а облучать радиацией семена вслепую - норм, может какая полезная мутация да выйдет, разгони-ка эти гамма-частицы побыстрее, брат.
Еще момент, что подобные продукты паразитируют на теле Stackoverflow и других проектов с корпусом качественных знаний, естественным образом произошедших из мозгов людей, получивших классическое обучение и набравших рабочий опыт. Причем паразитируют очень деструктивно, в формате конкуренции, убивая материал, на котором учатся и обесценивая классический жизненный цикл роста специалиста и государственные программы обучения.
В общем, вся эта истерия с нейрогенеративной разработкой кажется какой-то коммерческой игрушкой и злобным суррогатом от создателей "жизнь по подписке" и "купи самооценку за деньги". Ходишь по этому цирку-ярмарке нейросетей, все они такие громкие, яркие, манящие. На главном представлении тебе буквально показывают бородатых женщин и сросшихся близнецов с мутированными конечностями. Уходя в экстазе, ты покупаешь очередную свистоперделку по оверпрайсу, а придя домой, разочаровываешься, когда садится батарейка, или она ломается после первого падения в руках друга. И тут ты либо взрослеешь и идешь в детский мир за нормальными игрушки, а на бородатых женщин смотришь в генетической лаборатории, по пути придумывая лекарство от гипертрихоза. Либо остаешься ребенком, ведущемся на мишуру и беспроигрышную лотерею, пока другие мутировавшие мохнатые руки потрошат твою свинку-копилку.
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Архитектура решения воспроизводит 1С подходы. Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга? Или это больше поверхностная копия на самостоятельном размышлении и наблюдении? Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы. Вы до этих файлов тоже добрались, например?
Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора? Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?
Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.
Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы? Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему? Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям? Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?
Забавно, что даже на уровне технических директоров в 1Ске все равно ищут по конкретным типовым решениям от вендора (УТ, ДО, БП), а соискатели заявляются в обобщенном виде (максимум, ERP-системы). Совпадает с эмпирическим ощущением от прохождения собеседований, когда очень формально и напрямую подходят к поиску сотрудников, первичным фильтром сразу отсеивая кандидатов, у которых нет упоминания нужных решений в резюме.
Таким страдают и крупные компании, типа Яндекса, как будто прямо так сложно перестроить на месте человека с немного параллельным опытом, но внутри той же экосистемы. Почему-то мантра "не учите фреймворки, учите архитектуру" тут не работает, хотя уж для CTO это точно фундаментальная ценность.
подавляющее большинство разработчиков делают фичебранч
Я и сказал с самого начала ветки, что это вопрос ответственности. Для обычного разработчика в несломанных процессах, кроме плагина ничего и не нужно, с этим я не спорю.
gitlab-ci тут при чем
Ну например, чтобы написать базовую строку скрипта, мне кажется, все же надо знать, что такое дефолтная ветка, как она выбирается, почему раньше она называлась master, а сейчас main, почему в гитфлоу дефолтной считается main, но на прод надо выкатывать релизную и тому подобные нюансы. Это знания о гите, которые не дает плагин. Плюс кто-то же в компании выбирает, чем пользоваться - гитлабом, гитхабом, битбакетом, гитеей. Насколько плотная интеграция с гитом в скриптах ci/cd, насколько понятен и интуитивен синтаксис. Или все само по мановению волшебной палочки появляется? А RnD и экономическо-технический подсчет никогда не спускают на разработчиков?
Какой-то вы совсем трэш описали.
Не верю, что везде прям так все идеально, треш на любой работе есть в той или иной мере и с ним приходится сталкиваться. Пример был немного утрирован, хотя и близок к происходящему, но приведу более реальный пример.
У нас искусственно поддерживается нездоровая конкуренция между линейным персоналом. Репы форкаются, внутренние либы развиваются параллельно, потом оставляется наиболее выживший и приспособленный кандидат и все его потом дружно х***осят. И это не конструктивная история, как в каком-нибудь гугле, а очень сломанная и демотивирующая деятельность.
Но дает много материала, чтобы посмотреть на разные проблемы под разными углами, научиться решать их разными путями, и собственно, продвигаться к тому специалисту, кто выстраивает процессы для обычных разработчиков. В целом, негатив терпим и есть вызов как залог развития. Как работать без того, чтобы иногда глядеть по сторонам и помогать решать системные проблемы, если честно, даже не представляю. Мне кажется, это довольно скучно.
Хорошая новость! Концепция знакомая, пользовался ssh в VS Code, он тоже сначала был плагином, потом стал частью поставки редактора.
Просто в примере с уходом в линукс я в который раз хочу сказать, что существуют не только задачи разработки. Есть не менее комплексная и сложная деятельность смежных отделов, где все, кроме собственно кода, надо хранить как код. Docs as Code, DevOps as Code, Infrastructure as a Code. Необходимость обслужить компонент, систему или инфраструктуру целиком может возникнуть и у обычного разработчика, и это не какая-то невозможная ситуация, где среда с плагином в этом случае даст отказ.
В конце концов, гит - это изначально линуксовая утилита, она останется первичной материей и не может быть менее важна накрученных на нее для удобства оболочек, чтобы вот так просто ее отбросить.
Я не смогу привести примеры именно в том формате, в котором вы хотите.
При этом, моя позиция уже достаточно аргументирована. Уходим на линукс - привет, консоль. Плагина нет, потому что нет GUI и среды нет. Вы упомянули Gitkraken - это не плагин. То есть, плагина уже недостаточно, раз используется внешний продукт. Написать в скрипте гитлаба if: $CI_COMMIT_BRANCH = $CI_DEFAULT_BRANCH плагин тоже не поможет полностью. Может подсветить синтаксис и сделать автодополнение, но саму строчку и понимание, как она работает, надо будет брать из гугла. Итого есть 3 страйка, чтобы формально опровергнуть исходное утверждение автора коммента.
Но мы же не боремся формально, у кого больше аргумент, и не смотрим только на верхушку айсберга. В идеальном мире разраб сидит на конвейере и имеет узкую специализацию. В реальном мире прибегают 4 всадника апокалипсиса, отрывают у вас руки и ими же разыгрывают флеш-рояль: винды нет, мака нет, jetbrains нет, а вместо хотя бы крепкого фулл-хауса из знаний, как резко в моменте выполнить ежедневную операцию другим способом, вы в зубах (рук же нет) держите вальта по имени chatgpt и сраную тройку из нетерпимости к другим языкам, ложной самоуверенности и ограниченного кругозора.
Мне, как и вам, конечно, хочется, чтобы комфортные условия никогда не менялись, а какие-нибудь добрые умные дядьки заботились о том, чтобы я не вылезал за пределы придуманного ими контура и инструментария. Но это порочная стратегия, и транслировать ее миру тоже неправильно.
с 1с и прочими радостями - это все местная специфика
P.S.: Ну да, одинэсники - не настоящие программисты) Занимаетесь классическим обесцениванием, обидно. Из-за этого, наверное, уже и не хочется продолжать с вами дальнейшее обсуждение. Даже со всем уважением к вашей попытке понять позицию собеседника (не знаю уж, насколько она искренняя).
Конфигуратор на svn работает, а эклипс на гите, и шина на гите. На кой мне ваш mercurial сдался в обсуждении гита и одинэсок? Разобрались бы сначала в вопросе или не лезли уже.
И откуда вам про команды меркуриала знать, если по вашим же словам кроме плагина в студии ничего не видели, ведь вам хватает его с избытком?
Ну и вы на VS2022 разве не в винде кодите? На маке, что ли? Это тогда вообще эклектика какая-то нездоровая.
Все, теперь понял. Наверное, безумно удобно сидеть в чешско-кирпской компании и спамить в грубой форме в русскоязычный портал о технологиях. Довольны своим карьерным успехом? Почему не хотите рвать связь с русским профессиональным сообществом? Почему не бережете репутацию, все же оставаясь на связи в комментах? Ваши руководители вообще знают, чем вы занимаетесь в рабочее время?
В линкедине, кстати, численность указана в 50-200 сотрудников. На порядок отличается от "тысяч сотрудников в монорепозиториях" и очень далеко от "кровавого энтерпрайза".
Эх, я надеялся на конструктивную беседу и более уверенную и аргументированную позицию, а не на ожесточенное отбрехивание какахами. Правда было интересно, почему у вас настолько безапелляционная позиция без видимого основания, идущая вразрез с общим мнением.
Я упоминал специфику 1С с несколькими средами и поставками вендора. Образовалась ситуация, когда типовая версия поставщика безнадежно устарела и из-за режимов совместимости конфигурации и несовместимости между собой версий новой IDE, поддерживающей гит, невозможно было впрямую актуализировать продукт. Была проделана немного неприглядная, но давшая результат операция, сравнимая в хирургии с выращиванием носа на лбу из складок с задницы и последующей пересадкой его на лицо. В терминах системы управления версиями разворачивались отдельные репозитории и сериями последовательных сравнений вычищались конфликты, мешающие обновлению. Потом готовый артефакт бережно переносился в основной репозиторий, как будто это изначально было сделано там. Через среду это делать было бы довольно затруднительно, у нее эклипсовская основа с неродным гит-плагином. Здесь еще вмешивается оперирование несколькими проектами в рамках одной рабочей задачи, и у эклипса есть тоже свои нюансы, ну банально нельзя два проекта с одинаковыми именами держать в рабочей области.
В одной из команд используется сломанный гит-флоу. Постоянно возникают конфликты слияния, которые необходимо разрешать на стороне клиента и через форс опцию переписывать центральный репозиторий. Через ту же среду, кстати. Это не очень этично по отношению к разрабам, но поменять процесс невозможно по административным причинам. Плюс сотрудники продолжают иногда перетирать результат работы других и приходится восстанавливать свои внезапно исчезнувшие правки.
Есть проект статической документации на mkdocs, там vscode справляется, ок, но мне не очень наглядно сравнивать куски кода общим списком в паре популярных расширений, другие не смотрел.
Была проблема с внутренней самописной компонентой доступа к кафке. Автор был недоступен, пришлось ставить студию и резко разбираться в C#, чтобы внести небольшую правку. Опыт в студии у меня нулевой, встроенным плагином совместной разработки не владею, да и не хочу, пока принципиально не принял решения менять стек на дотнет.
Плюс есть небольшие менторские активности в виде обучения с нуля, где код и обучающие материалы хранятся вместе, а язык, и соответственно, среда, обучающимися не выбраны окончательно.
Во всех этих ситуациях использовал Sublime Merge, как один универсальный инструмент, не зависящий от среды, для меня это было критично. Плагин от студии мне не подходит.
С гитлабом возможно действительно поспешил, в тех простых скриптах с которыми я работал, действительно нет прямого упоминания гита. Но что-то мне говорит, что на полноценной должности девопса такая необходимость появиться может и не будет чем-то выдающимся.
Я не настаиваю на конкретном инструменте, но не согласен с мнением, что есть возможность и настоятельно рекомендовано оставаться в рамках плагина определенной IDE и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.
То-то я гляжу, вы только одним пользуетесь, в одной среде. Времени, наверное, нет бегать по средам, ах да, вы же скрипты за девопсов пишите.
понтов за край, а уверенности нет
Вы по причине кажущейся вам неуважительности от понтов переходите на личности и агрессию? Или из-за неуверенности в собственной позиции?
У нас как-то не принято для каждой фичи хреначить пару сотен серверов
А по TBD принято, и TBD используется много где, в том же Тинькове, например. Там энтерпрайз не просто кровавый, а с содомом и расчлененкой.
те самые, которые способны задачу на пару часов растянуть на неделю
Сочувствую вашему опыту. Мне же попадались люди, у которых много чему полезному можно научиться. И на удивление, они все избегали безапелляционной категоричности и примитивных жаргонизмов в обсуждениях.
Я до сих пор не вижу конкретного примера
Я до сих пор не вижу, какая методология используется в ваших монорепозиториях. Ну и метрики в отношении численности команд, частоты коммитов, наличия переходных процессов, если можно.
Все баги были решены. Последний клик по клавиатуре поставил жирную точку в этом модуле. Я снял палец с левой кнопки мыши - все было закоммичено. Напоследок системные часы в трее судорожно моргнули. Биения кварцевого кристалла передавались счетчику секунд и походили на удары сердца, складываясь в слоги: во-сем-над-цать-ноль-ноль. Люблю круглые числа, пора идти домой. Я накинул куртку... "ги-и-ит", - послышался голос на краю сознания. "Мой любимый плагин...", - вяло откликнулся я, погруженный в свои мысли. "Гии-и-и-и-иит", - уже громче и протяженнее прозвучал голос. "ГИТ!", - он резко превратился в крик и грянул как окрестр, составленный целиком из одних медных труб.
Я очнулся и взглянул на экран с окном видеоконференции. Часы снова моргнули и показали 14:48. Собеседование шло уже 15 минут, если не считать тех трех, на которые опоздал мой наниматель. Какая вопиющая непунктуальность.
– Простите, что вы сказали? – неожиданно произнес мой собственный голос. – Вы когда–нибудь использовали гит? – спросил интервьювер. – Вы имеете ввиду плагин в студии? – уточнил я. – Нет, я имею ввиду чистый гит. Давайте так, опишите своими словами, как сами понимаете, что происходит, например, во время операции коммита. – Ну, я обычно нажимаю кнопку, а плагин делает все сам, – обрадовал его я. "Кто в современном мире вообще учит чистый гит, – промелькнула мысль, – опять попался какой–то идиот, который спрашивает по анкете из интернета". – Хм. Понятно... А какие вообще команды знаете? – не отставал собеседник. – Вам надо настроить свой приватный гит–сервис? – я попытался перехватить инициативу. – Нет, у нас используется GitLab, пока его возможностей хватает. – А тогда зачем команды? – почти искренне удивился я. – Хорошо, принято... Давайте перейдем к следующему вопросу.
Тот день изменил все. Мне опять никто не перезвонил, и я решил наконец скачать шпаргалку с командами. Не то, что бы я реально вкурил, как они работают, но по крайней мере, рекрутеры сразу увядают, как двойка перед королевским джокером, после того, как я говорю "ребэйз" и "черри–пик". Мне даже выставили пару хороших офферов, но там не было моей любимой среды с шикарным плагином, и я отказался. Но прошло время, и теперь я уже сам иногда сомневаюсь, не стоит ли начать писать свои скрипты по-другому, чтобы заранее скачивать код с гитхаба, например, так – git clone ...
Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
расскажите, что это были за проблемы и как решались
Я же их описал. Все четыре приходилось решать.
не нужно про методологии спрашивать - возьмите свою
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
нужно оставить за скобками и не рассматривать
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?
Взаимоисключающие параграфы detected. Уж определитесь, надо или не надо обновляться.
Больше обновлений богу обновлений! Люблю
запах напалмаобмазываться обновлениями по утрам, каждый день ИТС проверяю, как бы чего не вышло без меня.Ну так поставьте отдельно бухгалтерию и отдельно заводскую конфигурацию, вплоть до ТОИР и MES. Релизные циклы разделены, интеграций между системами - ворох. Или злые php-шники забрали себе все интеграции и запрещают вам изучать новое? Вообще, это талант - выворачивать ситуацию наизнанку, когда преимущество оперативной реакции на актуальные изменения законодательства превращается в "плак-плак, я усталь обновляться".
Лол. С 1С-ки легко перейти и на шарп, и на флаттер, и на питон, и на чистый SQL, и на много чего еще. У меня прям живые примеры есть. И внутри самой 1С-ки непаханное поле технологий: шины, интерфейсы, интеграции, тестирование и много чего еще. Было бы желание. Кстати, про желание:
Здорово, правда?) Не хочешь напрягаться по жизни и сидеть на относительно тепленьком местечке - колупай себе формы и макеты. Хочешь нормально разрабатывать - изучай исполнитель, архитектуру, гитхаб, брокеры, метапрограммирование, нейросети, - всему найдется применение внутри экосистемы.
А впрочем, ничего нового. Самим то не надоело пиарить очередную CMS/CRM через неубедительную эфемерную критику одинэски? Оставляя в стороне реально существующие недостатки платформы и непомерные аппетиты вендора, каждая подобная статья отвратительна тем, что автор стабильно за рекламную копейку канонично обесценивает труд всех тех людей, кто строит одинэсную экосистему и автоматизирует, ну наверное, половину финансового учета и товародвижения в стране.
До сих пор не понимаю, почему так популярен оперативный учет в статической среде. Для ведения тех же задач система, кроме списков и вложений, должна удовлетворять требованиям ссылочной целостности, помнить историю изменений, предоставлять совместный доступ с разграничением прав. Оптимальный максимум обсидиана в этом плане – журнальный подход: личный дневник, дневник снов, агрегация новостей, где информация только добавляется. Задачи и канбаны как будто явно лишние.
Хотя лейтмотив статьи в целом правильный – в роли конструктора под индивидуальные нужды вещь шикарная. Если бы только не приходилось учить JS.
Наверное, хотелось бы увидеть в статье чуть более развернутое упоминание гита именно в свете закономерного этапа развития принципа простоты и использования нативных возможностей файловой системы, которые усиляют позиции идеи "Docs as Code". Что сам обсидиан не обязан брать ответственность за версионирование и синхронизацию, хотя последняя в нем и есть в облачном формате.
Мой второстепенный сценарий – быстренько спарсить миллион сохраненных закладок с того же хабра скриптом из .html в .md, создать из них хранилище и задействовать полнотекстовый поиск по ключевым словам, чтобы найти ту намертво засевшую в памяти статью про кофе и эволюцию технологии его приготовления, которая не ищется ни через родной поиск, ни через гугловый. А по пути залипнуть на случайно попавшие в выборку статьи про ОКР, СДВГ, гештальты и прочие профессиональные болезни цифровых инженеров. Как говорится, современные проблемы требуют современных решений!
Смутили два момента:
Как быть, если исправление требует стратегического, архитектурного рефакторинга по существующим модулям? Утрированно, - по сигнатурам методов прокинуть дополнительный параметр?
Есть еще моменты, которые нужно учесть? Что еще я могу потенциально повесить, если их не учту?
С учетом этих моментов и платы за запросы навык разработки выглядит просто как перекладывание когнитивной сложности на фоне инволюции обратно из науки в шаманство. Из области, где есть непротиворечивая теория, логика, законы, гайды, документация и дорожные карты происходит откат в область, где требуются все те же мысленные усилия, но не обеспеченные никакой жесткой структурированной основой и результатом. Ближайшая аналогия - производство семян, когда ГМО, хирургически точную технологию с целевым результатом, покрытую тестами и исследованиями, избегают, а облучать радиацией семена вслепую - норм, может какая полезная мутация да выйдет, разгони-ка эти гамма-частицы побыстрее, брат.
Еще момент, что подобные продукты паразитируют на теле Stackoverflow и других проектов с корпусом качественных знаний, естественным образом произошедших из мозгов людей, получивших классическое обучение и набравших рабочий опыт. Причем паразитируют очень деструктивно, в формате конкуренции, убивая материал, на котором учатся и обесценивая классический жизненный цикл роста специалиста и государственные программы обучения.
В общем, вся эта истерия с нейрогенеративной разработкой кажется какой-то коммерческой игрушкой и злобным суррогатом от создателей "жизнь по подписке" и "купи самооценку за деньги". Ходишь по этому цирку-ярмарке нейросетей, все они такие громкие, яркие, манящие. На главном представлении тебе буквально показывают бородатых женщин и сросшихся близнецов с мутированными конечностями. Уходя в экстазе, ты покупаешь очередную свистоперделку по оверпрайсу, а придя домой, разочаровываешься, когда садится батарейка, или она ломается после первого падения в руках друга. И тут ты либо взрослеешь и идешь в детский мир за нормальными игрушки, а на бородатых женщин смотришь в генетической лаборатории, по пути придумывая лекарство от гипертрихоза. Либо остаешься ребенком, ведущемся на мишуру и беспроигрышную лотерею, пока другие мутировавшие мохнатые руки потрошат твою свинку-копилку.
Спасибо за исчерпывающий ответ! Стало более понятно.
Буду с нетерпением ожидать опенсорс/лайт версии продукта, подкрепиться иллюстрациями с документацией и задействовать в корпоративных проектах.
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Архитектура решения воспроизводит 1С подходы. Насколько глубоко вы погружались в реализацию вендором веб-клиента во время реверс-инжиниринга? Или это больше поверхностная копия на самостоятельном размышлении и наблюдении? Грубо говоря, когда 1С локализовала клиент под арабский язык, то она меняла свои же встроенные в веб-клиент .css и .html файлы. Вы до этих файлов тоже добрались, например?
Как другие технические команды отреагировали, что json описания формы необходимо передавать в концепции, похожей на 1С? Не было неприятия, отторжения, ступора? Проталкивания альтернативных шаблонов описаний вместо импортозамещенного json?
Рассматривали ли для фронтэнда Flutter? Хотя, скорее всего, специалистов на нем меньше, чем на js/ts в целом и на vue в частности, но все равно любопытно в свете упомянутой поддержки кросс-платформенности.
Вы упомянули, что сущности элементов имеют события. Получается, на бекэнде необходимо реализовать обработчик для каждого события (3-5) каждого элемента (10-100) формы? Ну то есть, в среднем прописать 25-500 методов? Можно дополнительно осветить эту тему? Конкретно для 1С есть какая-то прослойка, внутренняя подсистема с заготовками, как быстро накидать форму, подцепить обработчики и раскидать их по модулям? Или например, воспроизвести такую же форму в конфигурации нативно и в одну строчку при создании формы привязать к фронту для транслирования вызовов через внутреннюю нативную же библиотеку?
Забавно, что даже на уровне технических директоров в 1Ске все равно ищут по конкретным типовым решениям от вендора (УТ, ДО, БП), а соискатели заявляются в обобщенном виде (максимум, ERP-системы). Совпадает с эмпирическим ощущением от прохождения собеседований, когда очень формально и напрямую подходят к поиску сотрудников, первичным фильтром сразу отсеивая кандидатов, у которых нет упоминания нужных решений в резюме.
Таким страдают и крупные компании, типа Яндекса, как будто прямо так сложно перестроить на месте человека с немного параллельным опытом, но внутри той же экосистемы. Почему-то мантра "не учите фреймворки, учите архитектуру" тут не работает, хотя уж для CTO это точно фундаментальная ценность.
Я и сказал с самого начала ветки, что это вопрос ответственности. Для обычного разработчика в несломанных процессах, кроме плагина ничего и не нужно, с этим я не спорю.
Ну например, чтобы написать базовую строку скрипта, мне кажется, все же надо знать, что такое дефолтная ветка, как она выбирается, почему раньше она называлась master, а сейчас main, почему в гитфлоу дефолтной считается main, но на прод надо выкатывать релизную и тому подобные нюансы. Это знания о гите, которые не дает плагин. Плюс кто-то же в компании выбирает, чем пользоваться - гитлабом, гитхабом, битбакетом, гитеей. Насколько плотная интеграция с гитом в скриптах ci/cd, насколько понятен и интуитивен синтаксис. Или все само по мановению волшебной палочки появляется? А RnD и экономическо-технический подсчет никогда не спускают на разработчиков?
Не верю, что везде прям так все идеально, треш на любой работе есть в той или иной мере и с ним приходится сталкиваться. Пример был немного утрирован, хотя и близок к происходящему, но приведу более реальный пример.
У нас искусственно поддерживается нездоровая конкуренция между линейным персоналом. Репы форкаются, внутренние либы развиваются параллельно, потом оставляется наиболее выживший и приспособленный кандидат и все его потом дружно х***осят. И это не конструктивная история, как в каком-нибудь гугле, а очень сломанная и демотивирующая деятельность.
Но дает много материала, чтобы посмотреть на разные проблемы под разными углами, научиться решать их разными путями, и собственно, продвигаться к тому специалисту, кто выстраивает процессы для обычных разработчиков. В целом, негатив терпим и есть вызов как залог развития. Как работать без того, чтобы иногда глядеть по сторонам и помогать решать системные проблемы, если честно, даже не представляю. Мне кажется, это довольно скучно.
Хорошая новость! Концепция знакомая, пользовался ssh в VS Code, он тоже сначала был плагином, потом стал частью поставки редактора.
Просто в примере с уходом в линукс я в который раз хочу сказать, что существуют не только задачи разработки. Есть не менее комплексная и сложная деятельность смежных отделов, где все, кроме собственно кода, надо хранить как код. Docs as Code, DevOps as Code, Infrastructure as a Code. Необходимость обслужить компонент, систему или инфраструктуру целиком может возникнуть и у обычного разработчика, и это не какая-то невозможная ситуация, где среда с плагином в этом случае даст отказ.
В конце концов, гит - это изначально линуксовая утилита, она останется первичной материей и не может быть менее важна накрученных на нее для удобства оболочек, чтобы вот так просто ее отбросить.
Я не смогу привести примеры именно в том формате, в котором вы хотите.
При этом, моя позиция уже достаточно аргументирована. Уходим на линукс - привет, консоль. Плагина нет, потому что нет GUI и среды нет. Вы упомянули Gitkraken - это не плагин. То есть, плагина уже недостаточно, раз используется внешний продукт. Написать в скрипте гитлаба
if: $CI_COMMIT_BRANCH = $CI_DEFAULT_BRANCHплагин тоже не поможет полностью. Может подсветить синтаксис и сделать автодополнение, но саму строчку и понимание, как она работает, надо будет брать из гугла. Итого есть 3 страйка, чтобы формально опровергнуть исходное утверждение автора коммента.Но мы же не боремся формально, у кого больше аргумент, и не смотрим только на верхушку айсберга. В идеальном мире разраб сидит на конвейере и имеет узкую специализацию. В реальном мире прибегают 4 всадника апокалипсиса, отрывают у вас руки и ими же разыгрывают флеш-рояль: винды нет, мака нет, jetbrains нет, а вместо хотя бы крепкого фулл-хауса из знаний, как резко в моменте выполнить ежедневную операцию другим способом, вы в зубах (рук же нет) держите вальта по имени chatgpt и сраную тройку из нетерпимости к другим языкам, ложной самоуверенности и ограниченного кругозора.
Мне, как и вам, конечно, хочется, чтобы комфортные условия никогда не менялись, а какие-нибудь добрые умные дядьки заботились о том, чтобы я не вылезал за пределы придуманного ими контура и инструментария. Но это порочная стратегия, и транслировать ее миру тоже неправильно.
P.S.: Ну да, одинэсники - не настоящие программисты) Занимаетесь классическим обесцениванием, обидно. Из-за этого, наверное, уже и не хочется продолжать с вами дальнейшее обсуждение. Даже со всем уважением к вашей попытке понять позицию собеседника (не знаю уж, насколько она искренняя).
Дядь, ты совсем дурак?)
Конфигуратор на svn работает, а эклипс на гите, и шина на гите. На кой мне ваш mercurial сдался в обсуждении гита и одинэсок? Разобрались бы сначала в вопросе или не лезли уже.
И откуда вам про команды меркуриала знать, если по вашим же словам кроме плагина в студии ничего не видели, ведь вам хватает его с избытком?
Ну и вы на VS2022 разве не в винде кодите? На маке, что ли? Это тогда вообще эклектика какая-то нездоровая.
Все, теперь понял. Наверное, безумно удобно сидеть в чешско-кирпской компании и спамить в грубой форме в русскоязычный портал о технологиях. Довольны своим карьерным успехом? Почему не хотите рвать связь с русским профессиональным сообществом? Почему не бережете репутацию, все же оставаясь на связи в комментах? Ваши руководители вообще знают, чем вы занимаетесь в рабочее время?
В линкедине, кстати, численность указана в 50-200 сотрудников. На порядок отличается от "тысяч сотрудников в монорепозиториях" и очень далеко от "кровавого энтерпрайза".
Эх, я надеялся на конструктивную беседу и более уверенную и аргументированную позицию, а не на ожесточенное отбрехивание какахами. Правда было интересно, почему у вас настолько безапелляционная позиция без видимого основания, идущая вразрез с общим мнением.
Спасибо за ответ! Тогда к обещанным примерам.
Я упоминал специфику 1С с несколькими средами и поставками вендора. Образовалась ситуация, когда типовая версия поставщика безнадежно устарела и из-за режимов совместимости конфигурации и несовместимости между собой версий новой IDE, поддерживающей гит, невозможно было впрямую актуализировать продукт. Была проделана немного неприглядная, но давшая результат операция, сравнимая в хирургии с выращиванием носа на лбу из складок с задницы и последующей пересадкой его на лицо. В терминах системы управления версиями разворачивались отдельные репозитории и сериями последовательных сравнений вычищались конфликты, мешающие обновлению. Потом готовый артефакт бережно переносился в основной репозиторий, как будто это изначально было сделано там. Через среду это делать было бы довольно затруднительно, у нее эклипсовская основа с неродным гит-плагином. Здесь еще вмешивается оперирование несколькими проектами в рамках одной рабочей задачи, и у эклипса есть тоже свои нюансы, ну банально нельзя два проекта с одинаковыми именами держать в рабочей области.
В одной из команд используется сломанный гит-флоу. Постоянно возникают конфликты слияния, которые необходимо разрешать на стороне клиента и через форс опцию переписывать центральный репозиторий. Через ту же среду, кстати. Это не очень этично по отношению к разрабам, но поменять процесс невозможно по административным причинам. Плюс сотрудники продолжают иногда перетирать результат работы других и приходится восстанавливать свои внезапно исчезнувшие правки.
Есть проект статической документации на mkdocs, там vscode справляется, ок, но мне не очень наглядно сравнивать куски кода общим списком в паре популярных расширений, другие не смотрел.
Была проблема с внутренней самописной компонентой доступа к кафке. Автор был недоступен, пришлось ставить студию и резко разбираться в C#, чтобы внести небольшую правку. Опыт в студии у меня нулевой, встроенным плагином совместной разработки не владею, да и не хочу, пока принципиально не принял решения менять стек на дотнет.
Плюс есть небольшие менторские активности в виде обучения с нуля, где код и обучающие материалы хранятся вместе, а язык, и соответственно, среда, обучающимися не выбраны окончательно.
Во всех этих ситуациях использовал Sublime Merge, как один универсальный инструмент, не зависящий от среды, для меня это было критично. Плагин от студии мне не подходит.
С гитлабом возможно действительно поспешил, в тех простых скриптах с которыми я работал, действительно нет прямого упоминания гита. Но что-то мне говорит, что на полноценной должности девопса такая необходимость появиться может и не будет чем-то выдающимся.
Я не настаиваю на конкретном инструменте, но не согласен с мнением, что есть возможность и настоятельно рекомендовано оставаться в рамках плагина определенной IDE и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.
Наши девопсы не переваливают свои задачи на нас)
То-то я гляжу, вы только одним пользуетесь, в одной среде. Времени, наверное, нет бегать по средам, ах да, вы же скрипты за девопсов пишите.
Вы по причине кажущейся вам неуважительности от понтов переходите на личности и агрессию? Или из-за неуверенности в собственной позиции?
А по TBD принято, и TBD используется много где, в том же Тинькове, например. Там энтерпрайз не просто кровавый, а с содомом и расчлененкой.
Сочувствую вашему опыту. Мне же попадались люди, у которых много чему полезному можно научиться. И на удивление, они все избегали безапелляционной категоричности и примитивных жаргонизмов в обсуждениях.
Я до сих пор не вижу, какая методология используется в ваших монорепозиториях. Ну и метрики в отношении численности команд, частоты коммитов, наличия переходных процессов, если можно.
Все баги были решены. Последний клик по клавиатуре поставил жирную точку в этом модуле. Я снял палец с левой кнопки мыши - все было закоммичено. Напоследок системные часы в трее судорожно моргнули. Биения кварцевого кристалла передавались счетчику секунд и походили на удары сердца, складываясь в слоги: во-сем-над-цать-ноль-ноль. Люблю круглые числа, пора идти домой. Я накинул куртку... "ги-и-ит", - послышался голос на краю сознания. "Мой любимый плагин...", - вяло откликнулся я, погруженный в свои мысли. "Гии-и-и-и-иит", - уже громче и протяженнее прозвучал голос. "ГИТ!", - он резко превратился в крик и грянул как окрестр, составленный целиком из одних медных труб.
Я очнулся и взглянул на экран с окном видеоконференции. Часы снова моргнули и показали 14:48. Собеседование шло уже 15 минут, если не считать тех трех, на которые опоздал мой наниматель. Какая вопиющая непунктуальность.
– Простите, что вы сказали? – неожиданно произнес мой собственный голос.
– Вы когда–нибудь использовали гит? – спросил интервьювер.
– Вы имеете ввиду плагин в студии? – уточнил я.
– Нет, я имею ввиду чистый гит. Давайте так, опишите своими словами, как сами понимаете, что происходит, например, во время операции коммита.
– Ну, я обычно нажимаю кнопку, а плагин делает все сам, – обрадовал его я. "Кто в современном мире вообще учит чистый гит, – промелькнула мысль, – опять попался какой–то идиот, который спрашивает по анкете из интернета".
– Хм. Понятно... А какие вообще команды знаете? – не отставал собеседник.
– Вам надо настроить свой приватный гит–сервис? – я попытался перехватить инициативу.
– Нет, у нас используется GitLab, пока его возможностей хватает.
– А тогда зачем команды? – почти искренне удивился я.
– Хорошо, принято... Давайте перейдем к следующему вопросу.
Тот день изменил все. Мне опять никто не перезвонил, и я решил наконец скачать шпаргалку с командами. Не то, что бы я реально вкурил, как они работают, но по крайней мере, рекрутеры сразу увядают, как двойка перед королевским джокером, после того, как я говорю "ребэйз" и "черри–пик". Мне даже выставили пару хороших офферов, но там не было моей любимой среды с шикарным плагином, и я отказался. Но прошло время, и теперь я уже сам иногда сомневаюсь, не стоит ли начать писать свои скрипты по-другому, чтобы заранее скачивать код с гитхаба, например, так – git clone ...
Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
Я же их описал. Все четыре приходилось решать.
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?