I hate overtime

Митап с окрошкой и инцидентами

10 августа в нашем офисе пройдет четвертый митап в серии Backend United, который получил название «Окрошка».

В программе — доклады про инструменты для улучшения incident response, работу с продакшн взрывами, ценность технического долга, автоматизированный сбор сведений при значительных инцидента. А во время перерыва запланировали поедание окрошки.

Если вам всё это интересно, то регистрируйтесь на встречу на таймпаде. Подробнее о докладах можно прочитать на Хабре.

Что творится?! В любом случае страдают обычные люди..😔

GitHub начал блокировать российских разработчиков.

Позиция GitHub
GitHub поясняет, что в настоящий момент он предлагает ограниченные услуги пользователям, проживающим в странах и регионах, которые находятся под санкциями, таких как Крым, Куба, Иран, Северная Корея и Сирия. Это означает в том числе ограниченный доступ к сервису публичных репозиториев — он может быть использован только для личной коммуникации, поясняется в электронном письме, которое получил от GitHub Анатолий Кашкин.

Источник

Однозначно мем недели

Не так давно пришла в голову мысль, что, поскольку я стал заниматься ФП из-за собственного интереса, а не каких-то объективных причин, у меня нет глобального понимания, почему оно "лучше" ООП — просто другая парадигма мышления.

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

Для тех, перед кем вопрос "ФП >? ООП" уже не стоит, статья может быть интересна кратким экскурсом в историю ООП и обилием достаточно забавных цитат.

Попалась на глаза подборка туториалов Робина Вирух про настройку React-проекта с нуля от создания package.json до настройки enzyme и hot module replacement.

Туториалы очень хорошие. В них всё написано по делу, понятно и аккуратно. Автор поддерживает их в актуальном состоянии; несмотря на то что некоторые статьи были опубликованы более двух лет назад, в них рассматриваются последние версии библиотек. Я немного запутался с перекрёстными ссылками, поэтому вот список ссылок на статьи в корректном порядке:

1. How to set up a modern JavaScript project
2. How to set up a Webpack project
3. How to set up Webpack with Babel
4. How to set up an advanced Webpack application
5. How to set up React with Webpack and Babel
6. How to test React components with Jest
7. How to test React components with Jest & Enzyme

Очень рекомендую пройти туториалы, если вы не настраивали сборку проекта самостоятельно.

#tutorial #webpack #react #jest

#dotnet #mongodb
Как-то так повелось, что мы активно используем монгу(и любим ее всем сердцем). У монги есть 2 api. Не вдаваясь в детали, первое покрывает большинство кейсов по выборке документов и все CUD-операции, второе, а именно, aggregation framework, нужно для аналитических выборок и прочих сложных "селектов"(еще есть map-reduce, но это отдельная история). Исторически считается, что AF тормозит и предпочтение всегда отдавалось первому api.
Тут как-то выдалась свободная минутка и я полез разобраться как же в c# драйвере парни linq в монго-запросы транслируют и ушел с неприятным, но довольно логичным, инсайтом: linq транслируется в af-пайплайн. Вроде бы можно и закончить на этом, но чет меня дернуло сходить в коммьюнити с вопросом че щас по перфомансу af. Кароч, парни, щас движок AF сильно потюнили(курсоры-то всегда были одни и те же) и, если для простых выборок выигрыш у простого api еще какой-то есть, то более сложные запросы и удобнее и быстрее делать через AF
Кстати, если кто не знал, в вики монги на гитхабе много статей про кишки

Production readiness

Советы от инженера Google Cloud на что стоит обратить внимание при запуске нового сервиса в продакшен.

https://jbd.dev/prod-readiness

https://medium.com/google-cloud/production-guideline-9d5d10c8f1e

#k8s
Еще одна деплой-тулза для k8s. Интересна тем, что в отличие от хельма умеет не сносить приложения которых нет в "umbrella-чарте"(только обновлять указанные). Для хельма нам пришлось для этого навернуть целую систему костылей. И еще это не один большой комбайн, а набор single purpose утилит. Кароч я бы присмотрелся.

k14s — тулсет для работы с Kubernetes от Pivotal (нейминг от бога)

Включает в себя:
- ytt — утилиту для YAML темлпейтов
- kbld — утилиту для сборки образов
- kapp — утилиту для деплоя приложений

+ в статье есть пример с хеллоуворлдом

#kubernetes

#coroutines #java
Еще один крутой видос про асинхронщину и детерменизм, на этот раз в java: https://youtu.be/9vupFNsND6o

Не пользы ради, а флейма для

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

А пихать все в одну должность - прост грузить сотрудников.
(Комбо с названием канала отлично доставляет)

Конечно все зависит от размера фирмы и навыков разрабов. Хотя и тут можно много мегабайт текста наспорить.

https://t.me/overtimehate/489
(Там след пост - инициатор темы)

(Если скучно - можете мне в свои отношение высказать-выплакать @olegkovalov)

И третья точка зрения на девОпс(и все разные)! Коллекция растет)

ELK + syslog http://devconnected.com/monitoring-linux-logs-with-kibana-and-rsyslog/ #elk #syslog

#sql
Должен признаться, что я очень не люблю Sql Server(да-да, ниосилятора пост). За долгие годы работы с ним скопилось много претензий: тут и неработающие хинты и наркоманские уровни изоляций, убогий MVCC и еще куча всего. Перечислять можно долго, но в топе, безусловно, params sniffing! Кто не в курсе скуль сервер строит план вызова хранимой процедуры опираясь на предыдущее выполнение. И его не очень волнует, что параметры могли поменяться и план, соответственно, было бы не плохо подкорректировать.
Для тех кто тоже страдает, вот цикл статей почему так и как с этим жить: https://www.brentozar.com/sql/parameter-sniffing/

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

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

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

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

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

Но вчера небезызвестный @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 инженеров, на самом деле ищут специалистов, которые знают этот инструментарий.

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