История давнишняя, но писать пост о ней не хотел - ибо думал, что ситуация в моем случае была причиной не технических, а больше организационных проблем МФЦ...

Но все-таки меня сподвигло совпадение следующих событий:

• пост в "Осторожно новости"

• аналогичная ситуация, произошедшая со мной (мне тоже заявили, что я вожу машину "находящуюся в угоне")

• скорое "долгожданное" появление мессенджера MAX

То, что мой случай не единственный, натолкнуло меня на мысль, что на самом деле проблема не чисто организационная, а и техническая в большей мере, чем мне казалось.

Суть (для тех, кто не переходит по ссылкам) в том, что в какой-то момент (либо в базе МФЦ, либо при интеграции/синхронизации) в качестве ключа уникальности для идентификации человека используется ФИО + дата рождения... и, как оказалось - "та-дам" - это сочетание отнюдь не уникально (хорошо еще, что у нас у большинства есть отчества).

В итоге при очередной синхронизации происходит перемешивание личных данных двух совпадающих людей. И все бы ничего - пока оба эти человека не имеют каких-либо проблем. Но вот если на одном из них появляются долги, не оплаченные кредиты, судебные дела и т.д. и т.п. - то страдают в итоге оба... А крайний случай - когда один из "двойников" умирает - и вся собственность, которая за ним числилась, меняет статус (в т.ч. машина снимается с регистрации, например).

Поначалу я думал, что проблема чисто организационная, т.к. при Сталине когда пользователей Госуслуг регистрировал Ростелеком, то идентификация шла строго по паспорту и СНИЛС... С приходом МФЦ появился вход по телефону и почте... И вот тут - еще до 2017 года, у меня начались приключения - когда сначала я не смогу зайти в свой личный кабинет, а потом в МФЦ мне показали, что есть 2 учетных записи - вторая не моя... но после ее заведения в моем личном кабинете как раз и пошла чехарда - в т.ч. пропали все документы, личные данные - кроме СНИЛС... Но новость показала, что проблема не про человеческий фактор.

Все это я к чему - близится 1 сентября 2025 года... нет, не только день знаний - но и день начала действия п.2 и 5 ФЗ 156 от 24.06.2025... И возникает вопрос - если, как заявлено, новый "многофункциональный сервис обмена информацией" будет интегрирован с ЕСИА - где гарантии, что теперь кроме штрафов, снятия с регистрации и прочих проблем у "двойников" еще и перемешается переписка в меcсенджере MAX (и здесь еще мы не поднимаем хайповый холливарный вопрос про архитектуру и качество защиты самого мессенджера) ?

Второй вопрос, который у меня возникает - что не так с архитектурой госуслуг, что уже почти 10 лет эта проблема лежит где-то в ядре, возможно в глубоком легаси, и до сих пор не заметно попыток исправить ситуацию ? В чем здесь причина: уровень компетенций специалистов, особенности смежных систем или еще что-то ? Не хочется давать повод господину Савельеву оказаться правым в его (на мой взгляд) заблуждении, что мощности современных компьютеров не хватает, чтобы учесть всех жителей РФ :-) У налоговой все чудно получается...

P.S.: в качестве развлечения давайте попробуем решить эту задачку проектирования (к слову, кмк, уровня курсовой ВУЗа по информационному моделированию). Что у нас однозначно определяет человека в реальном мире до того, как ему присвоили ИНН/СНИЛС и др ? Да, ФИО, дата рождения конечно помогают... но это действует только в рамках конкретной локации (т.е. вероятность совпадения в одном городе / роддоме очень мала). Т.е. достаточно было добавить в ключ уникальности место рождения (которое, к слову, у нас и в паспорте указывается, и в свидетельстве о рождении, и в СНИЛС и др.). Дальше можно, в т.ч. получить из этого надежный (не повторяющийся) ключ через одностороннее шифрование - если не хотим в открытом виде передавать составной ключ и в целом упростить процедуру сопоставления. И речь не столько про БД - информационное моделирование же оно в целом про хранение и обмен информацией.

P.P.S.: ну и "защита от..." сотрудника МФЦ тоже должна быть в ПО - чтобы не появлялись новые "дубли"

Неделю назад OpenGroup анонсировали публикацию черновика стандарта Archimate версии 3.3 (официально номер не обозначен - это мое предположение) для ознакомления с ним более широкой аудитории.

Я тоже скачал, полистал... Замечательно, когда есть раздел с кратким описанием отличий. Так вот, что же нас ждет:

• удалили связь композиции (composition) - теперь вместо него либо просто агрегация, либо специализация;

• удалили элемент "взаимодействие" (interaction) на всех уровнях, а также ограничение (constraint), разрыв (gap), контракт и представление (representation);

• элементы поведения на всех уровнях объединили в общие элементы "сервис", "процесс", "функция" и "событие";

• "событие" ("event") на слое implementation также заменено на общий элемент "событие";

• элемент "коллаборация" объединен для всех уровней (бизнес, приложения, технология);

• бизнес-роль стала просто "ролью";

• вместо представления фреймворка в виде аспектов и слоев теперь остался только шестиугольник Archimate;

• термин "слой" заменили на "домен";

• раздел по "Общей метамодели" заменили на главу 4, описывающую общие элементы (см. выше);

• путь ("Path") теперь входит в общий домен;

• вместо агрегации от пути к внутреннему активному структурному элементу теперь реализация от активного структурного элемента к пути;

• появилось визуальное отражение мощности связей (для отображения ограничений)

В качестве подходов для трансформации моделей из спецификации 3.2 в 3.3 предлагается выполнить замену (в т.ч. с использованием специализации соответствующего концепта):

• композицию - на агрегацию

• ограничения - на требование (requirement)

• контракт - на бизнес-объект

• разрыв (gap) - на оценку (assessment) или результата (deliverable)

• представление (representation) - на объект данных, артефакт или материал

• взаимодействия - на процессы и функции

• в целом элементы поведения с разных уровней - на универсальный аналог

• отмененные виды связей между конкретными типами элементов - на связь ассоциации

Если сравнивать с предыдущими версиями - они были менее революционными, и в основном добавляли что-то новое, дополняли. Грядущая же версия обещает чистку и унификацию - в т.ч. за счет активного применения введенного в предыдущих версиях понятия специализации для любого элемента / связи. По заверениям представителей OpenGroup это должно увеличить ясность и согласованность моделей, а также улучшить взаимопонимание при межкомандном взаимодействии.

На мой взгляд такое активное использование специализаций элементов алфавита языка Archimate с одновременным сокращением самого состава алфавита, с одной стороны повысит гибкость в подходах к моделированию, а с другой, после выработки этих подходов - потребует детализации соглашения по моделированию для конкретной организации/проекта/команды (т.е. насчет "лучшего взаимопонимания команд" я бы еще поспорил).

И еще один момент - переход на специализации по факту переводит от визуально заданного различия между элементами (либо цветом, либо формой) к необходимости вывода текстового уточнения, что сразу снижает наглядность и читаемость диаграмм (крайний случай - полный отказ от визуальной разницы и переход на нотацию "квадратики и стрелочки" - после чего, обычно, начинается обратный процесс визуального разделения "стикеров" по цветам и стрелочек по типам линий и окончаний, а потом и придумывание специальных графических обозначений).

P.S.: в Acknowledgements изменений нет - моя фамилия единственная русская :-)

Натолкнулся на рекламу в телеге...

Да... скоро уже не нужно будет знать как выбрать выдержку, диафрагму, поставить свет, взаимодействовать с моделью... Надо будет просто знать как правильно формировать промпт, чтобы было ровно 5 пальцев и одна голова

Хочу поделиться итогами последней моей переписки с ребятами из OpenGroup по поводу особенностей применения стандарта Archimate 3.2 для описания микросервисной архитектуры с использованием Docker.

Как оказалось, паттерн, который был предложен 4 года назад с применением элементов Node для моделирования docker-контейнеров после выхода версии стандарта 3.2 стал неактуален - поскольку Node потерял большинство типов связей, которые были для него допустимыми по отношению к Artifact.
Спросите, почему этот вопрос встал только сейчас ? Потому что полностью стандарт 3.2 был поддержан в редакторе Archi относительно недавно... плюс как раз появилась необходимость в актуализации старых схем технологического слоя - и тут-то и выяснилось, что больше нельзя показать, что docker-контейнер (Node) реализуется посредством docker-образа (Artifact).

Резюмируя итоги обсуждения с коллегами из OpenGroup:

• рекомендуется использовать для моделирования докер-контейнеров элемент Системное ПО (System Software), для которого по прежнему доступно установление связи Реализации от докер-образа (Artifact)

• элемент Node остается как элемент для моделирования некоей условной совокупности программно-аппаратных средств (включая физические, "не-ИТ" объекты - т.е. станки и др) - цитирую Jean-Baptiste Sarrodie: "используем Node, чтобы показать что именно будет размещать или предоставлять сервисы, не обращая внимания на то как эта функция будет реализована (приложение, сервер, контейнер и т.д.)". Иначе говоря Node остается некоей логической структурой, объединяющей физические элементы (System Software, Device и др.).

• элемент Device рекомендуется применять для моделирования не только физических, но и виртуальных машин (до этого были варианты использовать для "виртуалок" элемент Node) - но возможно в новой версии Archimate что-то уточнится

P.S.: почти месяц назад, 25 января, вышла версия Archi 5.5 - за это время удалось пощупать, и могу сказать, что обновляться стоит.

Из ощутимых улучшений:

• возможность удалять на схеме элементы-контейнеры (стиль nested - когда элементы помещаются друг в друга) без удаления вложенных элементов (команда "Delete from view (keep children)" )

• инструменты для фильтрации дерева (регулярные выражения, фиксация папок верхнего уровня, учет регистра текста, вовлечение пользовательских свойств элементов и видов) и навигации по нему (вкл/выкл режима синхронизации выбранного в схеме элемента с деревом)

О сколько нам открытий чудных... открытые источники готовят.

И вот очередное подтверждение - глянув на статистику по времени, которое проходит от момента подачи заявки в ФИПС до момента регистрации ПО для ЭВМ можно много чего для себя почерпнуть..

Например, вот в раскладке по годам видно, что с 2020 года достигнут рекорд по скорости - минимальная длительность обработки заявки составила 0 дней.
А вот в 2015-м году была обработана самая долгая заявка - 624 дня (правда календарных, не рабочих) - желающие могут убедиться на сайте найдя заявку №2015619410.

Есть еще много чего, что можно вытянуть еще - жаль, что этой статистики не видно на сайте ФИПС... надеюсь хотя бы внутри эта аналитика проводится.

Ну, а если сообществу интересно более подробно - напишите в комментах - подготовлю развернуто в виде статейки ;-)

Уж сколько раз убеждался, что ФИПС при регистрации по факту ничего не проверяет и не правит в данных от заявителя... но чтобы настолько можно было нагло проталкивать чужое ПО как свое, пользуясь ленностью ФИПСа...

Федоров Максим Владимирович - если ты это читаешь - покайся! :)

Если Jean-Philippe Lang не просматривает реестры ФИПС - это не значит, что можно так безоглядно использовать его интеллектуальную собственность.

P.S.: очень хочется узнать, как удалось уместить программу в 10КБ :))

Печальный день для пользователей соцсети Drooble...
Я конечно понимаю, что большинству в нашей стране это название ни о чем не скажет, но за рубежом и, особенно, в США эта социальная сеть была достаточно популярна на протяжении многих лет.

Основатель сети Мелина Крумова (https://www.linkedin.com/in/melinakrumova) - музыкантша из Болгарии, которая перебралась в США.

Идея соцсети, за которую ее любили пользователи - создать сообщество взаимоуважения и взаимопомощи для музыкантов, где бы могли свободно общаться "джуниоры", "мидлы" и "сеньоры" музыкальной индустрии, делиться опытом. Лозунг гласил - "вместо дизнайка напиши, что не так".

В отличие от того же SoundCloud модель монетизации была основана на покупке дополнительных услуг продвижения, цифровой обработки записей (мастеринга) и т.п.
При этом часть услуг можно было купить и за внутреннюю валюту ("Карму") - которую можно было либо заработать (комментариями, обзорами на песни, прослушиванием музыки), либо обменять на доллары.

На платформе была разная музыка - и низкого уровня, и бриллианты, которые можно было найти только там...

После того, как в 2022 году Мелина отказалась от дальнейшего сопровождения системы по экономическим причинам - полет продолжался какое-то время в свободном падении... потом появились новые владельцы, которые до последнего пытались как-то реанимировать пациента - но в итоге объявили об официальном закрытии 01.10.24.

Последнюю неделю в ленту люди присылали слова благодарности и прощались.

RIP Drooble.

Дал последний шанс Evernote...
Почему - потому что найти решение куда перескочить - не удалось, а к кнопке веб-клиппера я уже привык на уровне подкорки за эти ... да лет за 10 точно.

В общем потихоньку все равно продолжал клипить заметки. При этом я даже удалил (как писал недавно) толстого клиента и пользовался только веб-клиентом и веб-клиентом.

И какое же было мое изумление сегодня, когда я зашел в веб-клиент, и меня жестко обломали - мол выбирай, какое устройство использовать... Оказалось, что если раньше бесплатно можно было использовать веб и какое-то приложение, то сейчас или веб, или приложение... И это я еще не проверял, что мне заявит эвернот на смартфоне...

В итоге - я для себя принял решение экспортировать заметки из проги в локальный файл(ы) enex и искать замену - а с Evernote прощаться.

В толстом клиенте ждал сюрприз - теперь экспортировать можно только каждый блокнот отдельно. Оно и к лучшему - буду методично выгружать и удалять заметки - что собственно и начал делать.

Ну и по ходу поймал ряд глюков и дырок:

• при удалении блокнот пропадает, но окно висит, приходится отменять и выходит ошибка удаления;

• ребята ввели ограничение на кол-во заметок в месяц (50), но из клипера их можно продолжать клепать;

• в целом клиент висит и жрет ресурсы бессовестно (особливо при открытии).

В общем кризис Evernote продолжается, халява кончается... и даже платить нет смысла - потому что падает качество программы и сервиса. В общем все по тренду рилсов - "bye bye bye".

юбиквотус...

Коллеги, я понимаю прекрасно ценность английских терминов за их краткость... особенно не только когда слово просто короче, а когда оно заменяет целое сложное словосочетание или определение...

И, да, Эрик Эванс крутой чувак...
Но он не придумал с точки зрения английского языка ничего нового - Ubiquitous - это всего-лишь "вездесущий" (*с одной С:)), или, если переводить ближе к изначальному замыслу в контексте его подхода - то "всеобщий" (т.е. применимый везде, понятный всем - существующий в сознании всех участников проекта)...

От того, что на конференциях/вебинарах/на работе вместо "всеобщий язык" (ну, ладно - пусть даже "вездесущий язык") люди гордо говорят "юбикуитос лэнгуидж" (а на одном вебинаре - как в сказано в начале поста - "юбиквотус") становится только хуже, потому что:

• люди, которые не в теме и так сложной темы DDD, начинают "подвисать", их мозг пытается на ходу перевести это на привычные понятия... а говорящий продолжает бежать дальше, причем, зачастую, гордо думая, что он заставил окружающих загрузить мозг сложной информацией

• говорящий часто сам до конца (до глубины) не понимает, о чем речь, он не чувствует термин

А ведь у Эванса речь идет о простых вещах, что сначала нужно договориться об общих и понятиях.
И как здесь не вспомнить Эриха Фромма, который высказывал мысль, что современная наука настолько специализировалась по областям, что они перестали понимать друг друга и создание какой-либо общей теории затруднительно.

P.S.: на картинке UL как его понял ИИ

Дьявол — падший ангел. А ангелы — бесплодны (т. е. не могут сотворить чего‑то нового). Поэтому, по одной из версий, у Булгакова в «Мастере и Маргарите» Воланду нужен был Мастер, чтобы написать «Евангелие от Сатаны» — нужен был человек, потому что людям Бог дал возможность творить.

Искусственный интеллект в наши дни не может сотворить нового — он только комбинирует то, что было создано человеком, создавая причудливые сочетания из многократно повторяемых образов, мыслей, звуков...
Получается ИИ — это наш рукотворный дьявол? ...

P. S.: дальше каждый продолжает сам... Особенно я думаю Никита Сергеевич М. оценит аллегорию:)

P.P. S.: и да — картинка сгенернирована ИИ (Playground AI), но выбирал вариант человек.

В продолжение моего поста от 20.12.2023... Да, я до сих пор пытался продолжать пользоваться Evernote... Но сегодня понял, что:

• моя десктоп‑версия не синхронизируется уже как минимум месяц(!) — из‑за какой‑то ошибки синхронизации, которую даже не понятно где смотреть (просто восклицательный знак на кнопке синхронизации)

• меня достало постоянное напоминание каждый день об очередном обновлении (и ладно бы хотя бы ушла ошибка синхронизации — нет, обновляется каждый день. а что‑то полезное не появляется)

• из всего Evernote я по факту пользуюсь WebClipper, потому что из‑за ошибок синхронизации и тормознутости десктопный клиент почти бесполезен (особенно, когда что‑то нужно найти)

• оказалось, что и веб‑клиент Evernote теперь жутко тормозит даже просто чтобы вывести список заметок

Ну и понял, что уже все совсем созрело для перехода на Obsidian...
И что же ? Перейти можно сейчас только через десктоп-версию (потому что загрузить в Obsidian можно через enex-файл, а он выгружается только из десктопа Evernote). Т.е. новые заметки, созданные за последний месяц, нужно переносить "ручками".

В общем ладно - запустил я выгрузку из десктоп-версии в enex... и думаю - проверю, а место у меня хватит ? Иду в папку с данными evernote, и вижу, что она занимает 20ГБ (думаю - ничего так я за 10+ лет насобирал)... потом погружаюсь внутрь и понимаю, что сама база занимает ~5ГБ, а остальные ~14ГБ - это папка с копиями установочных пакетов (см. скрин ниже)... В общем адьос Evernote - десктоп удаляю!

Всем здравствуйте!

Уже давно стали мемами 6-типальцевые, многорукие и многоногие люди и прочие результаты генерации картинок с помощью ИИ.

Тем занятнее для меня было отметить, что не так давно один из сервисов генерации картинок на ИИ - https://playground.com/ - стал автоматически подставлять в разделе настроек для описания исключений следующий набор:

"ugly, deformed, noisy, blurry, distorted, out of focus, bad anatomy, extra limbs, poorly drawn face, poorly drawn hands, missing fingers, high contrast, over saturated, glossy, cartoon, 3d, 3d render, Photoshop, sketch, sketches, video game, draw, paint, painting, render, cgi, computer graphics, anime, manga, 2d art, 3d art, illustration, canvas frame, watermark, signature, username, artist name"

P.S.:

Этот ляп в последнем обновлении Evernote сегодня "сделал мой день"...

Программа долго что-то делала после обновления, как обычно обещая, что "осталось 2 минуты"

Через полчаса мне надоело ждать - нажал "крестик"... И вид окна мгновенно изменился:

собственно дальше программа продолжила "висеть", но уже обещая, что "закроется" через "1 минуту 15 секунд".

К ее чести можно сказать, что в итоге она все-таки завершила прерывание за примерно 10 минут :-)

01.11.2023 к радости любителей бесплатных опенсурс-решений для ведения архитектурных репозиториев вышла новая версия Archi от OpenGroup (а точнее в основном от активных альтруистов - Phil Beauvoir и Jean-Baptiste Sarrodie).

Список изменений версии 5.2 не такой и большой, но уже удалось потестировать и хочу выделить те из них, которые заслуживают внимания и, в общем-то, ожидались давно:

• возможность задания значения пользовательских свойств сразу для нескольких выбранных фигур (если значения свойств отличаются у выбранных фигур, то оно будет заменено соответствующим текстом);

• возможность более гибко задавать визуальное отображение линий/контуров - задавать толщину (правда из фиксированных качественных вариантов - "нормальный", "средний", "толстый") и задавать наследование цвета линий от цвета фигуры не глобально, а для каждого элемента на схеме - оба эти нововведения позволят лучше обходить скупую выразительность исходного языка Archimate;

• теперь в выражениях меток (Label Expressions) можно использовать ссылку на свойства связи и связанных элементов даже если они отсутствуют на схеме;

• при экспорте в HTML теперь появилась вкладка "Анализ" ("Analysis") как и в Desktop-приложении, что намного упростит навигацию через выбор элементов непосредственно на схеме (HTML-выгрузка - хороший вариант для предоставления доступа к архитектурному репозиторию широкому кругу специалистов для ознакомления в режиме чтения).

  Ну еще интригующее и загадочное "Add support for future coArchi 2"...