Что-то в этом есть😅

#юмор #жиза

👀 Видишь легаси? Нет. И я не вижу, но он есть.

Все, наверное, много раз слышали (а кто-то даже и участвовал) в различных инициативах в нашей стране по отказу от легаси, вендорозамещению и пр. Так вот, я озадачился вопросом, где и как в мире применяются устаревшие технологии. Беглый поиск информации в интернет привёл к интересным фактам. Для удобства я их сгруппировал по категориям.

📟 Средства связи. В Японии до сих пор пользуются факсами. Заметьте, в стране, которую многие ассоциируют с качественными автомобилями, роботами и другими передовыми разработками. Но, как говорится, не факсами едиными. Британские врачи всё ещё активно пользуются пейджерами, словно герои из "Доктора Хауса" или "Скорой помощи".

💾 Носители информации. Для создания резервных копий данных в мире по традиции используется магнитная лента. И буквально на днях выходила новость, что одна компания обнаружила, что их регулярно записываемые бэкапы годами не проверялись на возможность восстановления. Хорошо, обошлось без жертв. Ну а как насчёт типов видов носителей? А вот так. Метрополитен Сан-Франциско до сих пор использует дискеты в своей системе управления поездами, а отказываться от них планируется только в середине 2030-х. Удивляет? Меня точно удивляет. Но ещё больше удивляет то, что, как оказалось, на немецких фрегатах типа "Бранденбург", предназначенных для обнаружения и борьбы с подводными лодками противника, до сих пор используются 8-дюймовые дискеты. Ещё раз: не 3.5" и даже не 5.25", а 8"!

💻 Программное обеспечение. Легаси-системы довольно широко используются в промышленности. На своей первой работе, кстати, я удивлялся устойчивой практике использования языка C (именно "Си", никаких "плюсов") для реализации HMI-систем, работающих под Windows XP. И, судя по прочитанному на просторах всемирной паутины, ситуация за минувшие годы кардинально не изменилась.

👨‍💻 Языки программирования. Наверняка многие слышали, что язык Fortran до сих пор имеет широкое прикладное применение в задачах, связанных с математическими расчётами и наукой. Но, выяснилось, что "старичок" COBOL тоже в строю. Именно на нём на Западе написана куча систем в сфере финансов. Приложения, обрабатывающие транзакции, операции по счетам и ведущие расчёты доходности сложных финансовых инструментов – это всё историческая "вотчина" языка COBOL.

Если у вас есть что добавить по теме, обязательно делитесь в комментариях 👇

#любопытное #программирование #быловремя

Сегодня мир отмечает необычный праздник — День числа "пи". Это событие посвящено одной из самых известных математических констант — числу π, которое приблизительно равно 3.14 (поэтому и 14-е марта).

А раз так, то желаю всем успешно доπлить свои постановки задач, доπнать все выявленные баги и поскорей встретить окончание рабочей недели с любимым наπтком.

Сегодня открыл для себя "съедобные" названия элементов UI для разных типов меню. Гамбургер, дёнер, бенто, кебаб и фрикадельки — ну что может быть лучше? 😋

#uxui #любопытное #термины

Разбирая диаграммы последовательности, время от времени наблюдаю 3 повторяющиеся паттерна странного использования фреймов (фрагментов). Вот они.

1️⃣ Фрейм alt используется для опциональных условий. Это довольно частая ситуация. Возможно, авторы не знают или не понимают, зачем использовать opt, когда есть alt.

2️⃣ Во фрейме alt первая секция полностью пропускается. PlantUML, конечно, позволяет выполнить этот фокус, но вот зачем? Возможно, так хотят добиться выравнивания по левому краю всех проверяемых условий?

3️⃣ Вообще не используется break. Вместо этого может использоваться opt или alt. Авторы, видимо, полагают, что если довести стрелку до пользователя, то сценарий закончится.

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

#визуализация #plantuml #кейсы

📋 Подводные камни YAML

YAML уже давно и прочно вошёл в разработческий быт: многие конфигурационные файлы создаются именно в этом формате. Это в полной мере актуально и для нашей команды, однако несколько месяцев назад мы столкнулись с неожиданным поведением приложения, что потребовало отладки.

Ситуацию быстро локализовали, а результат вскрыл факт того, что YAML не так уж и прозрачен. Полученный тогда опыт и другие неочевидности, собранные из открытых источников, я попробовал собрать в кучу. Надеюсь, будет полезно. А вот и сама "куча" 🤭: https://telegra.ph/Pitfalls-of-YAML-03-27.

Кстати, я ранее делал пост со сравнением ряда текстовых форматов. Там YAML тоже есть, так что рекомендую.

#форматы #статьи #гайды

В этом году, насколько я могу судить, искусственный интеллект переживает очередную волну интереса. И если раньше всё крутилось вокруг ML, то в последнее время всё чаще в фокусе находятся AI-агенты.

В свете этого хочу поделиться вышедшим в этом году документом (в оригинале — whitepaper) от компании Google. Это достаточно понятное чтиво, которое позволит понять идею и принципы, на которых строятся AI-агенты.

Ссылка: здесь, ссылка для скачивания: здесь.

Для удобства в первом комментарии к данному посту 👇 размещу переведённую на русский язык версию. В целом неплохо, но в примерах на Python есть ляпы (может, ИИ переводил?👀), так что по необходимости рекомендую обращаться к оригиналу.

#книги #ai

Прочитал в одном профильном ТГ-канале новость о создании обширного глоссария для системных аналитиков с призывом пользоваться. Подумал, что это, наверное, неплохо. Да, с одной стороны, есть глоссарий в конце BABOK, но, быть может, у ребят больше уклон на технику?

И вот добрался я до оного (ссылка). Первое, что насторожило, это изображённый робот. Почему? Но этот вопрос стал проясняться, когда я при беглом пролистывании увидел термины: "дым-тест" 🚬, "загрузка баланса" 💰, "релиз-ноты" ♪♬. А чего только стоит красивое русское слово "рефайнмент"! В общем, рука-лицо…

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

Остаётся только вопрос: неужели нельзя было "причесать" созданный нейронкой текст? 🤷‍♂️ Даже если предположить, что это не нейронка, а условный гугл-переводчик, то от этого не легче.

📣 CodeFest 15 в Новосибирске

Друзья, спешу с новостью. Как вы, наверное, знаете, 31 мая – 1 июня в Новосибирске пройдёт 15-й по счёту CodeFest. А вот и сама новость: программа секции по системному анализу свёрстана. Поэтому, если кто-то ждал определённости, чтобы решить, идти ли на конференцию, то вот она 👉 https://15.codefest.ru/program/sa

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

#события #выступления #анонсы #codefestru

Читая на одном из ресурсов (не буду говорить где) объяснение, зачем нужны очереди и брокеры сообщений, поймал себя на мысли, что автор не оговаривает различий между очередями и топиками. Всё подаётся в куче в контексте событийного взаимодействия. И это натолкнуло на мысль написать данный пост. Поехали!

Очередь (queue) и топик (topic, она же "тема") — это различные подходы к организации взаимодействия между системами.

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

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

📌 Что ещё стоит отметить.

👉 Во-первых, очереди обеспечивают обработку входящих сообщений по принципу FIFO ("первый пришёл — первый вышел"). Топики же обеспечивают подобное упорядочение только в границах разделов (партиций, partitions), из-за чего соответствие FIFO можно считать условным.

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

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

#интеграции #архитектура #термины

😲 Как не ошибиться в своём имени

Заполняя форму на сайте СФР (это то, что многие по привычке называют пенсионным фондом), столкнулся с ошибкой валидации. Ошибка гласила, что фамилия не соответствует данным СНИЛС. Я перепроверил, всё было правильно.

Но тут вспомнился случай, который произошёл несколькими месяцами ранее на Госуслугах. Тогда не принималась буква "Ё" (сообщение гласило, что используется недопустимый символ) и я посчитал, что это из-за того, что они не учли эту букву у себя при валидации. Тогда я обращался в их техподдержку и анализ привёл к неожиданным результатам.

Суть. Если в вашем ФИО есть буква "Ё", то сложность может возникнуть при заполнении данных с этой буквой. Проблема не в самой букве, а в том, что некоторые производители виртуальных клавиатур для мобильных телефонов не вывели кириллическую букву "Ё" на эту самую клавиатуру. Как же так, спросите вы, ведь при зажатии клавиши с буквой "Е" всплывает вариант с "Ё". Вот тут и кроется проблема.

То, что на некоторых клавиатурах визуально выглядит как русская "Ё", на самом деле является латинской буквой "E с умляутом" (другое название — "E с диерезисом", подробнее). То есть ситуация такая же, как с кириллической "Е" и латинской "E". Побочный эффект: коды этих двух символов различаются и проверка не проходит.

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

#любопытное

📖 "Создание событийно-управляемых микросервисов" Адама Беллемара

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

💡 Содержание. Данная работа описывает создание распределённых систем сквозь призму потоков данных. И если под микросервисами обычно подразумевают отдельные небольшие приложения, общающиеся по сети (как правило, это REST), то здесь автор излагает концепцию и соответствующие паттерны событийно-управляемых архитектур (Event-Driven Architecture, EDA). Всё вращается, скорее, вокруг данных и операций над ними, нежели вокруг функциональности.

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

💡 Минусы. Здесь вынужден остановиться подробнее, чтобы ненароком не создать рекламу. Вот они.

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

👉 Слог. Очень тяжко читать длинные предложения типа "масло масленое" с кучей некритичных для понимания слов. Пример (а их много!): "При этом команды могут чрезмерно полагаться на платформу коннекторов для получения и приёма данных и отказаться от рефакторинга своих приложений в собственные приложения, управляемые событиями". Почему "получение" и "приëм" отделены, почему тут хочется отрефакторить (не переделать, не трансформировать) код в своë (а раньше чужое было?) приложение? Или вот: "Все совместно используемые данные публикуются в наборе потоков событий, образуя непрерывный поток..." Так поток или набор потоков — вопрос. Или вот ещё: "...процесс производства нового потока событий..." Звучит как что-то из области тяжёлого машиностроения.

👉 Перевод. Ну, камон, зачем писать вещи типа "масштабное управление микросервисами", когда речь не о масштабах, а масштабировании? Или зачем терзать читателя пассажами вроде такого: "Потребители данных используют ссылку на индексный ID для доступа к данным"? В этом случае, видимо, на масло масленое от косноязычного автора наслоился неудачный перевод. Также часто по тексту видна калька с английского вроде "производство в поток" или "нижестоящий потребитель". А то, что "перезагрузка темы" означает, перечитать топик брокера сообщений с начала, я лично долго не мог понять.

👉 Непоследовательность. К примеру, на странице 100 слово "отфильтровать" предполагает неуспешность проверки и отбрасывание некоторых данных, а уже на следующей странице "фильтр" это про то, что "соответствует необходимым критериям". Для тех же, кто дочитает до 189 страницы, увидит, что фильтрация это что-то вроде сходящегося шлюза или конъюнкции нескольких условий, синхронизирующих параллельные потоки...

Другой пример: на одной странице в рассуждениях используется поле updated_at, а на соседней (при схожих обстоятельствах) — уже updated-at. К слову, опечатки в книге тоже есть.

💡 Резюме. Если вы уже глубоко в теме, то, возможно, эту книгу есть смысл прочитать, чтоб поразмышлять о разных аспектах и неочевидных решениях (хотя туманные формулировки снизят радость знания). Однако ж если вы только планируете погружаться в проблематику событийно-управляемых архитектур и пока слабо представляете себе, что такое брокеры и при чём тут Кафка, то эта книга точно не для вас. Она очень тяжёлая, причиняет много боли и страданий, приходится постоянно возвращаться, перечитывать. В общем, рекомендовать эту книгу к обязательному прочтению не могу.

#книги #архитектура #интеграции

Немного актуального 😆

#ai #юмор #жиза

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

В зависимости от контекста смыслы вкладываются самые разные. И я для себя уложил их вот в такую картину.

#архитектура #майндмап

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

📜 Microsoft в феврале объявила о прорыве в области квантовых технологий, представив чип Majorana 1. Как сообщалось в различных медиа, в основе технологии находятся майорановские фермионы, предсказанные в 1934 г., однако ряд учёных выразил скепсис и возмущение из-за обнаруженных нестыковок в официальной информации. В общем, будем наблюдать.
Подробнее: здесь и здесь.

📜 Протокол авторизации OAuth 2.0 (Open Authorization 2.0) официально стал стандартом RFC. Несмотря на то, что в силу уже сложившейся практики применения данного протокола это мало что меняет, сам этот факт можно считать шагом в сторону унификации.
Подробнее: здесь.

📜 Компания из России создала фотолитограф с разрешением 350 нанометров, сообщается в телеграм-канале мэра Москвы Сергея Собянина. Это первая ласточка, которая в перспективе может позволить создавать в нашей стране собственную микроэлектронику.
Подробнее: здесь.

📜 В Китае запущено массовое производство атомных батареек размером 15х15х5 мм. Данный элемент питания должен прослужить 50 лет. Источником энергии выступает не встречающийся в природе изотоп никель-63, продуктом полураспада которого является нерадиоактивная медь-63, что серьёзно упрощает дальнейшую утилизацию батареек. Но не только КНР смотрит в этом направлении. Буквально 2 дня назад стало известно о разработке из Южной Кореи на базе безопасного углерода-14.
Подробнее: здесь и здесь.

📜 Японская компания Kawasaki анонсировала разработку робо-коня Corleo, на котором можно ездить. Под капотом этого внедорожного "скакуна" водородный двигатель и искусственный интеллект, позволяющий анализировать препятствия и балансировать положение в пространстве. Интересно, при появлении этой разработки на рынке нужно ли будет открывать новую категорию прав?
Подробнее: здесь.

📜 Учёные предложили способ терраформирования Марса. В основе идеи лежит использование наночастиц графена и алюминия, способных нагреть атмосферу красной планеты, что в конечном счёте должно привести к возможности жизни. Не уверен, что это случится в ближайшие годы, но идея колонизации Марса, судя по всему, по-прежнему занимает умы исследователей.
Подробнее: здесь.

📜 Выяснилось, что компания OpenAI, разработавшая ChatGPT, добавила в тексты, генерируемые их моделями, своего рода водяные знаки. Предположение состоит в том, что это сделано намеренно с целью маркировки происхождения текстового контента. Однако реализация вышла спорной, её довольно быстро обнаружили и буквально каждый может эти водяные знаки стереть.
Подробнее: здесь.

#дайджест #4ir #ai #технологии

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

На текущий момент я сформулировал следующие контринтуитивные факты, осложняющие этот процесс.

🤭 Авторы документации не всегда знают, как работает их система
С учётом того, что практика водопадной разработки становится редкостью, а сложность ПО растёт, многие принятые решения могут остаться "в головах" аналитика и других членов команды (даже если они изначально планировали подразгести завалы и описать позднее). Более того, пройдёт время и детали забудутся. Печальное следствие: уточнение вопросов по документации может увести вас по ложному пути и утвердить в ошибочном знании.

📚 Большой объём документации это не всегда хорошо
Исходя из моего опыта, неточностями часто страдает именно самые хорошо задокументированные системы. Возможной причиной может быть то, что такая документация ориентирована в большей степени на внутреннего потребителя и оттого в ней упущено общее, а сразу идут частности. Собрать целостную картину из массивного описания деталей стороннему наблюдателю становится сложно.

Другая причина. Почти всегда новая версия документации разрабатывается на основе предыдущей, и автором не во всех местах могут быть качественно внесены правки (не актуализировано название поля, приложенный макет экранной формы отражает промежуточное видение, JSON с примером обновлён, а пояснение к нему — нет и т.п.)

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

🤯 Документация разработчиков сервиса может не быть полной для потребителя
Казалось бы, этот пункт противоречит ранее сказанному. Но нет. Разные производственные цели у 2-х смежных команд (даже если речь идёт о командах поставщика и потребителя одного и того же сервиса) могут приводить к появлению моделей, не подходящих для смежников. Например, если для полноценной работы с сервисом потребителю дополнительно требуется выстроить взаимодействие с третьей стороной, то этот факт может быть упущен во внутренней документации поставщика сервиса (подобный пример я разбирал в видео).

⚡ Покорение новых вершин

Спешу поделиться новостями. Я стал серебряным призёром премии ECDMA Global Awards 2025 в номинации Outstanding Achievement in Technology Innovation! 🏆

Заявку на участие подавал несколько месяцев назад. Шло время, я уже стал уже про неё забывать. И вот, наконец, члены жюри завершили свою работу — и я в числе победителей!

#события #достижения

Друзья, кто-то понимает, что происходит с рынком труда?

Ещё совсем недавно телеграм-каналы пестрили курсами для желающих войти в АйТи, а буквально за минувшие 2 дня я натолкнулся на 2 поста о поиске работы с формулировками о том, что ничего не предвещало беды.

Автора одного из таких постов даже знаю лично. Буквально несколько месяцев назад он радовался карьерному росту, а тут — бац! — и сократили его вместе с его командой. 🤔

Читаю "Мифический человеко-месяц" Брукса и хотелось бы поделиться выдержкой из конца главы 16. Уж больно она мне понравилась.

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

Поэтому наиболее важной функцией, которую создатели программного обеспечения выполняют для своих клиентов, является итеративное извлечение и уточнение требований к продукту. По правде говоря, клиенты сами не знают, чего хотят…

#требования #стейкхолдеры

UR🙃, или разбираемся с URL, URI и URN

На днях в очередной раз запнулся о термин URI и решил наконец разобраться в вопросе. Обратился к определениям.

📌 URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Это общий термин, охватывающий два типа идентификаторов ресурсов: URL и URN. URI служит для уникальной идентификации любого ресурса независимо от способа его нахождения или адресации.

📌 URL (Uniform Resource Locator) — адрес конкретного местоположения ресурса в сети Интернет. URL определяет конкретный путь к ресурсу, включая протокол передачи данных, доменное имя сервера и путь к файлу/странице.

📌 URN (Uniform Resource Name) — уникальное название ресурса, которое не зависит от физического расположения ресурса. Оно используется для постоянного именования объектов вне зависимости от их текущего местонахождения в Интернете.

Определения прекрасные, но, поскольку лично у меня всё равно вопросы остались, решил углубиться и порассуждать. И вот к чему я пришёл.

💡 URL предназначен для точного указания физического местоположения ресурса в сети. URL указывает на ресурс, ключевое — это "где" (место, адрес). Если ресурс перемещён, доступ к нему прекращается (получаем "битую" ссылку) и нужен новый URL.

Примеры: путь к файлу (file://C:/Users/boss/Downloads/pic.png), адрес в интернет (https://t.iss.one/humane_analyst/222), электронная почта (mailto:[email protected]) и т.д.

💡 URN служит для однозначного определения ресурса независимо от его текущего физического размещения. URN называет объект, ключевое — это "что" (идентификатор, имя). Если ресурс перемещён, его глобальная идентификация остаётся неизменной.

Примеры: UUID, пространства имён (xmlns="https://www.w3.org/1999/xhtml", Namespace="https://www.contoso.com/" и т.п.), постоянные идентификаторы изданий и публикаций (ISBN, ISSN, DOI) и т.д.

💡 Следствие из ранее озвученного: один и тот же идентификатор не может удовлетворять требованиям URL и URN, то есть не может быть способом доступа и идентификатором ресурса одновременно. В этой связи пространство имён при всей его внешней схожести с URL (см. выше) таковым не является, это исключительно URN.

💡 Фундаментально разные цели URL и URN приводят к тому, что с позиции объектно-ориентированной парадигмы URI является родительским классом для классов URL и URN. URL и URN, соответственно, — это дочерние классы (подтипы) для URI. А поскольку примеры URL и URN существуют (см. выше), то URL и URN — это конкретные классы.

💡 URI не сводится к паре URL и URN, есть и другие URI.

Пример 1. Data URI используется для встраивания небольших файлов непосредственно в тело веб-документа. Data URI уникально не идентифицирует ни положение, ни внедряемый файл. Соответственно, Data URI не является URL и не является URN. Вместе с тем ограниченная специализация Data URI и его общность с URI позволяют считать Data URI экземпляром (объектом) класса URI.

Пример 2. Номер телефона в соответствии со спецификацией RFC 3966 (tel:+79211234567) является только URI. Номер телефона не является URL, так как не содержит компонентов для идентификации ресурса в Интернет, и номер телефона не является URN, поскольку URN только называет ресурс, но не говорит, как к нему добраться (а номер телефона позволяет понять, как можно провзаимодействовать с ресурсом и предложить совершить звонок).

Следствие: URI — не просто базовый класс, как говорилось выше, но ещё и конкретный класс.

💡 На практике терминология часто является взаимозаменяемой. Поэтому, говоря, например, про веб-адреса, можно оперировать как термином "URL", так и "URI". Это согласуется с приведёнными выше рассуждениями.

💡 Строго говоря, чтобы идентификатор мог считаться URI, URL или URN, он должен соответствовать определённым форматам.

#проектирование #термины #любопытное

🤔 Мысли об устойчивости и интерпретациях этого понятия

Много лет назад применительно к разработке сетевых протоколов был сформулирован принцип устойчивости (robustness principle), известный как закон Постела (Postel's law). Его формулировка: "Будь консервативен в том, что делаешь, и либерален в том, что принимаешь от других".

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

На стороне получателя же это можно трактовать так, что надо подходить гибче, игнорировать незначительные нарушения и предусматривать план "Б", не "падая" по пустякам. Какие это могут быть действия (моя версия):

💡 Игнорировать неизвестные (дополнительно появившиеся) поля, свойства, параметры. Причина их появления может быть самой разной, в том числе развитие схемы API.
💡 Использовать, где это возможно по смыслу, разумные умолчательные значения и типы данных, допускающие неопределённое значение (nullable).
💡 Обрабатывать отсутствие некритических для сценария значений (иллюстрация на примере скрытия кнопки в GUI здесь).
💡 Применять схемы проверок данных, игнорируя незначительные ошибки, не влияющие на семантику (например, лишние пробелы, неверный регистр символов, отличный от ожиданий формат даты-времени).
💡 Быть готовым принимать иные, но совместимые типы данных, например, когда числовые и булевы значения поступают в форме строк.
💡 Не закладываться на порядок следования ключей в объектах JSON, даже если в примерах ваши смежники всегда выдерживают один и тот же порядок.
💡 Если это несущественно, игнорировать вложенность полей (скажем, если поставщик данных практикует частую модификацию структуры, а вам требуется по ID найти небольшое число полей).
💡 Стараться мягко обрабатывать неопределённости, когда поступают неполные и/или противоречивые данные (например, восстановление состояния по доступным данным, запрос недостающих данных, организация переспросов клиента).
💡 По возможности предусматривать обобщённую логику обработки при отсутствии обязательных параметров (например, если нельзя ответить конкретному клиенту специфически, поскольку в запросе не был передан его идентификатор, то можно ответить более общо на ту же тему).
💡 Предвидеть возможные нарушения хронологии при асинхронном взаимодействии (условно, логически второе событие может поступить раньше первого) и дублирующие/повторные данные.

Наверняка, список можно продолжить, но я остановлюсь на этом.

Что ещё ☝️
Поскольку списка официальных и авторитетных рекомендаций нет, то практика применения принципа устойчивости складывается по принципу: "Я художник, я так вижу". В частности, мне довелось несколько раз столкнуться с мнением, что намеренная передача внутри JSON различных типов в форме строк (например, вместо true нужно "true") — это тоже следование принципу устойчивости.

На это я хочу возразить: передача чисел и булевых данных в виде строк сама по себе не может считаться соблюдением закона Постела, поскольку нарушается правило консервативной (!) отправки (в стандарте JSON типы данных введены не для того, чтобы кто-то их оборачивал кавычками, сводя всё к строкам). А вот готовность обработать такое "чудо" на принимающей стороне — это уже хорошо и правильно, это повышает устойчивость решения.

#проектирование #интеграции