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

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

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

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

💡 Содержание. Книга довольно увесистая, но это её плюс, так как автору точно есть что сказать по проблематике микросервисов: что это, какие преимущества и недостатки у микросервисной архитектуры, какие существуют паттерны 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-й наступил. Будущее всегда побеждает; хотя бы в этом можно быть уверенным.

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

Буквально несколько минут назад наткнулся на очередной пост про пет-проекты для системных аналитиков. Основной посыл, как водится, в том, чтобы таким способом помочь новичкам без опыта себя показать потенциальному работодателю.

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

Голосуем:
🔥 — неплохая идея.
🗿 — для специалистов с опытом не актуально.

🛰 MVP и его основные виды

Сегодня хочу затронуть тему MVP (Minimum Viable Product, то есть минимально жизнеспособный продукт).

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

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

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

#статьи #продукт #термины

https://telegra.ph/MVP-and-its-main-types-01-21