Сначала мы делали вид, что ничего не происходит.
Портал документации то открывался, то нет. Кто-то из коллег замечал, обновлял страницу, всё грузилось — ну ок, и мы шли дальше. Так продолжалось пару месяцев, пока «то работает, то нет» не превратилось в «чаще не работает». Портал жил на GitBook, большая часть пользователей у нас из России, и в какой-то момент эти два факта перестали быть совместимы — но признавать это очень не хотелось.
Некоторые графики объясняют происходящее лучше, чем десяток книг с прогнозами. Вот, например.
17 лет с покупки первого айфона я складывал музыку в одну медиатеку. Она начиналась с mp3-шек на жёстком диске, пережила переезд в стриминг (через iTunes Match) и росла до марта 2026-го. Плейлисты «Deepden», “Kizaru”, “повтор” — собранные под себя, годами.
Формат: туториал + личный опыт. Сложность: средняя. Время чтения: ~15 минут.
Говорят, Россия вымирает. Я скачал данные World Bank за 65 лет, построил 8 графиков и проверил. Вот что нашёл. Решайте сами.
Каждый из нас существует потому, что кто-то когда-то решил завести ребёнка. Ваша работа, ваш город, ваша пенсия, ваш любимый ресторан, водитель такси, врач в поликлинике. Всё это держится на простом факте: людей должно быть достаточно.
За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?
Кодовой базе было 6 лет. Node.js-монолит на 200K строк, который обслуживал 50K DAU. Восемь разработчиков за эти годы оставили след: файлы с JSDoc, файлы без него, 200+ комментариев // @ts-ignore от попытки миграции в 2022 году, которая дошла до 15% и остановилась.
Боль была конкретная: Читать полностью »
Всем привет! Хочу рассказать, как мы небольшой командой проектировали кэш поиска отелей для сервиса по бронированию отелей и почему за полтора года прошли путь от Infinispan к managed Redis а затем к Postgres. По стеку java-21, spring-boot-3, 1 вендор отелей, расчетная нагрузка 1000 RPS и 10M запросов в сутки.
Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.
Есть очень узнаваемая картина. Новый релиз выкатывается нормально на staging, а в production внезапно «висит». kubectl get podsЧитать полностью »
Переезд начался не из-за какой-то аварии. Просто в какой-то момент я понял, что мне уже неприятно лишний раз лезть в сценарии: одна правка тянула за собой еще несколько проверок.
В какой-то вечер полез поправить один старый сценарий. Дальше, как обычно, пришлось проверить соседние связи, потом еще один кусок логики, потом еще. На этом и поймал себя: система вроде работает, а трогать ее лишний раз уже не хочется.
Тогда я и решил, что пора переезжать.
Сразу скажу: osysHome я пишу сам. Поэтому это не обзор рынка и не попытка кого-то переубедить. Просто рассказываю, как переезжал у себя дома.
Привет! Недавно мы с проектом (а по факту я в гордом одиночестве) переезжали с MySQL на PostgreSQL. Зачем? Проект — гео‑сервис для рыбаков: карта с точками, поиск рядом, фильтры по регионам, водоёмам и рыбам. MySQL стал тормозить на гео‑запросах, а PostGIS обещал скорость и порядок. Плюс мы всё равно переезжали на новый VDS – решили заодно сменить СУБД, пока данных не стало неприлично много.
Продом обкатано: читать будет полезно.
1. Исходные данные (чтобы понимали масштаб)
Проект не огромный, но и не игрушечный:
