http://securitygym.ru/
https://github.com/yandex/securitygym

Ребята из Яндекса сделали свой мини портал для обучения своих команд навыкам безопасной разработки. Минимальная инфа из owasp top 10 + песочница для теста. Курс изначально доступен при онбоардинге нового сотрудника но можно пройти и отдельно.
В целом идея делать такие курсы и вставлять их в онбоардинг идея хорошая (и логичная).

Отличная возможность почитать и посмотреть какого уровня проблемы встречаются в Gitlab. Список инцидентов и как их решала инфраструктурная команда GitLab.

https://gitlab.com/gitlab-com/gl-infra/production/-/issues?label_name=incident

Отдельные проблемы (2021-05-25 Customers.gitlab.com down (filled filesystem)) прям напоминают что, в целом везде бывают факапы) даже у таких известных компаний.
Помните об этом и вы.
https://gitlab.com/gitlab-com/gl-infra/production/-/issues/4716

Stackoverflow запустили очередной developer survey.
Прошлый опрос был в феврале 2020, потом бахнул covid. Так что результаты этого опроса будут интересными. Проходим, отвечаем.

https://stackoverflow.blog/2021/05/25/the-2021-developer-survey-is-now-open/

Посмотрел доклад Haley Tucker из Netflix Resilience Engineering team.

Чем зацепило. Тема canary releases уже давно обсуждена, казалось бы, что тут еще можно придумать, бери и делай.

Но здесь эту тему модицифировали и применили для совершенно другого процесса. У команды Haley Tucker была необходимость тестировать плеер netflix на разных устройствах, начиная от браузеров и мобилок и заканчивая телевизорами и приставками. Придумали термин Sticky canaries, по аналогии со sticky sessions клиент выделяется в группу на все время теста (или релиза). В чем тут плюс, вы видите все время одного и того же клиента и можете наблюдать как его взаимодействие с новым сервисом влияет на более длинном промежутке времени, так как обычный canary, придусматривает просто выделения части "какого-то" трафика.
В целом это чем-то похоже на A/B тесты. Т.е. они могут направить одного конкретного пользователя на новую конфигурацию сервисов и спокойно снять метрики или протестировать что-то.
Платформма их собственная, сначала использовалась для Chaos тестирования, а потом переросла во что-то большее.

Пока искал исходники самой платформы, нашел что есть открытые аналоги, вот например Сhaos toolkit. Надо тестить.

https://www.infoq.com/presentations/sticky-canaries/

Ребята из проекта "Инженер заходит в бар" анонсировали интересный выпуск. Про трансформацию карьеры Dev-to-TeamLead. У них интересные дискусси рождаются на стримах. Заходите.

https://miro-event.timepad.ru/event/1650491/

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

https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/

Вдогонку к статье, оказывается уже есть FinOps. Collaborative, Real-Time Cloud Financial Management

https://www.finops.org/

Уверен что почти в каждом проекте где есть мобильные приложения и отправка пушей клиентам случалось такое. Или кто-то отправит дубли на всех или кто-то отправит легендарное "test".

Компания Buffer давно известна своей открытостью, то что у них открытая аналитика я читал. Например вот https://buffer.com/revenue. Но оказывается у них еще и открыты зарплаты. https://buffer.com/salaries.

Похоже что для выхода с удаленки понадобится еще год как минимум)
Давить опасно, сотрудники могут уйти к другим, кто предложит full remote. Сложна.

Apple employees rally against office working plan - BBC News
https://www.bbc.com/news/technology-57385999

https://status.fastly.com/

38 минут ушло чтобы починить глобальный CDN сбой на Fastly

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

https://blog.pragmaticengineer.com/uber-app-rewrite-yolo/

Отличная статья о том, как относится к советам в ИТ. Чем более общий совет вам дают, тем больше вопросов вы должны спросить у советующего и тем более настороженно следует отнестись к этому совету.

Software development is full of confident forecasters. We are a pretty new field, and yet everyone seems so sure that they have the best solution to whatever problem is at hand. I’d like to hear more people saying things like, “in this specific context, test-coverage seem like an important metric,” or “StopLang is great if you can afford the GC, but if you can’t, then you should look at IronOre.” A great tool is not a universal tool it’s a tool well suited to a specific problem.

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them. The more specific and contingent the advice - the more someone says ‘it depends’ or ‘YourSQL works well in a read-heavy context with the following constraints’ the more likely they are to be leading you in the right direction. At least that’s what I have found.

https://earthly.dev/blog/thought-leaders/