База по Базам Данных - Storage (Индексы, Paging, LSM, B+-Tree, R-Tree) | Влад Тен Систем Дизайн

ps: Соңына дейін жетпедім, бірақта басы тым жақсы


#systemdesign #database

Designing Data-Intensive Applications, 2nd Edition

ps: There is a trial period of 10-14 days

** [first edition]

Timeouts, retries, and backoff with jitter

How to design our systems to reduce the likelihood of failure is what Marc Brooker, a senior principal engineer at Amazon Web Services, explains in his article.

#aws #systemarchitecture #systemdesign

Exponential Moving Average (EMA): Definition, Formula, and Usage

ps: Қысқаша, бұл формуланы қолданып сервердің latency анықтауға болады. LRT Load Balancer жазатың болсаңдар

https://ru.wikipedia.org/wiki/Скользящая_средняя

Как программисту остаться нужным в век AI? (часть 1)

Последний месяц много думал о том, что будет с программистами. Кодинг в привычном смысле умирает. Машина пишет код в 100 раз быстрее, отлично понимает комментарии, и с каждым месяцем делает это всё лучше. Соревноваться с ней — то же самое, что соревноваться с калькулятором в арифметике

Вопрос: а что тогда остаётся?

Недавно слушал один подкаст, и там прозвучала мысль: машина не чувствует боли. Не только физической — а той боли, когда ты подвёл команду. Когда продакшн упал в пятницу вечером из-за твоего кода. Когда тебе стыдно смотреть в глаза коллегам. А машина просто скажет «ой, извините, сейчас поправлю»

Из этого следует ключевая вещь: машина не может нести ответственность. Ты можешь зашить метрики, натренировать модель, обвесить всё мониторингом. Но когда AI случайно сделает критическую ошибку — спрашивать не с кого

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

Как программисту остаться нужным в век AI? (часть 2)

Боль, ответственность и оунершип, это мы поняли. Но как человеку еще конкурировать с ИИ-шкой? Ответ: опыт

С технической точки зрения LLM-ки прочитали весь интернет, плюс сейчас они отлично умеют гуглить и обновлять свои знания в реальном времени. Чего у них нет, так это опыта работы с реальными системами. Поясню на примерах:

1. Twitter. Когда я работал в Твиттере, то увидел это воочию. Во главе миграции был PhD в графах, очень умный человек, но который никогда не проводил огромные переезды распределенных систем. Итог: миграция длилась 5 лет, пока не пришел другой человек с практическим опытом и не сдвинул команду с мертвой точки

2. Facebook. В документации система описана как надёжная и хорошо работающая. На практике — она постоянно падает и не выдерживает твоих нагрузок. Узнаёшь об этом, когда уже внедрил. Как итог — много потраченного времени впустую

3. Research. Я попросил AI сделать полное исследование всех решений для одной задачи. Claude упорно отсеивала один вариант — потому что в документации было написано «not production ready». Но я-то на практике использовал этот проект и знал, что он работает лучше множества других решений. Документация врала, а Claude ей верил

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

И я не вижу, чтобы это как-то быстро хакнулось и появилось. Так что пока ИИ остается теоретиком, программист с большим практическим опытом будет нужен

Слайды из видео про Kubernetes. Сохраняй как шпаргалку

Артём Шумейко

Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency

The primary author of go scheduler Dmitry Vyukov will look inside of the Go scheduler and expose how this magic is implemented. Great explanation with overview of the main components of the scheduler and overall operation. In the second part takes a closer look at some specific aspects like blocking system call handling and growable stacks implementation.

#go #eng #runtime

Внутреннее устройство планировщика Go - Concurrency в Go

Тут уже более детальное, понятное объяснение планировщика от Владимера Балуна

#go #runtime #ru

* Қазақшасын тапсам оныда салып жіберемін

Общался с другом из Меты. Говорит, очень сильно мониторят, какой процент твоего кода пишет AI. И если это меньше 80%, то к тебе резко возникают вопросики, что с тобой не так. Также очень сильно повысились ожидания, что ты несколько больших фичей параллельно фигаришь

И да, используют они Claude Code. Парам-пам-пам 🙂