I hate overtime
866 subscribers
129 photos
4 videos
54 files
961 links
Some DevOps, SRE and IT development stuff
Download Telegram
Defront — про фронтенд-разработку и не только
Фред Шот — автор библиотеки pika — опубликовал статью с рекомендациями по настройке bundler-free окружения для разработки современных web-приложений — "Building without bundling: How to do more with less". Может возникнуть резонный вопрос: "Зачем избавляться…
Вот это прямо очень-очень! Как-то так уж получается, что с современными микросервисными реалиями сборка бекенд(ов) происходит быстро, а вот фронтенд, по крайней мере, у нас собирается конское количество времени. И вот, похоже, мучениям приходит конец! Да и сама pika выглядит перспективненько
Гоферы на фестивале стрит-арта в Одинцово. Кстати, москвичам очень советую сгонять!
Forwarded from Zavtracast (Dmitriy Zombak)
О, дивный мир будущего!

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

https://thenextweb.com/cars/2019/09/03/tesla-owners-reportedly-got-locked-out-of-their-cars-because-the-app-was-down/
#sre
Тут Олег(@oleg_log) принес интересную пдфку про то как надо проектировать сервисы чтобы нипадало. Можно рассматривать как краткую выжимку из Нейгарда/sreBook или как еще один чек-лист готовности к проду. В любом случае годно
Forwarded from Мониторим ИТ
Издательство Wiley, которое выпускает серию «Для чайников» часто под этим же брендом публикует совместные издания с разными компаниями. В этой подборке три книги по теме мониторинга.

Alert Correlation for Dummies (совместно с BigPanda)

AIOps for Dummies (совместно с FixStream)

Network Monitoring for Dummies (совместно с Solarwinds)
Нашел тут видос 2хлетней давности про то как устроен Slack. Кароч, парни, как-то вот у них все и без ваших кафок-кубернетесов-микросервисов работает.
Более того, судя по стек-шаре они и до сих пор так работают и отлично себя чувствуют
#fp #books
Ой, котаны, че откопал! Ловите знаменитый курс по ФП из Кембриджа от Харрисона с переводом. Достаточно академизма, достаточно примеров, все прям шикарно.
Готовая пдфка в релизах репы, собрать из сорцов у меня не получилось(возможно плохо собирал)
Forwarded from Sergey Sporyshev
Коллеги друзья!
Сегодня очень крутой день)
Сегодня в официальном сторе Grafana появилась первая версия нашего (ITSumma/DevOpsProdigy) плагина для k8s
https://grafana.com/grafana/plugins/devopsprodigy-kubegraf-app
Мы ждали принятия пул-реквеста целых 22 дня
и оно свершилось)))

Плагин умеет:
1) строить красивую карту всех ваших приложений в кластере и рисовать рядом зелено-желто-красные лампочки означаюшие статус живости вашего приложения
2) красиво показывать какой под на какой ноде находится в данное время
3) выдавать сводную статистику о том, что в кластере идет не туда)
4) выдавать информацию с динамикой по загрузке конкретной ноды кластера
5) поставляется с большой пачкой дашбордов (мониторинг ноды, пода, деплойментов, демонсетов, стейтфулсетов)

Зачем и почему мы это сделали:
1) Плагина с подобной функциональностью в мире только 1 штука, официальный плагин от GrafanaLabs и он не поддерживается уже больше года
2) Просто мы можем себе это позволить

Лайк, шер, подписка, звездочка на гитхабе, ишшуи, пул-реквесты - приветствуются
https://github.com/devopsprodigy/kubegraf
Из разговора с коллегой:
"Основная проблема индустрии в том, что 90% кода пишется либо джунами, которые еще не читали Макконела, либо мидлами, которые уже читали Эриха Гамму"(с). Чет в голосину
Котаны, я тут давно одну мысль вынашиваю, вот решил поделиться. Речь пойдет о DRY и инкапсуляции в ООП.
Все 100 раз слышали мантру, что дублировать код грешновато и надо инкапсулировать дублирующуюся функциональность, используя все имеющиеся для этого средства вашего любимого ЯП(наследование, композицию, все чудеса GoF и т.п.). Обычно тут аппелируют к расширяемости, поддерживаемости и т.д.
В теории все шоколадно конечно, но в постоянно меняющейся среде все эти замечательные абстракции могут превратиться в тыкву протекающие, коллеги начнут путаться в этих бесконечных "фабриках сервисов стратегий" и в один прекрасный день кто-то все это снесет, построив на руинах еще одну такую же башню из слоновой кости. Знакомо?
Более того, в модных нынче микросервисах дублирование считается нормальным(ну по-крайней мере меньшим грехом чем связность сервисов как в классическом SOA). Оттуда же растет популярность сервисных каркасов(шаблонов проектов типа create-react-app или dotnet new), где через cli создается костяк проекта, который можно менять как душе угодно.
Кароч вот такая мысль, что думаете?
Мое мнение, что тут отлично работает правило 3х: 3 раза задублировал, значит надо инкапсулировать, а до этого нинада.
UPD: речь тут не про выделение кода в методы, а скорее, про ООП головного мозга с абстрактными классами, хелперами и всякими мутными стратегиями на каждый чих
И, раз уж почти пятница, вот вам крутой канал с перлами Миловидова: @milovidov_perls
Не самый короткий, но довольно полезный текст (с хорошими ссылками) про CAP-теорему, панк-рок и "Войну и мир" Льва Толстого http://www.julianbrowne.com/article/brewers-cap-theorem