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/

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

Вот что нашел, в топе Adobe, Intel, PayPal, остальные уже мало известные.
На примере Adobe - перечисленных за 5 лет работы вы получаете 4 оплачиваемых недели (20 рабочих дней).

https://www.glassdoor.com/blog/42136-2/

А вот список из Fortune (по состоянию на 2018 год): VmWare, FedEx
https://fortune.com/best-companies/2018/search/?sabbaticals=true

Ну и еще одна ссылка на исследование, судя по нему у Sabbatical больше американские корни и популярность его там выше.

A multinational study has revealed that Americans are the
most in need of an extended break, such as a sabbatical, with over half (52%) admitting that a ‘planned strategic work pause’ would improve their mental health. Americans rated much higher than all of the 12,0000 respondents in the eight countries surveyed (European average 39%)

https://www.edreamsodigeo.com/wp-content/uploads/sites/19/2017/09/Sabbaticals-U.S.-14SEP17.pdf

Cheat sheet: 10 Java security best practices

"А давайте сделаем сервис на 100% доступным". Хороший пост рассказывающий чего вам это будет стоит. Авторы говорят о 10x increase in development costs(!)
Спойлер, определите уровень который нужен вам, вряд-ли это именно 100%, каждая 9 после 99% стоит оочень много.

"Say a feature is estimated to take 20 days of development (including design). Add a further 10 days for testing (using the top end industry estimate of one-third time), and you have a total of 30 days cost for the good reliability feature. For the 100% reliability feature, we need much more testing, around 200 days using Colm’s talk. That means a total of 30 days for adding a feature with good reliability becomes 220 days for 100% reliability. More than seven times the cost. These are just rough estimates, but conservative and indicative of how there is a 10x increase in development costs."

https://medium.com/expedia-group-tech/the-cost-of-100-reliability-ecb2901f23a4

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

https://grafana.com/blog/2021/06/22/grafana-dashboard-showcase-visualizations-for-prometheus-home-energy-usage-github-and-more/

IT Revolution - это издательство которое подарило миру такие известные книги как - DevOps Handbook, The phoenix project, The unicorn project, Accelerate.

У них есть инициатива Bookclub. Каждую неделю выбирают одну главу из книги, читают, обсуждают, делают задания. Отличная практика выражения своих мыслей на английском.

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

https://itrevolution.com/bookclub/

Тут немного писал про издательство и автора Gene Kim https://xn--r1a.website/neverendingit/113

В комментариях спросили про ИТ книжный клуб у нас в компании. Раскрою тему.

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

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

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

К пятнице договариваемся в чате прочесть до определённой страницы и потом встречаемся обсуждаем, что мне запомнилось из прочитанного и приводим какие-то цитаты из книги. Важно предупредить всех быть готовыми рассказать что им запомнилось с выдержали из книги. Это такое ДЗ.
В процессе обсуждения появляется много разных инсайтов, обмен опытом, опыт с предыдущих компаний.
Состав тех кто приходит на встречу может меняться, на мой взгляд это ок.

Важный момент! Изначально я договорился читать книгу с одним из участников команды, т.е. у нас с ним был "контракт", даже если никто не прийдет из доп участников, он будет) это было его частью плана развития. Я просто решил это расширить на всю команду.

Что понял: дело трудозатратное, даже для 5-6 человек. Вам надо самому прочитать и быть готовым вести встречу.
Понял что расширять на все ИТ или все команды в компании не смогу и пока не хочу, все таки тут нужно это вклинивать рабочий процесс, ну либо сделать чтобы были разные ведущие.