Статья явно вдохновлена этой недавней статьей. Можно сослаться для интересующихся, там много дополнительного интересного обсуждения в комментах.
Вдруг человек действительно размечает так почту.
Если этот "вдруг" не случайный, то как стоит относиться к таким продвинутым людям?
требование от безопасников или комплаенса
Как выглядит это требование? Понятно, что в своем продукте можно устанавливать любые правила, но в такой формулировке есть намек на несогласованность управления внутри компании, и это вызывает больше опасений, чем предположительное недовольство от правил обработки плюса в адресе.
Не обязательно указывать исходный имейл, поиск всё равно пройдёт по нормализованным.
Помогите плиз, я все равно не до конца понимаю необходимость нормализации.
Откуда мне знать, какой именно набор правил использовал владелец продукта? Ок, гугл может себе позволить игнорирование точек, чтобы люди поневоле интересовались этим моментом глобально, на уровне окружающей среды. Но остальные компании не настолько крупные, чтобы устанавливать правила в экосистеме интернета в целом и рассчитывать, что их учтут.
Случай, когда две почты с разными тегами (после плюса) достанутся разным людям, уже контролируется держателем почтового сервера.
Наконец, если портал не отслеживает принадлежность одному человеку двух адресов с разным доменом, то зачем это делать в случае с разными тегами? Вы сказали про случайную ошибку, но конкретно плюс нажимается либо через шифт, либо на цифровом блоке, от которого в некотором роде усиленно избавляются, как от атавизма, то есть вероятность ошибка крайне мала.
Но по факту они ведь вообще незаслуженные) Если бы были заслуженными, я бы согласился, но соглашаться то не с чем.
Адекватные понимают, что должно быть в системе, и что 1С умеет, а что не умеет. Адекватным не надо объяснять в тысяче восьмистах комментах, почему lsfusion лучше чем 1С)
В принципе, хамство и оскорбления с вашей стороны были ожидаемы, поэтому имею право использовать это для прекращения обсуждения технических моментов, не будучи опровергнутым в аргументации и причисленным к сектантам.
Советую еще раз вдумчиво и внимательно ознакомиться с платформой 1С и ее сопутствующими продуктами, чтобы более осознанно и последовательно ссылаться на ее недостатки, которыми она, бесспорно, обладает.
Просто мало утверждать такое:
Разгром 1С просто в одну калитку
Этому утверждению нужно еще и соответствовать.
Если же вы нарисовали незаслуженные минусики прямому конкуренту, чтобы повысить выгодность своего продукта в глазах ваших клиентов, то подобное утверждение говорит лишь об очень слабой позиции этого продукта, который не может конкурировать на равных. Было бы приятно, если бы вы это честно признали и не разводили клоунаду при любом упоминании 1С на хабре.
Что речь идет когда вы в серверном действии можете вызывать клиентские действия. То есть единый поток выполнения.
В табличке написано не вызов серверным действием клиентского действия, и не единый поток выполнения, а четко и ясно - обращение сервера к клиенту. Называть черное белым можно, но вы же не приложите себя и свои объяснения к каждому зашедшему на эту страничку?
В 1С JSON / XML (да и в Java) надо формировать руками.
Вообще не надо. Просто одну кнопку нажал - выгрузить в файлы, а потом загрузить из файлов. Выгруженную форму можно править как угодно.
Вот давайте такие простые кейсы, сколько строк кода это займет на 1С.
Нужно принять соответствующий HTTP-запрос и создать новый заказ в базе данных с параметрами запроса.
Через OData можно создать заказ вообще без единой строчки кода. Запрос отправил и больше ничего делать не нужно. Здорово, правда?
Кодом, кстати, тоже в две строчки делается: ПрочитатьJSON() и ДокументОбъект.Заполнить()
language injection (когда внутри литерала идет resolving), с stub index
Раз уж затронули такие сложные и незнакомые слова, можете разъяснить, как вот эти все слова делают среду эргономичной и почему у Eclipse, Theia и VSCode минус?
Но вы это почему-то игнорируете
Просто даю вам возможность взять свои слова назад. У нас же исходная статья про Элемент? Так вот в Элементе текст запроса и подсвечивается, и автодополняется, и декларативный, и вполне себе IDE-ready. Отрицание очевидного меня настолько обескураживает, что я действительно могу отвечать через коммент.
Там специально ? стоят чтобы пояснить что имелось ввиду
Я на страничку со сравнением захожу читать о, собственно, сравнении возможностей систем, а не вникать в сумбурную расшифровку самопридуманных терминов и вытаскивать ценную информацию из ссылок на комменты, оставленных в других комментах к не очень убедительным статьям.
В сравнении четко и лаконично заявлено: Обращение сервера к клиенту. В 1С даже два способа это сделать, один из них я вам назвал. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Декларативная работа с внешними форматами. В 1С многое хранится декларативно в XML - и формы, и СКД, и настройки списков, и командный интерфейс, стоит лишь заглянуть в EDT, чтобы в этом убедиться, или выгрузить конфигурацию в XML-файлы и загрузить обратно. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Прозрачная интеграция. Данные формируются в любых форматах - JSON/XML/BASE64 и передаются по любым протоколам - HTTP/SOAP/FTP/WebSockets. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Эргономичная IDE. Eclipse является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Theia является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Даже VSCode является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Это уже три плюса напротив 1С, по числу сред разработки.
Забавно, что четкие и лаконично сформулированные заявленные преимущества в отношении своего продукта вы называете неоднозначными пунктами)
Почему у 1Ски минус? В платформе все нормально с этим.
Открытая структура БД
Довольно философский вопрос, является ли открытая структура БД преимуществом. В платформе гораздо легче спроектировать схему БД как раз из-за того, что есть визуальный редактор метаданных и продвинутые регистры, инкапсулирующие логику агрегатов и остатков. Внутри платформы доступ к таблицам точно не нужен, а для взаимодействий с внешними системами есть ATK BIView или Экстрактор. Так что я бы инвертировал плюсики в строке.
Декларативная работа с внешними форматами... ...значительно упрощая взаимодействие с внешними системами.
Опять, почему у 1Ски минус? Все форматы поддерживаются и формы прекрасно хранятся в XML. Да и не вы ли утверждали, что
Xml-формат вообще не очень хорошо подходит под разные слияния, так как там различия в строках видны очень плохо, и много лишних символов/слов. ... а на практике, сливание спагетти-кода и главное конфигурационных xml-файлов - это жесточайшая боль.
Легкая непоследовательность в аргументации) Сначала XML - это минус, а там, где надо, легким движением руки формат превращается в элегантный плюс. Или Git не относится к внешним системам?
Эффективное общение клиента с сервером
Вообще непонятно, почему у 1Ски минус. Из коробки работает ровно как вы и описали - и асинхронно, и с гарантией доставки и на узком канале связи. Не нравится родной клиент - обратитесь в Росатом, они свой клиент сделали, это ли не чудо полноценной поддержки трехзвенной архитектуры?
Эргономичная IDE
Опять не плюс, да что ж такое. Eclipse, видимо, теперь неполноценная IDE, ни отладчика, ни автодополнения.
Извините, дальше сравнение читать не стал в силу его необъективности и неактуальности. Можно ли доверять продукту, провалившемуся в позиционировании себя на рынке и сравнении с конкурентами? Вопрос обсуждаемый, но лично я бы не стал.
Пожалуй, соглашусь. "Просто деньги очень нужны", и на Eclipse тратиться не надо. Подвижки в плане современности и открытости есть, но заслуживают критики.
Фреймворк называется. Вроде как все знакомы с этой концепцией, чтобы так некрасиво ее упрощать.
если, конечно, смириться с русскоязычной разработкой
Зачем смиряться? Абсолютно нормально в разработке продуктов преимущественно для русскоязычной аудитории, чтобы язык тех же строковых литералов, повсеместно встречающихся в коде, совпадал с языком самого кода, чтобы избежать лишних переключений раскладки.
Я лишь хочу, что бы вы взглянули на среду разработки Элемент и на Visual Studio Code.
И Theia, и VSCode используют редактор Monaco, хороший проверенный встраиваемый компонент для разных назначений, в том числе и облачных сред разработки. Переносимость опыта между стеками технологий и тем более инструментами вроде как хорошо?
Если ему нужна светло-сиреневая кнопка — значит, она будет.
В корпоративной среде я все-таки склоняюсь в сторону унификации. Максимум, какой-то урезанный функционал для брендирования на уровне темы в корпоративных цветах.
Более глобально тем более не вижу смысла лезть в JS и что-то костылить, так как Элемент - это технология для предметно-ориентированной разработки на фуллстеке, а не для дизайнерских изысков на фронтенде.
По этому в статье я обобщу Элемент как язык программирования для простоты объяснений.
Стоит ли изучать Элемент? Нет, если вы не связаны с 1С и не планируете.
Опять неверные выводы из-за путаницы в терминах и неуместного упрощения. У нового языка пока нет собственного названия. В документации, например, его называют языком Исполнителя или языком Элемента. Элемент - это не язык, это фреймворк, причем с учетом существования шины, в которой используется урезанный Элемент, - конструктор не только для прикладного разработчика, но и для разработчиков вендора, поставляющих разные продукты на его базе. Исполнитель - это тоже не язык, это интерпретатор языка.
Самое важное тут то, что интерпретатор бесплатен, есть и под линукс, и под виндовс, а сам язык бодро развивается и вполне может стать скриптовым языком общего назначения взамен того же onescript, только со статической типизацией и иерархией типов. Чистый код в отрыве от фреймворка, кстати, пишется в VS Code через плагин.
В итоге, все это нормально масштабируется вплоть до того, что, если вам не нравится именно Элемент и политика лицензирования вендора, вы можете написать свой опенсорс-фреймворк на уровне джанги, реакта и других продуктов, с которыми вы потенциально сравниваете Элемент.
До сих пор не понимаю, почему так популярен оперативный учет в статической среде. Для ведения тех же задач система, кроме списков и вложений, должна удовлетворять требованиям ссылочной целостности, помнить историю изменений, предоставлять совместный доступ с разграничением прав. Оптимальный максимум обсидиана в этом плане – журнальный подход: личный дневник, дневник снов, агрегация новостей, где информация только добавляется. Задачи и канбаны как будто явно лишние.
Хотя лейтмотив статьи в целом правильный – в роли конструктора под индивидуальные нужды вещь шикарная. Если бы только не приходилось учить JS.
участвовали в обсуждени
Наверное, хотелось бы увидеть в статье чуть более развернутое упоминание гита именно в свете закономерного этапа развития принципа простоты и использования нативных возможностей файловой системы, которые усиляют позиции идеи "Docs as Code". Что сам обсидиан не обязан брать ответственность за версионирование и синхронизацию, хотя последняя в нем и есть в облачном формате.
практические задачки, которые вам хотелось бы решать с помощью Obsidian
Мой второстепенный сценарий – быстренько спарсить миллион сохраненных закладок с того же хабра скриптом из .html в .md, создать из них хранилище и задействовать полнотекстовый поиск по ключевым словам, чтобы найти ту намертво засевшую в памяти статью про кофе и эволюцию технологии его приготовления, которая не ищется ни через родной поиск, ни через гугловый. А по пути залипнуть на случайно попавшие в выборку статьи про ОКР, СДВГ, гештальты и прочие профессиональные болезни цифровых инженеров. Как говорится, современные проблемы требуют современных решений!
поэтому можно дополнительно попросить Cursor не трогать код рабочего функционала, чтобы он не сгаллюцинировал и все не испортил
Как быть, если исправление требует стратегического, архитектурного рефакторинга по существующим модулям? Утрированно, - по сигнатурам методов прокинуть дополнительный параметр?
я создал слишком много запросов кода и Телеграм меня забанил. Тоже учтите этот момент и заранее спросите у Cursor как этого избежать.
Есть еще моменты, которые нужно учесть? Что еще я могу потенциально повесить, если их не учту?
С учетом этих моментов и платы за запросы навык разработки выглядит просто как перекладывание когнитивной сложности на фоне инволюции обратно из науки в шаманство. Из области, где есть непротиворечивая теория, логика, законы, гайды, документация и дорожные карты происходит откат в область, где требуются все те же мысленные усилия, но не обеспеченные никакой жесткой структурированной основой и результатом. Ближайшая аналогия - производство семян, когда ГМО, хирургически точную технологию с целевым результатом, покрытую тестами и исследованиями, избегают, а облучать радиацией семена вслепую - норм, может какая полезная мутация да выйдет, разгони-ка эти гамма-частицы побыстрее, брат.
Еще момент, что подобные продукты паразитируют на теле Stackoverflow и других проектов с корпусом качественных знаний, естественным образом произошедших из мозгов людей, получивших классическое обучение и набравших рабочий опыт. Причем паразитируют очень деструктивно, в формате конкуренции, убивая материал, на котором учатся и обесценивая классический жизненный цикл роста специалиста и государственные программы обучения.
В общем, вся эта истерия с нейрогенеративной разработкой кажется какой-то коммерческой игрушкой и злобным суррогатом от создателей "жизнь по подписке" и "купи самооценку за деньги". Ходишь по этому цирку-ярмарке нейросетей, все они такие громкие, яркие, манящие. На главном представлении тебе буквально показывают бородатых женщин и сросшихся близнецов с мутированными конечностями. Уходя в экстазе, ты покупаешь очередную свистоперделку по оверпрайсу, а придя домой, разочаровываешься, когда садится батарейка, или она ломается после первого падения в руках друга. И тут ты либо взрослеешь и идешь в детский мир за нормальными игрушки, а на бородатых женщин смотришь в генетической лаборатории, по пути придумывая лекарство от гипертрихоза. Либо остаешься ребенком, ведущемся на мишуру и беспроигрышную лотерею, пока другие мутировавшие мохнатые руки потрошат твою свинку-копилку.
Классические ошибки и незнание методов стандартной библиотеки неинтересно разбирать, проще по-тихому дать коллеге ссылку на методическую документацию, чтобы оба сохранили лицо.
По версионированию запусков не хватает контекста. Прием разгрузки когнитивной сложности кода тупым копипастом иногда жизнеспособен и быстр в реализации, особенно если нет возможности или желания рефакторить или планировать вдолгую.
В обогащаемом во времени условии, если его инвертировать, а потом добавить новое значение в перечисление, логика сломается. Наверное, автор подразумевает переделать на поиск по массиву, но это эстетически опционально.
По оформлению - только использовать полумеры типа phoenixbsl или уже переходить на edt. В конфигураторе вендор линтеров не дал, это подстава, конечно, с его стороны.
Остальное норм, весело) Про гуманитариев прям в точку, бывает такое, когда засиживаешься над задачей и теряешь контакт с внешним миром.
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Архитектура решения воспроизводит 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 и экономическо-технический подсчет никогда не спускают на разработчиков?
Какой-то вы совсем трэш описали.
Не верю, что везде прям так все идеально, треш на любой работе есть в той или иной мере и с ним приходится сталкиваться. Пример был немного утрирован, хотя и близок к происходящему, но приведу более реальный пример.
У нас искусственно поддерживается нездоровая конкуренция между линейным персоналом. Репы форкаются, внутренние либы развиваются параллельно, потом оставляется наиболее выживший и приспособленный кандидат и все его потом дружно х***осят. И это не конструктивная история, как в каком-нибудь гугле, а очень сломанная и демотивирующая деятельность.
Но дает много материала, чтобы посмотреть на разные проблемы под разными углами, научиться решать их разными путями, и собственно, продвигаться к тому специалисту, кто выстраивает процессы для обычных разработчиков. В целом, негатив терпим и есть вызов как залог развития. Как работать без того, чтобы иногда глядеть по сторонам и помогать решать системные проблемы, если честно, даже не представляю. Мне кажется, это довольно скучно.
Статья явно вдохновлена этой недавней статьей. Можно сослаться для интересующихся, там много дополнительного интересного обсуждения в комментах.
Если этот "вдруг" не случайный, то как стоит относиться к таким продвинутым людям?
Как выглядит это требование? Понятно, что в своем продукте можно устанавливать любые правила, но в такой формулировке есть намек на несогласованность управления внутри компании, и это вызывает больше опасений, чем предположительное недовольство от правил обработки плюса в адресе.
Помогите плиз, я все равно не до конца понимаю необходимость нормализации.
Откуда мне знать, какой именно набор правил использовал владелец продукта? Ок, гугл может себе позволить игнорирование точек, чтобы люди поневоле интересовались этим моментом глобально, на уровне окружающей среды. Но остальные компании не настолько крупные, чтобы устанавливать правила в экосистеме интернета в целом и рассчитывать, что их учтут.
Случай, когда две почты с разными тегами (после плюса) достанутся разным людям, уже контролируется держателем почтового сервера.
Наконец, если портал не отслеживает принадлежность одному человеку двух адресов с разным доменом, то зачем это делать в случае с разными тегами? Вы сказали про случайную ошибку, но конкретно плюс нажимается либо через шифт, либо на цифровом блоке, от которого в некотором роде усиленно избавляются, как от атавизма, то есть вероятность ошибка крайне мала.
А еще завязываем со слабой технической аргументацией, меняем позиционирование продукта и выправляем репутацию!
Я же с иронией писал про клоунов. Это расхожее выражение. В чем хамство?
А клоуны остались)
Но по факту они ведь вообще незаслуженные) Если бы были заслуженными, я бы согласился, но соглашаться то не с чем.
Адекватные понимают, что должно быть в системе, и что 1С умеет, а что не умеет. Адекватным не надо объяснять в тысяче восьмистах комментах, почему lsfusion лучше чем 1С)
Называя что-то сарказмом, этому тоже надо соответствовать)
И срываться на хамство, когда заканчивается аргументация в доказательстве недостатков. Очень объективно)
В принципе, хамство и оскорбления с вашей стороны были ожидаемы, поэтому имею право использовать это для прекращения обсуждения технических моментов, не будучи опровергнутым в аргументации и причисленным к сектантам.
Советую еще раз вдумчиво и внимательно ознакомиться с платформой 1С и ее сопутствующими продуктами, чтобы более осознанно и последовательно ссылаться на ее недостатки, которыми она, бесспорно, обладает.
Просто мало утверждать такое:
Этому утверждению нужно еще и соответствовать.
Если же вы нарисовали незаслуженные минусики прямому конкуренту, чтобы повысить выгодность своего продукта в глазах ваших клиентов, то подобное утверждение говорит лишь об очень слабой позиции этого продукта, который не может конкурировать на равных. Было бы приятно, если бы вы это честно признали и не разводили клоунаду при любом упоминании 1С на хабре.
В табличке написано не вызов серверным действием клиентского действия, и не единый поток выполнения, а четко и ясно - обращение сервера к клиенту. Называть черное белым можно, но вы же не приложите себя и свои объяснения к каждому зашедшему на эту страничку?
Вообще не надо. Просто одну кнопку нажал - выгрузить в файлы, а потом загрузить из файлов. Выгруженную форму можно править как угодно.
Через OData можно создать заказ вообще без единой строчки кода. Запрос отправил и больше ничего делать не нужно. Здорово, правда?
Кодом, кстати, тоже в две строчки делается: ПрочитатьJSON() и ДокументОбъект.Заполнить()
Раз уж затронули такие сложные и незнакомые слова, можете разъяснить, как вот эти все слова делают среду эргономичной и почему у Eclipse, Theia и VSCode минус?
Просто даю вам возможность взять свои слова назад. У нас же исходная статья про Элемент? Так вот в Элементе текст запроса и подсвечивается, и автодополняется, и декларативный, и вполне себе IDE-ready. Отрицание очевидного меня настолько обескураживает, что я действительно могу отвечать через коммент.
Я на страничку со сравнением захожу читать о, собственно, сравнении возможностей систем, а не вникать в сумбурную расшифровку самопридуманных терминов и вытаскивать ценную информацию из ссылок на комменты, оставленных в других комментах к не очень убедительным статьям.
В сравнении четко и лаконично заявлено: Обращение сервера к клиенту. В 1С даже два способа это сделать, один из них я вам назвал. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Декларативная работа с внешними форматами. В 1С многое хранится декларативно в XML - и формы, и СКД, и настройки списков, и командный интерфейс, стоит лишь заглянуть в EDT, чтобы в этом убедиться, или выгрузить конфигурацию в XML-файлы и загрузить обратно. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Прозрачная интеграция. Данные формируются в любых форматах - JSON/XML/BASE64 и передаются по любым протоколам - HTTP/SOAP/FTP/WebSockets. Это плюс напротив 1С.
В сравнении четко и лаконично заявлено: Эргономичная IDE. Eclipse является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Theia является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Даже VSCode является полноценной средой разработки со всеми перечисленными в подсказке возможностями. Это уже три плюса напротив 1С, по числу сред разработки.
Забавно, что четкие и лаконично сформулированные заявленные преимущества в отношении своего продукта вы называете неоднозначными пунктами)
Почему у 1Ски минус? В платформе все нормально с этим.
Довольно философский вопрос, является ли открытая структура БД преимуществом. В платформе гораздо легче спроектировать схему БД как раз из-за того, что есть визуальный редактор метаданных и продвинутые регистры, инкапсулирующие логику агрегатов и остатков. Внутри платформы доступ к таблицам точно не нужен, а для взаимодействий с внешними системами есть ATK BIView или Экстрактор. Так что я бы инвертировал плюсики в строке.
Опять, почему у 1Ски минус? Все форматы поддерживаются и формы прекрасно хранятся в XML. Да и не вы ли утверждали, что
Легкая непоследовательность в аргументации) Сначала XML - это минус, а там, где надо, легким движением руки формат превращается в элегантный плюс. Или Git не относится к внешним системам?
Вообще непонятно, почему у 1Ски минус. Из коробки работает ровно как вы и описали - и асинхронно, и с гарантией доставки и на узком канале связи. Не нравится родной клиент - обратитесь в Росатом, они свой клиент сделали, это ли не чудо полноценной поддержки трехзвенной архитектуры?
Опять не плюс, да что ж такое. Eclipse, видимо, теперь неполноценная IDE, ни отладчика, ни автодополнения.
Извините, дальше сравнение читать не стал в силу его необъективности и неактуальности. Можно ли доверять продукту, провалившемуся в позиционировании себя на рынке и сравнении с конкурентами? Вопрос обсуждаемый, но лично я бы не стал.
Пожалуй, соглашусь. "Просто деньги очень нужны", и на Eclipse тратиться не надо. Подвижки в плане современности и открытости есть, но заслуживают критики.
С корпоративной учеткой - на портале сопровождения:
1C:Исполнитель, версия 7.0.3.3
С коммьюнити учеткой - на портале разработчика:
1С:Исполнитель
Фреймворк называется. Вроде как все знакомы с этой концепцией, чтобы так некрасиво ее упрощать.
Зачем смиряться? Абсолютно нормально в разработке продуктов преимущественно для русскоязычной аудитории, чтобы язык тех же строковых литералов, повсеместно встречающихся в коде, совпадал с языком самого кода, чтобы избежать лишних переключений раскладки.
И Theia, и VSCode используют редактор Monaco, хороший проверенный встраиваемый компонент для разных назначений, в том числе и облачных сред разработки. Переносимость опыта между стеками технологий и тем более инструментами вроде как хорошо?
В корпоративной среде я все-таки склоняюсь в сторону унификации. Максимум, какой-то урезанный функционал для брендирования на уровне темы в корпоративных цветах.
Более глобально тем более не вижу смысла лезть в JS и что-то костылить, так как Элемент - это технология для предметно-ориентированной разработки на фуллстеке, а не для дизайнерских изысков на фронтенде.
Опять неверные выводы из-за путаницы в терминах и неуместного упрощения. У нового языка пока нет собственного названия. В документации, например, его называют языком Исполнителя или языком Элемента. Элемент - это не язык, это фреймворк, причем с учетом существования шины, в которой используется урезанный Элемент, - конструктор не только для прикладного разработчика, но и для разработчиков вендора, поставляющих разные продукты на его базе. Исполнитель - это тоже не язык, это интерпретатор языка.
Самое важное тут то, что интерпретатор бесплатен, есть и под линукс, и под виндовс, а сам язык бодро развивается и вполне может стать скриптовым языком общего назначения взамен того же onescript, только со статической типизацией и иерархией типов. Чистый код в отрыве от фреймворка, кстати, пишется в VS Code через плагин.
В итоге, все это нормально масштабируется вплоть до того, что, если вам не нравится именно Элемент и политика лицензирования вендора, вы можете написать свой опенсорс-фреймворк на уровне джанги, реакта и других продуктов, с которыми вы потенциально сравниваете Элемент.
До сих пор не понимаю, почему так популярен оперативный учет в статической среде. Для ведения тех же задач система, кроме списков и вложений, должна удовлетворять требованиям ссылочной целостности, помнить историю изменений, предоставлять совместный доступ с разграничением прав. Оптимальный максимум обсидиана в этом плане – журнальный подход: личный дневник, дневник снов, агрегация новостей, где информация только добавляется. Задачи и канбаны как будто явно лишние.
Хотя лейтмотив статьи в целом правильный – в роли конструктора под индивидуальные нужды вещь шикарная. Если бы только не приходилось учить JS.
Наверное, хотелось бы увидеть в статье чуть более развернутое упоминание гита именно в свете закономерного этапа развития принципа простоты и использования нативных возможностей файловой системы, которые усиляют позиции идеи "Docs as Code". Что сам обсидиан не обязан брать ответственность за версионирование и синхронизацию, хотя последняя в нем и есть в облачном формате.
Мой второстепенный сценарий – быстренько спарсить миллион сохраненных закладок с того же хабра скриптом из .html в .md, создать из них хранилище и задействовать полнотекстовый поиск по ключевым словам, чтобы найти ту намертво засевшую в памяти статью про кофе и эволюцию технологии его приготовления, которая не ищется ни через родной поиск, ни через гугловый. А по пути залипнуть на случайно попавшие в выборку статьи про ОКР, СДВГ, гештальты и прочие профессиональные болезни цифровых инженеров. Как говорится, современные проблемы требуют современных решений!
Смутили два момента:
Как быть, если исправление требует стратегического, архитектурного рефакторинга по существующим модулям? Утрированно, - по сигнатурам методов прокинуть дополнительный параметр?
Есть еще моменты, которые нужно учесть? Что еще я могу потенциально повесить, если их не учту?
С учетом этих моментов и платы за запросы навык разработки выглядит просто как перекладывание когнитивной сложности на фоне инволюции обратно из науки в шаманство. Из области, где есть непротиворечивая теория, логика, законы, гайды, документация и дорожные карты происходит откат в область, где требуются все те же мысленные усилия, но не обеспеченные никакой жесткой структурированной основой и результатом. Ближайшая аналогия - производство семян, когда ГМО, хирургически точную технологию с целевым результатом, покрытую тестами и исследованиями, избегают, а облучать радиацией семена вслепую - норм, может какая полезная мутация да выйдет, разгони-ка эти гамма-частицы побыстрее, брат.
Еще момент, что подобные продукты паразитируют на теле Stackoverflow и других проектов с корпусом качественных знаний, естественным образом произошедших из мозгов людей, получивших классическое обучение и набравших рабочий опыт. Причем паразитируют очень деструктивно, в формате конкуренции, убивая материал, на котором учатся и обесценивая классический жизненный цикл роста специалиста и государственные программы обучения.
В общем, вся эта истерия с нейрогенеративной разработкой кажется какой-то коммерческой игрушкой и злобным суррогатом от создателей "жизнь по подписке" и "купи самооценку за деньги". Ходишь по этому цирку-ярмарке нейросетей, все они такие громкие, яркие, манящие. На главном представлении тебе буквально показывают бородатых женщин и сросшихся близнецов с мутированными конечностями. Уходя в экстазе, ты покупаешь очередную свистоперделку по оверпрайсу, а придя домой, разочаровываешься, когда садится батарейка, или она ломается после первого падения в руках друга. И тут ты либо взрослеешь и идешь в детский мир за нормальными игрушки, а на бородатых женщин смотришь в генетической лаборатории, по пути придумывая лекарство от гипертрихоза. Либо остаешься ребенком, ведущемся на мишуру и беспроигрышную лотерею, пока другие мутировавшие мохнатые руки потрошат твою свинку-копилку.
Классические ошибки и незнание методов стандартной библиотеки неинтересно разбирать, проще по-тихому дать коллеге ссылку на методическую документацию, чтобы оба сохранили лицо.
По версионированию запусков не хватает контекста. Прием разгрузки когнитивной сложности кода тупым копипастом иногда жизнеспособен и быстр в реализации, особенно если нет возможности или желания рефакторить или планировать вдолгую.
В обогащаемом во времени условии, если его инвертировать, а потом добавить новое значение в перечисление, логика сломается. Наверное, автор подразумевает переделать на поиск по массиву, но это эстетически опционально.
По оформлению - только использовать полумеры типа phoenixbsl или уже переходить на edt. В конфигураторе вендор линтеров не дал, это подстава, конечно, с его стороны.
Остальное норм, весело) Про гуманитариев прям в точку, бывает такое, когда засиживаешься над задачей и теряешь контакт с внешним миром.
Спасибо за исчерпывающий ответ! Стало более понятно.
Буду с нетерпением ожидать опенсорс/лайт версии продукта, подкрепиться иллюстрациями с документацией и задействовать в корпоративных проектах.
Интересная разработка, очень привлекла внимание пару лет назад во время поиска работы. Ждал подобного поста, но хотелось бы больше подробностей.
Архитектура решения воспроизводит 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 и экономическо-технический подсчет никогда не спускают на разработчиков?
Не верю, что везде прям так все идеально, треш на любой работе есть в той или иной мере и с ним приходится сталкиваться. Пример был немного утрирован, хотя и близок к происходящему, но приведу более реальный пример.
У нас искусственно поддерживается нездоровая конкуренция между линейным персоналом. Репы форкаются, внутренние либы развиваются параллельно, потом оставляется наиболее выживший и приспособленный кандидат и все его потом дружно х***осят. И это не конструктивная история, как в каком-нибудь гугле, а очень сломанная и демотивирующая деятельность.
Но дает много материала, чтобы посмотреть на разные проблемы под разными углами, научиться решать их разными путями, и собственно, продвигаться к тому специалисту, кто выстраивает процессы для обычных разработчиков. В целом, негатив терпим и есть вызов как залог развития. Как работать без того, чтобы иногда глядеть по сторонам и помогать решать системные проблемы, если честно, даже не представляю. Мне кажется, это довольно скучно.