Если уже ознакомились с 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/история-микросервисов/

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

Давненько ничего не писал, был завален работой. Наконец-то полегчало, поэтому пару слов

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

1) Практически не теряли время просто так и шли на максимальной скорости. Никаких ожиданий пока соберется сборка где-то там на билд-сервере, протыкиваний вручную или поиски нужного параметра, чтобы запустить проги локально. Но потребовало напряжения в самом начале. CI должен быть вашим внутренним продуктом с соответствующим отношением.
2) Благодаря тестам интеграция разных частей системы прошла лучше чем ожидалось. Сидеть втроем и пялить в дебаг не нужно
3) Анемичная модель - зло. Только нормальная инкапсуляция помогает справиться со сложностью предметки. При анемии уже через месяц получается непролазная каша
4) Гексогональная/чистая архитектуры - сложная для понимания концепция, особенно если привык клепать круды в слоенках

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

Zero trust. Подборка документации для архитектора.

https://www.redhat.com/architect/what-is-zero-trust

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

Первое, что может помочь - это определение типа ограниченого контекста. Если контекст не основной, а скажем неспециализированый (деятельность, которая одинаковая для разных компаний), то можно найти под него готовое решение и вообще не мучиться. Например взять какой-нибудь keycloak для управления доступом пользователей и не мучиться. Если контекст основной (основная деятельность компании, то чем она отличается от остальных и зарабатывает деньги) или специализированый, но он выглядит как максимально простой CRUD, то можно заиспользовать Spring Data Rest или же вообще взять что-то из Almost Zero Code вроде Retool. Получаем быстрый старт и проверку гипотезы о сложности предметной области. Если почувствовали, что штаны становятся маловаты, значит пришло время перейти на что-то посложнее.

Хороший обзорный пост про функциональное программирование https://habr.com/ru/company/jugru/blog/553028/

Чем нам грозит GPT

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

И если встарину разработчики на вопрос о замене человека ИИ лишь снисходительно улыбались и говорили «мы будем последние кого заменят», то теперь некоторые наблюдают за этой шайтан-машиной крепко сжав булки. Только на прошлой неделе получил несколько сообщений в личку вроде «ТЫ ВИДЕЛ????777 НАС ЩАС ВСЕХ УВОЛЯТ!!111адинадин». Но давайте не будем паниковать и подумаем, какие последствия могут быть для нашей уютной айтишечки.

Если брать весь процесс целиком, то нужно вспомнить, что разработка не состоит только из одного программирования. Тут вам и разработка требований и проектирование и обеспечение инфраструктуры и CI и тестирование и эксплуатация и много чего еще. Не сильно ошибусь, если скажу, что программирование занимает не больше половины от всего процесса. И собрать в кучу данные этапы и получить непрерывный конвейер по производству изменений (результат нашей работы не софт как таковой, а его изменения) не всегда могут даже целые коллективы не самых глупых людей. Это очень сложная и слабо формализованная штука и на данном этапе я сильно сомневаюсь, что машина может с этим всем справиться.

Но можно попробовать с помощью нее решить узкоспециализированые и/или рутинные задачи. Например:
- Программирование. Да-да, оно может быть очень скучным и унылым. Если вы придерживаетесь стандартов, о которых я говорил вот в этом ролике, то многие части программы будут выглядеть очень похожими. Можете посмотреть например на юзкейсы в наше референсном проекте. Они достаточно разнообразные, чтобы генерить их шаблонами, но логика очень схожа. Мне кажется самое оно для таких умных штук вроде ChatGPT (а то и проще)
- Разработка небольших прототипов или утилит. Чуть более продвинутая вещь чем предыдущий пункт, но все же очень ограниченная. С тем условием, что на внутреннее качество плевать. Тут может получиться интересно, что слегка умрет рефакторинг, ибо робот не умеет исправлять, ему проще сгенерировать заново.
- Фаззинг при поиске уязвимостей. Подаем на вход валидный запрос, на выходе имеем список пейлоадов.
- Поиск граничных значений и разработка негативных сценариев при тестировании и т.д.

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

З.Ы.: если у вас есть мысли какие действия можно поручить этой шкатулке с чудесами, то делитесь в комментариях, будет интересно почтитать.

Приятно, когда твои ученики растут и начинают участвовать в жизни индустрии.

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

https://dev.to/karvozavr/the-four-horsemen-of-software-complexity-architecture-decision-records-to-the-rescue-1211

Чему мы учим можно посмотреть на специальном лендинге.