Пока ковырялся в Rust, нашел несколько полезных/интересных материальчиков.

https://doc.rust-cqrs.org/ — крейт для построения CQRS и Event Sourcing приложений. Также там есть примеры построения агрегатов, объектов-значений и тд.
https://cheats.rs/ — хороший справочник по возможностям Rust. Также там есть ссылки на примеры, книги и тд.
https://www.youtube.com/@letsgetrusty — небольшой, но интересный канальчик, кстати у него тоже есть свой cheatsheet(ссылка придет на email).

Сохраните себе на случай когда к вам придет менеджер и попросит оценить большой проект 😉

https://youtu.be/1WfGSJf1Gmc

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

Записываться тут -> https://howto.stringconcat.com/technical_debt

Напишите в комментарии что бы вам хотелось услышать, а мы постараемся ответить на вебинаре

Quick Tip: Как сделать так, чтобы менеджер сам брал тех. долг в итерацию https://www.youtube.com/watch?v=XHWTHeIDDr0

https://www.youtube.com/live/LsE-DRP4sKI? го, мы создали!

Практический курс
Разработка Enterprise-приложений без боли и сожалений

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

- Наш курс поможет вам это исправить!
Пример лекции: youtube.com/watch?v=JDO81HrTGpg

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

Мы отвечаем на три фундаментальных вопроса:

1. Как разработать продукт, за который не стыдно?
2. Как поддерживать и развивать проект, не жертвуя сном и здоровьем?
3. Как перестать выгорать и начать жить?

Начать бесплатно: howto.stringconcat.com/enterprise?utm_source=telegram&utm_medium=cpc&utm_campaign=km&utm_content=zakrep

Открываем номинаицию самый waterfall’ный проект года!

Мы только-только планируем как реализовывать проект для клиента длиной в год, в котором будет задействовано около 30 разработчиков.
Клиент заверяет что он самый agile’ный и самый гибкий. Но, конечно же просит предоставить оценку в часах на год вперед. Но кого этим уже удивишь? 😅

Но он смог! Перед релизом нужно пройти сканирование кода на уязвимости. И клиент просит сказать сколько строк кода нужно будет сканировать в конце проекта.
То есть он спрашивает “а сколько строк кода будет в проекте через год”.

Пишим ответ, помножая количество кода, производимого программистом за день на 30*247. Обсуждаем есть ли метрики, указывающие а сколько линий кода программист обычно удаляет. Стоит ли ставить KPI на количество срок в день? А отчитываться на утренних стендах сколько ты вчера накодил и сколько планируешь накодить сегодня. Надеемся клиент оценит юмор :)

Как вам такой кандидат на звание самого ватерфольного?
Буду рад почитать в комментариях подобные примеры с вашей работы!

Парочку интересных статей с vc о том что такое GPT и как оно устроено. Для тех, кто ничего в этом не понимает (вроде нас) показалось интересными. Никогда бы не подумали, что Т9 — это далекий предок GPT. Во дела…

Начало
Продолжение

Забирайте в закладки!

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

Все мы используем шифрование с открытым ключом: вот эти ваши HTTPS, секретные чатики в телеграмме и дикпик-фотки в iCloud.

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

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

Приятного просмотра под кофеек!

https://www.youtube.com/watch?v=f5slLeCz7p8

С удивлением обнаружил что многие команды до сих пор оценивают задачи в часах. А потом в эти оценки не вписываются, перерабатывают и выгорают. Виной тому тот факт что 1 идеальный час != одному реальному.

Пришлось записать видео с изложением своей позиции. https://youtu.be/uLp-Ht_cRk8

А вы когда-нибудь попадали в оценку, используя часы?

Как можно раздуть стоимость проекта на 1.5 пользователя? Об AWS, девопсе, контейнерах и микросервисах

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

Потом пришел Kubernetis, и эта идея стала мегапопулярной. Я думаю многие из вас набирали EC2 инстансы и разворачивали на них кластеры. Очень удобно. К примеру, набрал три EC2 инстанса по 16ГБ и 4CPU, и твои 10 микросервисав кубернетис по ним раскатал равномерно. И отказоустойчивость вам, и доступность, и еще и экономия ресурсов за счет шаринга.

Потом AWS сказал, а зачем вам вообще парится с этими EC2 инстансами, которые являются виртуальный машиной по-сути. Мы вам дадим Fargate. Вы нам просто говорите сколько каждому контейнеру(ок, ПОДу) нужно. А дальше мы уж сами разместим их как нужно. Казалось бы, действительно хорошо. У нас на один уровень инфраструктуры стало меньше. Разработчики рады, девопсы пьют пиво. Но заметили ли вы, что мы уже ушли от идеи шаринга ресурсов? Теперь мы каждому контейнеру(хорошо, хорошо ПОДу) выделяем фиксированные ресурсы. И если у вас контейнер потребляет по пол ложки CPU в час, AWS не забудет билить вас за весь CPU.
И вот, изначальная, очень хорошая идея экономии куда-то испарилась.

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

И в итоге, приложение, которым будет пользоваться 35 человек 8ч часов будет крутиться на AWS за 10К USD в месяц.
Это реальный кейс. 35 пользователей и 10k USD в месяц. И никого это не смущает.

Вот и ролик в тему вам под кофеек: https://www.youtube.com/watch?v=nqa_Uyz1pBE

Я считаю что layered architecture — худшее что может случиться с проектом.
Появляется спонтанно, не несет никакой упорядоченности, и в конечно итоге скатывается в big ball of mud. Всегда.
Не сдержался, записался видео на тему https://youtu.be/lvUK92gYrn8

С радостью обсужу в комментариях 😉

Разобрали проблемы Layered Architecture, теперь поговорим о чем-то позитивном. Например о Clean Architecture и как она решает проблемы, созданые Layered Architecture https://www.youtube.com/watch?v=A37crsbFYeo

Почему Hexagonal Architecture лучше Layered Architecture, почему с ней проекты реже превращаются в big ball of mud? Потому что она точнее описывает правила и оставляет меньше возможностей для различной интерпретации. Вот скажите разработчикам “используем Layered architecture” и один сделает зависимости из домена на слой доступа к данным, а другой наоборот. Один решит что можно и пропустить слой домена и вызвать из API сразу Repository, чтобы сохранить несколько тактов процессора. А другой решит что так нельзя. И каждый из них по-своему прав. Слоненка она такая…

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

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

Очень интересно. А мы попытаемся разобраться в причинах.

Я решил подвести итоги по опросу:
70% Layered Architecture превращается в Big Ball of Mud
и только 9% Clean Architecture.

Поделился своими выводами вот здесь https://youtu.be/zl-wsU_Frd4

Господа, продолжение цикла про Clean Architecture. На этот раз рассматриваем на примере. И без кода! https://youtu.be/W6jCUNb3yPg

Реальная история как я ходил на собеседование.

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

Прихожу:
- Привет
- Привет
- (и с порога) Что ты можешь сказать о коллекциях в Java?
Тут мне показалось что хорошего диалога не выйдет. Ну, оказалось что не казалось
- Ну говорю, чего там у нас Collection, который вроде как Iteratable, и Map в стороне сиротливо стоит. Ну и вот от коллекшена унаследованы, List, Set, Queue и что там еще
- а еще там Стек есть.
- Круто, да.

- Ну ок, а расскажи как HashSet работает
⁃ Я говорю черт его знает, надо будет — посмотрю исходники. Но название намекает на то что внутрях то используется HashMap. Вот ключ явно Хеш, а значение… хим, может сам объект, может Список а может еще что
⁃ Знаешь, а там вот дерево используется
⁃ Круто. Рад за них

⁃ Как реализована SyncronizedHashMap?
⁃ Ну говорю, в жизни не видел, так как она вроде устарела еще до моего рождения, но намекает что наверное ацессоры синхронизированы.
⁃ Мммм, ну там не сам аццессор синхронизирован, а бакет внутри мапы.
⁃ Круто, расскажи мне еще про бакеты 🙂

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

Мне очень хотелось сказать: Вот тут мое мнение, что нужно спрашивать на собеседованиях. Если не согласен — напиши комментарий. И лайкнуть не забудь.
Но меня же мама с папой учили что грубить людям нельзя, поэтому я, видимо остался без нового подписчика 🙂