🧁🍭 Случилось! Сегодня каналу исполнился 1 год.

Много это или мало? Наверное, ни то ни другое. Это примерно тот возраст, когда ребёнок начинает ходить, а ведь это означает для него не что иное, как переход в качественно новое состояние автономии и появление новых возможностей.

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

Друзья, поздравляю всех с днём рождения канала и спасибо за ваш интерес!

📋 Текстовые форматы данных

Некоторое время назад открыл для себя формат JSON5. Это достаточно интересная, хотя и мало распространённая штука (ссылка). А поскольку каждая новинка помимо любопытства добавляет ещё и сложности соотнесения с уже имеющимися в арсенале средствами (надо же как-то понять, в каких случаях следует предпочесть тот или иной вариант), то я решил провести небольшое сравнение.

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

#интеграции #форматы #сервисы #таблицы

🧛 Тёмная сторона обратной совместимости

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

С одной стороны да, и многие книги учат именно по такой логике развивать свои API, чтобы зазря не травмировать потребителей. Но на днях я столкнулся с другой стороной этого вопроса. Об этом и хотелось рассказать в этот замечательный вечер🎃.

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

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

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

Выводы.
1️⃣ Описанная ситуация не универсальна и в ряде случаев на практике невозможна. В то же время держать её в голове точно не помешает.
2️⃣ При некоторых обстоятельствах общеупотребимые подходы и хорошие практики могут оказаться не такими уж и хорошими. Как минимум, они могут нуждаться в дополнительных действиях, нейтрализующих нежелательные эффекты.

#интеграции #сервисы

🤖 Тестирование обучающего курса

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

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

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

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

В-третьих, это слабое владение материалом. В одном из разделов, посвящённых работе с заказчиком, приводилась таблица "Бизнес-требования", которая состояла из двух разделов: "Функциональные требования" и "Нефункциональные требования". Это уже насторожило, но, как оказалось, это ещё не всё. В составе "Функциональных требований" были зафиксированы ограничения на требуемое условному заказчику техническое решение.

В-четвёртых, это неработоспособные элементы. Размещая ссылки на дополнительные материалы в Интернет, стоит убедиться что они открываются. Нерабочие интерактивные упражнения тоже вызывают изумление. Такого рода брак это явно не то, что ты ожидаешь увидеть в ходе обучения.

Мои выводы.

1️⃣ Попытка удовлетворить повышенный спрос на образование в некоторой сфере может негативно сказываться на содержании учебной программы. И большой вопрос ещё, насколько разработчики этой программы сами владеют материалом.

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

#войтивайти #требования

⚡ И снова IT Talk

Сейчас в Новосибирске проходит очередной, уже 5-й по счëту, митап IT Talk by Sber. Уверен, это хороший знак. 

В программе три доклада от спикеров из Москвы и Новосибирска. Слушаем про подход к шардированию баз данных, запуск контейнеров и про работу конкурентных коллекций.  

Не уверен, что сам всë уловил из описания, но будем разбираться😉. 

#события #сбер

В отличие от ряда коллег, которые посещали в минувшие дни профильные конференции типа Analyst Days, я отдал предпочтение выставке Ван Гога. И, судя по попавшим на глаза отзывам, мой выбор был вполне удачным😅.

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

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

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

#статьи #визуализация #цвет #требования

https://telegra.ph/Colors-in-software-requirements-11-25

Хочу поделиться впечатлениями после прочтения очередной книги. На этот раз это "Микросервисы. Паттерны разработки и рефакторинга" Криса Ричардсона.

Книга актуальная, содержит много полезной информации в одном месте. Но, если нужно больше деталей, читайте далее ⤵️

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

📖 "Микросервисы" Ричардсона

💡 Содержание. Книга довольно увесистая, но это её плюс, так как автору точно есть что сказать по проблематике микросервисов: что это, какие преимущества и недостатки у микросервисной архитектуры, какие существуют паттерны MSA и пр. При изложении материала приводятся контекст и дополнительные сведения общего характера, отчего книга становится самодостаточной.

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

💡 Ложка дёгтя. Есть 2 момента, которые омрачают общее впечатление.

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

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

💡 Резюме. Несмотря на описанные недостатки издания, книгу прочитать стоит. Рекомендую!

Давно я ничего не писал на Хабре, а после того, как прочитал комментарии к одной из статей, в которых говорилось о некрасивости PlantUML, решил, что надо что-то с этим делать☺️.

Как итог, только что запостил статью об управлении вёрсткой в PlantUML. За основу взял свою осеннюю статью о неочевидных возможностях PlantUML, а если точнее её 4-й раздел. Так что, если кто-то пропустил оригинал, можете ознакомиться.

#визуализация #plantuml #статьи #гайды

https://habr.com/ru/articles/865140/

Спешу поделиться.

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

Как я пришёл к этой мысли? Всё просто. За последнее время я получил от нескольких подписчиков запрос примерно одного содержания: почему я не открываю комментарии, этой возможности точно не хватает. На каждое такое обращение я отвечал примерно в том же духе, как выше, но в конце концов решил, что, время пришло.

Спасибо всем, кто был настолько вовлечён и активен, что писал мне об этом. Надеюсь, это только начало и ваше мнение поможет сделать канал ещё более полезным и комфортным. Да будет общение! 🎉

📖 "System Design" Алекса Сюя

Сегодня хочу рассказать свои мысли про книгу "System Design. Подготовка к сложному интервью", автор Alex Xu.

💡 Содержание. Книга написана с прицелом на прохождение собеседований в части решения задач на проектирование информационных систем. Этим и объясняется структура книги, построенная вокруг разбора кейсов (проектируем ограничитель трафика, систему уведомлений, ленту новостей и пр.). По мере разбора задач приводятся дополнительные материалы (ссылки на статьи в интернет), которые позволят при необходимости углубиться в те или иные аспекты.

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

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

💡 Ложка дёгтя. Внимательный читатель увидит несколько опечаток и несостыковок текста и прилагающихся иллюстраций. Так, на рисунке 13.7 вместо обещанного поиска слов true и try будут видны best и beer. Интересно, о чём в этот момент думал Алекс?..😉

Также отмечу, что при прочтении несколько раз мне не хватило более однозначных формулировок. Например, в 11 главе говорится о сохранении в кэш ленты новостей кортежей <post_id; user_id>, но не говорится о том, чей этот user_id — это идентификатор пользователя, который разместил пост в соцсети, или пользователя-друга, которому данный пост должен попасть в ленту новостей.

💡 Резюме. Несмотря на некоторые недочёты, книга хороша. В общем и целом она читается легко и её основная ценность в расширении кругозора. Рекомендую!

#книги #архитектура #собесы #проектирование

Друзья, небольшой дайджест о технологиях на излёте года.

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

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

📜 18 декабря начались значительные проблемы с доступом к YouTube в сетях российских мобильных операторов. И если ранее этот канал доступа оставался открытым, то уже второй день как всё закончилось. В довершение ко всему Роскомнадзор, как сообщается, намерен контролировать попытки обхода блокировок россиянами, обязав операторов связи передавать соответствующую информацию.
Подробнее: здесь и здесь.

📜 Опубликован обновлённый рейтинг популярности языков программирования. Лидером с завидно растущей положительной динамикой оказался Python. Следующими по порядку идут C++, Java, C, C#, JavaScript и другие. Не уверен, что рейтинг всеобъемлющий, но ознакомиться с "процентовкой" точно стоит.
Подробнее: здесь.

📜 Группа учёных разработала метод записи информации на молекулы ДНК. Как утверждается, одна молекула ДНК человека потенциально может хранить порядка 200 петабайт информации, хотя говорить о скором применении данного метода пока не приходится.
Подробнее: здесь.

📜 Студия AiMation выпустила полнометражный анимационный фильм. Над картиной работала команда из 9 человек с бюджетом в 8000 долларов. Эти показатели стали возможны благодаря тому, что картина была создана с помощью нейросетей Adobe Firefly и Stable Diffusion.
Подробнее: здесь.

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

🕓 Начинаем последний отсчёт. Сегодня 23 декабря, и в этом году осталось отработать всего лишь одну неделю. Но, знаете, в этом утверждении полно противоречий.

🙀 Неделя это 7 дней, но до Нового года осталось 9.
🙀 Когда идёт речь о рабочей неделе, то обычно это 5 дней. Но в этот раз придётся потрудиться 6.
🙀 На последней календарной неделе года будет только 2 дня, притом оба будут выходными.

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

🐣 #1. Проблема курицы и яйца в проектировании

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

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

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

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

Так что, курица и яйцо появились одновременно? 🤔

🪒 #2. Парадокс брадобрея и его аналогии в IT-системах

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

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

К примеру, проводится ли статический анализ кода (SAST) системы, которая выполняет такие проверки во время CI/CD? Описан ли в цифровом репозитории систем сам репозиторий? Выполняется ли архитектурный контроль над системой, на которую возложены эти обязанности? Есть ли гарантии, что обновляется система, которая контролирует обновления ПО в периметре компании?

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

Так, погодите, брадобрей вообще никогда не брился? 🤔

🧠 #3. Парадокс Сократа для системных аналитиков

"Я знаю, что ничего не знаю." Это, пожалуй, одно из самых известных изречений древнегреческого философа Сократа. Фраза кажется противоречивой, ведь как можно знать о своём незнании?

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

В этом смысле сбор и анализ требований можно рассматривать как новый мини-проект, даже если речь об однотипной задаче из уже хорошо знакомой предметной области. Такой подход позволяет увидеть скрытые потребности и убедиться в том, что все могут делать или желать одно и то же, но каждый по-своему. У каждого своё "хорошо".

🔍 Данный парадокс заставляет критически относиться к собственным знаниям, их полноте и универсальности в каждом конкретном случае. Важно оставаться открытым к новому и альтернативным точкам зрения, избегая предвзятых выводов и скоропалительных решений. Признавая факт собственной ограниченности, мы делаем шаг в сторону своего дальнейшего развития.

Подождите, выходит, синдром самозванца это признак адекватной самооценки? 🤔

🛠️ P.S. На этом парадоксе, пожалуй, всё. Неделя была парадоксально долгой, целых 6 дней. Ну, вы меня поняли. 😉

Друзья! Уже совсем скоро стрелки часов укажут на полночь, а значит наступит долгожданный 2025 год.

Пусть Новый год принесёт вам новые перспективы, идеально работающие системы и предсказуемых смежников, а Дедушка Мороз 🎅 подарит документацию, которая сама себя пишет. Безграничного частья, слепой удачи, железного здоровья и побольше релизов без багов новом году! 🎇🍾🥂

Ну что ж, праздники прошли. Лично я возвращаюсь в рабочий ритм довольно спокойно. Должно быть, это из-за того, что за минувшие дни мне удалось подзарядиться. Хотя всё прошло не без неожиданностей.

Поломка бытовой техники, пожар в одной из квартир в нашем доме, внеплановые посещения стоматолога и ещё несколько досадных событий перед Новым годом. Видимо, 2024-й год никак не хотел сдаваться без боя. Но 2025-й наступил. Будущее всегда побеждает; хотя бы в этом можно быть уверенным.

Желаю всем хорошей рабочей двухдневной😎 недели.