А так ли нужен staging в разработке?

Размышления на тему из платной рассылки Refactoring. В PDF полная версия.

Основные аргументы против:
— тяжело поддерживать окружение идентичное продакшену и проверка на стейже всё равно не даёт 100% гарантии работы на проде;
— релизы замедляются (часто значительно замедляются).

Есть, конечно, и плюсы, вот автор и размышляет, интересно глянуть разные мнения.

А что вы думаете по этому поводу? Как у вас в проектах?

Бро, ты можешь тут реализоваться и т.д.

Став частью ОТП Банка, именно ты сделаешь сильнее всю команду! Расти, учись и пробуй новое — это твой шанс создать что-то по-настоящему крутое.

Присоединяйся к ребятам и делись роликом с теми, кто тоже готов к переменам 🚀

Большая часть интерфейсов рассчитана только на людей с «идеальным» зрением, хотя проблемы с восприятием цветов есть у 8% мужчин и 0,5% женщин. Для них «красные ошибки» и «зелёные успехи» часто сливаются в один и тот же серо‑коричневый фон.

Один разработчик с дальтонизмом настолько от этого устал, что написал Colorblind Accessibility Guide, куда свёл все основные правила.

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

@prog_stuff

Hugging Face выкатили Smol Training Playbook — практический гайд, как тренировать LLM от решения нужно ли вообще это делать до рецептов пред-тренинга, пост‑тренинга и настройки кластера. Это не обзор теории, а реальная инструкция на примере SmolLM3 (3B, ~11T токенов) с конфигами, абляциями, подводными камнями и выводами.

Объём большой, даже просто прочитать и вникнуть скорее всего за один день не получится. К посту прикрепляем PDF-версию.

Результаты довольно безумного конкурса по C++: когда-то давно участники соревновались, чей минимальный кусок кода может породить максимально гигантский вывод ошибок компилятора. Есть несколько категорий: самые огромные ошибки с любыми трюками (вплоть до include самого себя), «чистые» ошибки, варианты без препроцессора, лучший чит и даже «самый жизненный» корпоративный ад из шаблонов и std::vector.​

Если кратко, это коллекция микроскопических C++‑примеров, которые превращают g++/clang в генератор мегабайт и гигабайт нечитаемого error‑спама — с описанием приёмов и исходниками прямо на странице.

Занятно глянуть на досуге на это безумие. Есть ли практическая польза каждый пусть сам решит :)

@prog_stuff

С кем знакомятся типичные программисты: 2D-тян или живая девушка?

Согласно недавним исследованиям Vantage Point Counseling Services, треть американцев хотя бы раз состояла в романтических отношениях с ИИ. Появилось даже приложение Loverse для виртуальных знакомств, где вместо реальных людей роль партнёров выполняют чат-боты с искусственным интеллектом.

Мы решили провести своё исследование и выяснить где и с кем сегодня знакомятся пользователи стран СНГ. Пожалуйста, пройдите наш небольшой опрос. Это поможет нашему исследованию.

Пройти опрос.

Статья про «обвал качества софта»: от калькулятора, который умудряется занимать десятки гигабайт памяти, до инцидентов уровня CrowdStrike и ИИ‑ассистентов, случайно сносящих продовые базы. Автор показывает, как за пару десятилетий мы привыкли к тому, что всё падает и жрёт ресурсы, а ответ индустрии — не чинить причины, а строить ещё дата‑центры.​

Забавно читать это в паре с заметками Futurist Programming Notes образца 1991 года, где уже тогда жаловались на тормозной софт, раздутые абстракции и неуважение к времени пользователя. Контраст даёт хорошее ощущение масштаба: ворчание «раньше было лучше» было всегда, но сейчас к этому добавились глобальные инциденты и слой ИИ, который усиливает чужие ошибки вместо того, чтобы их исправлять.

@prog_stuff

GitHub‑проект COS — это операционная система, написанная полностью на языке C. В репозитории лежит исходный код ядра, утилиты и сборочные файлы: 95% на C, немного ассемблера для низкоуровневых вещей, shell‑скрипты и линкер‑скрипт для сборки образа.​

В описании сказано, что система полностью на C, и явно указаны дефолтные учётные данные для входа: имя пользователя admin, пароль password. Это типичный для pet‑проектов подход: человек пишет ОС с нуля, чтобы разобраться, как работает железо, память, прерывания и всё остальное, что обычно скрыто за слоями абстракции.​

По структуре репо можно увидеть, что там есть исходники ядра, базовые драйверы, консольный ввод‑вывод и утилиты — минимальный набор, чтобы загрузиться и получить рабочую командную строку. Это не Linux и не готовое решение для продакшена, а скорее учебный стенд, где автор сам реализует каждый компонент, начиная от загрузчика и заканчивая менеджером памяти.​

Для разработчиков, которые хотят понять, как устроена ОС изнутри, это рабочий пример: можно склонировать репо, собрать образ, запустить в эмуляторе (QEMU/VirtualBox) и пошагово разбирать, как работает каждая часть — от установки стека и инициализации прерываний до работы с файловой системой и консолью.

@prog_stuff

Занятный проект на Python из категории «потому что могу»: Rubiksolver

Коротко: это десктоп-приложение, которое через веб-камеру считывает состояние перемешанного кубика Рубика и показывает пошаговое решение с анимацией в окне на PySide6 с отрисовкой через OpenGL и обработкой изображения в OpenCV. Проект позиционируется как учебный — подойдёт тем, кто хочет понять базовые приёмы компьютерного зрения и графики на практике.​

Сканирование: показываете камере по одной грани по заранее заданным правилам. После скана жмёте Play, чтобы запустить анимацию, или листаете шаги кнопками Previous/Next — так удобно проверять, что распознание и сама сборка идут корректно.​

Установка: клонируете репозиторий, выполняете uv sync для зависимостей и запускаете uv run rubiksolver — автор использует современный менеджер uv, так что установка занимает минимум времени.

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

@zen_of_python

Интерн в TikTok частично переписал один из платёжных сервисов с Go на Rust: только самые горячие, CPU‑зависимые эндпоинты, остальное осталось на Go. В результате сервис стал обрабатывать примерно в 2 раза больше запросов на тех же vCPU, p99‑латентность упала примерно на 76%, а по оценкам команды это даёт порядка 300k долларов экономии в год на вычислительных ресурсах.​​

В подробном разборе автор рассказывает, как они выбрали архитектурный подход (отдельный Rust‑кластер под те же API, без изменений для апстрим‑сервисов), как проверяли корректность через проигрывание реального трафика в shadow‑режиме и как поэтапно раскатывали Rust‑версию в прод. Почитать можно в его статье «A Case Study in Rewriting a Critical Service in Rust» и посмотреть доклад «FH #278: Rewriting Services in Rust @ TikTok» — там разложено по шагам, когда имеет смысл трогать Rust и как делать такой частичный рерайтинг без боли.

Вы тоже сначала делаете cd в директорию, чтобы снизить уровень стресса в подобных командах?