Крис Койер на 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/

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

Kubernetes Failure Stories, or: How to Crash Your Cluster

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

https://youtu.be/LpFApeaGv7A

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.

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

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

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

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

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

#ci #process #yandex

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

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

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

Очень крутой доклад про внутренности 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

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

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

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

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

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

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

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

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

Но вчера небезызвестный @SinTeZoiD скинул в группу ссылку на совместный подкаст с LinkMeUp, где обсуждали такие животрепещущие темы, как Kubernetes, Docker, DevOps и SRE. Шел 2019-ый год.

За 3 часа подкаста (я успел приготовить ужин, съесть ужин, переварить ужин, помыть посуду и узнать внезапно, что Service Mesh это хипстерский Enterprise Service Bus (Миша, серьезно?)), ближе уже к концу начался настоящий замес - почему DevOps инженеров не существует.

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

Если вы в индустрии уже достаточно давно и следите за трендами, которые задают смузихлебы из креативных коворкингов, то вы знаете, что DevOps расшифровывается очень просто: Development and Operations. Такой расшифровки достаточно, чтобы все понять.

Отсюда же появляется осознание, что DevOps инженеров не может быть в природе. Если мы берем за правило, что DevOps это культура, то откуда возьмется Культура Инженер?

Если же мы берем простой акроним, то тем более не может быть Разработка и Операции инженер.

Топящие за существование DevOps инженеров любят применять следующий прием: дескать DevOps инженер занимается настройкой работы CI/CD (кто тогда Release Engineer?), работать и настраивать Kubernetes/Mesos/Nomad (кто тогда системный администратор?) и работать напрямую с разработкой (а кто этим занимался раньше?).

Не ведитесь на это. Существование DevOps инженеров обусловлено лишь тем, что вместе с культурой пришел набор практик, а за набором практик пришел инструментарий. Ищущие DevOps инженеров, на самом деле ищут специалистов, которые знают этот инструментарий.

Что мешает текущему персоналу освоить этот инструментарий - для меня загадка.

А вот и альтернативная точка зрения

Крутая статья про Code Complexity. Особенно шикарна метафора с парадоксом Зенона

Тут статья подъехала про будущее и эволюцию atomic design от изобретателя сабжа: http://bradfrost.com/blog/post/extending-atomic-design/

Observability на конкретном примере одного проекта https://dzone.com/articles/microservices-observability - очень доступно #observability #tracing #msa