Разница в производительности на выборках и джойнах ключа 8 байт (long) и 16-байтного binary настолько мала на общем фоне, что это точно можно не учитывать. Так-то посмотреть и строки в однобайтных кодировках меньше занимают. И binary collation быстрее. И тот же RCSI гораздо дороже для отдельных запросов, но его точно надо включать в MS SQL.
А много ли в мире учётных систем на микросервисах? Ну то есть не чтоб мелочёвка сбоку, а чтобы прямо главную книгу банка или что-то подобное на микросервисах?
В прошлой статье я защищал 1С, а в этой, ну, пусть из латентного нонконформизма, но налью таки бочку дёгтя.
1С сейчас в современном IT-ландшафте, как чемодан без ручки — нести тяжело, выбросить жалко. Для 2003-2004 года интеграция в IT-ландшафт была суперской, но, чёрт подери, ко мне того и гляди на собеседование придут люди рождённые в те годы. Что я под этим подразумеваю — ниже. Слааабые возможности интеграции. Что у нас есть в 1С для общения с другими приложениями? Файлы, COM-объекты, внешние компоненты, HTTP-запросы, SMTP/POP3, ODBC-подобные соединения с СУБД, плюс ещё некоторая достаточно экзотическая мелочёвка. Причём всё вышепереписленное с кучей оговорок:
Файлы по сути только текстовые. Работа с бинарными файлами — раньше была совсем не возможна, а сейчас низкоуровневый трешак, который я не смогу обосновать по стоимости разработки прикладных решений. Только если жизненно важно что-то простое разобрать. Отдать вендору должное — на файлах у него достаточно много неплохих стандартизованных отраслевых решений.
SMTP/POP3 — э, ну вы же всёрьёз не считаете, что это способ сделать API?
COM-объекты — доступны только под Windows (а уже и сервер умеет с linux жить, и клиенты не все это умеют), тупиковая ветвь эволюции. Ну камон, эта тема была в тренде 20(!) лет назад, закопайте уже таки стюардессу.
HTTP-запросы реализованы очень низкоуровнево. Ну то есть простые GET по HTTP ещё куда ни шло, но, например, какой-нибудь SPNEGO реализовать уже совсем не весело. HTTPS, кстати, долго был недоюзабельный. Вкупе с ещё одной проблемой 1С (отвратительной модульностью и сложностью переиспользования технического кода) это приводит к тому, что разработчики прикладных решений часто говорят "ну его нафиг, давайте файлами обмениваться".
ODBC-подобные соединения с СУБД — это только чтобы забирать данные из витрин. Серьёзный "контрактный" API на этом не строят.
Внешние компоненты (ВК). Теоретически "вы можете всё". Ахаха. Теоретически. Практически это некий самописный аналог IDispatch (привет, динозавры!!!) со своим ГПСЧ и практикантками. Их и было-то не много — в основном для интеграции с торговыми устройтсами, а году в 2005-2006 1С поменяла нутро этого формата (ушла от явного использования COM по сути и от интерактивных возможностей) и с тех пор их совсем почти не пишут. При написании надо либо дофига делать руками, либо делать кучу нетривиального тулинга, а для этого надо много времени. Готовых публичных и полезных ВК если и появляется, то точно не больше 2 штук в год. Теоретически можно даже из 1С работать с .NET (Elisy .Net Bridge), а практически он не развивается, например, .NET Core там нет. Ну и даже там всё не просто.
Кому кажется этого достаточно, тот застрял в 2005 году. А я хочу: HTTP/2, GraphQL, gRPC, сериализацию в Protobuf, удобную интеграцию с kafka, RabbitMQ, ActiveMQ (и прочими ZeroMQ, nanomsg), хочу подключаться к MongoDB, Cassandra, Hadoop, хочу использовать комфортно распространённые API (ну, например, файлы в S3 хранить), хочу использовать SSO и аутентифицировать сервис 1С без хранения креденшелов. Это только то, что сходу вспомнилось. На самом деле этот список каждый день прирастает.
Слабая интеграция в инфраструктуру современного IT. Да у 1С по сих пор даже работа с доменом AD и внешней аутентификацией всё ещё в детском состоянии! Максимум, что есть — указание, что Вася Пупкин может аутентифицироваться как PupkinVD@my.company. Нет корректной работы с группами, OU, блокированием/удалением, нет работы с корпоративным RBAC, нет альтернативных сервисов аутентификации (KeyCloack, например, или аутентификация в google том же). Интеграция с корпоративным мониторингом на ELC на уровне "принципиально возможна". То есть как бы её никто не запрещает делать, но там делать, прямо скажем, немало. Про успешную интеграцию в WAF и DLP просто не слышал. Интеграция с мессенджерами, телефонией и exchange — примитивна. Зато в 1С сканер ШК и фискальный регистратор почти всегда из коробки заводится, ну да.
Слабые интерфейсные возможности. Пока сценарий работы кнопкутык, кнопкутык, полевбил, контрол-энтер, то всё прекрасно. Шаг вправо-влево и "не шмогла". Кто не согласен — вперёд покажите мне прототип интерактивного редактора markdown (хотя бы только с жирным и наклонным шрифтом) или интерактивную работу с картой (и нет, вам не поможет ГеографическаяСхема).
О, кстати, про ГеографическаяСхема. Отдельно упомяну "кладбище невзлетевших фич". Это целая гора фич, которые или просто оказались не нужны или были хреново сделаны или вышли не так и не тогда, когда нужно было.
Просто списком с минимальными комментариями:
ГеографическаяСхема — в этом виде оказалась никому не нужна. Вышла очень рано, не продумана инфраструктура. Сейчас проще пользоваться либо настоящими картами (яндекс, гугл), либо сторонними севисами/решениями
Статистический анализ данных — во многом опередил своё время, но сделан был "не для людей". Сейчас это делают либо в питон/юпитер, либо в табло/повербиай/клик. Очень обидно за державу. Они делали (хотели делать, точнее) кластерный анализ, пока остальные в том же классе всё ещё фильтровали эксель. Бигдата за несколько лет до хайпа.
Бизнес-процессы. Сделаны хуже, чем даже Elma, а это ещё надо постараться. Где-то как-то используются, обязательно присутствуют на экзамене 1С: Специалист (в жизни достаточно редко). Для сравнения посмотрите на эту же Elma или на Camunda или на любую другую BPM-систему.
Веб-сервисы (wsdl). Не успели появиться, как по факту списаны на свалку истории (заменены REST и MQ в нормальном, не 1С, мире)
Fast Infoset. Его место в нормальном мире занял ProtoBuf фактически.
Полнотектовый поиск не то чтобы совсем дохлый, но опять же — то как он сделан и подан не оставляет ему шансов быть в топе фич.
Сводная диаграмма — на фоне СКД и отчётов просто не взлетела.
Макеты текстовых документов. Крутая фича (нужна, если нужно отчёты в TXT формате делать). Но она никому почти не нужна.
Срез первых в регистре сведений. Ну просто оказался не нужен.
IBM DB2 RIP
Ну а в разработке, как я уже отметил, всё плохо с модульностью решений и сложностью переиспользования технического кода. И по мне так БСП не пример того, как это "победили", а пример того, как это "проиграли".
Вашу статью я читал. С чем-то согласен полностью, с чем-то частично, с чем-то полностью не согласен, но статья очень хорошая. Даже начинал писать комментарий, но а) я понял, что он по объёму может стать сопоставим со статьёй, б) там и так тьма комментаторов (и опять же — с кем-то согласен, с кем-то нет). Писать такой комментарий ради "в интернете кто-то не прав" — только тепловую смерть вселенной приближать :)
Все то, что вы написали стандартный «набор джентельмена» для любой высокоуровневой (в частности ERP) платформы. Для SAP и DAX — соглашусь, но если посмотреть шире, то боюсь разрушить вашу веру в человечество. Если б вы знали, какой трешак происходит в банковской и финансовой сфере даже по перечисленным пунктам.
В ваших же пунктах вы кстати почему-то сравниваете с совсем низкоуровневыми платформами вроде Java (даже не .Net где хотя бы LINQ есть). Потому что эти пункты низкоуровневые. Я могу, наверное, 100 пунктов хорошего и 100 плохого написать разной степени низкоуровневости и высокоуровневости. Потому и выбрал именно эти пункты, что сравниваю не только и не столько с Java, сколько со всеми распространёнными языками/платформами. Всё перечисленное применимо для Java/JS/C# и большая часть для Ruby/Python, а то что про СУБД для SQL Server/Oracle/PostgreSQL/MySQL.
Главный посыл, что если в платформе/среде есть доступ к распространённым языкам программирования (Java/JS/C#), или прямой доступ к структуре БД, то скорее всего будет возможность, особенно на ранних стадиях разработки решения, наделать решений, которые для этого класса задач будут очень неприятными. А в 1С — не самые лучшие решения, но от типичных грубых ошибок спасают. Я был бы рад, если бы этих грубых ошибок не было, но я их вижу в крупных финансовых организациях во всех без исключений. И во многих "не ERP" решениях (Jira, gitlab, IDEA прямо упомянуты). Отсутствие этих ошибок позволяет гораздо быстрее создать MVP на 1С (в определённом классе задач) и позволяет MVP дальше масштабировать.
Ваши статьи по lsFusion внимательно читаю. Не со всем согласен, настроен скептически, но искренне желаю удачи.
Ну и составные типы если они ссылочные, то это просто костыль для обхода наследования Мне кажется, что правильнее было бы приводить аналогию, что это тип-сумма из алгебраических типов данных, которые активно используются в ФП. Но работа с ними по-хорошему требует полноценного pattern matching и вообще, гораздо более зрелой работы с типами. Но это всё споры типа "эта какашка больше похожа на орхидею или на розу" — не похожа она ни на то, ни на другое и вообще лежит и пахнет.
мина замедленного действия с точки зрения производительности — не такого уж и замедленного, ага, и я выше кидал ссылку на свою статью.
А у MXL есть гарантия? Это же ячеистый формат с неограниченный шириной, как можно гарантировать что он влезет на A4?
Письменной гарантии от вендора нет. Но а) вендор один (в XLSX — несколько "совместимых"), б) если 1С не будет сильно стараться унифицировать печатный вид, то все печатные формы 1С: Бухгалтерии развалятся и для них это будет серьёзный фэйл.
В конечном итоге вся информация либо выводится на принтер, либо сохраняется в excel (как стандарт ячеистого формата). Промежуточное звено в виде MXL не совсем понятно чем помогает в этом вопросе.
Помогает делать макет 1 раз для всех конечных форматов. Да, есть ограничения. Но сам процесс достаточно удобен для всех целевых применений. Более того — часть процесса вёрстки формы можно отдать даже пользователю. Более того, в 1С мне очень удобно смотреть diff между макетами в системе контроля версий. В отличие от того же jasper (а уж как "прелестно" с SCM работать с каким-нибудь SSRS или SSAS — там вообще труба).
Если вы считаете, что эта "модель обычных reporting systems" лучше — да ради бога. Я у обеих сторон вижу гору недостатков и достоинств.
Это вообще не задача печатных форм, это задача аналитических отчетов, а точнее BI tools.
Ну… Где-то в мире розовых пони и танцующих единорогов оно так и есть. Реальность же сложнее и интереснее.
Вот есть прям классические отчёты и печатные формы. Счёт-фактура, 2НДФЛ, банковская выписка, отчёт биржевого брокера клиенту, отчёт агента принципалу. Сформировал, отправил, забыл. Со стороны клиента нет и, наверное, не может быть никакого дрилл-дауна.
Есть аналитики статистики, которые сидят в PowerBI, Tableau, QlikView или даже SAS (за психическое здоровье последних я уже не поручусь). Они сидят в башне из белого мрамора и пару раз в квартал/месяц/неделю снисходят к нам, глупым, неся свою мудрость (но мы-то знаем, что они ещё только учатся серьёзно обрабатывать данные на пятончике). Эти чуваки, конечно, без дрилл-дауна просто выпрыгнут с самого верхнего этажа башни, потому что это лучше и проще, чем BI без инструментов.
Но есть и промежуточные задачи. В рамках учётной системы оператор сделал накладную, смотрит — ой, а что это за строчка? Тыкает мышкой, проваливается в карточку товара или контрагента. А вот бухгалтер сформировал ОСВ по счёту — ой, что за странный дебетовый оборотик тут. Тыкает мышкой, листает проводки в карточке счёта. А вот завсклад, который тоже ткнул мышкой в отчёт и теперь-то понял, что за хрень с секцией №152. А вот и директор, который нахмурившись ткнул мышой в диаграмму на столбике и увидел детализированный отчёт по сложному проекту. И все они не могут себе позволить работать даже с QlikView (который как витрина достаточно прост), потому что в 1С это тык мышкой и 2 секунды, а просто найти нужные данные в QlikView или другой отчёт в 1С — это несколько минут.
Мы решаем бизнес-задачи и в них важны такие возможности. Да, в голой теории это можно разнести. А в практике простые возможности drill-down просто необходимы конечным пользователям.
Причём в джаспере дрилл-даун тоже относительно удачный для разработчика по сравнению с MS SSRS, или со старым Crystal Reports (современный лучше, но он стал SAP), или с, простите, FastReport. Я сам в нём делал такие отчёты, но после простоты 1С в данной теме мне это было некомфортно.
Кстати, мне лично сильно не хватает полноценного drill-down в дэшбордах и отчётах Jira и YouTrack. И я много раз видел и даже был участником, когда 1Сники за вечерок делали потрясные отчёты с расшифровкой по данным своих задач, загруженных из Jira.
Ну а графическим форматам тогда проигрывают оба эти формата.
Не надо так передёргивать. Если речь про "отчёты в табличном виде", то это некоторый вывод из программы, которые потом пользователем используются для просмотра, несложного анализа и печати. Графические файлы и PDF очень неудобны пользователю для "несложного анализа" (скопировать половину столбца чисел и сложить). HTML и XLSX плохи для печати (нет гарантии, что напечатается также). MXL плох потому что его не отдашь внешнему пользователю (у него может не быть 1С). Текстовый формат (а также csv, json, xml даже с xslt) проигрывает в возможностях оформления.
XLS/XLSX открывается внезапно совсем не одинаково и не всегда.
Важный плюс 1С в том, что из одного макета получаются приемлемые конечные формы большого количества форматов. У джаспера на словах это как бы почти так, но есть нюансы.
На практике за годы разработки, руководства и архитектуренья я вижу, что работа разработчика 1С с макетом и последующее сохранение в общеупотребимый формат в рамках этой задачи занимает в разы меньше времени при более стабильном и предсказуемом результате. И это если сравнивать с удачными платформами (типа Jasper), потому что в неудачных добавить новый формат это вообще отдельный проект.
Макеты печатных форм к форматам, в которых формируются эти печатные формы прямого отношения не имеют. В том же Jasper'е можно делать формы с разлинейкой (получая потом предсказуемые XLSX), а можно графические для PDF.
Имеют. Табличный документ и его файловое представление MXL — это основной инструмент и одновременно выходной артефакт в 1С. И 1С-ник именно в нём делает форму отчёта. В других платформах обычно это бывает по-другому, там инструмент и выход разнятся (а если не разнятся, то это скорее всего отчёт, формируемый из шаблонного файла MS Office и это один из худших вариантов).
Плюсы в 1С не очень явные, они раскиданы по платформе и видны, когда видишь, как это делается в других платформах. В основном это НЕ фичи, а наоборот — отказ от фич. Несколько примеров.
(Мой любимый пример) Числа. В 1С есть только аналог BigDecimal в контексте переменных встроенного языка (и numeric/decimal в данных). Это офигенно роняет производительность (сравните цикл инкрементов до миллиарда с любым языком, даже с Python). Но сколько же раз я видел ошибок прикладных программистов в решениях связанных с этим. То float начинают для денег использовать, то с округлением напортачат, то за maxint уйдут, то в конвертации между типами ерунду наделают. А как прекрасно выглядит java-код, который интенсивно работает с bigdecimal/biginteger! Особенно через пару месяцев, после его написания. Я после пары раз такого опыта, для этих задач настоятельно рекомендую kotlin или scala (ну или .NET) — там хотя бы перегрузка операторов есть.
Unicode. Что, блин, может быть проще? Не надо в 2019 году использовать однобайтные ASCII кодировки (кроме интеграции с дремучими legacy). Ни за что. Но нет же. Раз в год-два я очередной раз объясняю людям, что надо использовать nvarchar и не надо однобайтный varchar в БД (когда этой системы будет 100-200 инсталляций кастомизированных по несколько ТБ и в одной самой ценной невозможно будет внести имя клиента — будет прикольный фэйл). В 2015 году у gitlab отваливалась LDAP-авторизация из-за неправильной работы с кодировками, у JetBrains IDE до сих пор не везде работает с кириллицей в именах файлов. Ну чёрт подери — доколе?
Нумерация документов/справочников. В 1С она точно не самая гибкая и не самая лучшая. Но что делают в банковском софте и в самописных системах учёта — ну это же просто мрак. То identity воткнут (и потом "ой, а почему у нас дырки"), то наоборот, сделают генератор, который работает с блокировкой на уровне СУБД (и станет узким местом).
Составные типы. Я не рад тому, как это сделано в 1С. Но опять же ровно до того момента, как приходит пора увидеть очередную попытку их переизобрести в самописных решениях. Ну как же так вот у этих людей (senior+ уровня!) и гуру C# и Java получается сделать ещё хуже? Да даже с идентификаторами ссылки. 1С приняла волевое решение — всё, все идентификаторы ссылок абсолютно синтетические, но последовательные, примерно как NEWSEQUENTIALID в MS SQL и нет больше проблем, например, при репликациях/обменах. Нет же, разработчики других систем упрямо лепят что-то типа identity (она же короче!), тащат их в GUI, пока не придёт пора делать несколько связанных инстансов (и тут их ждёт открытие).
Ещё одна мелочь — отображение списков. В 1С есть достаточно удачные механизмы листания (больших) списков и навигации по ним. Вообще тема достаточно неприятная, она идеально не решается: тут либо интуитивно и просто (но риск огромных рекордсетов на клиенте), либо той или иной кривизны пейджинг. Те, кто делают пейджинг часто делают его криво. Те, кто делает честный скроллбар — кладут базу данных, канал и клиента.
Одно место для проектирования пользовательского интерфейса (я про управляемые формы). Спору нет, в веб-клиенте интерфейс работает не то чтоб идеально. Но работает. А вот для многих других учётных и банковских систем сделать удалённое рабочее место — это проект уровня предприятия. Оговорка: к счастью для тех кто изначально сделал на вебе это либо не нужно, либо есть Электрон.
Всё это лишь горстка примеров, когда ограничение функциональных возможностей или реализация с компромиссами оказывается важным архитектурным преимуществом в будущем. Даже компромиссный или не самый эффективный вариант — он уже есть в коробке и принимается как данность. Его самостоятельная реализация будет либо невозможной (потому что такие решения надо принимать в начале проекта, а там не до того, да и вообще архитектора нет), либо несколькими дорогими итерациями.
JasperReports отличный инструмент для отчётов. Но 1С-ной системе отчётов (инструменты работы с MXL, конструкторы, построитель, СКД) он скорее проигрывает. Проигрывает в простоте drill-down, сравнение табличных документов в 1С просто есть (джасперу оно не нужно, но когда нужно, то ХЗ что делать), когда нужно сделать странные шибанутые вещи, MXL позволяет. 1С тоже не лапочка, когда надо сделать готовый красивый отчёт-презентацию, но тут проще смотреть изначально на софт для презентаций.
1С-ный MXL, кстати, при определённой прямизне рук, позволяет без проблем работать с гигантскими MXL (миллионы строк). В Jasper я такие объёмы не пробовал, а вот Excel на этих объёмах просто ад.
lsfusion пока изрядно молодой, при всём уважении к ним, я пока не готов детально обсуждать.
XLSX выигрывает по одним фичам и проигрывает по другим. Выигрывает тем, что он не только формат отображения, но и формулы, умеет играть с источниками данных. Проигрывает, например, если есть строки с разной шириной колонок. Есть задачи, которые удобнее делать в XLSX, есть те, которые удобнее в MXL. Макеты печатных форм часто удобнее шлёпать в MXL.
Да, наверное. Я к тому времени уже не мог пользоваться 9x и жил в NT 4, с которой перешёл на 2К, поэтому Windows ME я увидел вживую пару раз на каких-то чужих компах.
Краткая история вопроса :)
Чтобы пользователи не запутались в версиях, Windows 4.0 выпустили, как Windows 95. потом вышла Windows 98, а так как они были очень совместимы, то чтобы не путаться их называли Windows 9x. Следующую версию назвали Windows ME. Наверное, чтобы в версиях не путаться. Чтобы победить проблему 2000 и новая версия не была меньше старой (пользователи же будут путаться!) следующая ОС стала Windows 2000 (хоть и выросла она из NT 4.0). И при всём при этом внутри нумерация версий была цифровой последовательной.
Тут пути серверов и пользовательских ОС немного разошлись (видимо энтерпрайз не выдержал борьбы за понятность версий:) ). В энтерпрайзе вышли 2003 и её R2, 2008 и её R2, 2012 и её R2, 2016 и 2019. При этом цифровая нумерация внутри почти выжила.
В пользовательском сегменте вышла XP и Vista. Vista, конечно, вышла, но лучше бы нет. Потому что следующего имени не придумали и решили перестать путать пользователей непонятными версиями и назвали "7". Выпустили 8 и 8.1, хотели уже выпустить 9, но тут выяснилось, что это приводит к путанице версий с Windows 9x! И чтобы путаницы не было, решили раз и (почти) навсегда выпустить Windows 10. Чем, кстати поломали нумерацию версий серверных ОС.
А чтобы как-то различать версии решили в релизе отмечать ГГММ в релизе. выпустили 10.0.1803, 10.0.1810, 10.0.1903. Но так как они все были Windows 10, то их стали называть по последним 4 цифрам. Чтобы не путаться в версиях, конечно же.
И! Внезапно! Приходит пора использовать 20 год и 03 месяц и возникает путаница в версиях! Windows 2003 уже была!
Глядя на качество последних «стабильных» обновлений винды, ставить что-то из «раннего» или «позднего» доступа выглядит слишком смелым ходом. И всё большее сомнение в необходимости получения стабилных обновлений не кажется параноей, если комп нужен для дела, а не только чтобы бесконечно разрешать MS добавлять и убавлять функционал ОС.
Как бы и да и нет. За пару лет (может больше) на раннем доступе у меня было несколько не очень удачных обновлений. Но а) если критичное и явное (например был поломан звук в firefox), то просто катишь обратно, б) если не критичное, то и ладно, в) если критичное и неявное, то у меня есть бэкапы. Больше достаёт частота обновлений и необходимость перезагрузок в принципе, чем сами изменения.
Но лично я готов быть подопытным кроликом, я могу быстро сориентироваться и продолжить работу. Зато на раннем доступе баги быстрее чинят, если находят критичные.
"Мы должны относиться к конфиденциальности как к праву человека. Мы должны иметь комплексную кибербезопасность, встроенную в технологию."
Это точно заявляет представитель компании Microsoft? :)
Как вы правильно отметили в начале статьи, на хабре уже это всё обсуждено, обмусолено. Лично я не нашёл никакой новой информации. Это был перевод ради перевода?
Тут главный вопрос — а сколько времени (в месяцах/годах) вы собираетесь это делать. Если пару дней, то точно дедики или даже aws. Если год-два, то скорее всего уже колокейшен чего купите.
Почему я до сих пор не запилили репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.
Я нигде не писал и не подразумевал публикацию прямо на гитхабе. Я имел в виду, что "гитлабо-/гитхабо-подобный сервис" это либо локальный (на своём сервере) отдельный гитлаб с доступом для участников, либо какое-то подобное решение.
Не, ну если тезисы переформулировать так, то я с ними уже почти согласен. Из статьи это не было видно. Единственное, что в части обмена правил не "блокчейн, не блокчейн, тут пофиг вообще, хоть по почте файлы рассылайте", а кажется, что правильнее и проще через какой-то гитлабо-/гитхабо-подобный сервис это лучше организовать: тут тебе и история с ветками, и процесс ревью с включением а апстрим, и дискуссии, и права пользователей.
Разница в производительности на выборках и джойнах ключа 8 байт (long) и 16-байтного binary настолько мала на общем фоне, что это точно можно не учитывать. Так-то посмотреть и строки в однобайтных кодировках меньше занимают. И binary collation быстрее. И тот же RCSI гораздо дороже для отдельных запросов, но его точно надо включать в MS SQL.
Распределённые базы попроектируйте. Как раз до этого момента многие в FK верят. :)
А много ли в мире учётных систем на микросервисах? Ну то есть не чтоб мелочёвка сбоку, а чтобы прямо главную книгу банка или что-то подобное на микросервисах?
В прошлой статье я защищал 1С, а в этой, ну, пусть из латентного нонконформизма, но налью таки бочку дёгтя.
1С сейчас в современном IT-ландшафте, как чемодан без ручки — нести тяжело, выбросить жалко. Для 2003-2004 года интеграция в IT-ландшафт была суперской, но, чёрт подери, ко мне того и гляди на собеседование придут люди рождённые в те годы. Что я под этим подразумеваю — ниже.
Слааабые возможности интеграции. Что у нас есть в 1С для общения с другими приложениями? Файлы, COM-объекты, внешние компоненты, HTTP-запросы, SMTP/POP3, ODBC-подобные соединения с СУБД, плюс ещё некоторая достаточно экзотическая мелочёвка. Причём всё вышепереписленное с кучей оговорок:
Кому кажется этого достаточно, тот застрял в 2005 году. А я хочу: HTTP/2, GraphQL, gRPC, сериализацию в Protobuf, удобную интеграцию с kafka, RabbitMQ, ActiveMQ (и прочими ZeroMQ, nanomsg), хочу подключаться к MongoDB, Cassandra, Hadoop, хочу использовать комфортно распространённые API (ну, например, файлы в S3 хранить), хочу использовать SSO и аутентифицировать сервис 1С без хранения креденшелов. Это только то, что сходу вспомнилось. На самом деле этот список каждый день прирастает.
Слабая интеграция в инфраструктуру современного IT. Да у 1С по сих пор даже работа с доменом AD и внешней аутентификацией всё ещё в детском состоянии! Максимум, что есть — указание, что Вася Пупкин может аутентифицироваться как PupkinVD@my.company. Нет корректной работы с группами, OU, блокированием/удалением, нет работы с корпоративным RBAC, нет альтернативных сервисов аутентификации (KeyCloack, например, или аутентификация в google том же). Интеграция с корпоративным мониторингом на ELC на уровне "принципиально возможна". То есть как бы её никто не запрещает делать, но там делать, прямо скажем, немало. Про успешную интеграцию в WAF и DLP просто не слышал. Интеграция с мессенджерами, телефонией и exchange — примитивна. Зато в 1С сканер ШК и фискальный регистратор почти всегда из коробки заводится, ну да.
Слабые интерфейсные возможности. Пока сценарий работы кнопкутык, кнопкутык, полевбил, контрол-энтер, то всё прекрасно. Шаг вправо-влево и "не шмогла". Кто не согласен — вперёд покажите мне прототип интерактивного редактора markdown (хотя бы только с жирным и наклонным шрифтом) или интерактивную работу с картой (и нет, вам не поможет
ГеографическаяСхема).О, кстати, про
ГеографическаяСхема. Отдельно упомяну "кладбище невзлетевших фич". Это целая гора фич, которые или просто оказались не нужны или были хреново сделаны или вышли не так и не тогда, когда нужно было.Просто списком с минимальными комментариями:
Ну а в разработке, как я уже отметил, всё плохо с модульностью решений и сложностью переиспользования технического кода. И по мне так БСП не пример того, как это "победили", а пример того, как это "проиграли".
Письменной гарантии от вендора нет. Но а) вендор один (в XLSX — несколько "совместимых"), б) если 1С не будет сильно стараться унифицировать печатный вид, то все печатные формы 1С: Бухгалтерии развалятся и для них это будет серьёзный фэйл.
Помогает делать макет 1 раз для всех конечных форматов. Да, есть ограничения. Но сам процесс достаточно удобен для всех целевых применений. Более того — часть процесса вёрстки формы можно отдать даже пользователю. Более того, в 1С мне очень удобно смотреть diff между макетами в системе контроля версий. В отличие от того же jasper (а уж как "прелестно" с SCM работать с каким-нибудь SSRS или SSAS — там вообще труба).
Если вы считаете, что эта "модель обычных reporting systems" лучше — да ради бога. Я у обеих сторон вижу гору недостатков и достоинств.
Ну… Где-то в мире розовых пони и танцующих единорогов оно так и есть. Реальность же сложнее и интереснее.
Вот есть прям классические отчёты и печатные формы. Счёт-фактура, 2НДФЛ, банковская выписка, отчёт биржевого брокера клиенту, отчёт агента принципалу. Сформировал, отправил, забыл. Со стороны клиента нет и, наверное, не может быть никакого дрилл-дауна.
Есть аналитики статистики, которые сидят в PowerBI, Tableau, QlikView или даже SAS (за психическое здоровье последних я уже не поручусь). Они сидят в башне из белого мрамора и пару раз в квартал/месяц/неделю снисходят к нам, глупым, неся свою мудрость (но мы-то знаем, что они ещё только учатся серьёзно обрабатывать данные на пятончике). Эти чуваки, конечно, без дрилл-дауна просто выпрыгнут с самого верхнего этажа башни, потому что это лучше и проще, чем BI без инструментов.
Но есть и промежуточные задачи. В рамках учётной системы оператор сделал накладную, смотрит — ой, а что это за строчка? Тыкает мышкой, проваливается в карточку товара или контрагента. А вот бухгалтер сформировал ОСВ по счёту — ой, что за странный дебетовый оборотик тут. Тыкает мышкой, листает проводки в карточке счёта. А вот завсклад, который тоже ткнул мышкой в отчёт и теперь-то понял, что за хрень с секцией №152. А вот и директор, который нахмурившись ткнул мышой в диаграмму на столбике и увидел детализированный отчёт по сложному проекту. И все они не могут себе позволить работать даже с QlikView (который как витрина достаточно прост), потому что в 1С это тык мышкой и 2 секунды, а просто найти нужные данные в QlikView или другой отчёт в 1С — это несколько минут.
Мы решаем бизнес-задачи и в них важны такие возможности. Да, в голой теории это можно разнести. А в практике простые возможности drill-down просто необходимы конечным пользователям.
Причём в джаспере дрилл-даун тоже относительно удачный для разработчика по сравнению с MS SSRS, или со старым Crystal Reports (современный лучше, но он стал SAP), или с, простите, FastReport. Я сам в нём делал такие отчёты, но после простоты 1С в данной теме мне это было некомфортно.
Кстати, мне лично сильно не хватает полноценного drill-down в дэшбордах и отчётах Jira и YouTrack. И я много раз видел и даже был участником, когда 1Сники за вечерок делали потрясные отчёты с расшифровкой по данным своих задач, загруженных из Jira.
Не надо так передёргивать. Если речь про "отчёты в табличном виде", то это некоторый вывод из программы, которые потом пользователем используются для просмотра, несложного анализа и печати. Графические файлы и PDF очень неудобны пользователю для "несложного анализа" (скопировать половину столбца чисел и сложить). HTML и XLSX плохи для печати (нет гарантии, что напечатается также). MXL плох потому что его не отдашь внешнему пользователю (у него может не быть 1С). Текстовый формат (а также csv, json, xml даже с xslt) проигрывает в возможностях оформления.
XLS/XLSX открывается внезапно совсем не одинаково и не всегда.
Важный плюс 1С в том, что из одного макета получаются приемлемые конечные формы большого количества форматов. У джаспера на словах это как бы почти так, но есть нюансы.
На практике за годы разработки, руководства и архитектуренья я вижу, что работа разработчика 1С с макетом и последующее сохранение в общеупотребимый формат в рамках этой задачи занимает в разы меньше времени при более стабильном и предсказуемом результате. И это если сравнивать с удачными платформами (типа Jasper), потому что в неудачных добавить новый формат это вообще отдельный проект.
Имеют. Табличный документ и его файловое представление MXL — это основной инструмент и одновременно выходной артефакт в 1С. И 1С-ник именно в нём делает форму отчёта. В других платформах обычно это бывает по-другому, там инструмент и выход разнятся (а если не разнятся, то это скорее всего отчёт, формируемый из шаблонного файла MS Office и это один из худших вариантов).
Плюсы в 1С не очень явные, они раскиданы по платформе и видны, когда видишь, как это делается в других платформах. В основном это НЕ фичи, а наоборот — отказ от фич. Несколько примеров.
Всё это лишь горстка примеров, когда ограничение функциональных возможностей или реализация с компромиссами оказывается важным архитектурным преимуществом в будущем. Даже компромиссный или не самый эффективный вариант — он уже есть в коробке и принимается как данность. Его самостоятельная реализация будет либо невозможной (потому что такие решения надо принимать в начале проекта, а там не до того, да и вообще архитектора нет), либо несколькими дорогими итерациями.
JasperReports отличный инструмент для отчётов. Но 1С-ной системе отчётов (инструменты работы с MXL, конструкторы, построитель, СКД) он скорее проигрывает. Проигрывает в простоте drill-down, сравнение табличных документов в 1С просто есть (джасперу оно не нужно, но когда нужно, то ХЗ что делать), когда нужно сделать странные шибанутые вещи, MXL позволяет. 1С тоже не лапочка, когда надо сделать готовый красивый отчёт-презентацию, но тут проще смотреть изначально на софт для презентаций.
1С-ный MXL, кстати, при определённой прямизне рук, позволяет без проблем работать с гигантскими MXL (миллионы строк). В Jasper я такие объёмы не пробовал, а вот Excel на этих объёмах просто ад.
lsfusion пока изрядно молодой, при всём уважении к ним, я пока не готов детально обсуждать.
XLSX выигрывает по одним фичам и проигрывает по другим. Выигрывает тем, что он не только формат отображения, но и формулы, умеет играть с источниками данных. Проигрывает, например, если есть строки с разной шириной колонок. Есть задачи, которые удобнее делать в XLSX, есть те, которые удобнее в MXL. Макеты печатных форм часто удобнее шлёпать в MXL.
Там кажется около 5000 часов гарантированных только было. А это всего около 200 дней.
Да, наверное. Я к тому времени уже не мог пользоваться 9x и жил в NT 4, с которой перешёл на 2К, поэтому Windows ME я увидел вживую пару раз на каких-то чужих компах.
Краткая история вопроса :)
Чтобы пользователи не запутались в версиях, Windows 4.0 выпустили, как Windows 95. потом вышла Windows 98, а так как они были очень совместимы, то чтобы не путаться их называли Windows 9x. Следующую версию назвали Windows ME. Наверное, чтобы в версиях не путаться. Чтобы победить проблему 2000 и новая версия не была меньше старой (пользователи же будут путаться!) следующая ОС стала Windows 2000 (хоть и выросла она из NT 4.0). И при всём при этом внутри нумерация версий была цифровой последовательной.
Тут пути серверов и пользовательских ОС немного разошлись (видимо энтерпрайз не выдержал борьбы за понятность версий:) ). В энтерпрайзе вышли 2003 и её R2, 2008 и её R2, 2012 и её R2, 2016 и 2019. При этом цифровая нумерация внутри почти выжила.
В пользовательском сегменте вышла XP и Vista. Vista, конечно, вышла, но лучше бы нет. Потому что следующего имени не придумали и решили перестать путать пользователей непонятными версиями и назвали "7". Выпустили 8 и 8.1, хотели уже выпустить 9, но тут выяснилось, что это приводит к путанице версий с Windows 9x! И чтобы путаницы не было, решили раз и (почти) навсегда выпустить Windows 10. Чем, кстати поломали нумерацию версий серверных ОС.
А чтобы как-то различать версии решили в релизе отмечать ГГММ в релизе. выпустили 10.0.1803, 10.0.1810, 10.0.1903. Но так как они все были Windows 10, то их стали называть по последним 4 цифрам. Чтобы не путаться в версиях, конечно же.
И! Внезапно! Приходит пора использовать 20 год и 03 месяц и возникает путаница в версиях! Windows 2003 уже была!
Глядя на качество последних «стабильных» обновлений винды, ставить что-то из «раннего» или «позднего» доступа выглядит слишком смелым ходом. И всё большее сомнение в необходимости получения стабилных обновлений не кажется параноей, если комп нужен для дела, а не только чтобы бесконечно разрешать MS добавлять и убавлять функционал ОС.
Как бы и да и нет. За пару лет (может больше) на раннем доступе у меня было несколько не очень удачных обновлений. Но а) если критичное и явное (например был поломан звук в firefox), то просто катишь обратно, б) если не критичное, то и ладно, в) если критичное и неявное, то у меня есть бэкапы. Больше достаёт частота обновлений и необходимость перезагрузок в принципе, чем сами изменения.
Но лично я готов быть подопытным кроликом, я могу быстро сориентироваться и продолжить работу. Зато на раннем доступе баги быстрее чинят, если находят критичные.
"Мы должны относиться к конфиденциальности как к праву человека. Мы должны иметь комплексную кибербезопасность, встроенную в технологию."
Это точно заявляет представитель компании Microsoft? :)
Как вы правильно отметили в начале статьи, на хабре уже это всё обсуждено, обмусолено. Лично я не нашёл никакой новой информации. Это был перевод ради перевода?
Тут главный вопрос — а сколько времени (в месяцах/годах) вы собираетесь это делать. Если пару дней, то точно дедики или даже aws. Если год-два, то скорее всего уже колокейшен чего купите.
Почему я до сих пор не запилили репозиторий с правилами на гитхабе — пресловутый STO, как бы это ни странно звучало.
Я нигде не писал и не подразумевал публикацию прямо на гитхабе. Я имел в виду, что "гитлабо-/гитхабо-подобный сервис" это либо локальный (на своём сервере) отдельный гитлаб с доступом для участников, либо какое-то подобное решение.
Не, ну если тезисы переформулировать так, то я с ними уже почти согласен. Из статьи это не было видно. Единственное, что в части обмена правил не "блокчейн, не блокчейн, тут пофиг вообще, хоть по почте файлы рассылайте", а кажется, что правильнее и проще через какой-то гитлабо-/гитхабо-подобный сервис это лучше организовать: тут тебе и история с ветками, и процесс ревью с включением а апстрим, и дискуссии, и права пользователей.