dependency hell

2022-06-14 15:49:04 Всем привет. Хочу немного поговорить об изучении Kubernetes.

Каждый раз когда я к нему возвращаюсь, в уме возникает картинка CNCF Landscape. Ну и когда она возникает, хочется просто сказать: "Да ну нахер!". И забить на это все. Я работаю с Kubernetes где то с 2017 года. По большей части как пользователь (другими словами раскатываю в нем свои приложения). Был период когда немного приходилось его администрировать. Потом был перерыв в пару годиков и вот теперь я снова вернулся к активной работе с ним. За это время он достаточно серьезно подрос. Поговаривают что кодовая база уже перевалила за 4 500 000 LoC.

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

По итогу я совершенно случайно наткнулся у себя в приложении Books на книжку:
"Cloud Native DevOps with Kubernetes". В русском переводе: "Kubernetes для DevOps. Развертывание, запуск и масштабирование в облаке". Ее я как то купил чтобы почитать и забыл о ней. Сейчас же глянул содержание и это оказалось именно то что мне нужно. В общем книга - "Галопом по Европам" по теме. Ни какой воды, минимум информации и при этом охватывается практически вся экосистема Kubernetes.

Начинается все с истории облачных вычислений, истории появления контейнеров, DevOps революции и истории появления Kubernetes. Далее дается краткое введение в сам Kubernetes. После этого авторы дается информация о возможных вариантах установки и развертывания кластеров. Рассматриваются как managed решения (Такие как GKE и AWS EKS) и так же on-permise решения (когда вы устанавливаете его самостоятельно). Дается введение в работу с k8s с точки зрения разработчика приложений. Дается информация об управлении ресурсами в кластере. Рассматривается администрирование и масштабирование кластеров. Дается подробное описание работы со всеми основными ресурсами и объектами кластера. Затрагиваются вопросы безопасности и резервного копирования. Вопросы процессов разработки и того, как Kubernetes повлиял на них. Рассматриваются вопросы мониторинга, алертинга и непрерывного развертывания (CI/CD). В общем в книге дается обзорная информация практически со всех сторон обо всей экосистеме Kubernetes.

Считаю книгу идеальным источником, если вам надо быстро ознакомится с темой. Крайне рекомендую книгу к прочтению. Читается легко. Есть примеры кода. И даже если вам лень запускать код, вы можете просто прочитать книгу. Кода там не так много и он в целом не обязателен для понимания темы. Чтобы просто получить теоретическую подготовку простого прочтения буде достаточно. Целостная картина экосистемы у вас в голове точно сложится. Дальше можно будет уже углубляться в интересующие вас темы и к конкретные проблемы.

Кстати я читал первое издание книги. При чем в русском переводе. Возможно в оригинале она будет чуть лучше. "Питер" все таки не очень переводит технические книги. Сейчас вот вышло второе издание. Я бы рекомендовал по возможности читать его. Например NGINX раздает книгу бесплатно (При условии что вы дадите им свои контактные данные конечно же).

Ну а на этом у меня все. Хорошей рабочей недели. Всем добра и успехов во всех ваших профессиональных начинаниях и пет-проектах. До встречи. Открыть/Комментировать

2022-05-22 18:06:48 Привет народ. Хочу немного поговорить о языках программирования. Вам наверняка известно, что я самоучка. Computer Science образования у меня нет. За всю свою жизнь я писал на разных языках. При этом я слабо представлял себе как языки на которых я пишу работают. Вообще до определенного момента мне это и не было особо интересно. Я использовал язык как инструмент и мне этого было достаточно.

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

В конечном итоге я решил все таки сесть и разобраться в теме. Хотя бы поверхностно на базовом уровне. Как оказалось, нора достаточно глубока. В общем есть несколько способов понять что к чему. Можно пройти какой-нибудь курс на условной Coursera. Можно взять какую-нибудь фундаментальную книжку. Как например Dragon Book. Можно попробовать написать свой язык программирования.

Что я выбрал для себя? Я попробовал один из курсов. К сожалению он показался мне достаточно скучным. Я купил Dragon Book и начал ее посматривать и почитывать. Там оказалось достаточно много информации, но читается она тяжело. Я не пробовал писать свой язык с нуля, потому что я ленивый мудак. Но при этом я нашел неплохую книгу, в которой автор проводит вас через написание собственного интерпретатора.

Книга называется Writing An Interpreter In Go. Читается очень легко. К ней прилагается полный исходный код интерпретатора, который по ходу этой книги пишет ее автор. Если вам совсем лениво, можете просто ее прочесть. Этого будет достаточно для понимания базовых принципов. Если у вас есть чуть больше времени и мотивации, можете по ходу чтения писать код этого самого интерпретатора. Я как раз пошел по такому пути. В таком случае информация запоминается чуть лучше. Можете вообще взять ее за основу и начать сразу писать свой интерпретатор. Тоже вариант.

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

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

PPS. Я все таки нашел работу в области SRE. Так что возможно канал снова оживет. :) Спасибо всем тем, кто до сих пор подписан. Даже учитывая тот факт, что от меня сложно ждать предсказуемого графика публикаций. Я очень это ценю. Открыть/Комментировать

2021-10-21 18:11:26 ​​Привет народ. Не писал сюда уже несколько месяцев. Впрочем ничего нового. В этом весь я. Пересказывать "банальные вещи" вроде не хочется, а каких то ценных мыслей кажется родить не выходит. Поэтому сижу, отмалчиваюсь и корю себя за то, что ничего не пишу.

Что поменялось за это время? Нашел ли я работу в области SRE/DevOps? Да и нет. Сейчас я работаю на должности Software Engineer в небольшом стартапе. Наша команда занимается как раз инфраструктурной частью продукта и отвечает как за backend так и за SRE. Как результат, я могу заниматься и тем что мне интересно, и тем в чем у меня есть опыт. И код писать и Kubernetes крутить и CI/CD настраивать, и метрики вертеть. Забавно, но факт. Как бы я не ставил цели, результат все равно чуток отличается от ожидаемого. Т.е. в целом цели достигаются, но дьявол кроется в деталях. Тут кажется 2 варианта. Или я что-то делаю не так, или мир просто так устроен. Хрен знает.

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

Мой посыл к вам следующий: Давайте писать README и относится к нему ответственно. Это не сложно, а при онбординге (да и вообще при работе над проектом после некоторого перерыва) хорошо описанный README экономит тонну времени. Не оставляйте README пустым. Не оставляйте README шаблоном, сгенерированным каким то фреймворком. README - это самая важная документация.

Вначале опишите в несколько предложений назначение репозитория. Что в нем лежит? зачем он появился? какую проблему решает? Можете использовать ASCII графику и нарисовать небольшую схему того, как работает то, что лежит в репозитории. Только самое важное. Код не даст ответов на все эти вопросы.

Опишите внешние сервисы (зависимости). Если ваш проект, это не библиотека а приложение, наверняка оно использует какие то внешние сервисы. Это могут быть базы данных (Postgres/MongoDb). Это могут быть системы очередей (RabbitMQ/Kafka) и т.д. и т.п. Расскажите: Какие именно сервисы используются? Требуется ли из специализированная настройка? Если да, как их нужно настроить, чтобы ваше приложение заработало. Нужны миграции? Откуда их взять. Нужны конфиги? Где их найти? Нужна конкретная версия? Какая?

Создайте раздел, в котором опишите то, как запустить тесты для вашего приложения. Как подготовить тестовое окружение, если оно необходимо. Как собрать исполняемый файл приложения. Какие флаги компилятора нужно использовать при сборке? Есть ли какие то особенности сборки?

Для каждого исполняемого файла опишите все ENVIRONMENT переменные которые он использует. Как правило с ними возникает больше всего проблем, т.к. они могут быть разбросаны по коду и неявно менять поведение приложения. Искать их бывает тяжело и долго. Если нужен конфиг, расскажите, как он устроен и где его взять. Как его создать. Расскажите, как запустить ваш проект локально.

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

Я уверен, если в вашем README будут все эти разделы и вся эта информация, коллеги непременно скажут вам спасибо. Новые разработчики скажут вам спасибо. Даже когда вы уйдете из компании или бросите проект. Человек, которому он достанется скажет вам спасибо. Есть такая поговорка "Встречают по одежке". Для меня README давно стал такой своеобразной "одежкой". Когда я знакомлюсь с новым кодом, первое что я пытаюсь выяснить: Как его собрать, как его протестировать и как его запустить. И хорошая вводная документация в виде README может ответить на все эти вопросы и сэкономить кучу времени.

На этом у меня в общем то все. Всем добра. До связи. Открыть/Комментировать

2021-07-09 15:22:01 Привет ребята, сегодня будет деМотивационный пост. Поговорим немного о том, как найти себя в профессии. Это будет история из жизни.

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

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

Через 1 месяц я ушел. 9 июля был мой последний рабочий день. При этом я взял "Welcome Bonus" размером в 1 ЗП (по факту беспроцентный займ). Я знал об этом, но думал что меня это как то дополнительно мотивирует. Я ошибся. Деньги пришлось вернуть. В итоге я бесплатно проработал этот месяц.

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

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

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

К чему я это все? Я вдруг понял, что достаточно давно я тащусь от DevOps и SRE. Мне нравится автоматизировать и оптимизировать процессы. Мне нравится убирать барьеры между разработчиками, админами, бизнесом и др. людьми. Мне нравится ковыряться в ОС и на серверах. Мне нравится писать код который что-то автоматизирует и упрощает повседневную рутину.

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

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

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

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

В завершение. Ребята, спасибо вам всем за то, что вы меня читаете. Спасибо что поддерживаете. Спасибо за лайки и главное - дизлайки. Я ценю то, что вы у меня есть. И если вы вдруг в депрессии или потерялись, не отчаивайтесь, все будет хорошо. Всем добра! Открыть/Комментировать

2021-04-29 13:12:29 Всем привет. Поговорим немного о политике. Обычно я стараюсь обходить эту тему стороной, но тут у меня бомбануло. Эта политика во первых напрямую связана с IT во вторых может коснуться каждого из нас.

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

Есть на GitHub проект golang-standards/project-layout, который был создан в 2017 году одним человеком (в ответ на отсутствие оффициальных стандартов оформления проектов на Go) и поддерживается им вот уже на протяжении нескольких лет. За это время он оброс большим кол-вом звезд (22k что составляет довольно значительный процент от размера Go community. Например в Slack сообществе 58k участников). Многие разработчики черпают оттуда информацию которая так или иначе кажется им полезной. Кто-то не согласен и проходит мимо.

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

- Название golang-standards вводит в заблуждение новых членов комьюнити (52, 41, 38, 36).
- Мне не нравится что у вас написано, я хочу чтобы вы это поменяли потому что считаю этот подход вредным (10).

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

История дошла до того что вчера был создан очередной Issue #117 говорящий о том, что репозиторий вводит новичков в заблуждение. И создан он был ни кем-то с улицы, а одним из создателей языка Go rsc (Russ Cox).

И здесь произошло интересное. Прибежали люди которые начали форсить и лайкать rsc продвигая идею того, что организацию надо переименовать, т.к. проект вредит сообществу. Некоторые особо горячие головы предложили вообще привлечь Trademark Law для запрета репозитория (1, 2).

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

По этому поводу хотел бы высказать свою позицию:

- Я с уважением отношусь к создателям языка и наиболее значимым персонам в Go community. В частности к Russ Cox. Я крайне признателен тем что он делает.
- Я с уважением отношусь к людям которые имеют другую позицию. Это нормально, что у людей есть разные взгляды.

В то же самое время:

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

Мы находимся в свободном OpenSource сообществе. Если нам не нравится чей то репозиторий или его название - мы вправе создать свой, или пройти мимо.
Issue #117 создает опасный прецедент который разделят Go community и вредит OpenSource в целом и я выступаю против подобных инициатив. Открыть/Комментировать

2021-03-22 11:00:19 ​​Всем привет. С новым годом друзья... или я поздновато? Ну и хрен с ним. Вот о чем хотел сказать:

Проблема разбиения исходного кода на модули существует достаточно давно. Даже больше чем может показаться на первый взгляд. Недавно я наткнулся на крайне интересную бумагу от 1972 года под названием “On the Criteria To Be Used in Decomposing Systems into Modules”. Уже почти 50 лет, а мы никак не научимся. Такие вот дела.

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

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

Второй способ основан на “сокрытии информации”. В нем разбиение на модули не связано с алгоритмом работы системы. Вместо этого вы смотрите на то, что вам нужно реализовать и начинаете задавать вопросы: “А что если то или иное требование поменяется?”. Что если БД не подойдет? Что если входной формат данных изменится? Что если пользователь захочет работать по сети?

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

Далее вы разделяете систему на модули по принципу 1 модуль решает одну проблему. При этом максимально скрывая детали реализации проблемы от других модулей. Входные данные могут поменяться? Хорошо, давайте выделим API в отдельный модуль, а в системе реализуем внутреннее представление данных. БД не подойдет? Давайте выделим модуль хранилища и скроем детали реализации предоставив пользователю модуля абстрактный интерфейс доступа к хранилищу.

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

Главное прекращайте выделять в каждом проекте каталоги models, views, controllers и подобные. В таком разбиении смысла не больше чем в разбиении приложения на модули по алфавиту. Хотя… Это вообще третий (особый) способ деления проекта на модули. В данной статье он вообще не рассматривается кстати... И на этом у меня пока что все. Читайте статью и хорошей рабочей недели. До встречи. Открыть/Комментировать

2020-10-12 13:30:02 Всем привет. Я думаю многие из тех кто интересуется микросервисной архитектурой знает, такой сайт https://microservices.io/ на котором собраны все основные паттерны применяемые при разработке микросервисов.

Если вы вдруг не знаете о таком сайте, советую его посетить. У меня конечно есть вопросы к его визуальной составляющей , однако информация там собрана вполне себе годная , хоть и в достаточно урезанном объеме. Я частенько использую данный сайт как справочник.

Но речь не столько о сайте, а вот о чем. У Криса Ричардсона, автора данного ресурса, есть отличная книга которая называется “Microservices Patterns”. Вот ее то я вам и хочу порекомендовать.

Если вы читали только классику, а именно “Building Microservices: Designing Fine-Grained Systems”, у вас скорее всего осталось достаточно много практических вопросов типа: “А как быть с распределенными транзакциями?”, “А где должна быть бизнес-логика?”, “Как работать с доменными событиями?”, “А внешний API как предоставлять”?

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

Во первых, я бы рекомендовал оригинальный вариант книги. Я сам приобрел перевод от издательства “Питер” и он оказался местами кривоват. Например в разделе о тестировании “stubs” и “mocks” переводятся как “заглушки” и внимание... “макеты” (wat?) .

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

На этом у меня все. Всем добра! Открыть/Комментировать

2020-07-13 11:00:16 ​​Всем привет. За последние пару месяцев ничего особо не изменилось и я все еще ковыряюсь в legacy коде. Иногда успешно, иногда не очень. Признаться честно, местами утомляет.

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

Книга эта называется Object-Oriented Reengineering Patterns. Написана она была в начале 2003, но последняя ее версия была опубликована в 2013 году. В любом случае, я бы не стал делать на это большой акцент. Книга актуальна как никогда. И да, актуальна она не только для ООП систем. Так что не упускайте возможности, даже если ваш основной язык не совсем ООП или совсем не ООП.

Чем же особенна данная книга?

В первую очередь она достаточно прагматична. В ней нет best practice и серебряных пуль. Все решения приведены в виде “Паттернов”. Т.е. шаблонов описывающих ту или иную проблему, пути ее решения и плюсы, а также подводные камни того или иного подхода.

Во вторых книга написана не чистыми консультантами (если кто-то скептически относится к консалтингу в области IT). Авторы имеют хороший академический бэкграунд (2 из них степень профессора в области CS) и некоторый промышленный опыт реинжиниринга ПО таких компаний как Nokia и Daimler-Benz (Mercedes).

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

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

На этом у меня все. Всем добра! Открыть/Комментировать

2020-06-11 12:00:59 Привет.

Сегодня хотел бы поделиться первыми впечатлениями от недавно приобретенной книги. Книга эта называется “Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford”.

Она достаточно новая. Была опубликована в феврале 2020 года. Естественно ее нет на русском языке и возможно даже нет в наличии в России. Я заказал ее с Амазона на бумаге. И конечно, обошлась мне она в копеечку. Если быть точнее в районе $70 с доставкой из США.

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

Читается она достаточно тяжело, материал порой довольно сложный, написана она строгим инженерным языком, местами достаточно скучным и формальным. В книге практически нет кода. Лишь отчасти попадаются примеры “псевдо-кода”. Достаточно часто встречаются диаграммы, иногда формулы и графики. Очень много текста и очень много формальных определений (Cohesion, Coupling, Connascence, Leveregability, Reliability, etc.).

В книге рассмотрены основы архитектуры как дисциплины, приведены архитектурные характеристики, а также метрики на которые можно ориентироваться при анализе архитектуры. Разобраны основные заблуждения относительно архитектуры в целом и относительно распределенных систем в частности. Рассмотрены 8 основных архитектурных стилей, которые встречаются в современном ПО (Layered, SOA, Event-Driven, Microservices, etc.). Рассмотрены вопросы оценки рисков, технического лидерства, формализации и документирования архитектурных решений.

Вот вам к примеру 2 основных закона архитектуры программного обеспечения, сформулированные в данной книге:

- Everything in software architecture is a trade-off (First Law of Software Architecture)
- Why is more important than how (Second Law of Software Architecture)

И еще пара цитат:

- Architecture is the stuff you can’t Google
- There are no right or wrong answers in architecture - only trade-offs

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

На этом у меня все. Всем добра! Открыть/Комментировать

2020-05-25 12:01:09 Друзья, всем привет, давно не слышались.

Я вижу, что последний пост про Legacy собрал достаточно много пальцев вверх. Это неимоверно круто. У меня уже есть некоторые идеи для продолжения данной темы, но сегодня речь пойдет о другом. Сегодня я хочу поговорить вот о чем:

В эту субботу 30 мая 2020 года я бы хотел пригласить вас на ONLINE митап “Карантин Go away”, который пройдет с 16:00-19:30 МСК. Данный митап проводится сообществами Golang Kazan (г. Казань) и Go Yola (г. Йошкар-Ола).

Да, это Go митап. Да, я знаю что не все из вас пишут код на Go. Тем не менее я думаю он стоит того, чтобы его посетить, и для этого есть ряд причин:

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

Вторая. Я лично буду выступать там с докладом. Я поговорю о таких концепциях, как Inversion Of Control (IoC), Dependency Inversion Principle (DIP) и Dependency Injection (DI).

Третья. У вас будет возможность задать вопрос голосом, а после мероприятия мы сможем пообщаться онлайн на импровизированной Afterparty.

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