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