Все потоки

Привет, коллеги! 

Сегодня мы копнем в самую суть инженерного подхода. На повестке дня - сравнение двух кардинально разных философий создания сложного UI-компонента. Это не просто рассказ о DatePicker, это анализ стратегического выбора, который каждая команда делает каждый день: скорость в ущерб предсказуемости или наоборот?

Исходный код доступен по ссылке: https://github.com/Codesrc-public-ru/ralf-datapicker

За основу мы возьмем два реальных кейса. Первый - «AI-драфтинг», отлично описанный нашей статье "Создаем WCAG-доступный DatePicker на React: как Claude пишет основу, а мы доводим до ума". Идея: получить 80% кода от нейросети, а остальное довести вручную. Это путь быстрых итераций и реактивного решения проблем.

Второй - «Системный инжиниринг», подход описан в этой документации к инструменту https://github.com/snarktank/ralph. Идея: сначала детальное проектирование, потом итеративная работа модели. Это путь проактивного управления сложностью.

Оба приводят к результату. Но какой ценой? И что скрывается под капотом каждого из них? Давайте разберем.

Я пять лет писал на .NET, и там у меня сложилась привычка держать доменную модель отдельно от инфраструктуры хранения. Repository pattern — не как догма из книги Фаулера, а как рабочий способ не тащить DbContext, маппинги и названия колонок в сущности. Домен остаётся доменом. Когда я перешёл на Go, меня сразу царапнули struct tags.

Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот

Подумаем в статье почему так происходит и что с этим делать

У меня был проект, где один Next.js сайт обслуживал несколько доменов, и возникла задача — эффективно кешировать страницы, чтобы не пересоздавать их каждый раз. Сначала я попробовал внедрить кеширование через Redis: я написал хендлер, подключил его, но вскоре обнаружил, что Redis потребляет колоссальный объём оперативной памяти — порядка 100 ГБ, и это при том, что ещё не все запросы были закешированы. Тогда я решил поискать другой подход и обратил внимание на PVC — общее хранилище, которое могли бы использовать все поды. Я начал изучать варианты работы с PVC и довольно быстро пришёл к идее общего кеш‑хранилища для всех подов. Я попробовал просто писать данные в PVC, но столкнулся с проблемой: каждый раз, когда под поднимался, он перезаписывал кеш. До тех пор, пока не подняты все поды, данные постоянно перезаписывались, а мне нужно было, чтобы первый под записал данные, а последующие только читали их. Я начал искать, как сделать кастомный кеш‑хендлер, но готовых решений не нашёл.

Привет, меня зовут Дмитрий Синявский. Я инженер по надёжности сервиса в Ви.Tech и одна из моих любимых тем SLI/SLO. Сегодня разберемся с «скоростью расхода бюджета ошибок».

Недавно я провел опрос в канале сообщества ALLSLO, в котором спрашивал вызывает ли понимание термина Error budget burn rate сложности. В опросе верный ответ отсутствовал и был вариант «нет верного ответа», однако более 40% выбрало неверный ответ. Потому давайте разберемся, что же это такое Error budget burn rate.

Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки ERP домена и требует особо пристальной реализации. Это особенно применимо для коммерческих систем (коей и является Kroncl - название системы), в которых классический RBAC требует определённых доработок, включающих адаптацию к упрощённой features-based access control (в народе - FBAC, является своего рода реализацией ABAC). Кроме того, технологические компании крайне редко (уникальные случаи всё же есть) посвящают публичные статьи внутреннему устройству своих систем тарификации, что крайне печально, ведь это буквально могли быть рассказы о том, как архитектурные решения напрямую влияют на маркетинг и как следствие доходность компании.

Как же строить системы определения доступа не вокруг конкретных действий, а экономической модели платформы? Как легко переусложнить то, что переусложнять априори не стоит? Где заканчивается гибкость и начинается ад поддержки?

Этот документ описывает процедуру воспоминания о девушке по имени Аня, с которой пользователь встречался в период с февраля 2011 по декабрь 2024 года. Процедура предназначена для случаев, когда автоматический триггер (запах кофе в кофейне White Swift, песня Animal Jazz “Три полоски на кедах”, фотография красных песков Алтая ближе к монгольской границе) приводит к непредвиденному состоянию системы.

Версия: 2.4.1
Последнее обновление: четверг, в три часа ночи
Статус: deprecated, но не удаляется.

1. Предварительные требования
Перед запуском процедуры убедитесь, что выполнены следующие условия:
* Вы один в комнате
* Уровень освещённости — низкий (рекомендуется настольная лампа с тёплым светом, не верхний свет)
* Все мессенджеры закрыты (особенно Telegram — известный источник побочных эффектов)
* В радиусе досягаемости находится: стакан воды, плед, Chateau Mukhrani Reserve Royale Goruli Mitsvane (опционально, но настоятельно рекомендуется)

⚠️ Внимание: запуск процедуры в состоянии алкогольного опьянения приводит к рекурсивному вызову функции написать_бывшей(), которая, как известно, не имеет корректного выхода.

2. Инициализация
2.1. Загрузка контекста
Откройте папку ~/память/2025/. Внутри обнаружится подпапка аня/. Не открывайте её сразу — сначала выполните:
$ ls -la ~/память/2025/аня/

Вы увидите 247 файлов. Большинство из них — .jpg, несколько .mp3 (в основном — голосовые сообщения), один файл последний_разговор.txt размером 4.2 КБ.

2.2. Проверка целостности
Файл последний_разговор.txt за прошедшие годы мог быть повреждён в результате многократного перечитывания. Это нормально. Не пытайтесь его восстановить — оригинал утерян безвозвратно, а ваша текущая версия содержит правки, внесённые задним числом, на основе того, как должно было быть.

В эксперимент мы шли с уверенностью, что ChatGPT хотя бы раз из пяти промахнётся с главным диагнозом. Не промахнулся. Пять из пяти: метаболический синдром, субклинический гипотиреоз, перименопауза, MGUS, статин-индуцированный рабдомиолиз. Ставка проиграна, но самое интересное оказалось не здесь.

Модели разошлись сразу после диагноза. У ChatGPT провалилось то, что в клинической работе называется «что пациент делает в ближайшие две недели»: к каким врачам идти, какие обследования сдать до начала терапии (ПСА перед заместительной терапией тестостероном, маммография перед МГТ), какие целевые уровни держать и когда перепроверять, как прочитать соотношение АСТ и АЛТ при рабдомиолизе. На четырёх плановых кейсах эта разница повторилась одинаково.

А на пятом — кейсе MGUS — проиграл уже МедАссист. ChatGPT и соотношение альбумин/глобулин посчитал явно, и конкретный список подтверждающих тестов для гематолога назвал — мы не сделали ни того, ни другого. Раздел про этот кейс у нас расписан подробнее остальных: мы договорились разбирать свои промахи внимательно, а не проматывать.

Оговорюсь сразу. Пишем мы от команды, которая делает МедАссист, — один из двух сервисов в сравнении. Интерес у нас есть, прятать его бессмысленно. Поэтому методику мы зафиксировали до первого прогона, ответы обоих сервисов приводим слово в слово, а кейс, где мы проиграли, разбираем подробно. Судить, насколько это уравновешивает конфликт интересов, — читателю.

В данной статье рассматривается создание сервиса для динамического изменения размеров изображений с функциями проксирования и кэширования, а также приводится вариант его применения.

Представьте: production, 3 часа ночи, пользователи жалуются на ошибки. Вы открываете логи и видите...

Левел дизайн игры Dishonored достойный пример грамотного построения уровней с гибкостью подхода к прохождению, одна ко мне заметился один элемент который как по мне является неполным или даже несколько непродуманным в общем настроении уровня и что именно не так, а так же как ещё более плотно связать мир игры и механику хаоса, попробую изложить как и в прошлой части, но с большим рассмотрением точечных изменений уровней которые сделают их более запоминающимися.
Отдельно упомяну переосмысление хаоса, которое перескажу для простоты понимания последующих рассуждений:

Памятники орхоно-енисейской письменности представляют собой древнейшие известные источники, фиксирующие тюркоязычную речь. Их научное значение первостепенно, так как они принадлежат средневековым обществам, сообщения о которых в иных письменных документах крайне скудны или полностью отсутствуют. Это не просто разрозненные артефакты, а сложные системы государственной письменности, где каждый алфавит являлся культурно-политическим признаком конкретного государственного образования.

Они по праву считаются летописями, поскольку относятся к эпохе становления и развития раннесредневековых феодальных государств и объединяют огромные пространства Европы и Азии. Каменные стелы использовались как официальное письмо в каганатах, содержат важные исторические и филологические сведения и отражают широкий спектр жанров — от эпитафий до религиозных текстов. Несмотря на то, что большинство надписей сохранилось на камне, сама письменная традиция была значительно шире и свидетельствует о развитой культуре письма.

Знакомство с этими памятниками обычного человека затруднено: не все руны легко различить на каменной поверхности, испещренной трещинами, и сами достопримечательности разбросаны по центральной Азии. Если даже и знать перевод надписи с памятника, то это взаимодействие все равно не будет достаточно интерактивным. Намного интереснее услышать, как звучали эти тексты на забытом языке. Автоматически восстановить звучание древнетюркских надписей становится возможным благодаря моделям распознавания рун. Идентифицируя каждую руну в надписи, реально озвучить весь текст. Подробнее про модели компьютерного зрения можно прочитать в предыдущей статье: https://habr.com/ru/companies/fa/articles/907950/

Рассмотрен подход к созданию управляемого "бэкдора", позволяющего подгружать функции без остановки и перезагрузки. С помощью манипуляций с линкер-скриптом и средств языка C создаются "точки расширения" в прошивке, позволяющие в будущем внедрять новые функциональные модули без пересборки и перезаписи всей программы. Такой подход может быть полезен при разработке отказоустойчивых систем для оптимизации жизненного цикла встроенного ПО, так как позволяет заложить гибкость при непредвиденных модификациях.

Несколько дней назад, 29 апреля 2026 года, вышел Proxmox Backup Server 4.2. Формально это промежуточный релиз: обновили базовую систему до Debian 13.4 Trixie, поставили Linux 7.0 как новый стабильный вариант ядра, добавили ZFS 2.4.1, поправили ошибки и доработали интерфейс. Но по смыслу релиз заметнее, чем кажется: S3-совместимые объектные хранилища стали официально поддерживаемыми, синхронизация между серверами научилась работать параллельно, появились шифрование и расшифровка на стороне сервера для задач синхронизации, а группы резервных копий и пространства имён теперь можно перемещать внутри хранилища.

То есть Proxmox Backup Server постепенно уходит от образа «удобной бэкапницы рядом с Proxmox VE». Он становится отдельным сервером резервного копирования: с дедупликацией, политиками хранения, проверкой целостности, удалённой синхронизацией, S3-хранилищами, лентами и внятной эксплуатационной моделью. Нет, не универсальной заменой всем системам резервного копирования на свете, но очень естественным инструментом для тех, у кого инфраструктура уже построена вокруг Proxmox.

Планирование времени это же целая «наука», до момента когда я стал интересоваться и применять методики тайм‑менеджмента, не представлял как много уходит времени мимо и расходуется не эффективно. Но стал ли я от этого успешнее, продуктивнее. Стало ли мне легче?

В комментариях к статье "Теорема Пифагора: великий обман школьной программы. Как абстракция убила смысл" прозвучало много претензий к современной системе общего школьного образования. Судя по общему тону высказываний, мало кто понимает, зачем и каким образом функционирует данная система (особенно в историческом контексте), какие задачи решает и каким целям служит. Не углубляясь в серьезно в глубину данного вопроса (который достоин целого исследования), позволю себе некоторые замечания по существу темы.

Всем привет. В этой статье расскажу о новостях касаемо Loki. О том что было представлено на GrafanaCON 2026 в Барселоне. Чего нам ждать от новой архитектуры Loki, как она будет работать, и что прячет под капотом.

Apache Doris 4.1 добавляет UPDATE, DELETE и MERGE INTO на Iceberg-таблицы прямо из SQL-клиента — без отдельного Spark job. Iceberg V3 Deletion Vectors и Row Lineage делают этот DML архитектурно здоровым: нет линейной деградации от delete files, нет false positives в CDC после compaction. Перевод и адаптация статьи Mingyu Chen (CC BY 4.0) с бенчмарками, SQL-примерами и Quick Start.

Представьте: совещание. Руководитель разбирает чужой проект, но смотрит почему-то на вас. Голос становится холоднее. Пауза затягивается.

Один человек в этой комнате начинает возражать — спокойно, но твёрдо. Другой молча собирает бумаги и говорит, что ему нужно срочно на звонок. Третий замирает, смотрит в стол, и его как будто нет. Четвёртый улыбается и кивает — соглашается со всем, что слышит, даже если это неправда.

Четыре человека. Четыре реакции. Один нейробиологический механизм возрастом несколько сотен миллионов лет.

Не так давно Rockstar поклялась выпустить GTA 6 к 19 ноября 2026 года. Вот только эти же слова мы уже слышали полгода назад — и тогда они не сработали. Между выходом пятой части и ожидаемым релизом шестой пройдет 13 лет — это самый большой разрыв в серии. За это время успели выйти и устареть целые поколения консолей и видюх, а GTA Online до сих пор исправно качает деньги из фанатов. Конкретика вроде есть, дата вроде финальная — вот только опыт подсказывает, что именно в такой момент обычно и прилетает новый перенос. И главный вопрос, который напрашивается сам собой: пришло ли время для очередного переноса? Давайте будем честны и попробуем сами во всем разобраться.