Если вы не можете объяснить начальству что такое технический долг и легаси, то вот вам хороший пример от нетехнаря (поэтому могут быть неточности), но со способностью хорошо объяснять сложное.
https://vitalyfilatov.ru/all/techdebt-and-legacy/

Продолжается прием заявок на доклады конференции по архитектуре IT-решений ArchDays 2022!

В этом году мы возвращаемся в офлайн!
Конференция пройдет 21 октября в Москве + Online-трансляция.

Основные тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре/развитие в архитектора
5. Soft skills
6. Кейсы

Всего в программе будет около 30 докладов и 4 очных воркшопов.

Подать заявку на выступление: https://archdays.ru/#speaker

Кажется мой доклад взяли на ArchDays 2022!

Новое видео на нашем канале. Наводим порядок в проекте, смотрим примеры, делаем выводы

👓OWASP TOP-10

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

Вообще, сам проект OWASP (Open Web Application Security Project) - это некоммерческая организация, нацеленная на повышение защищенности веб-приложений.

Помимо рейтинга уязвимостей, там есть еще немало интересного, например:
- Инструмент для поиска уязвимых зависимостей в Java
- Популярный сканер веб-приложений OWASP ZAP
- Руководство по тестированию веб-приложений
И многое другое. Полный список на этой странице

#Безопасность

Если уже ознакомились с OWASP'ом, то вот вам следующий материал, который касается более общей темы по безопасности.
Это CIS Сontrols (на данный момент версии 8 ) от некоммерческой организации CIS (Центр Интернет Безопасности).
Здесь собраны рекомендации для организаций, которые хотят повысить свою защищенность. То есть не для конкретного ПО, а для организации в комплексе (хотя про ПО там тоже есть). Можно сказать это некий ИБ-фреймворк.

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

Выглядит как отличная отправная точка для тех кто хочет поправить ИБ-здоровье в своей компании.

#Безопасность

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

- Один из самых популярных ресурсов HackTheBox Распространяется как SaaS, много бесплатных лаб.
- Vulnhub. Много виртуалок с уязвимостями (которые нужно скачать и запустить), но почему-то последняя активность в ноябре прошлого года.
- OWASP Juice Shop - уязвиомое веб-приложение от OWASP, содержит весь TOP-10 и много чего еще
- Список узязвимых приложений от OWASP
Думаю вы без труда найдете похожие проекты.

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

👨‍🚒Вебинар управление тех долгом.
Господа, мы готовим новый вебинар по теме управление тех долгом: как его продавать и кому. как работать с командой, чтобы он был не только вашим головняком, а общим. и в конечно итоге как его минимизировать.
Нам очень нужно понять что именно вы бы хотели узнать о борьбе с тех.долгом, какие проблемы есть у вас. Я Буду очень благодарен, если вы напишите в комментарии к этой записи свои проблемы и соображения. А мы постараемся включить их в программу вебинара и вышлем вам приглашение на него 😉

Спасибо! 🙏

📺Как отвечать на вопрос “Каковы ваши зарплатные ожидания?”. Поговорим про это в сегодняшнем ролике https://youtu.be/_kGt-dW7O-w

Спойлер: ответ зависит от того, на каком этапе собеседования вы находитесь. Приятного просмотра!

Вы или ваши коллеги считаете тесты 2nd class Citizens?

Kevlin Henney в своем недавнем выступлении убедит вас почему тесты лучше писать вместе с продакшен кодом. И более того, покажет почему тесты пишутся не только для компьютера, но и в НЕ меньшей степени для людей. + Огромное количество рекомендаций по лучшим практикам написания тестов.

Приятного просмотра! https://www.youtube.com/watch?v=MWsk1h8pv2Q

Мы строили, строили и наконец, построили.

Всем привет! На прошлой неделе у нас не было постов, потому что мы готовили документы для формального учереждения организации и таки учередили ее.
Теперь мы не просто канал, а целая региональная общественная организация "Объединение ИТ-Архитекторов".
Учередители:

- Баранов Сергей @sergey486
- Геннадий Круглов @GKruglov
- Лукьянов Евгений @elukianov
- Закревский Иван @emacsway

Почитать устав и ознакомиться с целями можно тут. По вопросам вступления обращаться в Joining Bot: @ru_arc_bot

Новое видео: 8 моих принципов эффективного рефакторинг
https://youtu.be/1pZ6UvyIfdY

1. Выработайте общий вектор рефакторинга
2. Начните с тестов
3. Переписать все - плохая идея
4. Двигайтесь маленькими шажками
5. Составьте план Рефакторинга
6. У вас должна быть веская причина для рефакторинга
7. Новая технология не повод!
8. Примите неудачи

Актуальное! Релокация в Сингапур для Программистов.
Если вы Сеньор разработчик и знаете английский - то это видео точно будет вам полезным https://youtu.be/4pt35Dy5MIk
Узнай как переехать в фантастический Сингапур за месяц!

Code duplication.
Думаю более опытные разработчики на своем опыте уже поняли что дублирование кода - не всегда плохо. Да и Дядюшка Боб в своем SOLID’е об этом же упоминает. Но косвенно. Но молодые разработчики просто одержимы устранением дублирование, которое ведет к увеличению coupling’а.

Если у вас есть в команде такие приверженцы устранения дублирования no matter what Просто дайте им посмотреть это видео https://youtu.be/OkDrlNY5mMc

Выступил сегодня на ArchDays 2022. Спасибо организаторам за такое крутое мероприятие!

Technology Radar 27 released!

На наш взгляд самое интересное в данном выпуске не технологии, а техники.

Path-to-production mapping. Техника, похожая на эвент шторминг, только в результате получается не бизнес-процесс, а процесс доставки софта от ноутбука разработчика до продакшена. Как происходит? В одной комнате запираются все заинтересованные лица: разработчики, дизайнеры, аналитики, можно даже пару пользователей посадить и на доске рисуется процесс доставки, непрерывно задаются вопросы “а зачем так”, “а что, если вот тут произойдет нечто”, “а можно ли лучше”. Практика обещает что таким образом процесс получается более проработанным и всеобъемлющим.

Team cognitive load. Судя по всему продолжение Закона Конвея о том что архитектура ПО повторяет структуру команды. Техника советует при разбиении на команды принимать во внимание размер когнитивной нагрузки на команду и контролировать нагрузку со временем. Команде стало тяжко - дроби. Слишком легко живется - объединяй. Прилагается шаблон для отслеживания когнитивной нагрузки. (Напишите в комментариях если использовали)

Threat Modelling - Мне кажется всем понятно что надо использовать модель угроз. Мне кажется технику включили в радар, чтобы в очередной раз напомнить, что недостаточно создать модель угроз в начале проекта и положить ее в стол. Ее надо периодически обновлять и анализировать как ваше ПО и вы сами на эти угрозы можете реагировать.

Observability for CI/CD pipelines - С тем что очень важно понимать что происходит на продавшее вроде уже все смирились. Логи собираются, метрики пишутся, дашборды строятся. Но Не менее важно имплементировать пайплайн таким образом, чтобы было понятно что там внутри происходит, где он отвалился в этот раз и почему. А еще было бы не плохо понимать его эволюцию со временем. Почему вдруг в этом месяце сборка начала занимать в среднем на минуту дольше, а деплой на целых 5.

Thoughtworks Technology Radar https://thght.works/3sw3Hlr

Делитесь в комментариях что интересного нашли вы!

Возможно вы пропустили, но вышел новый отчет State of Devops 🙂 https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf

Несколько интересных фрагментов
«Надежные (Dependable) команды обеспечивают надежный(Dependable) сервис: творческая командная культура ведет к большей надежности».

Мы видим, что люди с меньшим опытом в целом имеют худшие результаты при использовании trunk based development. (Что и не мудрено. Вы попробуйте trunk based, когда, скажем у вас тестов нет. прим stringconcat)
Хотя она оказывает положительное влияние на общую эффективность организации» (есть предположение о том, что этот результат является неожиданностью, и возможные причины включают гораздо более неопытных участников, чем в предыдущие годы)

«Исследование этого года показало, что loosely-coupled architecture (слабосвязанная архитектура) может способствовать выгоранию команд.
Это удивительное открытие, которое противоречит результатам предыдущих лет. Наш анализ показывает, что стабильно
команды, в которых используется loosely-coupled architecture, имеют более низкий уровень выгорания. Генеративная культура Westrum и стабильность команды поддерживают слабосвязанную архитектуру и снижают выгорание, так что это явно противоречит друг другу. Необходимы дополнительные исследования, прежде чем мы сможем сделать окончательные выводы».

«Самый важный фактор, который мы обнаружили, был вовсе не техническим, а скорее культурным: организации, наиболее близкие к «генеративной» культурной группе Westrum, значительно чаще говорили, что у них широко распространены методы обеспечения безопасности, как это определено в рамках SLSA».

Если вам не знаком термин Westrum Cultrue (как и мне), то вот тут сам Профессор Westrum объясняет. https://youtu.be/gKH3Y4G8TfI?t=107 К слову, многие интуитивно чувствовали это при выборе компании. Но вот оказывается есть четкое определение

Закончил краткий пересказ статьи «Microservices: The Evolution and Extinction of Web Services?» за авторством Luciano Baresi и Martin Garriga 👌

abstract
Еще 20 лет назад SOA и Web Services были на пике популярности. Это был самый настоящий хайп. Особенность хайпа в том, что его применяют ради хайпа, а не для пользы дела, в массе своей даже не разобравшись в сути явления или технологии. Такое положение дел привело к тому, что количество определений и трактовок SOA и Web Services было примерно равно количеству внедрений Это, в свою очередь, приводило к тому, что проблема подгонялась под решение. Сегодня то же самое происходит с микросервисами. Авторы статьи исследуют эволюционный путь от SOA к микросервисам на основе анализа литературы, как академической, так и научно-популярной.

http://agilemindset.ru/история-микросервисов/

Приятного чтения 🧠