#monitoring
История про то как Pinterest строит anomaly detection. С алгоритмами и блекджеком)

#devops
Тут парни из Авито на днях рассказывали про Live Site Review. Пошел погуглить про сабж, чет ничего особенно не нагуглилось, но нашел видосик как LSR делает Микрософт. Круто, интересно, хоть и щедро приправлено рекламой TFS
P.S. осторожно, шотландский английский))

Красивый однострочный постмортем от Monzo.

TLDR: добавляя новые машины в кластер, убедись, что у них есть хоть какие-то данные. Ну и читай доку.

https://monzo.com/blog/2019/09/08/why-monzo-wasnt-working-on-july-29th

PS: однострочная причина фейла

Котаны и котанессы, нашел мега-крутой научпоп видос про медиа-процессинг. В пятницу под пивчанский самое то!

Хорошая статья о непопулярных техниках автоматической генерации тесткейсов: символьное выполнение, тестирование с помощью моделей, комбинаторное тестирование, адаптивное случайное тестирование (adaptive random testing) и тестировании на основе поиска (search-based testing). Для каждой техники описаны базовые идеи, практическая применимость, существующие проблемы и перспективы.

https://cs.stanford.edu/people/saswat/research/ASTJSS.pdf

Кстати символьное выполнение можно попробовать прямо в браузере - http://klee.doc.ic.ac.uk/

#непишитетесты

Очень крутая статья, и все это действительно работает(я знаю людей, которые юзают и Model-Based и SBST), но, во-первых, этих людей единицы (по крайней мере, на пост-советском пространстве), а во-вторых, их услуги стоят конских денег, и не каждая галера может себе это позволить(даже ынтерпрайз). Гораздо проще и дешевле ведь нанять кучу кожанных ублюдков джуниоров, прочитавших Савина, которые будут регрессить руками.
White-box тестирования, кстати, не видел вообще ни разу(тоже на пост-советском)

Kubernetes security notes and best practices

Советы и заметки по безопасности Kubernetes.

https://github.com/kabachook/k8s-security

Ваще обычно обхожу тему сесурити, т.к. некомпетентен чуть менее чем полностью...но, блин, тут есть attacker's guide!
пошел взрывать кубернатесы

Напомнили в одном из чатов про серию книг The Architecture of Open Source Applications

Довольно занятное чтиво о том, как устроены БД, парсеры, компиляторы, очереди и прочие вещи.

Онлайн читать не сильно удобно (иногда текст слишком широко размазан), но проблема решаема. В общем неплохое чтиво.

http://www.aosabook.org/en/index.html

Митап по SRE

Когда: следующий вторник, 27.08 с 19:00 Мск

Что: митап с ведущими DevOps Deflope, руководителями инфрастуктуры и инженерами Skyeng и Nvidia, а также лидером питерского комьюнити

Где:
- Москва, м. Таганская - количество мест в зале ограничено. Нужна регистрация
- Онлайн - на YouTube

Цена вопроса: Free

Как попасть: все ссылки на регистрацию, трансляцию, а также бонус - блиц с докладчиками - можно найти тут

#event

Перевели для блога очередной занятный материал по близким нам темам — про distributed tracing и его сложности: https://habr.com/ru/company/flant/blog/460365/

Интересный видос про то зачем теоркат в реальной жизни(дада, котаны, все-таки пригодился)

#dotnet
Тут коллега принес набор полезных dotnet tips and tricks от царь-архитектора МС. Знаю, что вы не особо фанаты, но вдруг пригодится 🤷‍♂️

Иногда заполнение и отправка web-формы превращается в проблему: например, непонятно, к какому полю относится лейбл или сообщение валидации говорит, что есть ошибка, но не говорит, где именно и т.п. Адам Силвер написал статью о том, чего лучше всего избегать при проектировании форм и чего стоит придерживаться — "Form design: from zero to hero all in one blog post".

Вот несколько интересных моментов. Следует избегать форм с многоколоночной раскладкой, так как более 10% пользователей, не могут заполнить такие формы правильно. В поля ввода, которые отвечают за ввод грамматически неправильных данных (например, email'ов), следует добавить атрибуты autocapitalize="none", autocorrect="off" и spellcheck="false", чтобы браузер автоматически не изменял вводимые данные. Используйте <select> только в самой безвыходной ситуации, потому что им неудобно пользоваться. Вместо него лучше всего использовать radio-кнопки или <select> с автодополнением для очень большого списка опций.

Статья очень хорошая с большим количеством ссылок на другие полезные статьи по теме. Рекомендую почитать.

#ux #forms

https://adamsilver.io/articles/form-design-from-zero-to-hero-all-in-one-blog-post/

#ux
Статья про основы(точнее про основные ошибки) UX. Интересненько, с примерами, можно побомбить вместе с автором от селектов с кучей вариантов😎

#ml
Для тех кто удивляется, почему ему не дают кредит, вышла статья про банковский скоринг на шпагах пальцах

Очередной материал от наших инженеров — обзор утилит, помогающих разработчикам, живущим [по своему ли желанию, по принуждению ли…] в Kubernetes: https://habr.com/ru/company/flant/blog/462707/

90% фич вылетает в трубу

Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.

9 из 10 фич. Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями — вот сейчас сделаем и заживём!. Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?

Вместо пиления фич вы начнёте проверять гипотезы.

Ваш код тоже станет совсем другим — вы начнёте тратить время не на фичи, а на скорость производства новых фич.

Помните мой совет со входом через инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.

Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.

Согласен на 146.6. Особенно зацепило "...вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?"
Имхо, основная проблема тут в том, что надо еще отличить функционал, который будет подвержен пользовательскому тестированию(и выкинут с вероятностью 90%) от фундаментальной телеги(oauth из примера с инстаграм-авторизацией), на которой можно проверить 100500 гипотез, и которую надо делать хорошо и сразу.
Чуйка нужна какая-то))