I hate overtime

Тут чет опять начался холивар про то, что DevOps -- просто хайп и это просто очередной алиас для одмена(как и sre). Щас может обидно будет, так что заранее сорян.
Кароч мое мнение, что парни правы. DevOps и SRE по большому счету просто позволило поменять тайтл в резюме и хайпануть на конфах и медиуме, но, основная телега в том, что подкачала не идея, а реализация. Проблема была изначально такая: большая часть operations не очень понимала чем они собственно оперируют. Они не знали(да и не очень интересовались) тем как их софт работает, как он должен работать, какие есть проблемы и как их можно порешать. Все это традиционно летело через забор на сторону разрабов, которые тоже были не очень в восторге от такого jira-пинг-понга. В итоге парни посидели, подумали и решили, что тикета а-ля поменять входные параметры в коде, что-то выкинуть в конфиг, подружить софт с CI и другие консерны operations к софту может реализовывать сам operations.
Google пошли дальше и решили отдать (почти)все НФТ на откуп специальной команде(sre).
Понятно, что для успешного решения таких задач не достаточно просто админских компетенций и нужно еще и уметь в разработку в той или иной степени. Упрощая все до нельзя получаем:
Админ + codding skills = DevOps
Админ + software development skills = SRE

Но т.к. это толком нигде не формализовано, то просеять тех кто реально нужен кампании среди админов почти невозможная задача. Мы частично решили ее, добавив в вакансию пункт а-ля "знание одного из менстримовых ЯП на уровне Junior". Кол-во откликов уменьшилось в разы, но и шлаковых собеседований стало сильно меньше(хозяюшке на заметку)

Выложили доклады с SeleniumConf 2019 - Tokyo

https://www.youtube.com/playlist?list=PLItJNH7uWaWDm7saQ9xXDYn4msTARDI-M

...И большие, и маленькие компании применяли методологию «аджайла» и «скрама», позволившую некомпетентным менеджерам дисциплинировать и контролировать инженеров, чью работу они не способны ни выполнить самостоятельно, ни оценить...
Виладж, аххаха, прекрати

#books #computerscience
Вот, кстати, крутая книжка по сабжу. Не профессор Фортран, конечно, но тоже интересно)

Тут недавно помогал джуниору разобраться с кодировками текста и после удивленного взгляда и лекции про разные кодировки и зачем это нужно созрела мысль, что очень много современных инженеров не очень сильны в основах computer science. Да, возможно, с современными инструментами и высокоуровневыми ЯП не нужно досконально знать спецификацию TCP/IP, но какой-то минимум, кмк, все-таки должен быть.
Более того, с одной стороны, спрашивать на собесе чувака про такое грешновато(из общих знаний щас на собесах выжили только алгоритмы и структуры, и то масса холиваров), а с другой стороны, можно ведь так и нанять синиора, который не в курсе про кеширование, буферизацию и считает, что биты в воздухе невидимые гномики друг-другу передают.

Очень крутой доклад про внутренности AWS Aurora.

Я не следил за этой штуковиной, но честно говоря я удивлен: они переписали слой хранения данных Postgres и этим добились шикарных результатов. Как и в перф, так и в репликации, бекапе и тд.

На сторедж постгри давно ругались, но все же он работает. Вот только не cloud ready™.

Кстати, фича с fast clone заслуживает отдельно внимания. Ты прост жмешь клон и получаешь копию прода (по времени старт инстанции в авс). Мечта для стейджинга и CI.

https://www.youtube.com/watch?v=cMJV2vvNsts

слайды, если лень смотреть, большая часть показана https://www.slideshare.net/GrantMcAlister/dat305-deep-dive-on-amazon-aurora-postgresql?from_action=save

📺 По ссылке плейлист с видео, в которых Brendan Burns (один из создателей Kubernetes) про облака, и непосредственно про работу с Kubernetes рассказывает.

#видео #фидбечат #kubernetes

Мой коллега — Александр Воронянский — сегодня на хабре опубликовал статью про то, как наша команда Яндекс.Маркета доставляет фичи до пользователей — "От идеи до релиза. Детальный опыт фронтенда Маркета".

У нас работает более 40 фронтенд-разработчиков. В нашей ответственности находятся клиентская часть и Node.js BFF (Backend For Frontend). Мы работаем в контурах-командах, состоящих из разных специалистов: фронтендеры, бэкендеры, дизайнеры и продакт менеджеры. Любой человек из команды может предложить свою идею для улучшения сервиса, которая проходит оценку по системе GIST. Если идея хорошая, то команда начинает над ней работать. После того как написан код, пройдено ревью, тесты и другие проверки, фича попадает в релиз. Релизят у нас ребята из QA. Во время релиза проходит большое количество проверок: E2E-тесты, нагрузочные тесты, скриншот-тесты и т.п. Если всё ок, релиз попадает в престейбл (стейджинг). Там тоже проводятся проверки. После этого этапа свежий код релиза раскатывается по датацентрам.

В общем, в статье очень подробно рассказывается про наши рабочие процессы. Рекомендую почитать.

#ci #process #yandex

https://habr.com/ru/company/yandex/blog/459960/

Сегодня флейм немножко не про разработку, а про, прости госпаде, Агиле.
Так уж получилось, что довелось поработать на многих галерах и, что показательно, самые плохие результаты стабильно демонстрировали те, кто пытались натянуть кота на кактус, а именно, привозили BDSM, ретро и груминг в свой ватерфол и считали, что теперь у них всем Scrum'ам Scrum и вот теперь-то заживем.
Прикол в том, что Lean и Agile это не просто итеративный ватерфол + несколько митингов, а совершенно другая система ценностей на всем цикле разработки и всех уровнях кампании. Если разработчик все еще работает исключительно по детальной спеке, и не готов взаимодействовать с коллегами, учавствовать в проработке требований и пытаться всеми силами выпустить MVP что бы проверить продуктовую гипотезу, то у вас, простите, Срам, а не Скрам. Если тестирование не вовлечено в процесс и включается в процесс после разработки, то у вас тоже явно не агиле.
Процесс перехода очень сложный, трудоемкий и тернистый именно из-за перестройки системы ценностей, и перед внедрением м.б. стоит сначала задуматься, а подходит ли вам эта самая "гибкая" система? Может быть у вас это не работает(и это нормально), и не стоит гнаться за хайпом что бы потом присоедениться к толпе Agile-хейтеров?
Более того, мое личное мнение, что Agile в России построить невозможно куда сложнее чем в загнивающей из-за нашего менталитета. Почему-то на просторах СНГ гораздо меньше коммандных игроков, и больше индивидуалистов. Опять же, это не плохо(индивидуалисты, обычно, профессионально сильнее из-за постоянного стремления быть лучше соседа), но это еще один челендж по внедрению Аджайла(причем очень серьезный). Не зря ведь манифест Кокберна начинается с телеги про "самоорганизованные замотивированные комманды"

нашел тут bullshit bingo на все случаи жизни: https://www.bullshitbingo.net/cards/bullshit/ Спасибо https://t.me/hexlet_ru/1228 за вдохновение!

Build your own React

How does React really work? In this talk, you'll find out. You'll write a simplified version of React from scratch, based on the real source code, including: jsx, fibers, reconciliation, hooks, and more.

Kubernetes Failure Stories, or: How to Crash Your Cluster

Классный доклад от компании Zalando про то, с какими проблемами им пришлось столкнуться в процессе менеджмента 130ти кластеров Kubernetes.

https://youtu.be/LpFApeaGv7A

Отличное дополнение к Typeclassopedia:
https://github.com/thma/LtuPatternFactory

Крис Койер на CSS-Tricks написал небольшую статью про работу с псевдоэлементами — «A Little Reminder That Pseudo Elements are Children, Kinda».

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

Взял на заметку, как получить стили псевдоэлемента из JavaScript. Для этого нужно использовать getConputedStyle с двумя аргументами:

const styles = window.getComputedStyle(
document.querySelector('.container'),
'::before'
);


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

#css #layout

https://css-tricks.com/a-little-reminder-that-pseudo-elements-are-children-kinda/

Anomaly Detection for Dummies

This tutorial explores unsupervised anomaly detection for univariate and multivariate data. Covers a variety of detection strategies with python code snippets and screenshots.

Jupyter notebook: http://bit.ly/2O2PFp9

http://bit.ly/2O7unaa

#design #java #patterns
Каталог с конским кол-вом паттернов всех сортов и расцветок: https://github.com/iluwatar/java-design-patterns имхо, не самый удобный каталог, но для каждого есть пример на java

Тут лента выплюнула, что на 74 % порносайтов обнаружены трекеры Google. Удивляет даже не то, что корпорации следят за нами(это вроде ни для кого уже не секрет), а то что это гугл, а не баду, пьюр или тиндер. Хмм #идеядлястартапа

💬 Если у тебя, камрад, выходные оказались свободны, а за окном поливает дождь, попробуй пройти вот по этой ссылке https://www.usenix.org/conference/atc19/technical-sessions - там неприличное количество разных докладов и материалов с USENIX конференции.

#usenix