Не, ну если даже ему так можно...

MongoDB Best Practices on Linux 2020 Edition

https://www.percona.com/blog/2020/04/17/mongodb-best-practices-2020-edition/

#mongodb #mongo #linux #nosql

#cache
Старенький, но годный пейпер про то как Facebook скейлил memcache

#management #grades
Тут твитером выбросило грейд систему авито с целями-обязанностями по каждому грейду.
Эх, мне бы вот это на пол-годика пораньше, когда я у себя на галере похожее делал...

#arch
Это скорее себе заметка, но мб кому-то тоже пригодится.
IBMовский архитектурный фреймворк IBM Garage Methodology. На сайте чет очень много маркетинга и не понятно как до сути добраться, но из того что я понял он адаптирован под клауд, помогает с DevOps, SRE и, внезапно, Agile(Kanban)

Интерактивчик подвезли http://thesecretlivesofdata.com/raft/

Канал Юры Насретдинова на английском языке, где он разрабатывает распределенную key-value базу данных на Go. Касаются различных подходов к шардированию, как делать решардинг, и многое другое.

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

# Почему ООП — это плохо
Создатель языка Erlang Джо Армстронг написал эту статью 20 лет назад. Но в ней поднимаются важные и острые вопросы, поэтому мы перевели этот материал для вас.

Армстронгу не нравилось ООП по разным причинам. В статье он поделился несколькими из них:

- Функции и структуры данных имеют разную природу, поэтому с ними нельзя работать, как с одинаковыми сущностями.
- Отношение к любой сущности как к объекту усложняет работу. В объектно-ориентированном языке, например, в Smalltalk, даже число — объект. А в Erlang это экземпляр типа данных.
- В объектно-ориентированных языках принято прятать состояние. По мнению Джо Армстронга, это худшее из возможных решений.

Подробнее об отношении Армстронга к объектно-ориентированному программированию читайте в нашем блоге.

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

прокричите от боли, если у вас тоже такое в каждом сервисе👇

UPD вскрикнул благодаря https://t.me/ebanatics

да нахуй оно не надо, можно просто взять рантаймовый диай и проверять корректность графа тестами

Наткнулся на очень крутую работу про LSM деревья 🔥

Авторы вначале вкратце разбирают как работает LSM-tree.

Затем рассказывают про существующие методы оптимизации LSM деревьев, например:
🔸 Как уменьшить Write Amplification Factor (который, кстати, уменьшает время жизни SSD)
🔸 Какие есть методы ускорения merge операций
🔸 Какие оптимизации позволяют LSM дереву использовать возможности SSD/NVMe и скэйлится по CPU
🔸 Техники auto-tuning'а и построение secondary index и т.д.

В конце авторы разбирают имплементации RocksDB, HBase, Cassandra, AsterixDB.

В общем это must read для тех, кто использует LSM-tree или собирается использовать.

Такой настольный white paper для пользователя LSM-tree 😉

Ссылка на white paper:
https://arxiv.org/pdf/1812.07527

#frontend
Очень годный лонгрид про микрофронтенды. Расписано все от мотивации до технических аспектов. Лично для меня интересное началось с середины(способов композирования), но пробежаться по мотивационной части тоже будет полезно

#frontend
И еще немножечко фронтенда:
1. Шикарный труд про кишки webpack. И нет, там не просто экскурсия по исходникам, а инструкция как сделать свой простенький сборщик
2. Все же знают, что современный фронтенд использует транспиляцию(возможность заюзать современный JS последнего стандарта в доисторическом браузере)? Но мало кто знает как это работает. А вот тут вот подоспел чудо-доклад про устройство транспиляторов(babel'а в частности)

Кратко и иллюстративно об иерархии сложности задач в современной компьютерной теории, с примерами.

#java
Тут вот наткнулся на сборник заметок по Java. С удовольствием полистал. Будет полезно, если знакомитесь с языком или готовитесь к собесу.
Ну и автор просил поблагодарить звездочкой и фидбеком

Оказывается у Hydra Conference есть свой очень крутой подкаст. Крайне рекомендую! Там пока всего 4 выпуска, но все прям огонь

#management
Наконец-то прочитал статью про ревью в netify, и прям проникся идеей.
Собственно проблема:
Наверное часто у всех на ревью возникало ощущение, что ревьюер придирается и на "такое" уж точно можно было закрыть глаза.
Решение:
Каждый коммент в ревью тегается меткой, означающей значимость. Netify выбрали для этого... камни. Например
[boulder] something is wrong with xxx

#jvm
Очень интересная статья про обработку ошибок в Kotlin'е. Наиболее важным, имхо, тут являются даже не дизайнерские решения jetbrains(хотя это тоже интересно), сколько мотивация ухода от java checked exceptions.

сорямба, опять ссылку потерял((