На картинке "World’s First Computer Bug" 1947.

Скорее академический видос, в котором автор рассказала происхождение многих ИТ слов, bug (боян, но картинку c жуком приклееным скотчем к документу я увидел впервые), foobar, shell.

Короче один раз для общего развития полезно посмотреть.
https://www.youtube.com/watch?v=2KTK2qD4-gs

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

Quantify the problem and success criteria
Определите проблему и критерии успеха, да это может выглядеть как занудство, но это правда важно, даже если вы просто разработчик. Попытайтесь понять как вы измерите успех. Если вы менеджер или вид, важно вдвойне, вам потом отвечать перед бизнесом а может-быть даже и продавать эту идею.

Start with a tracer bullet
Начните с какого-то действия которе даст вас проверить самый большой риск или проверить саму концепцию идеи. Желательно чтобы задача была короткой и вы могли ее сделать от начала до конца, пусть даже и на заглушках.

Work in small, end-to-end increments
Работать малыми инкрементами, от начала до конца. Очевидно вроде, но как много мы все ошибаемся в этой части. Жадность, желание побыстрее закончить. "Эта задача не делится на части и ее нельзя сделать отдельно." - самая распространенная отмазка)

Prioritize increments by risk and value
"Fail fast" тут тоже подходит, выбирайте задачи по приоритетам, если все еще рисковые, можно взять их раньше.

Use ratcheting to prevent regressions
Подумайте как предварить регрессию в проекте. Например если вы мигрируете на новую библиотеку, вам нужен способ как исключить использование старой, но так чтобы не мешать процессу разработки в целом.

Start what you finish
Закончите наконец работу и принисите пользу)

https://leaddev.com/technical-direction-strategy/making-big-changes-successfully

Вышел State of DevOps Report 2021 от Pupet.

Больше всего зацепился за картинку сделанную по мотивам книги Team Topologies,
Легко и понятно описаны все виды команд и их область ответственности

https://puppet.com/resources/report/2020-state-of-devops-report/

Хорошая статья-рассуждение на тему, что есть технические решения в проектах и как они пересекаются с целями бизнеса.

Всю статью можно сосредоточить в замечательной фразе.

Our role as developers is to guarantee that the business can prosper through evolving software.

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

https://guifroes.com/no-such-thing/

15 лет назад, на Agile конференции было представлено то, что сейчас называется CI Pipeline/Build pipeline. Офигеть - 15 лет!

https://dl.acm.org/doi/10.1109/AGILE.2006.53

https://continuousdelivery.com/wp-content/uploads/2011/04/deployment_production_line.pdf

Вышел Developer Survey 2021 от Stack Overflow

https://insights.stackoverflow.com/survey/2021

Классный доклад про разные структурные и процесные изменения в Тинькофф на уровне инфраструктуры/девопс.

Чем зацепил:
- вижу параллели со своим опытом, по мере роста количества разработчиков тоже были такие изменения, верю докладчику, авторизую свой опыт;
- сжато рассказано про изменения процессов если у вас в компании 1000+ девелоперов. Каждый новый рост вашей компании/команды разработки требует другого подхода;
- платформа разработки это прям моя мечта, а платформа разработки как продукт, это прям очень очень круто. Надеюсь мне доведется когда-нибудь поработать с таким продуктом/платформой;
- докладчик рассказал про факапы. У них не получилось в полной мере привить разработчикам культуру, "you build it, you run it, you own it" ;
- Kubernetes as a Service в рамках компании, на чем обожглись;

DevOps-эры в Тинькофф: культура, люди, инструменты

https://www.youtube.com/watch?v=VLcMAS_lIQw&t=12115s

Интересные вопросы и ответы от крупных светил мира Java

Four top Java architects—Mark Reinhold, chief architect of the Java Platform Group; Brian Goetz, chief language architect for Java; Mikael Vidstedt, director of software engineering for the Java Virtual Machine; and Ron Pressler, consulting member of the Java technical staff—answer six questions about Java’s vibrancy, the group’s priorities, and the future of the platform.

https://blogs.oracle.com/javamagazine/java-architects-loom-panama-valhalla

Уровень "взрослости" Rest API.

http://blog.restcase.com/4-maturity-levels-of-rest-api-design/

Тоже самое у Фаулера
https://martinfowler.com/articles/richardsonMaturityModel.html

Очень крутой лонгрид про эволюцию протокола HTTP и для чего она вообще нужна (какие проблемы хотят решить)

HTTP->HTTP/2->HTTP/3

https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/

Шпаргалка по написанию комментов из блога StackOverflow

https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments

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

Вообще конечно в какой-то дефицит продуктов для разработчиков. Все делают или 101 Api testing tool (postman) ну или крупные корпорации пишут AI-Pilot.

Напишите в комментах какой продукт вы нашли за последний год который увеличил вашу персональную продуктивность или продуктивность процесса разработки в вашей компании?

https://stackoverflow.blog/2021/08/25/see-where-your-engineering-process-go-wrong-with-data-visualization/

Сегодня второй день конференции https://springone.io/, записи обещают по окончанию.

5 треков
- Beginner-Friendly Spring
- Intermediate/Adv Spring
- Architecture
- Cloud Native Platforms
- Agile Leadership
- Social

Запиши прошлого года (Spring One 2020) здесь, попозже разберу лучшие и поделюсь с вами.

Очень крутой отчет от JetBrains, по первых он русифицирован, во вторых читая методологию тестирования увидел что его перевели на 6 языков!, конкретно заморочились)

Кстати интересный факт заметил на себе, читая результаты такого объемного отчета на русском, кстати первый раз наверное. Мозг автоматически пытался применить/интерпретировать эти результаты как результаты опроса со стран СНГ и только благодаря тому, что в отчете была информация об языке опрашиваемых и странах удалось это корректировать.

https://www.jetbrains.com/ru-ru/lp/devecosystem-2021/

Sonatype (разработчик Nexus) запустил небольшой локальный курс по DevSecOps,

A Policy-Centric View of OSS Threats
" You'll learn ways to:

Determine which of your open source dependencies are vulnerable and the severity of the vulnerability.

Implement an automated process to detect these vulnerabilities early on in the software development lifecycle.

Create automatically enforced policies with rules for when certain risks are detected.

Automate workflow features for when policies are violated "

https://www.devsecops-academy.com/event-information/21

После сканадала с алгоритмом обрезания фоток в twitter решили сделать Bug bounty для поиска проблем с алгоритмами. На моей памяти это первый кейс вознаграждения не за проблемы безопасности. Запустили на платформе HackerOne.


https://blog.twitter.com/engineering/en_us/topics/insights/2021/algorithmic-bias-bounty-challenge

https://hackerone.com/twitter-algorithmic-bias

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

Подобрал свой топчик, а ведь и правда тяжело принять правду):

- “Deploys are scary, so we need to slow down and be careful.”(slow motion bias)

- “We’ve already invested a ton of engineering hours into building a deployment framework that doesn’t ship especially fast and doesn’t ship one change at a time, but it works, and we don’t want to have to redo everything from scratch.” (surrogation, ostrich effect, irrational escalation, ikea-effect, law of the instrument)

- “The best way to protect people’s personal time is to let merged code pile up between Thursday night and Monday morning, and ship all at once.” (continued-influence effect, plan-continuation bias, pseudocertainty effect, zero-risk bias)

https://charity.wtf/2021/08/27/software-deploys-and-cognitive-biases

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

на картинке браузер Mosaic - 1993 год.

https://blog.mozilla.org/en/internet-culture/deep-dives/why-are-hyperlinks-blue/

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

1. Генерация интерактивных архитектурных схем продукта/проекта. Вы скажете, "Да есть же diagrams.net (draw.io)", но это ведь вам нужно постоянно синхронизировать ее, а пробовали расположить все эти кубики/сервисы на одном листе да так что было еще красиво и одновременно помещалось на лист? Это отнимает прилично времени, ну или я не знаю какого-то таинства. Да и потом каждый блок на схеме можно расписывать бесконечно, как схему сделать более живой (вложенные ссылки)?

2. Inventory managment - все эти десятки и сотни микросервисов уже становится боевыми единицами, о них надо знать, версия, статус, целики, апи, команда которая отвечает. И вот вся эта информация может быть размазана по 3-4 системам (git (gitlab.github), kubernetes orchestration platform (rancher),jira/confluence), почему и как они связаны.

3. Авто-документация - тут самое лучшее что пока изобретено это javaDoc и разные openApi/Sqwagger генераторы. На мой взгляд кому и надо было бы пойти в эту сторону так это Spring community, можно поиграть с ast проекта и получить документацию вообще другого порядка, да она будет 90% из кода, но это что иногда надо, быстро глянуть дерево вызовов, посмотреть дергать ли этот API метод какой-то внутренний сервис. И опять таки если покрыть это аннотациями можно получить новый сваггер, но уже другого порядка