Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
расскажите, что это были за проблемы и как решались
Я же их описал. Все четыре приходилось решать.
не нужно про методологии спрашивать - возьмите свою
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
нужно оставить за скобками и не рассматривать
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?
Вопрос в зоне ответственности, численности команды, и с какой стороны код-ревью находишься. Чем дальше, тем больше непростых сценариев, связанных с организацией работы большой команды, параллельными обновлениями вендором программного продукта, коллизий с одновременной разработкой функционала. Тут уже желательно погибче владеть инструментом, чтобы наладить работу. Пусть и не обязательно прямо через консоль (есть удобные графические оболочки), но и на плагине уже не выедешь.
О, спасибо за выжимку! Так основная мысль доносится быстрее. Спасибо, что прислушались и начали исправляться!
Но мой посыл остался тем же, - вы пользуетесь плодами революции, чтобы с извращенным кайфом описывать несовершенство системы в этой же самой системе, попутно обвиняя инструментарий и подходы революции, приведшие к созданию этой системы. И не готовы при этом подстроиться со своей стороны и поступиться частью убеждений, например, не писать ненужные подробности в отзывах. Это забавно)
После прочтения статьи больше задумался о границе между принципиальностью и занудством. Ненужное графоманство в отзывах на торговой площадке - прям хороший маркер. И с выводом не согласен, - наоборот, такая революция нужна. Люди теперь могут удовлетворять свои некомфортные для других потребности в суррогатных беседах с компьютером, не мешая остальным. Это ли не чудо прогресса?
Интерактивным сравнением/объединением. Эта возможность доступна как при слиянии веток, так и при сравнении разных конфигураций между собой. Это специальный инструмент (команда, окно, форма) edt, экранирующий внутренний формат хранения. Вы правда не знали про него?
То есть про делегацию сложности вы проигнорировали. Остался только страх...
По большому секрету скажу, что у 1С есть собственное окно сравнения, которое учитывает всю специфику своих же xml. И я не зря упомянул про возможность локального разрешения конфликтов. То, что вы лезете в формат исходников - исключительно ваша осознанная воля, а может, даже и провокация.
Вы бы хоть матчасть подтянули, прежде чем аппелировать к тому, что считаете больным местом. В кажущихся вам выдуманными мирах это не представляет такой сложности.
Мне кажется, довольно поспешно и недружелюбно с вашей стороны называть мою реальность выдуманной.
Хотелось бы услышать агрументированную и заслуженную критику без прилагательных в превосходной степени сравнения.
На моей стороне успешный опыт использования предложенной выше схемы, понимание преимуществ гита, делегация сложности нового формата хранения исходников edt собственно самой edt, и нейтральное спокойное принятие подходов к переиспользованию кода от авторов типовых конфигураций. Что может предложить ваш мир, кроме страха перед спагетти?
Как же вам, должно быть, сложно ловить собеседника на выдуманных ограничениях, искусственно раздувать проблему и потом героически переводить разговор в обсуждение того, что умеет и как бы тут пригодился lsfusion.
Давайте я отвечу по существу вместо автора статьи. Проект переносится в git и EDT, за первоначальный коммит берется конфигурация поставщика, от ствола ответвляется ветвь с чистой конфигурацией поставщика и периодически обновляется поставкой и вливается в основной ствол репозитория. Git уже на этом этапе разрешает всевозможные конфликты слияния кодовой базы. Если не решает - слияние выносится в локальный репозиторий, проводится на локальных ветвях, и EDT, с учетом специфики метаданных и платформы, с помощью платформенного сравнения добивает оставшиеся конфликты. После чего локальное разрешение конфликтов отправляется в удаленный репозиторий.
Это чисто на уровне гита. А на уровне разработки выбор просто широчайший – методы-заглушки, перенаправления на свои методы в начале типовых методов, отдельные подсистемы, общие реквизиты, регистры с любыми объектами в измерениях и многое другое.
Таким образом, никакой код нельзя назвать лишним, потому что, употребляя ваши просторечные обороты, он "спокойно лежит и каши не просит", и никому не мешает. Исправленный код спокойно сольется при описанной выше схеме.
Если будете предлагать стандартный набор возражений, что EDT сырая, требует много памяти, зачем 1С две среды разработки, зачем переводить проект в гит и прочий абсурд, то лучше давайте сразу не продолжать обсуждение, потому что в итоге можно все свести к гиту, а против него и его возможностей спорить бесполезно.
Спасибо за уточнение! Я уж голову сломал, думал, может, есть дополнительные полноценные преобразования значений в указатели и обратно.
И спасибо за статью, с этим объяснением с языка упал флер экзотики, в которой подсознательно не хочется разбираться, и он стал гораздо ближе и очевиднее. Можно взять за базовую отправную точку для изучения машины Тьюринга и смежных тем.
код [-]>>[-] зануляет 2 ячейки, превращая {head, 0, [?], 0, ?, ...} в {head, 0, 0, 0, [0], ...}
У меня и в голове, и в наспех накиданном скрипте получается, что {head, 0, 0, 0, [?], 0, ?, ...} превращается в {head, 0, 0, 0, 0, 0, [0], ...} То есть, смещение вправо больше на 2 единицы, чем в примере, и в начале памяти есть еще две нулевых ячейки.
Это ошибка или особенности интерпретации? Потому что насколько я понимаю, интерпретация тут намеренно примитивная в виде последовательного чтения символов, без какого-либо стека. За исключением возвращения к предыдущим парным скобкам (перескакивания к следующим), но он реализовано лишь дополнительными циклами и просто переводит указатель текущего символа входного текста и не относится напрямую к памяти и ее собственному указателю.
Мне помогла волшебная аббревиатура LTSC. Там вырезан маркет приложений, ворох предустановленных программ типа "людей" и "почты", всякие onedriv'ы и прочее, что можно определить как самоцель использования ОС из статьи. С помощью O&O ShutUp10++ донастраивается остальное, касающееся телеметрии, оформления и поведения системы. Плюс папка с обновляемыми установщиками проверенных программ, VLC, Faststone, qbittorrent, WinRar. О, вспомнил, еще 7+ Taskbar Tweaker, чтобы колесиком окна открывать! О некоторых оставшихся неудобствах типа защитника можно поспорить, потому что неоднозначность полного отказа от них все же существует, и компромиссы между безопасностью и удобством достигать можно и нужно.
Очень удобно, что описанная потребность в ненавязчивости совпадает с потребностью в ненавязчивости и стабильности ключевого потребителя ОС, приносящего деньги, - больших корпораций, которым бы не хотелось в массе и на множителе разбираться с уловками, мешающими сотрудникам отдавать все рабочее время самим корпорациям) 11-ая же версия к вашим услугам, если хочется новизны и суррогатного впечатления нахождения на волне технологий. Так же жду выхода ее LTSC редакции.
Поэтому призываю не сильно расстраиваться и сублимировать, а быть хитрее и гибче - ситуацию с выбором целевой аудитории можно трактовать в свою сторону, начав идентифицировать себя вертолетом апач, понарошку перейдя в другой сегмент пользователей ОС. Ха-ха, тупой майкрософт, я же не корпоративный клиент, а физическое лицо, но пользуюсь твоей корпоративной сборкой! В общем, всем советую.
P.S. Кстати, в комментах встретил только одно упоминание LTSC. Незнание о ее существовании плюс то, что она особо не афишируется, косвенно подтверждает, что большинство приняло и согласилось с предложенной вендором сегрегацией. Но это не значит, что вариантов нет и счастье недостижимо.
Так не выдумки же, вам и на инфостарте про это говорят. Вот эталонный пример, как докопаться до столба на пустом месте.
Забавно, что ради возможности почесать эго вы делитесь наработками и образом мышления даже с этими самыми ненавистными анонимами. Но вдруг оказывается, что позиция "один я умный в белом пальто стою красивый", которая так хорошо прокатывает с заказчиками, не особо действует на вдумчивых разработчиков. А потому что уже сбоит оценка адекватности поведения и границ публичности. И не учитывается повышенная критичность целевой аудитории к необъективной и недостоверной информации. Остается кричать "вы всё врети! я не хочу вас слушать! вы все плохие, не любите меня! мне воспитательница наклейку со звездочкой подарила, а вам нет!". Детский сад, ей-богу.
По существу статьи мой посыл все тот же - вы даже не прикоснулись к реальной простоте, красоте и технологичности разработки. Даже стоя прямо перед этим, будучи устроенным по жизни, имея на руках все возможности и проживая в богатое на события и прорывы время. И в отсутствии внутреннего трепета и кайфа от работы со сложными системами и объемными слоями абстракции пытаетесь заместить пустоту в сердце какими-то суррогатами в виде самоубеждения и громких принципов, не понимая ни их сути, ни их применения.
С чего вдруг место в топе стало показателем профессионализма, а не популярности? Это ортогональные понятия, развитие в этих двух дисциплинах может происходить независимо. Например, поп-музыка тоже популярна, но примитивна по музыкальности и бедна на смыслы.
Если все ваши механизмы заточены на маркетинг, пиар и иногда прямой обман, и при этом вы жертвуете профессиональным развитием, то поставленная речь, искусство убеждения, грамотные манипуляции и заработок чуть выше среднего в профессии не мешают вам быть проходимцем, рвачом и откровенным говнокодером.
Естественно, вы ни за что не признаетесь, что сознательно говнокодите ради быстрых денег. Так хотя бы постесняйтесь свой бред в виде этой статьи нести в сообщество. Мы все же рядом с вами работаем, и эти приемы с игрой в бога и перекрашивание морали не действуют даже на мало-мальски опытного специалиста.
Ну нет, так нечестно) Хоть он и не к вам был изначально, но мой вопрос про методологию уже в который раз остался без ответа. "Методология не нужна" не принимается. Сначала ответьте, как у вас, прежде чем мы продолжим обсуждение)
Я же их описал. Все четыре приходилось решать.
Не нужно пользоваться пакетным менеджером в вашей любимой среде. Пишите свои библиотеки.
С самого начала написал, что вопрос в зоне ответственности. Если вам так легко в рассуждениях отбросить как перечисленные вами и мной сценарии, так и те, которые остались за кадром, и о которых вы не подозреваете, значит у вас просто не очень большая зона ответственности. Это нормально, но подход "я не выхожу из среды лишний раз" - как раз следствие, что за вас кто-то очень сильно и много подумал и реализовал, и не только разработчики среды, а даже в том числе и в вашей собственной компании.
Если правильно вас понял, то достичь простоты, ощущать дзен и быть понятным - как раз, наоборот, самое сложное в карьере разработчика)
Для этого надо иметь очень широкий кругозор, многогранный опыт, быть открытым и толерантным к новым подходам, идеям и чужому мнению и владеть фундаментальными основами. Использование сырого гита релевантно всем пунктам)
Ок, если кратко - плагина не хватает там, где нет GUI.
Если вы работаете в кровавом энтерпрайзе, у вас наверняка есть девопсы/SRE. Если вы наблюдали за их работой тоже, могли заметить, что они пишут скрипты для CI/CD, в котором гит вызывается, внезапно, консольно. Если контура многогранные и процессы поставки сложные, скрипты тоже будут сложные, а не просто "гит пулл".
Про методологию спросил тоже не просто так. TBD предполагает разворачивание feature-контуров, отдельных виртуалок под тестирование атомарных функциональных задач. Что тоже удобно скриптуется и тоже требует консоль.
Наконец, плагин в одной среде - ок. А вот если плагины в разных средах, пусть это будет например, IntelliJ + Studio + VSCode + еще что-нибудь, то для человека в кросс-командной роли, который прыгает между разными командами, стеками, средами и репозиториями, вроде как удобнее использовать один внешний инструмент, а не конкретный плагин, чтобы не переключаться между нюансами использования в разных реализациях. Такие люди в компаниях есть, обычно это амбициозные, не боящиеся изучать новое сотрудники, которых привлекают к поднятию с нуля новых или разгребанию старых закостеневших процессов.
Про 1С, 2 языка, 3 IDE, особенности сравнения xml-фалов (для тех же правил конвертации), наверное, не буду рассказывать, чтобы не триггерить вас лишний раз. Как минимум, заверю вас, что плагин там хоть и стабильный, но не очень неудобный.
Не будете, плиз, столь любезны в ответ рассказать про вашу инфраструктуру и методологию? Хочется понять, почему вы отвергаете инструменты, кроме плагина и избегаете чистого гита.
Можно поинтересоваться, на каких методологиях выстроены монорепы (GitFlow, TBD)? Были ли в процессе вашего наблюдения смена методологии в командах? Стек тоже, получается, у всех общий?
Вопрос в зоне ответственности, численности команды, и с какой стороны код-ревью находишься. Чем дальше, тем больше непростых сценариев, связанных с организацией работы большой команды, параллельными обновлениями вендором программного продукта, коллизий с одновременной разработкой функционала. Тут уже желательно погибче владеть инструментом, чтобы наладить работу. Пусть и не обязательно прямо через консоль (есть удобные графические оболочки), но и на плагине уже не выедешь.
О, спасибо за выжимку! Так основная мысль доносится быстрее. Спасибо, что прислушались и начали исправляться!
Но мой посыл остался тем же, - вы пользуетесь плодами революции, чтобы с извращенным кайфом описывать несовершенство системы в этой же самой системе, попутно обвиняя инструментарий и подходы революции, приведшие к созданию этой системы. И не готовы при этом подстроиться со своей стороны и поступиться частью убеждений, например, не писать ненужные подробности в отзывах. Это забавно)
После прочтения статьи больше задумался о границе между принципиальностью и занудством. Ненужное графоманство в отзывах на торговой площадке - прям хороший маркер. И с выводом не согласен, - наоборот, такая революция нужна. Люди теперь могут удовлетворять свои некомфортные для других потребности в суррогатных беседах с компьютером, не мешая остальным. Это ли не чудо прогресса?
Фух, хорошо, что Таро обошли стороной, карты вне подозрений!
Интерактивным сравнением/объединением. Эта возможность доступна как при слиянии веток, так и при сравнении разных конфигураций между собой. Это специальный инструмент (команда, окно, форма) edt, экранирующий внутренний формат хранения. Вы правда не знали про него?
То есть про делегацию сложности вы проигнорировали. Остался только страх...
По большому секрету скажу, что у 1С есть собственное окно сравнения, которое учитывает всю специфику своих же xml. И я не зря упомянул про возможность локального разрешения конфликтов. То, что вы лезете в формат исходников - исключительно ваша осознанная воля, а может, даже и провокация.
Вы бы хоть матчасть подтянули, прежде чем аппелировать к тому, что считаете больным местом. В кажущихся вам выдуманными мирах это не представляет такой сложности.
Мне кажется, довольно поспешно и недружелюбно с вашей стороны называть мою реальность выдуманной.
Хотелось бы услышать агрументированную и заслуженную критику без прилагательных в превосходной степени сравнения.
На моей стороне успешный опыт использования предложенной выше схемы, понимание преимуществ гита, делегация сложности нового формата хранения исходников edt собственно самой edt, и нейтральное спокойное принятие подходов к переиспользованию кода от авторов типовых конфигураций. Что может предложить ваш мир, кроме страха перед спагетти?
Как же вам, должно быть, сложно ловить собеседника на выдуманных ограничениях, искусственно раздувать проблему и потом героически переводить разговор в обсуждение того, что умеет и как бы тут пригодился lsfusion.
Давайте я отвечу по существу вместо автора статьи. Проект переносится в git и EDT, за первоначальный коммит берется конфигурация поставщика, от ствола ответвляется ветвь с чистой конфигурацией поставщика и периодически обновляется поставкой и вливается в основной ствол репозитория. Git уже на этом этапе разрешает всевозможные конфликты слияния кодовой базы. Если не решает - слияние выносится в локальный репозиторий, проводится на локальных ветвях, и EDT, с учетом специфики метаданных и платформы, с помощью платформенного сравнения добивает оставшиеся конфликты. После чего локальное разрешение конфликтов отправляется в удаленный репозиторий.
Это чисто на уровне гита. А на уровне разработки выбор просто широчайший – методы-заглушки, перенаправления на свои методы в начале типовых методов, отдельные подсистемы, общие реквизиты, регистры с любыми объектами в измерениях и многое другое.
Таким образом, никакой код нельзя назвать лишним, потому что, употребляя ваши просторечные обороты, он "спокойно лежит и каши не просит", и никому не мешает. Исправленный код спокойно сольется при описанной выше схеме.
Если будете предлагать стандартный набор возражений, что EDT сырая, требует много памяти, зачем 1С две среды разработки, зачем переводить проект в гит и прочий абсурд, то лучше давайте сразу не продолжать обсуждение, потому что в итоге можно все свести к гиту, а против него и его возможностей спорить бесполезно.
Вот дураки, за лицензии 1С платят, когда опенсурс есть. Полстраны дураков.
Вот дураки, надо было lsfusion покупать. Там же ноль противоречий.
Спасибо за уточнение! Я уж голову сломал, думал, может, есть дополнительные полноценные преобразования значений в указатели и обратно.
И спасибо за статью, с этим объяснением с языка упал флер экзотики, в которой подсознательно не хочется разбираться, и он стал гораздо ближе и очевиднее. Можно взять за базовую отправную точку для изучения машины Тьюринга и смежных тем.
У меня и в голове, и в наспех накиданном скрипте получается, что
{head, 0, 0, 0, [?], 0, ?, ...}превращается в{head, 0, 0, 0, 0, 0, [0], ...}
То есть, смещение вправо больше на 2 единицы, чем в примере, и в начале памяти есть еще две нулевых ячейки.Это ошибка или особенности интерпретации? Потому что насколько я понимаю, интерпретация тут намеренно примитивная в виде последовательного чтения символов, без какого-либо стека. За исключением возвращения к предыдущим парным скобкам (перескакивания к следующим), но он реализовано лишь дополнительными циклами и просто переводит указатель текущего символа входного текста и не относится напрямую к памяти и ее собственному указателю.
Мне помогла волшебная аббревиатура LTSC. Там вырезан маркет приложений, ворох предустановленных программ типа "людей" и "почты", всякие onedriv'ы и прочее, что можно определить как самоцель использования ОС из статьи. С помощью O&O ShutUp10++ донастраивается остальное, касающееся телеметрии, оформления и поведения системы. Плюс папка с обновляемыми установщиками проверенных программ, VLC, Faststone, qbittorrent, WinRar. О, вспомнил, еще 7+ Taskbar Tweaker, чтобы колесиком окна открывать! О некоторых оставшихся неудобствах типа защитника можно поспорить, потому что неоднозначность полного отказа от них все же существует, и компромиссы между безопасностью и удобством достигать можно и нужно.
Очень удобно, что описанная потребность в ненавязчивости совпадает с потребностью в ненавязчивости и стабильности ключевого потребителя ОС, приносящего деньги, - больших корпораций, которым бы не хотелось в массе и на множителе разбираться с уловками, мешающими сотрудникам отдавать все рабочее время самим корпорациям) 11-ая же версия к вашим услугам, если хочется новизны и суррогатного впечатления нахождения на волне технологий. Так же жду выхода ее LTSC редакции.
Поэтому призываю не сильно расстраиваться и сублимировать, а быть хитрее и гибче - ситуацию с выбором целевой аудитории можно трактовать в свою сторону,
начав идентифицировать себя вертолетом апач, понарошку перейдя в другой сегмент пользователей ОС. Ха-ха, тупой майкрософт, я же не корпоративный клиент, а физическое лицо, но пользуюсь твоей корпоративной сборкой! В общем, всем советую.P.S. Кстати, в комментах встретил только одно упоминание LTSC. Незнание о ее существовании плюс то, что она особо не афишируется, косвенно подтверждает, что большинство приняло и согласилось с предложенной вендором сегрегацией. Но это не значит, что вариантов нет и счастье недостижимо.
А у меня голубые погоны.
Так не выдумки же, вам и на инфостарте про это говорят. Вот эталонный пример, как докопаться до столба на пустом месте.
Забавно, что ради возможности почесать эго вы делитесь наработками и образом мышления даже с этими самыми ненавистными анонимами. Но вдруг оказывается, что позиция "один я умный в белом пальто стою красивый", которая так хорошо прокатывает с заказчиками, не особо действует на вдумчивых разработчиков. А потому что уже сбоит оценка адекватности поведения и границ публичности. И не учитывается повышенная критичность целевой аудитории к необъективной и недостоверной информации. Остается кричать "вы всё врети! я не хочу вас слушать! вы все плохие, не любите меня! мне воспитательница наклейку со звездочкой подарила, а вам нет!". Детский сад, ей-богу.
По существу статьи мой посыл все тот же - вы даже не прикоснулись к реальной простоте, красоте и технологичности разработки. Даже стоя прямо перед этим, будучи устроенным по жизни, имея на руках все возможности и проживая в богатое на события и прорывы время. И в отсутствии внутреннего трепета и кайфа от работы со сложными системами и объемными слоями абстракции пытаетесь заместить пустоту в сердце какими-то суррогатами в виде самоубеждения и громких принципов, не понимая ни их сути, ни их применения.
С чего вдруг место в топе стало показателем профессионализма, а не популярности? Это ортогональные понятия, развитие в этих двух дисциплинах может происходить независимо. Например, поп-музыка тоже популярна, но примитивна по музыкальности и бедна на смыслы.
Если все ваши механизмы заточены на маркетинг, пиар и иногда прямой обман, и при этом вы жертвуете профессиональным развитием, то поставленная речь, искусство убеждения, грамотные манипуляции и заработок чуть выше среднего в профессии не мешают вам быть проходимцем, рвачом и откровенным говнокодером.
Естественно, вы ни за что не признаетесь, что сознательно говнокодите ради быстрых денег. Так хотя бы постесняйтесь свой бред в виде этой статьи нести в сообщество. Мы все же рядом с вами работаем, и эти приемы с игрой в бога и перекрашивание морали не действуют даже на мало-мальски опытного специалиста.