Конечно же, при возникновении разногласий утверждать, что черное - это белое и кидать ссылки на свой портал, явно поможет вам доказать свою экспертизу и благонадежность)
Мне кажется, очевидно, почему не стоит так поступать. Если кратко - появляются сомнения в качестве ваших услуг.
Вы выбрали самый дешевый, простой и нетребовательный способ прорекламировать свой продукт через поверхностное сравнение с конкурентом. Не осветили свои достоинства, но расписали чужие недостатки.
Это говорит, что, во-первых, вас ни что не остановит от применения подобных подходов в коде при непосредственной разработке и внедрении, а значит, может привести к проблемам у клиента. Во-вторых, вы не дорожите репутацией и не можете привлекать клиентов, используя эти самые репутационные механизмы. В-третьих, это обесценивает клиентов, превращая их в кормовую базу таргета, а не полноценных деловых партнеров.
В долговременной перспективе вы лишаете себя развития и более высокого заработка, потому что не работаете над ошибками, остаетесь в нижней доле рынка и общаетесь с окружением, допускающим неблагонадежные подходы в профессиональной деятельности. Ну и моральные аспекты всего этого.
Также я, конечно же, не против того, что вы высказываетесь в принципе и удовлетворяете свою потребность. Я против того, чтобы вы в корп. блоге имени себя маскировали рекламу под свое "мнение" и унижали конкурента.
У вас в статье 6 раз упомянуто слово "конкуренция" и его производные, а потом "ненавязчиво" интегрирована реклама. Причем из всех разделов длинной статьи интегрирована, вот неожиданность, именно в контекст раздела о конкуренции)
Был уверен, что мемы также и не могут удалять через обычную жалобу стороннего участника обсуждения. Обратился в техподдержку, если это действительно произошло, и вина исключительно модерации, принесу вам свои извинения.
Тем не менее, мое мнение о неприятности статьи остается в силе. И не могу не отметить, что нападку про пиар через конкурента вы обошли вниманием в ответе.
Будьте осторожны, автор статьи с модераторами чистят неприятные комментарии. Видимо, к обычному негативу и критике они готовы, потому что прекрасно понимают, к чему приводит пиар через принижение конкурента. А вот юмор и мемы уже задевают что-то личное.
Мне не кажется правильным, когда корпоративный блог может пользоваться своим положением, чтобы смещать фон вокруг своих продуктов в нужную сторону.
Я уже наглядно показал выше, что чаще всего обновления оказываются вообще не нужны компаниям, которые используют 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 и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.
Конечно же, при возникновении разногласий утверждать, что черное - это белое и кидать ссылки на свой портал, явно поможет вам доказать свою экспертизу и благонадежность)
Мне кажется, очевидно, почему не стоит так поступать. Если кратко - появляются сомнения в качестве ваших услуг.
Вы выбрали самый дешевый, простой и нетребовательный способ прорекламировать свой продукт через поверхностное сравнение с конкурентом. Не осветили свои достоинства, но расписали чужие недостатки.
Это говорит, что, во-первых, вас ни что не остановит от применения подобных подходов в коде при непосредственной разработке и внедрении, а значит, может привести к проблемам у клиента. Во-вторых, вы не дорожите репутацией и не можете привлекать клиентов, используя эти самые репутационные механизмы. В-третьих, это обесценивает клиентов, превращая их в кормовую базу таргета, а не полноценных деловых партнеров.
В долговременной перспективе вы лишаете себя развития и более высокого заработка, потому что не работаете над ошибками, остаетесь в нижней доле рынка и общаетесь с окружением, допускающим неблагонадежные подходы в профессиональной деятельности. Ну и моральные аспекты всего этого.
Также я, конечно же, не против того, что вы высказываетесь в принципе и удовлетворяете свою потребность. Я против того, чтобы вы в корп. блоге имени себя маскировали рекламу под свое "мнение" и унижали конкурента.
У вас в статье 6 раз упомянуто слово "конкуренция" и его производные, а потом "ненавязчиво" интегрирована реклама. Причем из всех разделов длинной статьи интегрирована, вот неожиданность, именно в контекст раздела о конкуренции)
Был уверен, что мемы также и не могут удалять через обычную жалобу стороннего участника обсуждения. Обратился в техподдержку, если это действительно произошло, и вина исключительно модерации, принесу вам свои извинения.
Тем не менее, мое мнение о неприятности статьи остается в силе. И не могу не отметить, что нападку про пиар через конкурента вы обошли вниманием в ответе.
Будьте осторожны, автор статьи с модераторами чистят неприятные комментарии. Видимо, к обычному негативу и критике они готовы, потому что прекрасно понимают, к чему приводит пиар через принижение конкурента. А вот юмор и мемы уже задевают что-то личное.
Мне не кажется правильным, когда корпоративный блог может пользоваться своим положением, чтобы смещать фон вокруг своих продуктов в нужную сторону.
Так и называется, Обновлятор 1С
Взаимоисключающие параграфы 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 и избегать изучения самой технологии гита в отрыве от ее реализации в виде плагина или инструмента, приводя в защиту своей позиции аргументы, похожие на самооправдания.