Интересная статья как устроен процесс работы с инцидентами в небольшой технической компании. Как, что и кому нужно сделать. А самое главное тут задействованы три команды. Engineering, Product, Customer Success. Ведь если компания разрабатывает публичный продукт и произошел инцидент, критически важно давать правильную информацию клиентам. Понимаю, что в тех компаниях где работал, опытным путем пришли примерно к такой же схеме, разве что роли не были формализованы/описаны.

https://klaviyo.tech/klaviyo-incident-management-interview-with-laura-stone-28563ac9558b

Stackoverflow объявил о партнерстве с OpenAi. Мне кажется это какой-то новый этап, этап заката StackOverflow в том виде котором мы его знали. По ощущениям я стал гораздо реже заходить на SO по простым вопросам. Но по сложным все еще бывает ищу, проблема только в том что свежих ответов мало. Вытащил статистику, она конечно очень условная, но падение по трафику есть. Это открывает возможности для какие-то новых продуктов, что тоже интересно.

https://stackoverflow.co/company/press/archive/openai-partnership

Захожу сегодня на StackOverflow а там говорят что опять подумывают над открытим jobs раздела.

Напомню, раздел закрылся 31 марта 2022 года, почти сразу после продажи/покупки компании.

https://xn--r1a.website/neverendingit/436

Сегодня хочу с вами поделится ресурсом, где собраны ссылки на карьерные матрицы разных компаний. Тут есть примеры для разных ролей разработчики, дизайнеры, продакты. Можно использовать как вдохновение для составления матрицы грейдинга в вашей компании, плана развития для членов вашей команды, ну или как ориентир развития для себя.

https://progression.fyi/

Бывают такие статьи который читаешь и прямо перед глазами пробегают ситуации из прошлых проектов. Сегодня статья о 8 ошибках при переписывании проектов/систем. Автор собрал замечательный список. Чаще всего здесь идет речь о переписывании системы в которых вы не принимали участия при проектировании/написании. Выбрал несколько которые особо понравились и откликнулись, остальные читайте в оригинале.

- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.

- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси 🥲. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки

- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?

- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.

Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)

Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"

Люблю такие статьи в стиле lessons learned и сам люблю говорить на эту тему. Правда в последнее время прихожу к мысли что некоторые советы даже если их прочитать и понять логику, просто не получится применить или прочувствовать/понять. В молодости всегда хочется доказать, что ты умнее/сильнее и у тебя другой путь. Ну это как родительское "одевай шапку зимой" чувствуешь только после того как пару раз сляжешь с серьезным воспалением чего-нибудь.
Но! Это не значит, что про это не надо говорить, такие статьи помогают структурировать и уложить в голове хотя бы то, через что уже точно прошел сам, а значит может появится доверие и к другим советам.

Вынес пару советов которые понравились, остальные читайте в оригинальной статье.

Do things in the most straightforward way possible. It’s easy to fall into the trap of clever solutions, or clever applications of technology, or overbuilding something because you’re anticipating the future. Don’t do it. You will hate yourself for it later when you have to maintain it. Build the thing in the simplest way you can, as fast as you can. You can improve it over time as needs demand.

The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over. I’ve lost track of all of the software I’ve delivered that isn’t running anywhere anymore. Some of that is because my career is 35 years long. But even some of the software I worked on five or ten years ago isn’t running anymore. This is another good reason to build small increments, just good enough, get them out there, and iterate from there. Anything more and you’ve overbuilt some software that isn’t going to run forever anyway.

https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/

Несколько раз видел статьи про использование UUID в качестве ключа в postgresql, наконец-то добрался почитать. Вообщем кратко, если вам по какой-то причине пришлось использовать UUID в качестве PK то рассмотрите использование UUID v7, он показывает хороший прирост производительности в отдельных случаях. Дефолтный Java randomUUID выдает v4. Поэтому нужно будет подключение внешней библиотеки.

https://maciejwalkowiak.com/blog/postgres-uuid-primary-key/

Очень подробная статья от 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