I hate overtime

2021-07-04 14:09:33 Найди свой стек на картинке))
Кстати, картинка абсолютно реальная. Сфотано в Индийской провинции Открыть/Комментировать

2021-06-20 20:30:44 ​​Кафка для детей от автора Mastering Kafka Streams and ksqlDB https://www.gentlydownthe.stream/ Открыть/Комментировать

2021-06-14 12:03:05 #concurrency
Очень хорошая статья из серии "да кто такие эти ваши фиберы/ко(го)рутины ...". В частности объясняют какую проблему они решают и почему так не получится сделать на обычных ОС тредах. Рекомендую!
З.Ы. не смотря на то, что блог java'овый про java в статье только пара упоминаний proj loom Открыть/Комментировать

2021-06-06 13:59:16 #arch
Про проектирование "на берегу"
Как-то я уже писал пост про эмержентную архитектуру. Это такая штука, которая позволяет вашей системе легко адаптироваться к новым требованиям(привет аджайл), но при этом не скатываться в большой комок известной субстанции. Так вот, не смотря на все модные аджайлы и лин-стартапы фаза проектирования никуда не девается. Просто она становится более верхнеуровневой и концептуальной.
Расскажу байку: в бытность моей гребли на галере у нас был очень крупный заказчик, которому мы делали и внедряли хранилище данных. Досталось мне это поделие уже на изрядной степени готовности и ребята там решили для витрины заиспользовать одну известную отечественную колоночную СУБД. Все бы хорошо, но вот только в документации к этой СУБД было черным по белому написано, что деньги в нее класть не стоит, т.к. при определенных положениях лун юпитера возможны частичные потери данных. Угадайте что лежало в хранилище? Проблема обострялась тем, что сайзинг уже был рассчитан и тачки закуплены, а значит признание и устранение этой ошибки нам влетало в штрафы примерно равные бюджетам проекта.
История кончилась хорошо, проблему вовремя эскалировали и все решилось без особых денежных и репутационных потерь, но с тех пор я и сам стараюсь и всех призываю первым делом понимать что является реально "архитектурными" решениями. Под архитектурными я понимаю то, что потом будет очень сложно или даже невозможно(как в истории выше) поменять. Такие вещи надо обсуждать на берегу, аккуратно принимать решение и не менее аккуратно документировать вместе с контекстом, альтернативами и участвовашими в принятии решения стейкхолдерами. Я пользуюсь замечательным шаблоном от Майка Нейгарда, но вот тут кажется уже собрали пару-тройку неплохих альтернатив.
Смысл в том, что ваши потомки, а может даже и вы сами через какое-то время точно забудете нюансы под давлением которых было принято решение, а тут получается нужно только смахнуть пыль с пары десятков(у меня пара десятков скапливается за несколько лет) вики-статей и вуаля, вы снова полностью в контексте и нет желания орать на весь опенспейс "ну и какого оно вот ТАК!" Открыть/Комментировать

2021-05-05 17:03:03 #arch
Про арх. надзор
Одной из основных моих обязанностей в бытность сис. архом было осуществление арх. надзора. Это означает то, что помимо проработки решения и реализации PoC надо было еще и, каким-то образом, гарантировать, что реализация концептуально не отличается от задумки.
Проблема в том, что "вас много а я одна". Читать внимательно весь код времени нет, свои задачи ждать не будут, да и глаз со временем замыливается, а джуны тем временем не дремлют и в результате все эти ваши воздушные замки на бумажке начинают очень слабо походить на то, что попадает на продуктив.
Серебряной пули тут, к большому сожалению, нет. Но есть несколько способов все-таки снизить вероятность деградации наших любимых НФТ из-за шаловливых ручек.
Первый из них это уже упомянутые фитнесс функции. В результате достаточно плотного покрытия ими, можно получить достаточно неплохую "приемку". К сожалению, не все НФТ можно дешево "зафитить"(как насчет расширяемости и maintainability, например). Тут в дело врываются гексагональная(ну или чистая) архитектура и DDD. При правильной мотивации и сноровке эти 2 инструмента дадут не только достаточно аккуратный код, но и даже уменьшат time to market. Но тут на первый план выходит вопрос мотивации. DDD и clean architecture очень хрупкие и сильно подвержены закону разбитых окон, поэтому вся тима без исключения должна быть единодушна в их использовании. Ведь стоит кому-то одному по незнанию или из-за давящих сроков "наговнякать" и скоро все ваши усилия и человекочасы потраченные на ивент сторминги и проработку модели пойдут прахом. На C# и Go мне удавалось более-менее успешно бороться с этим используя линтеры и статический анализ, но, тем не менее, ревью по прежнему жрало конскую долю моего рабочего времени.
Если вам повезло и у вас есть сильная система типов и HKT(и, конечно же, команда готова к такому повороту событий), то можно попробовать еще сильнее закрутить гайки и зафорсить архитектурный стиль через интерпритаторы. Тут мне, к сожалению, ничего не понятно, но очень интересно, так что сильно рекомендую послушать замечательный выпуск scalalaz'а про TF и джун-пруф девелопмент. Там гуру классно рассказывают, что это и как с этим жить.
В заключение скажу, что как не крути, но код читать придется. Причем много. И, скорее всего, плохого. И свои тикета из-за этого закрывать по ночам тоже придется(в лес не убегут, да). Но в результате, когда общий уровень команды поднимется, процессы устаканятся, вы незаметно перестанете просыпаться от pagerDuty по ночам. А это, как не крути, приятно))) Открыть/Комментировать

2021-04-20 20:55:22 ​​ Ну что, лед тронулся ?
Вышел релиз Apache Kafka 2.8, в котором уже можно пощупать KIP-500 в действии.

НО НЕ НАДО ПОКА ВЫПИЛИВАТЬ ЗУКИПЕР ИЗ ПРОДА! ЭТО ТОЛЬКО НА ПОИГРАТЬСЯ!

Но и про новые фичи посмотрите видос

Открыть/Комментировать

2021-04-20 20:55:22 охохо, историческое событие, однако! Открыть/Комментировать

2021-04-20 20:50:35 Про измеримость
Вот за что не люблю современное IT, так это за то, что из инженерии оно плавно скатывается в карго-культ. Стоит только Фаулеру или компании Нетфликс опубликовать пост с обзором очередных микросервисов или дельта-лейка и каждое ООО "Рога и Копыта Inc" уже рвануло это внедрять.
В дискуссии с CV-driven карго-культистами бывает не просто: в попытках занести bleeding edge технологию или архитектурный стиль они обязательно будут аппелировать к своему личному опыту и/или публичной экспертизе IT-гигантов и рассказывать как наши корабли будут бороздить просторы бесконечной масштабируемости, отказоустойчивости и других НФТ. Проблема в том, что с одной стороны любое решение имеет свои границы применимости, которые, конечно же, почему-то опускаются, а с другой стороны размахивать руками и тратить рабочее время на митингах можно бесплатно и безнаказано. За косяк в архитектурных решениях отвечать придется еще ой как не скоро, а то и вообще не нам. Померять эту волшебную скалабилити нельзя... или можно?
Давайте представим себе, что мы написали некий простенький тест, который запускает нашу приложеньку в x и в 2х инстансов с измерением максимально-выдерживаемого количества транзакций на обоих инсталяциях. Кажется сложновато, но в наш век IaC и контейнеризации более чем реально и вот уже наша скалабилити стала вполне себе измеримой. Цимес тут в том, что даже самый простенький тест подсвечивает кучу проблем. Например, что масштабируемость далеко не всегда линейная, под приложеньками есть базы, о чем почему-то часто забывают. Кстати, поздравляю, мы только что вместе с вами изобрели простенькую fitness-функцию! Этот термин в свое время придумал Нил Форд и описал в своей замечательной книжке, где он демонстрирует всю мощь этого инструмента.
Фитнес-функции не обязательно должны быть настолько высокоуровневыми, на самом деле, они даже не обязательно должны быть автоматизированны. Главное тут то, что теперь вы можете измерять любые аспекты вашей системы, что отлично демонстрируется ката.
Основная идея очень проста: нужно определить какие-то минимальные пороговые значения характеристик системы, при которых она является "приемлемой" после чего придумать пачку таких фитнес-функций, успешное прохождение которых и будет являться гарантией того, что ваша система готова выйти в свет
Напоследок скажу, что после появления в вашей жизни этого замечательного инструмента, по-другому работать будет сложно. Без фитнесс-функций любое решение будет казаться неполным и создавать впечатление хождения в потемках. Наверняка для стартапа-однодневки или интернет-магазина на заказ тащить фитнес-функции не стоит, но для систем, действительно сложных и важных для бизнеса, они незаменимы. Кстати, фитнес-функции вошли в инструментарий Agile Architecture Framework от Open Group, т.е. скоро (надеюсь) станут стандартом и их перестанут незаслуженно обходить стороной Открыть/Комментировать

2021-04-19 22:22:42 #arch
Котаны, привет! Давно ничего не писал, опять затянули работа, семья и весеннее обострение отвращения к этому вашему АйТи
Благо нашел несколько заметок про системную архитектуру, которой, видимо, суждено увидеть в ближайшем будущем свет в виде серии постов. Пока планирую чиркануть про наиболее важные и (надеюсь)наименее обсуждаемые аспекты:
1. про измеримость
2. арх. надзор
3. проектирование "на берегу"
А пока я привожу это все в порядок, очень рекомендую шикарную статью и пост про нее от Юры Богомолова про личный бренд, выгорание и вот это все Открыть/Комментировать

2021-04-06 10:40:17 #perf #scala
После нескольких лет боли и мучений с JMeter открыл для себя Gatling и огромным удовольствием нырнул в мир типобезопасных удобных DSL для нагрузочного тестирования.
Гатлинг замечателен всем, но вот с документацией есть некоторые проблемы, из-за чего кривая входа может быть достаточно крутой(особенно для не-скаланов). И вот тут я нашел совершенно замечательную статейку про циклы, control-flow statements и паузы с отличными примерами, блекджеком и герцогинями Открыть/Комментировать