0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.
Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение
std::stable_sort с её помощью в llvm. Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.
Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.
Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.
1. [article] Unconventional PostgreSQL Optimizations.
Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.
Я всё больше убеждаюсь, что любая бд, как и плюсы, это огромная дыра, в которой можно жизнь провести. Стать экспертом везде нереально. Это гложет.
2. [article] Why Senior Engineers Let Bad Projects Fail.
Я тоже видел проекты, которые очевидно создадут больше проблем, чем профита. Я видел проекты, которые делаются, потому что кто-то где-то наверху договорился, а потенциальные результаты притягиваются кое-как и, очевидно, не стреляют. И видел огромное количество проектов, которые в моём понимании «плохие» хотя бы потому что они создают огромнейшее кол-во техдолга на моей поляне.
И иногда не то чтобы ты не хочешь с этим ничего делать. Иногда ты ничего и не можешь.
Научиться с этим жить наверное было одной из самых сложных проблем с момента техлидства. Не уверен, что всё-таки умею.
3. [article] How I estimate work as a staff software engineer.
Автор рассуждает на тему оценок задач, после чего говорит, что на самом деле не оценивать задачи, а возможный объём работы за имеющееся время. Типа перевернул всё.
Ну может и да! Надо поприменять и понять.
4. [article] Scaling PostgreSQL to power 800M ChatGPT users.
Статью прилагаю как антипаттерн.
Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.
Что мы видим внутри?
Проход по базовым пунктам, каждый из которых вообще-то можно раскрыть на отдельную статью, но тут пробежали по верхам и на этом закончили.
Вот я бы почитал про оптимизацию отдельных запросов, например. Или про workload isolation. Там сто процентов есть крутые детали.
А так выглядит как набор топиков на ресёрч.
=============================
Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.