Очень подробная статья от Notion как они переходили от монолитной postgresql к шардированию БД.

Сервис проработал первый 5 лет на одном инстансе БД и только в 2020/2021 году они перешли на шардирование. Подробно описан процесс выбора схемы шардирования, непосредственно переход.

И самое главное выводы.
- Команда хорошо знала об опасности преждевременной оптимизации и откладывала переход на шардинг до последнего. Это сыграло против них, база стала неповоротливой и сузило выбор инструментов для миграции.
- Жалеют что не потратили немного времени и не реализовали zero downtime обновление.

https://www.notion.so/blog/sharding-postgres-at-notion

Очень интересное исследование от команды Google. Они провели 12 недельный эксперимент по внедрению обученной ML модели для комментирования пулл реквестов. Каких-то цифр не привели, но результаты интеграции и % принятия сгенерированных моделью рекомендаций в районе 40% очень впечатляет. На масштабе гугла это поможет сэкономить много часов времени на комментирование других ревьюверов.

https://research.google/blog/resolving-code-review-comments-with-ml/

Интересная статья по тому, как postgresql  хранит данные в файлах и за что какие файлы отвечают.

https://drew.silcock.dev/blog/how-postgres-stores-data-on-disk/

Back pressure (Backpressure) - это такая техника управления потоком данных, когда клиент отправляет слишком много данных и сервер может ответить, "не могу все обработать" и клиент уменьшит скорость передачи.
Например rate-limiting по сути является одной из стратегий реализации Back pressure.

Чаще всего выделяют 3 основных.
- Игнорирование данных (определенная часть данных просто игнорируется, в данном случае умышленно, а не потому что сервер просто не успевает их вычитывать). Сюда можно включить rate-limit. Само собой не тогда когда rate-limit например ограничивает ваш тарифный план например а когда это реальный ограничитель рассчитанный исходя из мощности системы.
- Буферизация данных (Накапливаем пиковые волны данных и обрабатываем позже). Немного более затратный метод, какие волны будут? Как часто? Какого размера может быть волна?
- Контроль генератора данных (Сервер контролирует скорость клиента, ускоряет или замедляет его) Клиент получает ответ от сервера что ему слишком быстро и замедляется. Эта реализация требует поддержки на уровне вашей инфраструктуры/фреймворков. Те реализации про которые знаю Kafka producers/consumers, Redis, MongoDB, RxJava, Sping Webflux, скорее всего и другие RX библиотеки других языков программирования тоже, потому что этот концепт популярен в реактивном программировании.

Хорошая обзорная статья

Пример на java

Замечательная статья от Kent Beck, статья компиляция его нескольких лет опыта коучинга в Facebook. Очень круто видеть подтверждения своим мыслям и размышлениям у реально крутых авторов.

- Longevity/diversity. Elite engineers stick with projects long enough to see the consequences of their decisions. Insight is best mined deep in maintenance. At the same time, elite engineers have enough diversity of projects to separate context-dependent lessons from more general ones.

- Success/failure. Elite engineers need to succeed enough to maintain confidence and initiative but they also need to fail enough to question themselves and their assumptions when doing so is valuable.

- Mentored/self-directed. Most elite engineers can point to one or more mentors who changed the trajectory of their career. Elite engineers are also self-directed learners, trusting their curiosity as a compass pointing towards future growth.

- Urgency/slack. Elite engineers work hard, but lots of folks work hard. Elite engineers have the habit of investing the margin in personal growth. When that odd hour or two isn’t likely to yield a great new feature, it can still yield useful learning.

https://tidyfirst.substack.com/p/the-impossibility-of-making-an-elite

Хорошая вводная статья про B-trees и индексы БД в контексте MySql,  статья интерактивная/анимированая.

https://planetscale.com/blog/btrees-and-database-indexes

Хочу сегодня поделится с вами обзором новомодного CursorAI. Это такая IDE/Code editor которая очень плотно интегрируется с многими LLM/AI сервисами. Самая главная фишка это то, что сервис будет понимать полный контекст вашего проекта. И тут лучше посмотреть видео чтобы понять насколько это интересно выглядит в работе.

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

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

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

Какой интересный код оказывается есть.

451 Unavailable For Legal Reasons
HTTP-код ответа 451 Unavailable For Legal Reasons указывает, что пользователь запросил ресурс, который недоступен по юридическим причинам, например веб-страница, заблокированная из-за судебных исков.

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/451

В блоге Sequoia Capital (крупный венчурный фонд) интересная статья с прогнозами по развитию AI сферы. По сути уже года два как формируется новый пласт продуктов сделанных поверх AI. Т.е. кодовая часть для сопровождения этого AI все равно нужна, архитектура тоже) В статье есть также небольшой экскурс в историю. Вообщем краней полезно почитать чтобы понимать куда развивается область Software Services. Картинка говорит сама за себя.

https://www.sequoiacap.com/article/generative-ais-act-o1/

Использование связки Data aggregation + LLM + vector database для агрегирования разных внутренних источников информации и предоставления пользователям интерфейса к ним, потихоньку переходит из разряда диковинки в разряд обычных помогающих инструментов. Uber запустили внутреннего бота который помогает on-call инженерам быстрее выдавать ответы из внутренних вики и прочих систем документации, в ответ на запросы.

https://www.uber.com/en-IN/blog/genie-ubers-gen-ai-on-call-copilot/

В приватных беседах про мощь и силу LLM/AI мои друзья из software безопасности жалуются, что в порыве всеобщей эйфории от открывшихся возможностей все прогрессивное человечество стало направо и налево внедрять все инструменты где упомянуто AI, при этом напрочь забыв про безопасность. По последним постам могло показаться что и я так агитирую делать. Но нет, безопасность хоть и не мое второе имя но я стараюсь учитывать ее как могу/умею. Поэтому сегодня будет пост про Security в AI/LLM. И база которую всем стоит почитать это конечно-же OWASP. Сообщество OWASP уже имеет отдельный раздел genai.owasp.org где есть много всего интересного. Но первое что рекомендую это OWASP Top 10 for LLMs and Generative AI Apps.
Аналогично классическому OWASP это список базовых 10 уязвимостей с описанием их опасности и примерами атак. Признаю я знал только половину, очень интересное и полезное чтиво. Вообщем почитайте пожалуйста, пошарьте тем кто занимается внедрением.

Недавно озаботился вопросом, а как используются данные которые я ввожу в OpenAI/ChatGPT. Быстрый поиск дал ответы:

Как обстоит дело для обычных пользователей:

https://openai.com/policies/privacy-policy/

As noted above, we may use Content you provide us to improve our Services, for example to train the models that power ChatGPT.

Отправить запрет/исключение на использование своих данных можно здесь
https://privacy.openai.com/policies -> Make a Privacy request.

Для энтерпрайз пользователей и пользователей API все проще.

https://openai.com/enterprise-privacy/

By default, we do not use your business data for training our models.

- ChatGPT Team or ChatGPT Enterprise

We do not train our models on inputs and outputs through our API.

- OpenAI API Platform

Правда про fine-tuning models все таки есть нюанс.

Q: "Who can view stored API inputs, outputs, and fine-tuning data?"
A: Our access to API business data stored on our systems is limited to (1) authorized employees that require access for engineering support, investigating potential platform abuse, and legal compliance and (2) specialized third-party contractors who are bound by confidentiality and security obligations, solely to review for abuse and misuse.

Старый код не умирает вам нужно его убить. - Grady Booch

На канале The Pragmatic Engineer вышло интервью с живой легендой Software архитектуры Grady Booch!

И на мой взгляд оно получилось мега крутым! Очень интересные рассуждения про историю развития архитектуры и программирования в целом, его мысли на текущее положение вещей и LLM/AI в целом. Кратко законспектировал как менялось история разработки именно в контексте архитектуры.

60-70 - Маинфреймы, компьютеры в лабораториях. Осознание разработки и языков программирования в целом.
70-80 - Появляются мини компьютеры, первое появление распределенных систем. Бурный рост терминалов и терминальных систем. Так появляется потребность понимания как будут связываться такие системы и как они будут работать.
1980 - 1990 - Восхождение ООП, Рождение Rational Software где участвовал Буч и Которую потом купит IBM. Рост темпов разработки корпоративного ПО и как следствие потребности в best practices.
90 - 00 - Рождение и бурный рост интернета, HTML, TCP/IP. В 94-95 в Rational Software создали UML. До середины 00 MS/IBM и прочие гиганты несут знамя корпоративной разработки в массы. Системы становятся еще сложнее.
00 - 10 - 2001 год создание Agile манифеста. Появляется альтернатива корпоративной разработке. Развитие XP практик.
10 - present - Первое появление Solution Architect как роли в cloud компаниях. Строительные блоки становятся крупнее, и появляется потребность продавать клиентам решения созданные из этих блоков.

Ну и пара фраз от Гради Буча которые очень зацепили.

Про Легаси:

"У всех есть легаси, Facebook, Google, даже у OpenAI есть легаси. Как только вы написали строчку кода она становится легаси. Старый код не умирает вам нужно его убить. Если у вас нет саморазрушающегося кода вам прийдется работать с легаси."

Про OpenAI/LLM Гради Буч очень критичен):

"They allow us to build global scale bu...it generator"

Я настоятельно рекомендую посмотреть все интервью, возможно даже не один раз, потому что интересных мыслей действительно много!

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

Попался очень крутой плейлист в youtube. IBM делают хороший обучающий материал на своем канале, среди прочего серия про Cybersecurity Architecture. 10 роликов каждый по 15-20 минут. В среднем у вас уйдет часа 3-4 на просмотр всех роликов. Материал очень концентрирован и просто очень круто подан. Рассказывает его Jeff Crume очень крутой чел в IBM по cubersecurity (профиль на linkedin). Я просто на одном дыхании посмотрел все ролики чего и вам советую, очень круто добавляет контекста про security и понимания как все части безопасности на разных уровнях связаны между собой.

https://www.youtube.com/watch?v=jq_LZ1RFPfU&list=PLOspHqNVtKADkWLFt9OcziQF7EatuANSY&index=1

Gen AI уже становится де-факто, а значит потихоньку начинают образовываться паттерны использования AI в приложениях. Хорошая статья у Мартина Фаулера. Emerging Patterns in Building GenAI Products

Первая статья из серии, обещают продолжение.

https://martinfowler.com/articles/gen-ai-patterns/

Интересный пост про построение AI системы код ревью. Автор поста - опытный разработчик в прошлом, сейчас консалтер с 17+ лет опыта. Много деталей нет, скорее интересен общий подход и архитектура. И самое главное на что я обратил внимание в посте. "LLM в этом продукте была самая простая часть, очень много усилий уходит хорошо интегрировать LLM в окружение" - и эту идею можно распространить на большую часть крупных продуктов. AI/LLM просто еще один компонент в вашей архитектуре.

https://theburningmonk.com/2025/01/how-we-built-an-ai-code-reviewer-with-serverless-and-bedrock/

OpenAI опубликовали интересное исследование/анонс. Почему это интересно? Потому что в результатах модели OpenAI — не победители. Это как минимум даёт намёк на справедливость оценки. В исследовании анонсирован новый бенчмарк для LLM-моделей — назвали его SWE-Lancer.

SWE-Lancer включает в себя более 1400 фриланс-задач по разработке программного обеспечения от Upwork, общая стоимость которых составляет более $1 млн. Задачи SWE-Lancer охватывают весь инженерный стек — от UI/UX до проектирования систем — и включают ряд типов задач: от исправления ошибок ($50) до реализации фичей ($32 000). SWE-Lancer включает как инженерные задачи (кодинг), так и менеджерские задачи.

На выполнение похожих комплексных задач фрилансерам требовалось в среднем 21 день. Стоимость задач отражает реальную стоимость задач на Upwork. По сути, OpenAI довольно здраво предлагают оценивать модели по реальной работе разработчика и ценности выполненных задач. В исследование очень много деталей об исследовании, его стоит почитать.

Ну и результаты: большинство моделей не могут решить даже половины задач(по ценности а не по количеству). Максимум был у Claude 3.5 Sonet. Но зато теперь есть новая планка и, что самое главное, моментальное подтверждение ценности для бизнеса, выраженное в $$$. А значит, как только стоимость решаемых задач новой модели превысит среднюю зарплату разработчика, пока кожаные , нас ждёт новый виток развития software-индустрии.

Mock coding interview - новое видео от команды Google

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