Рабочий день разработчика в команде обычно начинается с проверки текущего состояния проекта. В трекере могли появиться комментарии к задаче, в pull request замечания от ревьюеров, а в CI могла упасть сборка. Иногда приоритет меняется из-за стоппера в соседней команде или ошибки, найденной во время тестирования.

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

После синка разработчик обновляет карточку задачи: меняет статус, добавляет ссылки на pull request или сборку, фиксирует блокеры и договорённости. По хорошему описанию коллега должен понять текущее состояние работы без дополнительного созвона.

Если задачу можно брать в разработку, перед первым коммитом стоит ещё раз проверить её содержание. В карточке должны быть указаны:

• цель изменения,
• ожидаемое поведение системы,
• пользовательские сценарии,
• ограничения,
• условия приёмки.

Для интерфейсной задачи понадобится согласованный дизайн, для интеграции с другим сервисом потребуются контракт API и описание возможных ошибок.

Как задача попадает в работу

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

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

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

Готовая к разработке карточка обычно содержит:

• цель изменения и ожидаемый результат;
• пользовательские сценарии;
• дизайн, спецификацию или контракт API;
• условия приёмки и способ тестирования;
• ограничения и зависимости от других компонентов;
• оценку объёма работы.

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

При работе спринтами готовые карточки обсуждают на планировании. Команда определяет цель спринта, оценивает доступные ресурсы и выбирает объём работы. После планирования карточка переходит в статус To Do. Теперь у разработчика есть понятная цель, согласованный объём и условия приёмки.

С этого момента начинается техническая работа: исследование проекта, выбор решения и декомпозиция реализации.

Что проверяет разработчик перед кодом

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

• где находится код, связанный с задачей;
• какие модули, интерфейсы и пользовательские сценарии изменятся;
• какие готовые компоненты можно использовать;
• зависит ли реализация от другой задачи или сервиса;
• потребуется ли feature toggle или A/B-тест;
• какие проверки нужно добавить или обновить.

Отдельно разработчик смотрит активные ветки и pull request в той же части проекта. Параллельные изменения могут затронуть общий интерфейс или компонент. Если узнать об этом заранее, можно согласовать порядок мержа и избежать повторной проверки обеих задач.

Дальше разработчик определяет объём тестирования. Он изучает существующие тест-кейсы, отмечает затронутую функциональность и решает, где понадобятся юнит-тесты или UI-тесты. Эти данные пригодятся и тестировщику при подготовке функциональной проверки и регресса.

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

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

Как проходит код-ревью

Когда реализация готова, разработчик открывает pull request и связывает его с карточкой задачи. Вместе с кодом ревьюер получает контекст: цель изменения, требования, затронутые компоненты и способ проверки.

Перед ручным ревью запускается CI. Пайплайн собирает проект, проверяет код линтером и прогоняет юнит-тесты. Результаты видны прямо в pull request, поэтому ошибки сборки и упавшие тесты можно исправить до мержа.

Ревьюеры проверяют:

• соответствует ли реализация требованиям задачи;
• корректно ли код взаимодействует с существующими модулями и интерфейсами;
• учтены ли изменения в соседних компонентах;
• добавлены ли необходимые тесты;
• проходят ли автоматические проверки.

Обычно pull request смотрят разработчики, которые работают с той же функциональностью и знают её ограничения. Если в команде только один специалист по нужной платформе, подключают коллегу из другой команды с подходящей технической экспертизой.

Замечания оставляют в комментариях к конкретным строкам или участкам решения. Автор исправляет код, обновляет pull request и повторно запускает проверки. Если комментариев недостаточно для обсуждения сложной реализации, участники созваниваются и разбирают решение вместе.

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

Как задачу тестируют

После код-ревью CI собирает тестовую версию. Ссылка на сборку появляется в карточке задачи, поэтому разработчик и тестировщик работают с одним и тем же вариантом приложения.

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

Тестировщик проверяет соответствие условиям приёмки, работу связанных компонентов и регрессионные сценарии. Быстрые автоматические проверки запускаются в CI, а ресурсоёмкие UI-тесты могут выполняться по расписанию или перед релизом.

Найденная ошибка возвращает карточку в статус Reopen. Разработчик исправляет код, CI выпускает новую сборку, и проверка запускается повторно. После успешного тестирования задача получает статус готовности к релизу и связывается с нужной версией продукта.

Как команда готовит релиз

Когда задачи прошли тестирование, команда фиксирует состав релиза. Карточки связывают с конкретной версией продукта, а изменения, которые не успели пройти все проверки, переносят в следующую.

В проектах с релизным циклом CI создаёт релизную ветку и собирает из неё готовую версию. При непрерывной доставке похожий пайплайн запускается для каждого принятого изменения. В обоих случаях сборка выполняется в настроенном окружении, чтобы результат не зависел от компьютера конкретного разработчика.

Перед выпуском срабатывают quality gates:

• проект успешно собирается;
• юнит-тесты проходят;
• статический анализ не находит критических проблем;
• регрессионные и UI-тесты завершаются успешно.

Если в релизной версии находят ошибку, исправление делают в отдельной ветке от релизной. После повторного ревью и тестирования код возвращают в релиз, а затем переносят в основную ветку разработки. Так исправление сохраняется и в следующих версиях.

Дальнейший процесс зависит от настроек CD. При Continuous Delivery готовая сборка ждёт ручного подтверждения выпуска. При Continuous Deployment изменение автоматически отправляется в прод после прохождения всех проверок.

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

Если вам интересно работать над программными решениями в составе нашей команды, загляните на карьерную страницу Centicore Group. Там мы публикуем открытые вакансии и отзывы наших разработчиков, аналитиков и тестировщиков.

Что происходит после выхода в прод

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

Команда отслеживает:

• ошибки и сбои в новой версии;
• технические показатели затронутых компонентов;
• продуктовые метрики, указанные в задаче;
• обращения пользователей в поддержку.

Набор метрик зависит от цели изменения. Для нового пользовательского сценария можно смотреть количество открытий, завершённых действий и выходов на отдельных этапах. Если фича выпущена в рамках A/B-теста, команда сравнивает поведение контрольной и тестовой групп.

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

Для срочного исправления создают hotfix. Он проходит сокращённый по времени цикл, сохраняя обязательные проверки: код-ревью, сборку и тестирование затронутого сценария. После выпуска исправление добавляют в основную ветку разработки, чтобы ошибка не вернулась в следующем релизе.

Задачу закрывают после проверки технических и продуктовых показателей. Если новая функция работает стабильно и даёт ожидаемый результат, она остаётся в продукте. При отклонениях команда возвращается к требованиям, анализирует реализацию и планирует доработку.

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

Рабочие встречи сопровождают задачу на разных этапах. У каждой встречи своя функция и конкретный результат: подготовленная карточка, выбранный объём работ, принятое техническое решение или проблема.

Основные встречи связаны с процессом так:

• на груминге уточняют требования и готовят задачи к планированию;
• на планировании выбирают задачи для следующего спринта;
• на дейлике проверяют прогресс и находят блокеры;
• на техническом синке обсуждают зависимости и сложные решения;
• на демо показывают готовую функциональность;
• на ретро разбирают проблемы прошедшего цикла и корректируют процесс.

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

Итого

В Centicore мы смотрим на задачу как на общий результат команды. Аналитик помогает сформулировать требования, разработчик отвечает за техническое решение, ревьюеры проверяют его влияние на проект, а тестировщики подтверждают, что всё работает по согласованным сценариям.

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

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

Проект поддерживается преимущественно разработчиками из России, Казахстана, Украины и Германии. Код распространяется под открытой лицензией, а сборки регулярно публикуются на официальном сайте и зеркалах сообщества.

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

1. Rainwave: интерактивное радио с геймерским сердцем

Rainwave — культовое онлайн-радио для фанатов видеоигр, работающее с 2000 года. Оно предлагает пять каналов: Game (классика VGM), Chiptune (8-битные треки), Covers (каверы игровых OST), OCRemix (фанатские ремиксы) и All (микс всего). Плейлист формируется сообществом — можно голосовать за треки, запрашивать любимые мелодии из The Legend of Zelda или Final Fantasy и даже общаться в чате.

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

2. VGM Radio: чистый поток игровой классики

VGM Radio — минималистичное радио, которое вещает саундтреки из игр 80-х, 90-х и современных тайтлов. Здесь нет рекламы — только музыка от NES (Mario, Metroid) до PS5 (God of War). Стримы идут 24/7, с упором на ретро и оркестровые треки, создающие атмосферу приключений.

Идеально для кодинга, где нужна стабильная фоновая музыка без резких смен настроения.

3. 8Beats Radio: сообщество и саундтреки 24/7

8Beats — это радио, созданное геймерами для геймеров, с фокусом на саундтреки от инди-игр (Hollow Knight) до AAA-тайтлов (The Witcher). Станция работает круглосуточно, с обновляемыми плейлистами и возможностью запросить треки через Discord. Чиптюн, lo-fi и оркестровые мелодии чередуются, создавая баланс между релаксом и мотивацией.

Для кодеров, которые любят комьюнити и хотят микс из свежих и классических треков. Отлично для работы в команде или долгих спринтов.

4. RPGamers Network Radio: для фанатов RPG и эпоса

Это радио специализируется на саундтреках из RPG — жанра, где музыка всегда была эпичной и эмоциональной (Final Fantasy, Skyrim, Chrono Trigger). Станция позволяет слушателям голосовать за треки, формируя плейлист в реальном времени. Есть миксы из action/RPG и ретро-игр, чтобы держать слушателей в тонусе.

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

5. AccuRadio: Video Game Soundtracks — эпичность без пауз

AccuRadio предлагает канал, посвященный оркестровым саундтрекам из игр вроде The Legend of Zelda, God of War и Halo. Без рекламы (можно пропустить редкие объявления), с акцентом на кинематографичные треки, которые вдохновляют на подвиги.

Для айтишников, которым нужно вдохновение для больших проектов. Отлично для работы над фронтендом или визуализациями.

6. TuneIn: Stream Video Game Music — универсальный выбор

TuneIn агрегирует станции с VGM, предлагая микс из ретро (Sonic, Mario) и современных игр (Cyberpunk 2077). Там не только радио, но и подкасты о гейминге, если нужен перерыв. Стримы стабильны, с широким выбором: от чиптюна до ambient-саундтреков.

Для тех, кто хочет разнообразия и не против переключиться на подкаст. Подходит для кодинга и ресеча.

7. YouTube: Coding Stupor ~ Video Game Music for Focus

Плейлист на 10+ часов. Здесь треки из инди-игр (Stardew Valley, Journey) и крупных тайтлов (Mass Effect). Музыка мягкая, без резких переходов, глубокого погружает в код. Обновляется редко, но качество на высоте.

Для соло-кодинга, когда нужно уйти в себя и писать сложные алгоритмы.

8. YouTube: Video Game Work Music Playlist

Плейлист на 100+ треков, от чилловых (Celeste) до более драйвовых (Halo, Doom). Собран для работы и кодинга, с упором на баланс между релаксом и энергией. Регулярно обновляется, чтобы не приедалось.

Для спринтов и дедлайнов — музыка мотивирует, но не отвлекает.

Делитесь любимыми онлайн-радио в комментариях!

Код считался устаревшим, его удалили из ядра в версии 2.6.20 (в 2006 году), а теперь воскресили с помощью ИИ-помощника.

За проект взялся разработчик из Wikimedia — Дмитрий Брант, который сначала не рассчитывал на быстрый успех. Но благодаря Claude Code (ИИ-помощник от Anthropic), старый код удалось привести в рабочее состояние всего за два вечера.

Что за драйвер и зачем он нужен?

ftape — это драйвер для лент, использующих QIC-картриджи. Такие накопители были популярны в 1990-х для резервного копирования, особенно в малом бизнесе и домашних системах.

В отличие от дорогих SCSI-устройств, QIC-ленты подключались прямо к контроллеру флоппи-дисков (или через LPT-порт) — и в этом была вся магия. Драйвер буквально «обманывал» флоппи-контроллер, заставляя его работать с лентами.

ftape умел снимать полные дампы картриджей в raw-режиме, которые потом можно было расшифровать. Это важно для тех, кто хочет восстановить архивы со старых лент, даже если файловая система повреждена.

Как ИИ помог воскресить драйвер

Работа велась в три этапа:

1. Миграция под новое ядро. Claude Code получил старый код, совместимый только с ядром 2.4, и на основе подсказок заменил устаревшие вызовы ядра на актуальные API, устранил ошибки компиляции, адаптировал структуры данных.
2. Преобразование в модуль. Драйвер был встроенным, а теперь работает как загружаемый модуль (.ko), что делает его удобнее и безопаснее.
3. Отладка на современных системах. Разработчик подавал ИИ ассистенту dmesg-логи и сравнивал с поведением старого драйвера. После нескольких итераций и ручных правок модуль заработал — ленты определяются, данные считываются.

На проект, который казался адом из макросов и документации, ушло всего пару вечеров и три запроса.

Почему это важно

• Проект демонстрирует практическую пользу ИИ в разработке системного ПО, особенно при адаптации заброшенных проектов.
• Драйвер позволяет работать со старыми ленточными архивами без необходимости содержать старые дистрибутивы или «заводить» музейную технику.
• Разработка открывает путь к восстановлению данных с дефектных носителей: сейчас планируют добавить утилиты для низкоуровневого анализа и восстановления по raw-дампам.

Но не все заслуга ИИ

Дмитрий подчеркивает: без понимания архитектуры ядра и Си-языка ничего бы не вышло. ИИ — всего лишь инструмент, который можно направить, если знаешь, куда двигаться.

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

Где это можно использовать

• В архивных лабораториях — для восстановления старых данных.
• В проектах по реставрации ретро-компьютеров.
• Для системных экспериментов и исследований истории хранения информации.

Модуль работает на Ubuntu 24.04 и других дистрибутивах с ядром 6.8+, но требует контроллер флоппи-дисков на материнской плате.

Зимой 2024 года художник Дуг Макдауэлл приобрёл в комиссионном магазине капельную кофеварку General Electric Coffeematic 1980-х годов. Его целью было создание ретро-игрового компьютера, но идея трансформировалась: устройство стало гибридом — и компьютером, и кофемашиной. Так появился Coffeematic PC.

Работает и как компьютер, и как кофеварка

Машина полностью функциональна: она умеет заваривать кофе и выполнять вычисления. Более того — горячая Java (в прямом смысле) используется в качестве элемента системы охлаждения. Насос перекачивает горячий (~90°C) кофе через два радиатора к процессору, а затем обратно в графин. Цикл повторяется, пока устройство работает.

На базе Coffeematic PC Макдауэлл собрал систему сбора данных, которая фиксирует параметры работы машины. В ходе наблюдений выяснилось, что компьютер стабилизируется при температуре около 33°C — вполне рабочие условия.

Спецификации и компоненты

Внутри — переработанные и современные комплектующие:

• Материнская плата: ASUS M2NPV-VM AM2
• Процессор: AMD Athlon II X4 640
• ОЗУ: 1 ГБ DDR2 Hynix
• Накопитель: SSD 240 ГБ
• Видеокарта: Radeon HD 4670
• ОС: Linux Mint
• Система охлаждения: кофейная жидкость, насос, радиаторы
• Пищевая силиконовая трубка, латунные штуцеры, мембранный насос и водонепроницаемые тумблеры

Макдауэлл потратил около месяца на проектирование и сборку. Большинство деталей — переработанная электроника или простые компоненты из магазина для аквариумистов и сантехники.

Произведение искусства

Coffeematic PC — пятое устройство в истории компьютеров-кофеварок, начиная с The Caffeine Machine 2002 года, и первое, в котором горячий кофе задействован как элемент охлаждения. Родословная включает также Zotac Mekspresso (2018), Mr. Coffee PC (2019) и проект NerdForge (2024).

Макдауэлл представил свою работу на художественной выставке Sparklines, где объединил хенд-мейд компьютер с нарисованными вручную визуализациями данных. По его словам, проект — часть большого исследования на стыке искусства, технологии и бытовой абсурдности.

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

Высокая доступность основывается на трёх ключевых элементах: архитектуре, культуре разработки и процессах. Вместе с Борисом Кузоваткиным, директором облачной платформы One-cloud в VK, рассказываем, как создавать такие системы и что лежит в их основе.

Архитектура

Архитектура строится на принципах горизонтального масштабирования, изоляции компонентов, многоуровневого кэширования, автоматического восстановления и мониторинга на основе SLO.

Разберем на нашем кейсе: сегодня в VK активно развивается облачная платформа One-cloud. Вместо того чтобы привязываться к конкретным серверам, мы используем внутреннее облако. Это даёт гибкость: если в «классических» системах ночью сервера простаивают, то у нас эти ресурсы перераспределяются на другие задачи.

Ещё одна важная цель — обработка запроса в рамках одного ЦОД. Обычно, при сбое в одном ЦОД, часть трафика уходит на другой, и запускается эффект домино: узлы начинают падать один за другим. Обработка в рамках одного ЦОД позволяет избежать каскадных обращений между дата-центрами и минимизирует задержки. Такую стратегию применяют и другие крупные компании, разрабатывая свои сетевые решения вроде Minipack и FBOSS.

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

Культура разработки

Технологии сами по себе не обеспечивают надёжность. Важно то, как они применяются. Важно закладывать fallback-поведение: если, например, рекомендации не могут быть загружены, страница должна остаться рабочей.

Инженер должен уметь сам замечать, что «что-то идёт не так». Бывает, метрики показывают, что всё нормально, а пользователи уже начинают массово жаловаться. Или, наоборот, система присылает тревоги, но причина совсем в другом. Здесь решающим становится опыт команды и отлаженные on-call процессы.

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

Чтобы её поддерживать, необходимо регулярно проводить ретроспективы, обучающие сессии и внутренние симуляции сбоев (chaos drills).

Процессы и мониторинг

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

• частоту ошибок,
• квантили длительности запросов,
• загрузку CPU, RAM и дисков,
• бизнес-метрики (например, количество видео, просмотренных за минуту).

Для сбора метрик — Prometheus, VictoriaMetrics, Forge, а для визуализации использовать Grafana. Падение бизнес-метрик может быть вызвано не только сбоями в системе, но и внешними факторами — например, перебоями связи в праздничный день.

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

В VK есть и аварийные инструменты — для быстрого перемещения данных, поднятия сервисов, ручной настройки. Все действия сопровождаются мониторингом, чтобы видеть, как именно они влияют на систему в реальном времени.

После любого серьёзного сбоя обязательно проводится анализ:

• Что произошло?
• Как это починили?
• Что можно было сделать лучше?
• Как предотвратить повторение?
• Как система переживает сбои

Самое очевидное решение при перегрузке — выделить дополнительные серверы. Это работает, если система масштабируется горизонтально. Но если перегрузка остаётся или возникают новые проблемы — вступает в силу подход graceful degradation. Это стратегия, при которой отключаются второстепенные функции, чтобы сохранить основную работоспособность. Например:

• Пропадают рекомендации со страницы, но остаётся доступ к основному контенту;
• Увеличивается срок доставки, чтобы пользователи перестали совершать слишком много заказов;
• На стриминговых сервисах пользователь может слушать только предзагруженные треки — никаких новых загрузок и поисков.

На некоторых видеосервисах применяется load shedding: часть запросов сбрасывается, чтобы сохранить качество видео.

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

Уроки надёжности для любой команды

Кажется, что высокая доступность — задача только больших компаний. Но устойчивость начинается с малого. Всё начинается с понимания, как работает система и что с ней может случиться. Потом важно заранее продумать, как она будет вести себя при сбоях, наладить автоматизацию и внимательно относиться к качеству релизов. И только затем начинать считать «девятки» — стремиться к высокой доступности.

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

Выпущенный в 1983 году, он стал первым массовым ПК с графическим интерфейсом. Хотя по-настоящему «массовым» его назвать сложно: всего было продано около 10 000 экземпляров.

Теперь познакомиться с ОС, которая была установлена на этом компьютере, можно прямо в браузере — благодаря проекту LisaGUI.

Что такое LisaGUI

Разработчик Эндрю Ярос создал веб-эмулятор оригинальной операционной системы Lisa OS. Проект назван LisaGUI и полностью работает в браузере. Ядро эмулятора написано на JavaScript, так что пользователю не нужно устанавливать дополнительные программы.

LisaGUI позволяет увидеть, как выглядела и работала одна из первых ОС с графическим интерфейсом. Причем эмулятор не стремится к 100% точности: некоторые функции адаптированы для удобства современных пользователей.

Особенности интерфейса Apple Lisa

В отличие от привычных сегодня систем, интерфейс Lisa строится вокруг документов. Программа запускается не напрямую — пользователь создает новый документ («отрывает листок»), который потом открывает двойным щелчком.

Рабочий стол служит временным пространством: файлы можно «отложить» на него, но физически они остаются в своих папках.

В оригинальной Lisa меню открывались только при удерживании кнопки мыши. В LisaGUI меню стали «липкими» — они остаются открытыми, пока пользователь не сделает выбор.

Также добавлены современные функции, такие как часы на панели и счётчик fps, которых в оригинальной Lisa, конечно, не было.

Что доступно в эмуляторе

Сейчас основной доступной программой остается текстовый редактор LisaType. Отсутствуют такие знаковые приложения, как LisaProject — то, ради чего NASA закупало Lisa. Однако проект находится в стадии альфа-версии, и возможно, со временем появится больше программ.

LisaGUI предлагает кастомизацию: можно менять 1-битные палитры, настраивать иконки для документов и изменять размеры окон — в отличие от фиксированного 4:3 оригинала.

Для кого это интересно

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

LisaGUI — скорее ностальгический экспириенс, чем точная копия системы. Но для знакомства с историей этого вполне достаточно.

Попробовать веб-эмулятор можно бесплатно по ссылке.

Шаг 1: Оцените текущую ситуацию

Прежде чем увольняться, трезво оцените свое решение и текущие реалии рынка. В 2025 году рынок IT стал рынком работодателя (раз, два) — конкуренция за вакансии сильно выросла. Массовые сокращения в крупном ИТ-секторе за последние пару лет привели к перенасыщению рынка опытными кадрами и осложнили поиск работы, особенно для джунов и миддлов. Многие, кто сейчас выходит на рынок, сталкиваются с тем, что рекрутеры больше не пишут им первыми.

Работодатели меняют фокус на найм по рекомендациям (раз, два, три), в то время как открытый рекрутинг и холодный поиск отходят на второй план. Число открытых вакансий снизилось, потому что на публичные позиции с популярных job-сайтов сыпется слишком много откликов — в том числе от ботов и всевозможных карьерных консультантов. Чтобы не захлебнуться в потоке нерелевантных заявок, компании избегают размещать вакансии в открытом доступе, предпочитая искать через знакомых по внутренним рекомендациям (раз, два, три). В таких условиях одного резюме, выложенного на сайте, недостаточно, чтобы дождаться приглашения на собеседование. Нужно вести активный поиск, и он может занять больше времени, чем раньше.

Ещё одна реальность — развитие ИИ для выполнения рутинных задач. Очевидно, что сотрудники, выполняющие легко автоматизируемые рутинные задачи, в скором времени перестанут быть востребованы: их работу сможет заменить один удачный промпт к нейросети. В то же время спрос на специалистов, которые умеют эффективно работать с современными AI-инструментами, сейчас очень высок. Будь то разработка собственных моделей или интеграция готовых нейросетевых сервисов в рабочие процессы и продукты — теперь этот скилл — конкурентное преимущество.

Шаг 2: Обновите резюме

Для подготовки первоначального резюме можно воспользоваться специальными сайтами-конструкторами (например resumeworded.com), но использовать их стоит осторожно и только для вдохновения. Можно взять готовый шаблон резюме. Оптимальный объём резюме должен быть 1–2 страницы, а содержать оно должно ваши достижения в каждой должности. Убедитесь, что резюме правильно структурировано и содержит все ключевые слова по вашей специализации. Структура должна легко считываться не только человеком, но и автоматическими системами, так как ATS-системы отфильтровывают резюме, в которых нет структуры или терминов из описания вакансии.

Готовый вариант резюме желательно дать на проверку знакомому рекрутеру или выложить в группы Telegram по вашему профилю, для обратной связи. Свежий взгляд со стороны поможет выловить ошибки и слабые места. Есть специализированные группы (например, @resume_review), где вам субъективно оценят резюме: прислушаться стоит, но решения о правках принимайте исходя из здравого смысла.

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

Шаг 3: Прокачайте онлайн-профили

Убедитесь, что вы представлены в основных профессиональных сетях, например, на Хабр Карьера и LinkedIn. Зарегистрируйтесь (если почему-то до сих пор этого не сделали) и добавьте в контакты всех, с кем вы лично знакомы и работали: бывших коллег, одногруппников, клиентов. Когда придёт время объявить о поиске работы, их активность (лайки, комментарии, рекомендации) поможет продвинуть ваш пост.

Подготовьте площадки, на которых вы собираетесь мониторить вакансии и откликаться. Раньше многим хватало одного HeadHunter, но в нынешней конкурентной среде стоит использовать все доступные ресурсы. Вот основные из них:

• Хабр Карьера — на этой платформе сейчас меньше соискателей, чем на HH, поэтому у вас больше вероятность быть замеченным, а значит, ненулевой шанс получить ответ от работодателя.
• LinkedIn — несмотря на блокировку, там по-прежнему активное русскоязычное IT-сообщество, и многие HR ищут разработчиков через LinkedIn. Особенно полезно, если вы рассматриваете работу за рубежом.
• Сервисы типа Geekjob и Getmatch — сервисы и сайты-агрегаторы вакансий, популярные в стартап-тусовке. Пока проект небольшой, удобнее опубликовать вакансию в таком сервисе.
• Telegram-каналы и чаты с вакансиями — вступайте в сообщества, соответствующие вашему стеку или специализации, и следите за публикуемыми там предложениями. В интернете можно найти множество подборок таких каналов, по каждому направлению. (вот наиболее актуальный список каналов и чатов с вакансиями в ИТ).
• Сайты компаний — банально можно написать прям через карьерные страницы интересующих вас компаний. Вакансии там могут появляться раньше, и отклик попадает сразу в систему к рекрутеру.

Кроме того, обратите внимание на ваши проекты и код в открытом доступе. Если у вас репозитории с проектами, которыми вы гордитесь, сделайте их публичными и закрепите в своём профиле. Добавьте понятные README-файлы, описывающие проект. По возможности прикрепите ссылки на работающие демо или публикации. На пустой же GitHub ссылку лучше не давать.

Шаг 4: Сохраните и расширьте деловые контакты

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

Также будет полезно запросить рекомендательные письма от руководства и бывших коллег — как в виде официальных документов с печатью компании, так и в виде рекомендаций в специальных разделах LinkedIn и Хабр Карьеры.

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

И наконец, прямо заявите о своём статусе. Поставьте везде отметку Open to Work. В идеале — публично объявите в личных соцсетях, что вы в поиске новой позиции. Небольшой пост с благодарностью прошлой компании и упоминанием, что открыты для предложений. Информация быстро разлетается по сети, и нередко именно через знакомых приходят интересные предложения.

Шаг 5: Подготовьте шаблон отклика (сопроводительное письмо)

Составьте динамический шаблон отклика, который будете подстраивать под каждую вакансию. На крупных сайтах вроде HH рекрутеры сейчас получают сотни заявок, и сделать выбор становится всё сложнее. Ваша задача — выделиться из массы. Поэтому важно уже в первых строчках сопроводительного письма показать, что вы идеально подходите под требования вакансии. Укажите 2–3 ключевых навыка или достижения, наиболее релевантных описанию позиции.

Чтобы повысить шанс на отклик, под каждую вакансию пишем индивидуальное письмо. Для экономии времени можно воспользоваться нейросетью, чтобы она помогла быстро проанализировать описание вакансии и выделить основные требования. На основе полученного списка убедитесь, что в отклике и резюме упомянуты все ключевые навыки, которыми вы владеете и которые требуются работодателю, а лишние детали — удалены. Это нужно для того чтобы ваш отклик прошёл авто-скрининг (раз, два, три): если резюме не содержит определённых слов, его может даже не увидеть живой рекрутер. Чтобы не быть отсеянным бездушной машиной, сопроводительное письмо и резюме должны на 100% подходить под вакансию. Если же в вакансии указана технология, с которой вы мало работали, но в целом знакомы — всё равно упомяните её, честно указав уровень владения. Пусть лучше ATS пропустит вашу кандидатуру, а решение уже будет принимать человек.

И будьте готовы к тому, что даже отличные специалисты с идеальным резюме получают отказы на отклики. Не падайте духом и не спешите думать, что с вашим резюме что-то не так. Дело может быть вовсе не в вас. Вполне вероятно, что когда вы отправите отклик, рекрутер уже получит десятки других и приступит к их рассмотрению. Остальные заявки какое-то время ещё «повисят», а потом получат автоотказ. Ваш отклик могут просто не успеть открыть.

Шаг 6: Грамотно работайте с откликами

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

Получив заветный отклик, вы переходите к уже привычному этапу — подготовке к собеседованиям. Идеально еще на этапе переписки выяснить у HR, какие этапы вас ждут, когда и что будет происходить на каждом из них. Зная примерный план, вы сможете лучше подготовиться.

Вооружившись нейросетью, опишите ей предполагаемую должность и попросите сгенерировать список типовых вопросов для интервью. Можно смоделировать мок-интервью: попросить бота выступить в роли интервьюера и провести сеансы вопросов-ответов (примеры промптов). Такие тренировки реально помогают почувствовать себя увереннее. Вы освежите знания и вспомните всё, что могли забыть.

Но настоящий интервьюер в 2025 не станет задавать «100 вопросов разработчику», а скорее всего предложит решить прикладную задачу или обсудить реальный кейс из практики. Полезно также поискать и посмотреть видео с реальными собеседованиями в похожих компаниях или на аналогичные позиции. Это не даст готовых ответов, но поможет понять общую структуру интервью, зная, чего примерно ждать.

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

Заключение

Рынок труда 2025 года предъявляет к программистам новые требования, и старые подходы уже не работают так эффективно. Теперь, когда кандидатов больше, важно максимально активно и продуманно подходить к поиску работы. Приведите в порядок свой профессиональный профиль: обновите резюме, прокачайте онлайн-активность, наладьте связи и будьте готовы учиться новому. Используйте нейросети на каждом этапе — от составления резюме до тренировки перед собеседованием. Не теряйте уверенности в себе, а если сразу не получаете отклика — тщательно работайте над каждой заявкой и продолжайте совершенствоваться.

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

Полезные ссылки:

• Мой блог, в котором есть и другие статьи по теме
• Мой Telegram-канал
• Шаблон АТС-френдли резюме
• Каналы и группы с вакансиями

Спрос на таких специалистов продолжает расти. Средняя зарплата проджект-менеджера в России в 2025 году составляет около 147 000 руб., при этом сеньоры могут получать до 240 тыс. Для продактов цифры еще выше — опытные специалисты в крупных IT-компаниях зарабатывают от 300 000 руб.

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

1. Академия Softline: «Управление проектами в области ИТ»

Академия Softline предлагает актуальный курс в рамках обширной обучающей программы для повышения квалификации. Программа разработана практиками из крупных IT-компаний и охватывает все аспекты работы с проектом.

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

Каждый участник работает над реальным проектом, применяя инструменты управления на всех этапах — от запуска до завершения. Наставники-практики сопровождают студентов на протяжении всего обучения, помогая разобрать нюансы применения методик в реальных ИТ-проектах.

Уникальность программы

Курс отличается синтезом мировых стандартов: PMBoK и ITIL интегрированы с гибкими методологиями (Agile, Scrum, Kanban). Такой подход учит адаптировать инструменты под специфику конкретных задач, а не просто следовать шаблонам.

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

Преимущества:

• практическая направленность: 70% времени посвящено работе с реальными кейсами;
• гибкие методики для ИТ-среды: от классического Waterfall до гибридных моделей;
• поддержка наставников с опытом в Сбере, Яндексе и других топовых компаниях.

Что получают выпускники

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

Стоимость и условия

Полная цена программы — 80 000 рублей. Доступна рассрочка на 4 месяца (20 000 руб./мес). Для корпоративных клиентов действуют скидки до 15% при обучении групп от 3 человек.

2. Компьютерная Академия ТОП: «Проджект-менеджер в IT»

Компьютерная Академия ТОП уже несколько лет готовит сильных проджектов для IT-индустрии. Курс подходит тем, кто хочет научиться управлять проектами в условиях неопределенности — именно с этим сталкивается большинство новичков.

Курс длится 10 месяцев и доступен в двух форматах: очном (в 200+ филиалах по России) или онлайн с живыми вебинарами. В отличие от многих программ, здесь нет записанных уроков — все занятия проходят в режиме реального времени с преподавателями-практиками. Каждую группу курирует действующий проджект из IT-индустрии, который дает каждому участнику обратную связь и разбирает ошибки на практике.

Уникальность программы

Живое обучение в малых группах (до 15 человек), где студенты отрабатывают навыки на 12 реальных кейсах — от запуска мобильных приложений до управления релизами SaaS. Например, один из проектов имитирует работу с заказчиком из банковского сектора, где нужно согласовать требования и сроки под жесткими ограничениями бюджета.

Программа обновляется каждые 6 месяцев с учетом запросов работодателей. В 2025 году добавлен модуль по гибридным методологиям (Agile-Waterfall) для госпроектов и FinTech.

Помимо Jira и Trello, студенты осваивают специализированные решения для IT-команд — Axure RP для прототипирования и MS Project для сложных диаграмм Ганта.

Преимущества:

• стажировка у партнеров (VK, Сбер, Тинькофф) после успешной защиты дипломного проекта;
• доступ к закрытому чату выпускников с вакансиями от 500+ компаний;
• сертификация PMI CAPM® включена в стоимость.

Что получают выпускники

По данным академии, до 80%студентов трудоустраиваются в течение нескольких месяцев после выпуска.

В портфолио входят:

• 4 завершенных учебных проекта с метриками эффективности (например, сокращение сроков на 15-20% в симуляциях);
• готовые артефакты: устав проекта, реестр рисков, отчеты по Scrum-спринтам;
• государственный диплом о профессиональной переподготовке и международный сертификат.

Стоимость и условия

• онлайн: 4 590 руб./мес (рассрочка на 10 месяцев);
• очно: 17 910 руб./мес (скидка 15% при оплате за год);
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

3. ProductStar: «Профессия Продакт-менеджер»

Курс от ProductStar подойдет как новичкам, так и тем, кто уже работает в IT, но хочет перейти в продукт.

Особенности программы:

• 8 месяцев обучения с упором на практику;
• 3 специализации на выбор: B2C, B2B или стартапы;
• работа с Figma, Miro, Amplitude, SQL;
• кейсы от партнеров: Яндекс, МТС;
• подготовка к реальным собеседованиям.

Один из плюсов ProductStar — сообщество. Студенты получают доступ к закрытому чату, где общаются выпускники и преподаватели. Там можно получить совет, найти напарника для проекта или даже предложение о работе.

Каждый модуль курса завершается защитой проекта перед экспертами из индустрии. Это не только возможность получить обратную связь, но и шанс заявить о себе потенциальным работодателям.

4. Академия Softline: «Управление проектами по разработке программных продуктов»

Курс от Академии Softline создан для тех, кто хочет научиться выводить проекты на финишную прямую без переработок и конфликтов.

Формат обучения и особенности курса

Курс длится 252 академических часа и реализуется в мультиформатном режиме:

• Живые вебинары с разбором кейсов и домашних заданий от экспертов-практиков.
• Самостоятельная работа на обучающей платформе с доступом к записям и шаблонам документов.
• 80% практики. Симуляции переговоров с заказчиками, разработка проектной документации (устав проекта, реестр рисков, отчеты), защита итогового проекта перед комиссией с обратной связью.

У курса Академии Softline гибкий подход к методологиям управления проектами. В отличие от стандартных программ, здесь учат не просто следовать шаблонам Waterfall или Agile, а адаптировать их под специфику российского IT-рынка.

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

Практическая направленность — еще одна особенность программы. Все теоретические знания сразу применяются в реальных кейсах от партнеров (Сбер, VK, МТС), включая разработку мобильных приложений и SaaS-платформ. Участники осваивают профессиональные инструменты: Jira для трекинга задач, MS Project для построения сложных диаграмм Ганта и Confluence для ведения проектной документации.

Преподаватели курса — действующие проджект-менеджеры с опытом в международных компаниях. Они делают акцент на технических аспектах управления: понимании жизненного цикла разработки ПО (SDLC), базовых принципах DevOps и особенностях работы с API. Это позволяет выпускникам говорить на одном языке с разработчиками и грамотно ставить технические задачи.

Результаты выпускников

По окончании обучения студенты получают диплом о профессиональной переподготовке государственного образца и готовое портфолио. В него входят: устав проекта для финтех-стартапа, реестр рисков с mitigation-стратегиями и отчеты по Scrum-спринтам с метриками эффективности.

Выпускники также получают доступ к вакансиям партнеров через карьерный центр Softline, что существенно повышает шансы на трудоустройство.

Стоимость и условия

• полная цена: 156 000 руб.;
• рассрочка: 13 000 руб./мес × 12 месяцев;
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

5. Нетология: «Продуктовый менеджер»

Курс «Продуктовый менеджер» от Нетологии предназначен для тех, кто хочет освоить управление продуктом на всех этапах его жизненного цикла — от исследования рынка до масштабирования. Программа подходит как новичкам, так и специалистам, которые хотят углубить свои знания в продуктовой аналитике и стратегическом планировании.

Формат обучения и особенности

Обучение длится 8 месяцев и включает 104 урока в формате видеолекций, практических заданий и живых вебинаров. Студенты работают над собственным продуктом, проходя все стадии разработки: от формирования гипотез до запуска MVP и анализа первых метрик. Каждый модуль завершается практическим заданием, которое проверяют кураторы — действующие продакт-менеджеры из Mail.ru Group, Avito и других компаний.

Основные темы:

• Анализ рынка и целевой аудитории — методы CustDev, построение CJM (Customer Journey Map), выявление Jobs To Be Done (JTBD).
• Продуктовая аналитика — работа с метриками AARRR и HEART, настройка дашбордов, проведение A/B-тестов.
• Финансовое моделирование — расчет юнит-экономики, стратегии монетизации, оценка рентабельности продукта.
• Управление продуктом — создание роадмапа, приоритизация фич, работа с бэклогом и командой разработки.

Что отличает курс:

• Практическая направленность. 70% времени посвящено работе с реальными кейсами, включая задачи от партнеров Нетологии.
• Карьерный модуль. Помощь в составлении резюме, подготовка к собеседованиям, разбор переговоров о зарплате.
• Гибкий график. Возможность изучать материалы в удобное время, совмещая обучение с работой.

Что получают выпускники

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

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

Карьерная поддержка включает доступ к вакансиям компаний-партнеров (VK, Тинькофф), персональные консультации по составлению резюме и подготовку к собеседованиям с HR-специалистами. Для лучших студентов предусмотрены стажировки с возможностью дальнейшего трудоустройства.

Стоимость

Полная цена: 158 160 руб. (доступна рассрочка — 4 393 руб./мес). В рамках корпоративного обучения площадка предлагает индивидуальный расчет для групп.

6. SkillFactory: «Проджект-менеджер в IT»

SkillFactory предлагает подробный курс по управлению проектами. За 9 месяцев студенты полностью погружаются в профессию и выходят готовыми к реальным задачам.

Курс SkillFactory предназначен для тех, кто хочет освоить управление IT-проектами с нуля или систематизировать имеющийся опыт. Программа сочетает теорию с практикой: студенты изучают методологии (Agile, Scrum, Waterfall) и сразу применяют их в реальных кейсах, таких как разработка мобильного приложения или внедрение CRM-системы.

Формат обучения

• Онлайн-вебинары с разбором кейсов от преподавателей-практиков (например, Павла Максимова, который руководил запуском eSIM в России).
• 3 проекта в портфолио: планирование приложения по Agile, внедрение софта для call-центра по Waterfall, дипломная работа — сервис для видео-найма персонала.
• Поддержка наставников, включая персональные консультации и проверку заданий.

Ключевые навыки

Курс фокусируется на практических инструментах:

• работа с Jira, Trello, MS Project для планирования;
• управление бюджетом и рисками;
• проведение ретроспектив и дэйли-митингов (коротких ежедневных собраний команды);
• подготовка документации (уставы проектов, реестры рисков).

Трудоустройство

Выпускники получают доступ к вакансиям партнеров SkillFactory и помощь в составлении резюме. По данным портала hh.ru, средняя зарплата junior-проджекта после курса составляет 95 000–120 000 руб.

Стоимость

Полная цена: 87 000 руб. (доступна рассрочка — 7 250 руб./мес). Включен бонусный курс по нейросетям.

7. GoPractice: «Профессия: Продакт-менеджер»

Программа длится 11 месяцев и предназначена для специалистов, планирующих переход в продакт-менеджмент из смежных ролей (аналитики, маркетологи, проджекты).

Обучение включает пять ступеней:

1. Анализ траекторий перехода в профессию.
2. Освоение основ продакт-менеджмента через кейсы.
3. Работа с симулятором управления продуктом.
4. Дипломный проект.
5. Подготовка к трудоустройству.

Занятия проходят онлайн с гибким графиком. Каждую группу курируют менторы из компаний (Яндекс, Avito, Ozon), которые проводят приветственные звонки и консультируют по заданиям.

Программа

Курс охватывает:

• построение продуктовой стратегии;
• проведение качественных и количественных исследований;
• управление бэклогом и приоритизация фич;
• расчет юнит-экономики;
• взаимодействие со стейкхолдерами.

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

Результаты

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

Стоимость

Полная цена: 219 900 руб., рассрочка: 18 325 руб./мес × 12 мес.

Как выбрать курс и начать карьеру

Выбор программы зависит от ваших целей и стартовых условий. Тем, кто только начинает, лучше выбрать курсы с упором на практику и помощью в трудоустройстве. Опытным специалистам подойдут программы с углублением в конкретные области — аналитику, управление командами или работу с данными.

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

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса.

Недавно сходил с Витей на запись подкаста на эту тему и настолько преисполнился, что решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

• множество библиотек и зависимостей;
• единый store, в котором живут состояние и данные;
• компоненты, которые нужно собрать, чтобы сделать из них приложение.

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

Монолитное приложение — старое доброе приложение, которое, как правило, создают один или несколько разработчиков, потом его дорабатывает армия джунов, синьоров и всех, кто оказался рядом. Каждый «чуть-чуть поправил», и вот уже никто не понимает, почему оно работает, — но трогать страшно. Монолиты пишут и сейчас — все зависит от бизнеса. Если нужно приложение для небольшого проекта, микросервисы могут и не понадобиться.

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

Масштабировать можно и монолиты, но у них всегда остается какая-то единая точка отказа — например, база данных. Особенно если это реляционная СУБД, завязанная на Oracle или PostgreSQL. Когда база достигает сотен гигабайт или даже терабайт, масштабировать такую штуку становится дорого, больно и ненадежно.

Микросервисы — панацея? Не совсем

Тренд на микросервисный подход появился в начале 2010-х годов, вместе с проникновением интернета в широкие слои населения. Первый iPhone вышел в 2007 году, люди стали гораздо ближе к интернету, к данным, к информации. Бизнес захотел дотянуться до этой аудитории, и тогда началась диджитализация, сложность систем стала повышаться. Особенно остро это почувствовали крупные организации вроде банков: функциональность увеличивалась, и монолит начал «трещать» не только технически по инфраструктуре, но и по возможностям команд разработки, которые с ним работали.

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

Распространение DevOps-культуры и инструменты оркестрации

Раньше разработчик писал код, собирал артефакт и перекидывал его через забор в поддержку. Коллеги за забором его деплоили, запускали — и разработчику можно было больше не думать про плоды своей работы.

В новой реальности количество артефактов, которые нужно перекидывать через забор, кратно выросло. Вместе с этим появилась и стала распространяться DevOps-культура: понимание, что за качественную раскатку в проде отвечает не только команда поддержки, но и разработчики.

Важно учитывать еще и то, что сложность поддержки кратно увеличилась. Если монолит можно было отдебажить, просто заглянув в логи, то с сотней микросервисов так не получится. Поэтому появились такие инструменты, как централизованное логирование, распределенный трейсинг — и сотни, если не тысячи других, связанных в первую очередь с observability. В таких обстоятельствах DevOps-культура стала особенно важна.

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

DDD: как правильно нарезать сервисы

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

Вместо того чтобы пилить отдельные сервисы для авторизации, логирования и уведомлений, команда может подумать вот над чем: все это части одного бизнес-контекста — пользовательского доступа. И целесообразно оставить их в одном сервисе. Это и есть DDD в действии.

Существует и еще одна проблема, с которой DDD помогает справиться, — неправильная нарезка сервисов с точки зрения бизнесовой функциональности. Если не понимать бизнес-контекста, можно получить «распределенный монолит»: будет много отдельно стоящих сервисов, но профита никакого, только все сложности микросервисов плюс проблемы монолита с масштабируемой базой данных. Особенно остро это проявляется, когда изменения в одной части бизнес-процесса (в одном сервисе) влекут за собой изменения еще в трех-четырех-пяти других сервисах.

DDD помогает выделить bounded context — согласованные по бизнесу участки. Они позволяют более или менее правильно нарезать большой бизнес-функционал на отдельные части.

Еще один важный принцип правильной архитектуры микросервисов — у каждого микросервиса должна быть своя независимая маленькая база данных (если она вообще нужна).

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

И вот что важно: при проектировании и внедрении микросервисов лучше избегать «велосипедостроения». Если индустрия уже решила проблему, нет смысла изобретать новое логирование или оркестрацию. Собственное решение вряд ли будет работать лучше, а сил, времени ресурсов на него можно потратить очень много.

Поддержка микросервисной архитектуры

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

В крупных организациях микросервисов могут быть сотни: например, в некоторых системах насчитывается почти 700 микросервисов на продакшене. Каждый инстанс еще масштабирован — это тысячи подов, которые постоянно обрабатывают клиентский трафик. И при этом в современных условиях нужно стремиться к доступности системы на уровне четырех девяток (99,99%), то есть к простою всего в несколько минут в год.

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

Паттерны отказоустойчивости

Микросервисы — это не про «разбили монолит», это про то, что сбой одного сервиса не должен валить весь продукт. Поэтому если какой-то важный сервис упал, то максимум, который нужно сделать, — чтобы клиент не увидел упавший кусочек функционала приложения.

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

Все это must have для абсолютно любой системы. Даже если у вас низкая нагрузка, она когда-нибудь увеличится. Лучше вовремя предусмотреть это, заранее потратив чуть больше времени и реализовав эти паттерны.

Как эффективно работать с инцидентами

Начало всех начал в траблшутинге — мониторинг. Здорово, когда разработчики понимают, как устроена их система, и уже вложились в мониторинг: есть дашборд, где можно посмотреть по уровням абстракций основные точки отказа.

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

Совет: если вы вдруг нашли что-то, что еще не мониторится, — это повод поскорее добавить эту метрику, начать ее мониторить и ретроспективно отслеживать.

Еще одна важная вещь в работе с инцидентами — культура постмортемов. Ретроспективы по каждой аварии пишутся не просто так — их можно свести по категориям и понять, из-за чего чаще всего происходят аварии: например, из-за протухших сертификатов либо человеческого фактора в конфигурации. Категорий причин отказа обычно не так много. С постмортемами проще выработать стратегию технического инженерного развития.

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

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

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

Однако эти организационные моменты еще не гарантируют быстрого решения проблемы. Ключевой фактор — культура компании. На людей часто нападает отстраненность — авария случилась, и все думают: «Кто-нибудь другой разрулит. Я разработчик, ну, что я там сделаю?»

Многие привыкли жить по старой парадигме: написали код, потестировали, отдали поддержке и забыли. Но культура в команде должна дорасти до такого уровня, когда каждый понимает: я не только разрабатываю или тестирую код, но еще и отвечаю за него на продакшене.

Из-за этого разрыва в осознании между командами поддержки и разработки возникают конфликты. У каждой разные цели, и зачастую одна команда не понимает, чего хочет другая. Чтобы лучше понять природу этих конфликтов, важно вспомнить про DevOps-культуру и SRE. В их парадигме разработчики не только пишут код, но и деплоят в продакшен.

Проще говоря, есть два варианта взаимодействия с поддержкой: классический, когда она административно отделена, и SRE-подобный, когда сотрудники «второй линии» прямо интегрированы в команду разработки. Могу сказать, что второй эффективнее.

При этом не обязательно сливать всех в одну плоскую структуру на уровне административного деления. Достаточно, чтобы люди, даже находясь в разных административных юнитах, работали как команда и коммуницировали постоянно, а не от случая к случаю. Важно, чтобы все были проактивными — если что-то случилось, сразу подрывались и по инструкции пытались устранить проблему.

Это то самое SRE, о котором пишет Google. Но людей нужно долго обучать такой культуре — это не дело одного месяца. Благодаря такому подходу инженеры, которые раньше были просто разработчиками или аналитиками, глубже осознают свою ответственность за стабильность продакшена. И это действительно правильное направление развития. Потому что и DevOps, и SRE — это в первую очередь культура, а уже во вторую — набор инструментов.

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

Нейросеть будет находить протухшие сертификаты внутри инфраструктуры, работать инструментом для early warning, подсвечивать риски.Кажется, что все инструменты для этого есть уже сейчас. Надо только, чтобы кто-то сложил этот пазл в рабочее решение.

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

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

Что злит инженеров

1. Постоянные «синки», которые мешают работе

Инженер наконец вошёл в поток, начал разбираться с запутанным багом — и тут появляется менеджер с «пятиминутным» разговором. Фокус сбит, восстановить его может быть непросто.

Проблема в том, что некоторые руководители не понимают, как устроена работа программиста: они считают, что задачу можно приостановить и быстро вернуться к ней позже. На деле это ведёт к потере продуктивности.

2. Пренебрежение реальностью

Руководители, далёкие от кода, часто принимают неверные технические решения: обещают невозможные фичи, назначают сроки без обсуждения с командой и недооценивают сложность задач.

Даже бывшие разработчики, удалившись от ежедневной практики, порой начинают мыслить чересчур упрощённо: «ну это же просто кнопка».

3. Присвоение заслуг

Инженер вкладывается в проект, ночует на работе, решает сложные задачи — а в итоговом отчёте звучит: «мы это сделали», «я это обеспечил». При этом имя разработчика даже не упоминается.

Нередко менеджеры не осознают, что подобная «командная риторика» выглядит как попытка присвоить чужие успехи.

4. Бессмысленные митинги

Многие менеджеры заменяют простое сообщение в мессенджере регулярными встречами. Расписание команды заполняется планированиями, синками, ретроспективами и демо. На саму работу времени почти не остаётся.

5. Поверхностный фидбек

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

Что чувствуют сами менеджеры

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

Руководители тоже испытывают давление — со стороны бизнеса, клиентов и команды. Многие из них не «плохие по натуре» — просто не справляются с системой, в которой находятся. Они вынуждены действовать в условиях нехватки информации, ресурсов и времени.

В целом, это скорее не оправдание, а объяснение позиции человека «с той стороны».

Как выглядит хороший менеджмент

Лучшие руководители, с которыми автор работал, выделяются несколькими подходами:

• Уважают «фокусное время» инженеров и не мешают по мелочам.
• Поддерживают техническую насмотренность и слушают команду.
• Делятся заслугами команды и берут ответственность на себя.
• Дают своевременную и конкретную обратную связь.
• Активно продвигают своих сотрудников внутри компании.

Зачем тимлиду вообще оценивать себя и команду

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

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

Регулярная оценка процессов помогает избежать накопления технического и эмоционального долга.

В чём разница между рефлексией тимлида и ретроспективой команды?

Важно разделять две зоны ответственности:

• Саморефлексия — это про вас как руководителя. Что сработало в управлении? Где вы промолчали, когда стоило вмешаться? Что стоило делегировать, а что — взять на себя?
• Ретроспектива — это формат командной обратной связи. Обсуждаются процессы, договорённости, коммуникация.

Если вообще не оценивать команду, ошибки повторяются. В команде накапливается усталость и раздражение. Скорость разработки падает, появляются конфликты, растёт текучка. Команда теряет гибкость и способность адаптироваться. Поэтому регулярный «внутренний аудит» — это не формальность, а необходимость.

Самооценка тимлида: навыки, зоны роста, влияние

Регулярная самодиагностика — важный навык для тимлида. Она помогает не только корректировать собственные действия, но и видеть, как твоя работа влияет на команду. Без этого легко застрять в ощущении, что «вроде всё нормально» — хотя на самом деле давно пора пересмотреть подход.

Какие навыки важны тимлиду в 2025 году?

В центре — работа с людьми. Не просто организовать процессы, а выстраивать доверие, развивать каждого участника команды, создавать среду, в которой люди хотят работать. Управленческие навыки, планирование, приоритизация — важны, но без человеческого фундамента всё это не работает в долгую.

Чтобы оценить свою эффективность, нужно опираться не только на ощущения. Помогают конкретные маркеры:

• достигнутые цели;
• стабильность и прозрачность процессов;
• обратная связь от команды и руководства;
• собственный анализ ошибок и сильных сторон.

Важно задавать себе прямые вопросы: где я сработал хорошо? Что пошло не так? Что можно сделать по-другому в следующий раз?

Но что делать, если даже при хороших результатах чувствуешь синдром самозванца? В такой ситуации стоит сравнивать себя не с «идеальным» тимлидом или чужими успехами, а с собой в прошлом. Если за последние месяцы есть прогресс — ты движешься в правильном направлении. Это помогает вернуть фокус на реальное развитие, а не на внутреннюю тревожность.

Оценка команды: не про «кто слабый», а про развитие

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

Какие метрики командной эффективности реально работают?

Есть простые, но показательные ориентиры:

• Удовлетворённость. Проверяется через анонимные опросы. Если люди довольны процессами, они не просто работают, а вовлечены.
• Инициативность. Если команда предлагает улучшения, сама находит точки роста — это сильный сигнал, что внутри всё в порядке.

Как распознать рост или стагнацию участника команды

Рост видно по тому, что человек начинает справляться с более сложными задачами, предлагает решения, берёт на себя больше ответственности.

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

Как отличить выгорание от потери интереса

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

Если же разработчик давно «отключился», не хочет брать новые задачи и не проявляет интереса даже после отдыха — это уже не про усталость, а про стагнацию. Тут нужна отдельная работа: понять, в чём затык, и готов ли человек двигаться дальше.

Подходы и инструменты для оценки команды

Необязательно устраивать месячник самопознания с табличками и ритуалами. Но если нужно видеть, как развивается команда (и самому при этом не буксовать), придётся систематизировать подход. Без данных всё будет держаться на ощущениях — и чаще всего, ложных.

Что использовать для оценки команды

Универсального рецепта нет, но рабочая комбинация выглядит так:

• 1:1 — регулярные личные встречи раз в две недели или раз в месяц. Здесь можно выстроить доверие и быстро решать проблемы до того, как они всплывут на митапах.
• Опросы — раз в квартал, чтобы понять общее настроение, уровень удовлетворённости, зоны риска.
• 360-фидбек — раз в полгода или год, если хочется посмотреть на человека глазами коллег, а не только руководителя.

Можно начать с чего-то одного, но лучше — использовать инструменты в комплексе. Они дополняют друг друга: фидбек даёт нюансы, опрос — картину в целом, 1:1 — конкретику.

Типичные ошибки в оценке команды — и как их избежать

Оценка — не просто «подведение итогов». Это инструмент развития. Но в неумелых руках она легко превращается в источник выгорания и конфликтов. Разбираемся, где чаще всего ошибаются тимлиды и как этого избежать.

Фокус на «проблемных людях»

Распространённая ошибка — искать крайнего. Если что-то не работает, проще всего обвинить одного человека и навесить на него ярлык. Но команда — это не набор изолированных людей, а система. И системные сбои почти всегда связаны с процессами: неясными ролями, плохой коммуникацией, отсутствием поддержки или перегрузкой.

Фиксация на «слабом звене» только усугубляет ситуацию: остальные теряют мотивацию, настоящие проблемы не решаются, атмосфера становится токсичной.

Псевдо-ретро

Ретроспектива должна вести к изменениям. Если после ретро нет реальных действий или если обсуждают только безопасные темы для галочки, команды перестают воспринимать ретроспективу всерьёз, и это становится пустой процедурой.

Путаница между личным и рабочим

Личное отношение легко затуманивает взгляд. Особенно если кто-то «приятный в общении», но стабильно опаздывает с задачами — и наоборот. Чтобы оценка оставалась честной, нужны факты: как человек справляется с задачами, как влияет на процессы, насколько вносит вклад в общее дело.

Хорошая привычка — фиксировать наблюдения и результаты заранее, чтобы не принимать решения на эмоциях.

Что делать с результатами оценки команды

Провести самооценку и опросы — полдела. Главное — что происходит дальше. Если оценки остаются на бумаге, а разговоры — в воздухе, смысл теряется. Но как этого избежать?

Корректно даем фидбек по итогам само- и командной оценки

Фокус должен быть не на ошибках, а на росте. Начинать лучше с того, что получилось хорошо, а потом мягко обсуждать, что можно улучшить. Стоит использовать конкретные примеры и предлагать поддержку, а не просто указывать на проблему. Главное — говорить уважительно и показать, что фидбек нужен для развития, а не для наказания.

Строим индивидуальные планы развития по результатам

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

Вовлекаем команду в изменения, не вызывая сопротивления

Не навязывайте изменения сверху. Лучше вместе обсудить проблемы и идеи на ретроспективе или встрече. Объясните, зачем нужны изменения, и покажите, какую пользу они принесут каждому. Дайте людям возможность влиять на процесс — тогда изменения будут восприниматься как общее дело, а не как чья-то чужая инициатива.

Итоги: чек-лист для оценки себя и команды

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

На что обратить внимание при самооценке?

• Достигаю ли я цели, которые ставлю перед собой и командой?
• Поддерживаю ли рост и развитие каждого члена команды?
• Регулярно ли даю понятную и полезную обратную связь?
• Умею ли я решать конфликты спокойно и конструктивно?
• Развиваю ли процессы, а не просто работаю в режиме пожаров?

Какие сигналы говорят, что в команде что-то не так?

• Появляются частые недопонимания и скрытые конфликты.
• Сильно падает мотивация и вовлечённость в задачи.
• Заметны регулярные срывы сроков без очевидных причин.
• Люди сопротивляются изменениям или делают их для вида.
• Пропадает инициатива и стремление предлагать улучшения.

Что проверить, прежде чем делать оргвыводы?

• Не перегружена ли команда задачами и ожиданиями?
• Чётко ли распределены роли и зоны ответственности?
• Достаточно ли у команды ресурсов и поддержки для выполнения работы?

• Нет ли системных проблем в процессах, которые мешают работе и развитию?

Единый чек-лист для тим-лида:

1. Цели команды понятны, достижимы и разделяются всеми участниками.

2. Каждый знает свои роли и зоны ответственности.

3. Есть регулярные 1:1 встречи для обратной связи и поддержки.

4. Команда понимает, как её успех оценивается (метрики, критерии качества).

5. Процессы не мешают работе, а помогают — есть баланс структуры и гибкости.

6. Конфликты обсуждаются открыто и решаются конструктивно.

7. У команды есть возможности для профессионального роста.

8. Тимлид следит за собственным развитием и рефлексирует над своими действиями.

9. Проблемы не замалчиваются, а выявляются и устраняются без страха наказания.

10. Изменения в процессах объясняются заранее и обсуждаются с командой.

11. Успехи команды замечаются и признаются.

12. Фокус — не только на результатах, но и на атмосфере и здоровье команды.

Для поколения Z и альфа дискеты, кассеты и CD — такая же архаика, как патефон для миллениалов. Но именно эти носители стали мостом между эпохой аналоговых технологий и цифровой революцией. Некоторые до сих пор помнят скрежет модема, загружающего игру с аудиокассеты, или волнение при записи первого CD — этот ритуал требовал идеального буфера в Nero и молитв, чтобы электричество не отключили в процессе.

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

Носители информации: эволюция

Сегодня данные окружают нас, как воздух — невидимые, но жизненно важные. В наших смартфонах — навигаторы, приложения для заказа еды, интернет-банкинг, весь Лев Толстой в текстовом или аудиоформате. Фотографии автоматически загружаются в облако, рабочие документы синхронизируются между устройствами, а музыка и фильмы доступны по первому требованию без необходимости записывать что-либо на пленку или вставлять диск в дисковод.

Мы живем в эпоху, когда информация стала нематериальной, а ее хранение — виртуальной услугой, за которую ежемесячно платят подпиской. При этом цена за удовольствия, информацию и духовную пищу (музыка, кино, книги и т.д.) несоизмеримо ниже, чем несколько десятилетий назад.

Но так было не всегда. Было время, когда никто не доверял интернет-хранилищам — да их и не было в том виде, к которому мы сегодня привыкли. Важные файлы хранили на чем-то осязаемом — дискетах, дисках, пленках. Данные были привязаны к физическим объектам, которые можно было потерять, сломать или случайно очистить.

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

Первые носители информации были аналоговыми и требовали физического контакта. Бумага, перфокарты, магнитная лента — все это работало по принципу «записал один раз и следи, чтобы не испортилось». Но с появлением продвинутой техники понадобилось что-то более гибкое, что позволило бы не только хранить, но и быстро перезаписывать данные. Так началась эра магнитных носителей.

Магнитные кассеты использовались не только для записи и воспроизведения музыки, но и стали первым массовым способом хранения цифровой информации для домашних компьютеров. Пользователи писали на пленку игры типа Pacman или Dizzy, а также прикладные программы для компьютеров АТМ Турбо и Spectrum.

Кассеты были дешевы, доступны, но обладали низкой скоростью доступа. Загрузка программы с кассеты занимала несколько минут: один сбой — и данные отправлялись в небытие. Тем не менее для своего времени это был прорыв: в отличие от перфокарт, кассеты позволяли перезаписывать информацию, а их компактность делала этот способ удобным для домашнего использования.

Затем пришли дискеты, и мир узнал, что такое «портативность» в цифровом смысле. Если кассеты были еще слегка похожи на предыдущее поколение (массивные бобины), то флоппи-диски уже вполне выглядели как технология из будущего. Первые модели хранили жалкие 80 КБ, но к 1980-м емкость выросла до 1.44 МБ — достаточно для текстовых документов и простейших программ. Правда, надежность оставляла желать лучшего: магнитные диски боялись пыли, влаги и просто времени.

Оптические носители, такие как CD и DVD, стали следующим шагом. Они предлагали куда больший объем (от 700 МБ до 4.7 ГБ) и теоретически — вечное хранение данных. Правда, на практике царапины, солнечный свет и некачественные болванки приводили к быстрому обнулению файлов. Но главный минус — эти диски нельзя было просто так перезаписать. CD-RW и DVD-RW решили проблему, но их распространение было медленным: люди уже начали привыкать к тому, что данные можно копировать бесконечно.

Конец XX века принес еще несколько любопытных форматов вроде ZIP-дисков, которые пытались заменить флоппи, но проиграли войну, поскольку оказались слишком дорогими и неудобными.

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

Как хранили и передавали информацию до флешек и облаков

Ненадежные, но безальтернативные дискеты, вмещавшие меньше, чем сегодняшний снимок экрана; кассеты с уязвимой магнитной пленкой; CD с их обманчивым обещанием «вечного хранения». Все эти носители в свое время считались если не революционными, то прогрессивными и передовыми. Нынешнему поколению будет полезно узнать, где хранили музыку, видео, софт и другие данные их родители и почему эти волшебные изобретения больше не используются массово.

Аудио и видеокассеты: не забудьте перемотать на начало

До того как видеохостинги и стриминговые сервисы стали нормой, люди обменивались музыкой и фильмами при помощи хрупких пластиковых коробочек с магнитной лентой внутри. Аудио- и видеокассеты были не просто носителями — они стали культурным феноменом, символом эпохи, когда контент нельзя было получить мгновенно, зато можно было легко испортить — поместить рядом с магнитом или «зажевать» в некачественном проигрывателе.

Магнитная лента появилась задолго до кассет — первые бобинные магнитофоны использовались еще в 1940-х, но они были громоздкими и дорогими. Все изменилось в 1963 году, когда компания Philips представила компакт-кассету — небольшой, удобный и, что важно, дешевый формат. В отличие от винила, кассеты можно было записывать повторно, носить с собой и даже ронять без катастрофических последствий.

К 80-м годам кассеты стали основным способом слушать музыку. Их продажи в США достигли пика в 442 миллиона штук в 1990 году, но затем началось стремительное падение — CD-диски предлагали лучшее качество звука и отсутствие изматывающей перемотки. Однако кассеты не исчезли полностью: даже в 2012 году в Штатах продали 13 миллионов штук, в основном благодаря автолюбителям, чьи старые машины были оборудованы кассетными магнитолами. В России формат держался примерно до середины 2000-х, после чего кассеты почти исчезли из обихода.

Пока аудиокассеты правили балом в музыке, VHS делал то же самое с видео. Этот формат, появившийся в 1970-х, быстро вытеснил конкурентов (например, Betamax от Sony) благодаря простоте и доступности. Видеомагнитофон стал почти обязательным устройством в каждом доме, а прокат кассет — целой индустрией.

Но у VHS были свои причуды:

• Длинный фильм на двухчасовой кассете мог закончиться в самый напряженный момент, заставляя зрителя в недоумении хлопать глазами.
• Качество изображения ухудшалось с каждой перезаписью, превращая картинку, над которой так трудилась съемочная группа, в движения размытых или крупнозернистых силуэтов.
• Размагничивание, скручивание ленты и вечная борьба со «снегом» и полосами на экране — все было неотъемлемой частью пользовательского опыта.

Несмотря на это, VHS формат продержался до начала 2000-х, пока его не вытеснили DVD, а затем и стриминговые сервисы.

Магнитная лента использовалась не только для музыки и фильмов — в 1980-х она стала первым массовым носителем данных для домашних компьютеров. Владельцы ZX Spectrum и Commodore 64 загружали программы с аудиокассет, подключив магнитофон к компьютеру. Процесс напоминал шаманский ритуал: нужно было выставить правильный уровень громкости, надеяться, что маг не зажует ленту, и ждать несколько минут, пока игра загрузится (если, конечно, в середине не возникала ошибка, заставляющая начинать все сначала).

Перезапись данных на кассетах была рискованным делом — старую информацию можно было случайно стереть, а новая не всегда записывалась корректно. Тем не менее, это был прорыв: в отличие от дискет, кассеты были дешевы и доступны, что делало их идеальным вариантом для домашнего использования.

Казалось бы, эпоха магнитной ленты бесповоротно миновала, но это не совсем так. В дата-центрах до сих пор используют ленточные библиотеки (например, LTO), потому что они дешевы, энергоэффективны и отлично подходят для долгосрочного хранения больших объемов данных. Современные картриджи LTO-9 вмещают до 45 ТБ информации — это в тысячи раз больше, чем могла предложить кассета 1980-х.

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

Флоппи-диски (дискеты): 1,4 Мб славы

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

Флоппи-диски, или просто дискеты, стали символом компьютерной революции 1980-1990-х: они были везде, их боялись потерять, ими обменивались, как сейчас ссылками, и их регулярно проклинали, когда на экране возникало сообщение «Диск не отформатирован».

Первая дискета, представленная IBM в 1971 году, была 8-дюймовой и вмещала смехотворные по современным меркам 80 КБ данных. Она создавалась как альтернатива перфокартам — более надежная и удобная, но по-прежнему громоздкая. К середине 1980-х индустрия перешла на 5,25-дюймовые гибкие диски, а затем и на 3,5-дюймовые, которые стали стандартом. Последние, кстати, были не такими уж «гибкими» — прочный пластиковый корпус защищал магнитный диск внутри, хотя слово «флоппи» (от английского floppy — «гибкий») так и осталось в названии.

Объем памяти рос медленно: если в 1984 году дискета на 3,5 дюйма хранила 720 КБ, то к 1987-му — уже 1,44 МБ. Этого хватало для текстовых документов, простых программ и даже некоторых игр. Microsoft Word 2.0, выпущенный в 1991 году, умещался на одной дискете, а его современный аналог требует около 4 ГБ — в 3000 раз больше.

Дискеты были удобны и одновременно ужасно ненадежны. Они боялись магнитов, пыли, влаги, перепадов температуры и даже слишком резкого извлечения из дисковода. Классическая ситуация: вы вставляете дискету в компьютер, слышите характерный скрежет, а через пару секунд получаете роковое сообщение о том, что носитель не читается. Иногда помогало «продувание» — буквально дыхание на магнитную поверхность в надежде, что влага временно восстановит контакт.

Еще одна проблема — ограниченный срок жизни. Даже идеально хранимая дискета могла потерять данные через 5-10 лет из-за размагничивания. Архивы на флоппи требовали регулярного перезаписывания, что превращало хранение информации в постоянную головную боль.

В 1980-х развернулась настоящая битва форматов. Компания Apple сделала ставку на 3,5-дюймовые дискеты, в то время как IBM и другие производители первое время держались за 5,25 дюймов. Победил, как известно, меньший размер — отчасти благодаря тому, что новые носители были прочнее и компактнее.

Любопытно, что следы дискетной эпохи до сих пор встречаются в цифровом мире. Буква «A:\» в Windows, которая изначально обозначала дисковод, осталась в системе как дань традиции. Иконка «Сохранить» во многих программах до сих пор изображает флоппи-диск, хотя большинство современных пользователей и в руках-то его никогда не держали.

К началу 2000-х дискеты начали стремительно исчезать. В 2011 году компания Sony, последний крупный производитель, прекратила их выпуск. Но, как это часто бывает, технология не умерла полностью.

Оказалось, что множество промышленных станков, медицинского оборудования и даже некоторых банковских систем до сих пор используют флоппи-диски. В 2018 году выяснилось, что американские ядерные силы все еще управляются с помощью 8-дюймовых дискет (хотя позже систему все же модернизировали).

На вторичном рынке дискеты до сих пор в ходу. Предприниматель Том Перски в 2010 году скупил около миллиона 3,5-дюймовых флоппи и создал целый бизнес по их продаже. Основные клиенты — владельцы старого промышленного оборудования, для которого переход на современные носители оказался слишком дорогим.

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

Сиди и Дивиди: эпоха лазерного ренессанса

В конце 1990-х дискеты уже выглядели архаично, а облачных хранилищ еще не существовало. На сцену вышли оптические диски — сначала скромные CD на 700 МБ, после — DVD на 4,7 ГБ, а затем и Blu-ray с их 50 ГБ. В определенный период записать фильм на болванку считалось технологическим подвигом. Нужно было также красиво написать название на внешней стороне специальным маркером.

Изначально компакт-диски создавались для музыки — первый коммерческий CD выпустили в 1982 году с записью альбома ABBA «The Visitors». Объем в 650 МБ (74 минуты аудио) выбрали не случайно: разработчики из Sony и Philips хотели, чтобы на один диск целиком поместилась Девятая симфония Бетховена. К концу восьмидесятых большинство звукозаписывающих компаний перешли на CD-формат.

Когда технологию адаптировали для компьютеров (CD-ROM), эти же 700 МБ стали стандартом для софта, игр и даже операционных систем, например, Windows 95.

Запись CD представляла собой сложную процедуру . Программа Nero Burning ROM с ее интерфейсом, напоминающим кабину пилота, требовала идеально настроенного буфера записи. Ошибка «Buffer underrun» означала, что диск испорчен, а 30-50 рублей за болванку (по меркам 2000-х — немалая сумма) летели в мусорку.

Когда в 1996 году появились DVD, их емкость в 4,7 ГБ казалась фантастической. Почему не 5? Все просто: инженеры Sony и Philips изначально планировали 5 ГБ, но пришлось пожертвовать частью объема ради совместимости с форматом CD. Впрочем, даже 4,7 ГБ хватало для фильмов в приличном качестве — пиратские копии расходились быстрее, чем студии успевали считать убытки.

Киноиндустрия быстро поняла угрозу и начала войну с пиратством. На диски добавляли защиту вроде SecuROM и StarForce, которая не только мешала копированию, но и могла вывести из строя дисковод. Пользователи в ответ придумывали хитрости: от скотча на краю диска до специальных программ, которые «прожигали» защитные сектора.

В середине 2000-х разгорелась война форматов высокой четкости: Blu-ray от Sony и HD DVD от Toshiba. Технически Blu-ray был лучше — большая емкость (50 ГБ против 30 ГБ у HD DVD), но исход противостояния решил не этот фактор. Sony, которая владела киностудией Columbia Pictures, обеспечила Blu-ray эксклюзивными релизами. А когда за синий формат неожиданно выступила индустрия фильмов для взрослых (на тот момент — один из главных драйверов продаж любых носителей), судьба HD DVD была предрешена.

К 2010-м оптические диски начали сдавать позиции. Скорость интернета росла, стриминговые сервисы набирали популярность, а производители ноутбуков массово отказывались от дисководов. Последний гвоздь в крышку гроба забила Apple, выпустив в 2012 году MacBook Pro без CD-привода — тогда это казалось смелым шагом, а сегодня воспринимается как норма.

Но диски не исчезли полностью. Blu-ray до сих пор используют для фильмов в 4К, а некоторые госструктуры предпочитают архивные DVD — они дешевы и, в отличие от флешек, не подвержены спонтанному размагничиванию. Да и любители ретро-техники продолжают охотиться за редкими релизами игр на CD — например, оригинальная Half-Life на диске сегодня стоит дороже, чем в Steam.

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

Почему все это исчезло

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

Три причины краха:

• Первая и главная — объем. В 1990-х 1,44 МБ дискеты хватало для текстовых документов, но уже к началу 2000-х этого было недостаточно даже для одной MP3-песни. CD на 700 МБ казались спасением, но и они быстро устарели, когда размеры софта перевалили за гигабайты. Современные игры и видеофайлы просто не поместились бы на десятках дисков, которые пришлось бы таскать с собой.
• Вторая причина — скорость. Загрузка программы с кассеты занимала минуты, запись DVD — десятки минут, а копирование файлов с дискеты напоминало медитацию. Когда на смену пришли USB-накопители с их мгновенным доступом к данным, терпеть эти задержки стало невозможно.
• Наконец, надежность. Магнитные ленты размагничивались, дискеты боялись кофе и магнитов, а царапины на CD превращали их в елочные украшения. Потерять данные было проще, чем сохранить — особенно если учесть, что резервные копии требовали такого же ненадежного носителя.

Некоторые архаичные носители до сих пор используются там, где важнее стабильность, а не прогресс. В авиации, например, часть бортовых систем Boeing 747 до недавнего времени обновлялась через 3,5-дюймовые дискеты — потому что проверенная временем технология надежнее экспериментальных решений.

Промышленные станки, медицинское оборудование и даже банковские системы иногда работают на технологиях 1980-х просто потому, что их модернизация стоит дороже, чем покупка партии старых дискет на eBay. А энтузиасты ретро-компьютеров сознательно используют кассеты и флоппи-диски — для них это не просто носители, а часть культурного кода.

Что мы потеряли и что приобрели

Физические носители учили нас ценить данные. Когда файл нельзя было скопировать в два клика, а каждый мегабайт занимал место, люди тщательнее подходили к хранению информации. Переписка кассет требовала времени, коллекцию CD бережно держали на книжных полках, стирая пыль с футляров, а игры на 10 дискетах устанавливали с замиранием сердца — вдруг последняя окажется битой.

Сегодня данные стали абстрактными. Мы не держим их в руках, не боимся потерять из-за царапины и даже зачастую не знаем, на каком именно сервере они лежат. Это удобно, но лишает нас того самого «тактильного» отношения к информации.

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

Флешки, SD-карты и облака: вы находитесь здесь — что дальше

Флешки, которые еще недавно казались чудом технологий, уже выглядят архаично на фоне облачных хранилищ. SD-карты, вмещающие терабайты информации, размером не больше ногтя на мизинце. Но что дальше?

Твердотельные накопители, основанные на кремниевых чипах, приближаются к физическим пределам. Производители научились упаковывать данные невероятно плотно — современные 3D NAND-чипы содержат до 200 слоев памяти. Однако закон Мура (формулирующий неизбежность технологического прогресса) хотя и универсален, имеет определенные физические ограничения: стоимость новых фабрик по производству микросхем измеряется десятками миллиардов долларов.

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

Будущее, которое уже тестируют в лабораториях:

• ДНК-хранилища. В 2017 году гарвардские ученые записали на ДНК кишечной палочки GIF-анимацию и изображение. Технология CRISPR позволяет редактировать геном, превращая его в биологический жесткий диск. Пока процесс дорогой и медленный, но потенциал огромен: один грамм ДНК может хранить 215 петабайт данных — эквивалент 14 тысяч современных SSD.
• Молекулярные диски. Исследователи из Университета Брауна (Провиденс, США) создали прототип накопителя, где информация кодируется органическими молекулами. Метод напоминает древние глиняные таблички, только вместо клинописи — бинарный код из присутствия или отсутствия конкретных молекул.
• Кварцевые кристаллы. Технология «5D-памяти» использует фемтосекундные лазеры для записи данных в кварцевое стекло. Такие носители выдерживают температуру до 1000°C и могут хранить информацию миллиарды лет. В 2018 году Илон Маск отправил в космос Tesla с кварцевым диском, содержащим трилогию А. Азимова «Основание».
• Арктические архивы. На Шпицбергене уже работает «Арктический мировой архив», где данные хранятся на специальной пленке в стальных контейнерах. Туда поместили исходники GitHub, цифровое искусство и даже конституции некоторых стран — на случай глобальной катастрофы.

Парадоксально, но будущее может вернуть нас к чему-то очень древнему: подобно тому, как египтяне высекали иероглифы в камне, мы будем записывать информацию в молекулы и кристаллы — носители, которые переживут не только нас, но и предположительно саму человеческую цивилизацию.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.

Это лишь один из многих довольно общих примеров. Но есть уникальные кейсы, как разработчики с крайне простой идеей выпустили приложение и проснулись миллионерами — рассказываем о них в статье.

Flappy Bird (олдскулы свело)

Кто-то еще помнит эту безумную птичку? В 2013 году она появилась на iOS, а в 2014 — на Android. А разработал ее вьетнамский кодер Донг Нгуен всего за несколько дней. Сам программист заявлял, что всего его игры проходимы, и главное их отличие от сложных западных игрушек — простота, хард-левел и истинное веселье. В общем, те самые ретро-игры.

Суть, кажется, объяснять не стоит — все и так помнят, что есть пиксельная птичка, которой нельзя упасть или удариться об трубу. Самое же интересное — как в 2013 году к этой в какой-то степени дурацкой игре пришла такая популярность. На самом деле, до сих пор загадка: одни связывают это с роликом PewDiePie (на тот момент у него было уже более 20 млн подписчиков на YouTube, другие — с вирусным эффектом в соцсетях.

В январе 2014 птичка возглавила топ бесплатных приложений в американском и китайском App Store, а потом — в британском. Игрушку скачали более 50 млн раз, а разработчики зарабатывали с рекламы $50 000 долларов в сутки!

10 февраля 2014 года Нгуен неожиданно удалил Flappy Bird из App Store и Google Play. В интервью Forbes он объяснил это чувством вины: игра, задуманная как легкое развлечение на пару минут, стала для многих «наркотиком». Нгуен говорил, что не мог спать из-за давления популярности и хотел вернуть себе спокойствие. После удаления начался ажиотаж: телефоны с установленной игрой продавались на eBay за тысячи долларов, а рынок заполонили десятки клонов.

Однако в этом году должно было произойти чудо: в сентябре 2024 компания Gametech Holdings объявила, что готовит перезапуск игры в 2025 — она банально украла права у Нгуена, когда те истекли. Правда, твиттерские было выяснили, что это скам: Gametech связана с другой компанией — 1208 Productions, которая делает игры для Web 3 с NFT. А еще Gametech подписаны на кучу инфоцыганских аккаунтов в Твиттере. Вишня на торте — на официальном сайте перезапуска птички лежала демка, один из юзеров ее скачал, и в конце его попросили завести криптокошелек. В общем, птичку не тапаем, на NFT-развод не попадаем.

Но в Flappy Bird все еще можно поиграть: здесь лежит браузерная версия. Честно, феномен птички все еще для нас загадка, но зато это хороший пример, что можно создать абсолютно обычную игру и сделать так, чтобы она сильно завирусилась в сети.

BeReal

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

Сейчас у приложения нет монетизации, поэтому все цифры основываются на оценках и капитализации. Последняя сделка по BeReal прошла в июне 2024 года — привлекли более $580 млн.

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

Wordle

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

Эту игру придумал программист Джош Уордл в 2021 году как подарок для своей девушки, которая любила словесные головоломки. Он выложил её в интернет просто «для друзей», но очень быстро Wordle стала вирусной. В январе 2022 года игрушку купила The New York Times за небольшую семизначную сумму, то есть где-то за $1-3 млн.

Технология тоже очень простая: обычная веб-страница, написанная на HTML, CSS и JavaScript. Загружается список слов, одно из них выбирается как «слово дня», и дальше работает простейшая логика — сравнение букв и подсветка.

Популярность тоже вполне объяснима. Во-первых, игра ужасно простая. Там нет рекламы, регистрации, внутриигровых покупок — просто заходишь и играешь. Во-вторых, можно сыграть только один раз в день, и это ограничение превратилось в фишку — у многих игроков это стало ритуалом. Кстати, в 2022 году wordle был самым частым запросом в Google среди американцев.

Автор этой статьи тоже обожает Вордл! Это еще и отличный шанс подтянуть свой английский. Если еще не пробовали — оцениваем здесь.

Locket Widget

Еще одна до жути простая идея: делаете фото в приложении, и оно появится у ваших друзей на главном экране в виде виджета.

Мэтт Мосс запустил Locket Widget в 2022 году — он разработал приложение всего за несколько недель для своей девушки, с которой у них были отношения на расстоянии (опять романтическая история). Сейчас им пользуются десятки миллионов людей по всему миру, а в 2022 году в него загрузили более 2 млрд фотографий.

На пике популярности Мосс с командой привлекли $12,5 млрд инвестиций. Кстати, завирусилось приложение опять благодаря ТикТоку — видео в аккаунте Мосса набирали миллионы просмотров.

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

Calm

Calm — одно из самых известных приложений для медитации и сна. Его разработали два предпринимателя — Алекс Тью и Майкл Эктон Смит — в 2012 году. Идея была очень простой: помочь людям справляться со стрессом и тревогой с помощью коротких медитаций, приятной музыки. Интерфейс — тоже максимально минималистичный.

Когда Calm только появилось, никто особо не верил, что такое «спокойное» приложение может выстрелить. Но всё оказалось наоборот: люди устали от шума, соцсетей и перегрузки. Приложение стало настоящим островком тишины — его включали перед сном, в перерывах на работе или просто чтобы немного расслабиться.

В 2016 году Calm начал активно развиваться и добавлять новые функции, которые сделали его намного популярнее и полезнее для пользователей. Тогда появилась одна из главных фишек — Sleep Stories. Считайте, что это сказки на ночь, только для взрослых работящих людей. А сейчас самая популярная функция в приложении — 10-минутная медитация, которая доступна пользователям всего лишь 24 часа.

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

Уже в 2019 году Calm стал первым «единорогом» в сфере ментального здоровья — его оценили в $1 млрд, а позже — и в $2 млрд. Плюс компания зарабатывает на ежемесячных и пожизненных подписках.

Как говорится, think different, а все гениальное — просто. Приложение на миллион долларов можно сделать даже за несколько дней, главное — немного удачи, крутая идея и промо.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Для этого использовали NES86 — эмулятор IBM PC на NES, который эмулирует процессор Intel 8086 и создаёт среду, совместимую с ELKS (Embedded Linux Kernel Subset).

Проект доказывает: даже на железе 80-х можно заставить работать современные системы.

Что реально запустили?

• Ядро ELKS – облегчённая версия Linux, созданная для процессоров x86 16-bit.
• Оболочка и базовые утилиты – работа в Терминале возможна!
• Файловая система – пусть и с ограничениями, но функционирует.

Какие ограничения?

NES – это не современный ПК, поэтому:

• Производительность минимальна – консоль просто не тянет сложные процессы.
• Нет многозадачности – выполняется одна операция за раз.
• Графический интерфейс не поддерживается – только текстовые команды.

На чём можно запустить?

• Эмуляторы: NES86 стабильно работает на FCEUX и Rustico.
• Оригинальная NES: требуется Everdrive N8 Pro, так как стандартный Everdrive N8 не поддерживает проект.

Почему это важно?

Этот эксперимент – не просто фанатская забава. Он демонстрирует:

• Гибкость Linux – система может работать даже на консоли 80-х.
• Возможности кроссплатформенной адаптации – подобные технологии могут быть полезны в сфере ретро-компьютинга.
• Наследие NES – культовая консоль продолжает удивлять спустя десятилетия.

Проект NES86 уже доступен в открытом репозитории. Более подробно – на GitHub.

Эта история о том, как мы обнаружили, что «больше» не всегда значит «лучше», и как реорганизация команды помогла уложиться в сроки и повысить качество работы. Меня зовут Игорь Котов, я СТО стрима Ипотека, и в этой статье я поделюсь нашим опытом. Возможно, он будет полезен тем, кто ищет способы ускорить разработку без увеличения команды.

С чего мы начинали

От банка клиенты ждут удобных сервисов. Однако наш процесс подачи заявки на ипотеку устарел. В 2022 году мы решили сделать современный личный кабинет заемщика. Новый инструмент должен был включать:

• заполнение заявки онлайн с возможностью сохранять черновики;
• отслеживание статуса рассмотрения заявки;
• добавление созаемщиков;
• загрузку и обновление документов;
• доступ с любого устройства через авторизацию по номеру телефона.

На первый взгляд всё казалось несложным: к маю 2023 года мы собрали команду из более 20 человек. Это были опытные инженеры, знакомые с продуктом, новички, аналитики и тестировщики. Работа организовывалась по классическим agile-принципам: двухнедельные спринты, дейли, демо и ретро.

На бумаге всё выглядело идеально, но на практике появились проблемы. Дейли затягивались до 40 минут: каждый участник говорил пару минут, а остальное время люди ждали своей очереди или слушали нерелевантные обновления. В итоге на такие встречи уходило больше 13 часов в неделю.

Серьёзной оказалась и другая проблема — низкая вовлечённость. Новички полагались на опытных коллег, а те брали на себя больше работы. В результате инициативность в команде снизилась. Мы также столкнулись с отсутствием фокуса: команда пыталась одновременно продвигать несколько крупных фич. Задачи переносились из спринта в спринт, а усталость нарастала.

К сентябрю, когда мы всё-таки выпустили MVP, стало ясно: команда выгорела, а релиз в срок оказался под вопросом.

К какому решению пришли

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

Каждая получила чёткую зону ответственности и полный набор компетенций для автономной работы:

• Одна команда занялась функциями работы с созаемщиками.
• Вторая — модулем загрузки и обработки документов.
• Третья — анкеты заемщика.

Мы тщательно перемешали составы: опытные сотрудники и новички распределились равномерно. Это позволило сбалансировать компетенции и создать условия для обучения внутри команд.

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

Такое разделение изменило подход к планированию: теперь каждая команда могла сосредоточиться на своей задаче, а не пытаться двигать несколько фич одновременно. Уже через два спринта стало очевидно, что новый формат работает.

Каких добились результатов

Реорганизация принесла ощутимые улучшения. Дейли сократились до 15 минут, планирование занимало около часа, а ретро стали откровеннее и конструктивнее. Это позволило устранить чувство безответственности: каждый участник ощущал свою значимость.

Фокусировка на отдельных задачах избавила от постоянного переноса задач из спринта в спринт. Процесс разработки стал предсказуемым. К концу 2023 года мы запустили кабинет заемщика в срок с полным набором фич: от удобного интерфейса для созаёмщиков до автоматизированной обработки документов. Результат подтвердил, что выбранный подход оправдан.

Как понять, что вашей команде нужно изменение

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

Попробуйте присмотреться к процессам в вашей команде: возможно, именно дробление и чёткое распределение зон ответственности станет ключом к успеху. Важно помнить, что универсальных рецептов не существует, но наш опыт показывает, что изменения — это не только вызов, но и возможность вывести команду на новый уровень эффективности.

Проект содержит 50 000 строк ассемблерного кода, который был тщательно задокументирован и прокомментирован для понимания работы игры под капотом.

Что это за проект?

Разработчик Мара Моксон, энтузиаст и исследователь классических игр, опубликовал исходники Elite, позволив тем самым не только изучить их, но и собрать полную рабочую версию игры для Commodore 64 на современных компьютерах.

Документация включает:

• Подробные комментарии к каждой строке кода.
• Варианты сборок для NTSC и PAL версий игры.
• Пояснения к структуре файлов и использованным техникам.

Почему это важно?

Elite, впервые вышедшая в 1984 году, считается одной из величайших игр в истории, задавших стандарты для жанров космических симуляторов и открытого мира.

Для Commodore 64 игра вышла в 1985 году и использовала ассемблерный код, демонстрируя уникальные для своего времени технические решения.

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

Где найти код?

Исходный код доступен на GitHub. Кроме того, проект сопровождается удобным сайтом с визуализированным и более «читаемым» представлением исходников.

Этот релиз — редкая возможность заглянуть в историю и увидеть, как программисты 80-х справлялись с ограниченными ресурсами для создания одной из самых знаковых игр в индустрии.

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, в чем польза ежедневных встреч и как их спланировать так, чтобы ни у кого не закатывались глаза.

Зачем нужны созвоны и какую роль они играют

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

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

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

Созвоны должны решать проблемы, отвечать на вопросы (быстрее, чем в переписке), заставлять не лениться, мотивировать, держать в курсе новостей продукта, компании. Другими словами, синковать и подталкивать, занимая минимальное количество времени (зачастую проблемы возникают тут) — работать ведь тоже нужно. Если ваши созвоны какому-то из пунктов не удовлетворяют, стоит задуматься, не нужно ли что-то оптимизировать.

Какие бывают созвоны

На самом деле видов созвонов немало — рассмотрим самые популярные из них, которые, пожалуй, были почти в каждой команде и компании:

• Стендапы/дейлики — базированная база, краткие созвоны по 15 минут с целью получения статусов каждого из исполнителей: что делал вчера? что сегодня?
• Груминги — это встречи, на которых вы собираетесь и вместе приходите к решению какой-то из проблем. К примеру: «Груминг по вопросу проектирования платежей»: собираетесь и вместе думаете над архитектурой платежей.
• Ретро — вы собираетесь вместе, чтобы обсудить хорошие и плохие моменты за последний период работы. В процессе обсуждения будет круто, если вы придете к каким-то Action Pointам — задачам, которые помогут устранить плохие моменты.

Иногда созвоны бывают просто по необходимости — быстро обсудить какой-то момент (возможно не всей командой). В таких случаях не нужен никакой регламент, все решается по ситуации.

Стендапы и дейлики: фокус или отвлечение?

Первым делом Даниил с лидом QA приняли решение внедрить 15-ти минутные ежедневные встречи по утрам.

В Озоне у меня уже было такое, признаюсь честно. Мне как разработчику так не хотелось просыпаться на него по утрам, но когда ты лид — думаешь по-другому, потому что если твоя команда будет лениться и не давать результат, придут к тебе.

Для начала важно отметить, что дейлик = стендап. Оба термина используются в Agile-методологиях (особенно в Scrum) и означают одно и то же мероприятие.

Теперь давайте представим себя на моем месте и объективно подумаем, какие плюсы есть у стендапа, чтобы даже с утра пораньше они были оправданы:

• Явная точка старта рабочего дня. Особенно актуально на удаленке, где у каждого рабочий день начинается в свое время, плюс есть те, кто не обладает силой воли каждый день в константное время вставать с кровати — для них стендап будет той самой жесткой точкой, к которой они должны войти в фокус.
• Мотивация на результат. Стендапы подстегивают думать: «А что я скажу завтра?» Это мотивирует завершать задачи и продуктивно использовать день.
• Напоминание о темпе. Работает в том случае, если в одной команде есть и нереально продуктивные сотрудники, и те, кто работают медленнее. Вторые будут испытывать страх и волнение и думать: «Я работаю гораздо медленнее, чем Саша… А вдруг это не нравится руководству? А вдруг премию не дадут?» И как раз благодаря стендапам и наглядному прогрессу коллег ребята могут подкорректировать свой темп, чтобы не отставать и соответствовать ожиданиям. Но здесь не перегнуть палку, чтобы избежать выгорания.
• Для руководителей. Понимаешь, кто чем занимается, направляешь, ставишь приоритеты. В моем случае ситуация такова: задач много, исполнителей мало, так еще и стоят они дорого, каждый час дорог, нужно контролировать.
• Новости по продукту или про компанию. Это занимает обычно не более 5 минут, стендапы хорошо подходят для таких мини-сводок.
• Решение вопросов, которые затрагивают большое количество людей. Если понимаете, что текстом решить какой-то вопрос не получится и важно мнение каждого, есть смысл обсудить его на стендапе. Главное избежать такой ситуации: два исполнителя общаются между собой, пока другие просто сидят и бессмысленно тратят время. В нашем случае желательная граница созвона — 25 минут (стендап классически длится 15 минут, но иногда этого не хватает еще и для ответа на вопросы и мини-синка). Если на это уходит больше времени, нужно оптимизировать. Локальные вопросы лучше обсуждать текстом — так сохраняется история размышлений и выводов, плюс не привлекаются другие сотрудники.

Внедрение стендапов прошло хорошо — после адаптации мы заметили хорошие результаты по каждому из пунктов.

Формат стендапа: наш отработанный план встреч

Мы пришли к такому формату стендапов — он, по моему мнению, реализует максимум из того, что возможно за короткий срок до 25 минут:

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

2. Даём слово исполнителю, задавая несколько вопросов:

• Что сделал вчера? (тут можно уточнить у разработчика про статусы по важным задачам — таким образом подтолкнуть и узнать, как идет работа)
• Что планируешь делать сегодня? (здесь можно скорректировать приоритеты)
• Есть блокеры или какие-то вопросы, которые можно вкратце обсудить сейчас? (важно вовремя остановиться, чтобы дейлик не превратился в груминг)

А еще можно напомнить про вопросы в чате, на которые еще не получены ответы.

3. Всем хорошего дня — всё.

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

Но в описанной мной схеме выше есть и уязвимости — это вопросы. Из-за них дейлик может превратиться в груминг. Такого важно не допускать, груминги — отдельные мероприятия, к которым люди готовятся, на которые приглашают ограниченный круг лиц, чтобы не отбирать время у других, а на стендапе присутствуют все, и большинство только проснулось.

Груминги: что это такое и с чем едят?

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

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

Уже спустя час у меня в документе был приоритезированный набор задач с теоретическими решениями, который можно было превратить в план. Объединив свое первичное видение с экспертизой команды, я справился с задачей и принес подробный план техническому директору.

Резюмируем: зачем нужны груминги

• Чтобы совместно прийти к общему решению, которое будет максимально приближено к правде, поскольку одна голова — хорошо, две — еще лучше, а головы целой команды — вообще бомбически круто.
• Бас-фактор отдельно взятого человека понижается, потому что в идею решения вовлечены все члены команды
• Каждый может поделиться своим виженом, и его послушают — это положительно влияет на отношение человека к компании

Груминги занимают мало времени — в среднем на него уходит час в зависимости от сложности вопросы. Но, поверьте, результаты вас удивят.

Несколько советов, как нужно проводить груминг

Довольно быстро я пришел к следующему довольно очевидному формату:

1. Ставим встречу в первый день недели (а лучше в пятницу прошлой недели), пишешь в чате о груминге и его теме и уведомляешь каждый день на протяжении недели на стендапах то, что у нас в четверг (ориентировочно) будет груминг. Просим подготовиться, немного подумать на тему — люди обычно ленятся, но если повторять много раз так или иначе будут результаты. А еще можно попросить поставить встречу коллегу — в ребятах тоже важно растить софты таким образом, чтобы найти себе преемника и двигаться дальше в будущем.
2. На самом груминге сначала отмечаем проблему, предлагаем свои теоретические варианты решения.
3. Потом поочередно спрашиваем каждого члена команды, чтобы уничтожить фактор стеснения — так люди вынуждены будут что-то сказать.
4. Готово — дальше вы обсуждаем вопрос и приходим к решению

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

Теперь о самом приятном — ретро

Ретро — пожалуй, лучший вариант созвона для членов команды. Это время, когда можно похвалить друг друга за успехи и честно обсудить, что можно улучшить. Но когда я внедрял эту идею к нам в команде, результаты были не очень позитивные — ребята просто не знали, что нужно писать, поскольку 2 недели в Kanban — это не очень много. Поэтому в случае ретро важно правильно продумать периодичность встреч. Наиболее оптимальная схема для меня — раз в один/два месяца по ситуации. В Озоне мы, однако, пришли к одному ретро в неделю, поскольку формат работы был совсем другой — слишком меняющийся и с моментами, где правда нужно собраться и обсудить и что-то улучшить.

Какие смыслы несет ретро

1. Во-первых, это желание становиться лучше, которое идет у нас с самого детства — оно тут реализуется сполна, вы анализируете и выявляете Action Points (моменты, которые нужно улучшить) и двигаетесь далее с понимание проблемы и желанием ее решить.
2. Тимбилдинг. В момент ретро — если все правильно организовать и не уходить в негатив — можно укреплять дружеские связи между членами команды, что тоже весьма полезно. Дружеские связи повышают привязанность к компании и команде, поэтому можно будет меньше беспокоиться о том, что человек может в один прекрасный момент уйти и оставить все проблемы нам.
3. Способствует вовлеченности человека в продукт и компанию. Тут все очевидно: в позитивной форме мы по сути заставляем людей говорить о проблемах и вытаскиваем из них предложения на улучшение процессов. Может быть через некоторое время и вытаскивать не придется — проблемы сами будут выходить.
4. Самоутверждение. На ретро можно хвалиться тем, что ты уже сделал, и самоутверждаться за счет похвал других. Зачастую бывает, что успехи людей упускаются и им не придается особого значения — ретро исправляет эту проблему.

На самом деле в случае ретро я не буду рекомендовать ничего конкретного, потому что у каждой команды своя специфика. Человек — это не системное существо, а эмоциональное Сумма всех характеров и образует специфику команды. Под эту специфику вам и нужно будет подстраиваться.

Принуждение к встречам: свобода vs. контроль

Во всех компаниях, где я работал, явно обязательность встреч не отмечалась, но она, конечно, подразумевалась. Но если ты физически не можешь ее посетить — например, стало плохо или нужно срочно куда-то отъехать, то мы не давим на человека, а отпускаем.

Моя позиция такая: каждый из вышеописанных созвонов должны посещать все обязательно, потому что отсутствие на одном из них может привести к проблемам — рассинк с командой, придется все повторять, не учитывается мнение человека. Поэтому если кто-то заранее говорит, что не может прийти, мы стараемся переносить встречи.

Как тимлидам оптимизировать встречи

• Не допускайте того, о чем я писал выше: стендапы не должны превращаться в груминги
• Не ленитесь устраивать груминги — это полезно, поскольку вы спрашиваете мнение каждого из команды
• В ретро важно выстроить доверительное отношение — пытайтесь максимально переходить на другие темы
• Внимательно слушайте каждого члена команды. Часто бывают ситуации, когда стендапы деградируют по уровню ответов следующим образом: делал X, вот сейчас делаю Y — всё. Уточняйте, вежливо выводите человека на чистую воду, и тогда стендап не будет лишь формальностью

К таким результатам я пришел совместно с командой за первое время оптимизации процессов, дальше — больше. Сейчас все на канбане, но мы планируем внедрить скрам.

Делитесь в комментариях, как у вас проходят созвоны? И каких моделей вообще придерживаетесь?

Наставничество — это долгосрочная инвестиция. Подопечные, получившие поддержку в начале карьеры, со временем становятся профессионалами, которые готовы делиться знаниями с другими.

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

Типы наставничества

Формальное и неформальное наставничество

Наставничество бывает двух типов, и каждый из них полезен в разных ситуациях:

• Формальное наставничество: есть чёткие цели, расписание встреч, и прогресс отслеживается по заранее утверждённым метрикам. Например, в IT-компаниях создаются внутренние программы, где младшие разработчики проходят обучение под руководством старших коллег. Для этого даже выделяются отдельные платформы, где фиксируются задачи, отслеживаются результаты и собирается обратная связь. Такой подход удобен, если нужно быстро обучить сотрудников работе с конкретными технологиями или инструментами.
  
  
• Неформальное наставничество: здесь всё проще, представьте, вы с коллегой случайно завели small talk, он спросил совета по проекту, а вы рассказали, как это можно реализовать. Такой формат наставничества строится на человеческом взаимодействии, без расписаний и строгих правил. Часто он помогает решить проблемы, которые не всегда очевидны, например, выбор подхода к разработке или личный рост в команде. Подобный стиль часто встречается в небольших компаниях или стартапах, где формальных программ нет, но культура взаимопомощи сильна.

Индивидуальное наставничество

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

Групповое наставничество

Групповое наставничество немного похоже на мини-воркшопы. Наставник работает сразу с несколькими подопечными, что полезно для обучения основам технологий или общего подхода к работе. Например, это может быть мастер-класс по внедрению CI/CD в проекте или тренинг по улучшению производительности приложений.

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

Равное наставничество

Это про ситуацию, когда два человека с одинаковым уровнем знаний учат друг друга. Например, один специалист хорошо знает Kubernetes, а другой — как работать с Docker. Вместо того чтобы каждый изучал новую тему в одиночку, они делятся опытом и растут вместе. Это отличный способ строить партнёрские отношения, где оба могут быть и наставниками, и учениками.

Часто такой формат встречается в распределённых командах, где коллеги из разных регионов помогают друг другу освоить новые подходы. Например, один разработчик из отдела данных учит другого создавать пайплайны для обработки больших объёмов информации, а взамен получает советы по работе с API.

Обратное наставничество

Вот это уже что-то необычное, но в IT всё больше набирает популярность. В этой модели менее опытные сотрудники учат более опытных коллег. Как это работает? Представьте, джун рассказывает тимлиду, как использовать популярный инструмент автоматизации тестирования, который тот ещё не успел попробовать. Или молодой разработчик показывает, как лучше организовать работу в новой версии IDE.

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

Кросс-функциональное наставничество

Этот формат на стыке технологий и управления. Здесь наставничество строится между сотрудниками из разных отделов. Например, backend-разработчик делится своими знаниями о построении API с аналитиком, который хочет лучше понимать, как обрабатывать данные.

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

Качества эффективного наставника

Чтобы наставничество действительно работало, наставник должен обладать рядом ключевых качеств. Это не только технические знания, но и умение взаимодействовать с людьми, понимать их проблемы и находить правильные подходы.

Основные качества

• Техническая экспертиза — наставник должен знать теорию, практику и решать нестандартные задачи, чтобы давать подопечным точные и полезные советы.
  
  
• Эмпатия и коммуникация — наставник должен уметь слушать и понимать чувства подопечного. Важно улавливать, где человек испытывает затруднения, и находить способ объяснить сложные вещи простым языком.
  
  
• Опыт — здесь речь идёт не только о профессиональных достижениях, но и об ошибках. Наставник, который не боится рассказывать о своих провалах, вызывает больше доверия. Поэтому если вы однажды установили неподходящий фреймворк, это может научить подопечных проверять совместимость технологий с реальными задачами.

Проверьте модели поведения

1. Открытость к обратной связи: наставник не только даёт советы, но и принимает критику. Если подопечный говорит, что определённый метод не подходит для его задачи, наставник должен быть готов обсудить альтернативы, а не настаивать на своём.
   
   
2. Поддержка и ободрение: наставник — это человек, который помогает подопечному преодолеть неуверенность. Когда вы видите, что разработчик боится выступить с докладом на внутреннем митапе. Вместо того чтобы критиковать, вы предлагаете подготовить презентацию вместе и репетируете перед выступлением.
   
   
3. Совместная постановка целей: это не о том, чтобы просто дать подопечному задачу, а о том, чтобы вместе определить, к чему он хочет прийти. Например, если ваш подопечный хочет освоить новый фреймворк, вы помогаете разбить этот процесс на небольшие шаги: от чтения документации до создания пилотного проекта.

7 шагов, чтобы стать наставником

Если вы хотите стать наставником, важно не только обладать необходимыми качествами, но и правильно выстроить процесс. Вот несколько шагов, которые помогут вам в этом:

1. Выбор подопечных — посмотрите вокруг: кто в вашей команде или профессиональном сообществе нуждается в поддержке? Если вы видите, что новый сотрудник часто задаёт вопросы о процессе работы, это сигнал, что ему может быть полезен наставник.
   
   
2. Установление контакта — наставничество начинается с первого разговора. Пригласите коллегу на кофе или организуйте неформальный звонок, чтобы узнать, чем вы можете быть полезны.
   
   
3. Определение границ и ожиданий — с самого начала обсудите, как будет построено взаимодействие. Как часто вы будете встречаться, какие вопросы вы готовы обсуждать, а какие нет. Это поможет избежать выгорания и недопонимания.
   
   
4. Постановка целей и составление плана — вместе с подопечным определите, чему он хочет научиться, и составьте план. Если цель — освоить новую технологию, добавьте этапы: изучение основ, выполнение учебных задач, работа над реальным проектом.
   
   
5. Создание учебной среды — наставник должен поощрять вопросы и обсуждения. Вместо того чтобы сразу дать готовый ответ, попросите подопечного подумать над решением задачи самому, а затем разберите его предложение.
   
   
6. Поддержка роста — наставничество — это не только про обучение, но и про вдохновение. Рассказывайте подопечному, как навыки, которые он сейчас изучает, помогут ему в будущем карьерном росте.
   
   
7. Постоянное совершенствование — наставник тоже должен учиться. Анализируйте, что получилось хорошо, а что можно было сделать лучше, и корректируйте свои методы.

Как выстроить отношения с подопечным

Ставьте чёткие ожидания и цели

В самом начале важно договориться, к чему вы вместе стремитесь. Например, подопечный хочет научиться работать с Kubernetes, а вы можете помочь ему пройти весь путь — от настройки локального окружения до развёртывания приложения в продакшене. Определите конкретные шаги и зафиксируйте их.

Стройте доверительные отношения

Доверие — это основа любых взаимодействий. Подопечный должен чувствовать, что может быть честным и открытым, даже если он сталкивается с трудностями. Вы можете начать с рассказа о своём первом провале, чтобы показать, что ошибки — это часть обучения.

Поддерживайте открытую коммуникацию

Планируйте встречи заранее, чтобы обе стороны могли подготовиться. На этих встречах обсуждайте прогресс, решайте проблемы и отмечайте достижения.

Пример структуры встречи:

1. Ретроспектива: Что удалось за прошлую неделю, какие были сложности?
2. Анализ: Как можно улучшить процесс или подойти к задаче иначе?
3. План: Какие шаги предстоит сделать до следующей встречи?

Практикуйте активное слушание

Иногда наставники совершают ошибку, когда пытаются сразу дать совет, не разобравшись в сути проблемы. Вместо этого сосредоточьтесь на слушании. Например, если подопечный говорит: «Я не понимаю, как работает эта библиотека», спросите: «Что именно вызывает у тебя сложность? Документация или примеры?»

Современный подход: некоторые наставники используют технику коучинговых вопросов, чтобы помочь подопечному самому найти решение:

• Что ты уже пробовал?
• Какие ещё варианты ты видишь?
• Какой из них тебе кажется самым перспективным?

Совместно решайте проблемы

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

Поддерживайте баланс

Наставничество не должно становиться источником стресса ни для подопечного, ни для наставника. Договаривайтесь о том, сколько времени вы готовы уделять этому процессу. Выделите по часу в неделю, чтобы не перегружать ни себя, ни коллегу.

Отслеживайте прогресс

Регулярно оценивайте, как идут дела. Например, если вы работаете над обучением новому фреймворку, отмечайте, какие шаги уже выполнены, а какие ещё предстоит сделать.

Проблемы в наставничестве

Коммуникационные барьеры

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

Как решить:

• Используйте простую и понятную речь, особенно если подопечный — новичок.
• Спросите напрямую, что именно вызывает сложности.
• Попробуйте визуализировать сложные концепции с помощью диаграмм или схем. Например, объясняя микросервисы, покажите, как они взаимодействуют друг с другом.

Временные затраты

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

Как решить:

• Запланируйте фиксированное время для встреч. Например, каждую среду с 16:00 до 17:00.
• Используйте асинхронные методы коммуникации: оставляйте комментарии в коде или записывайте короткие видеоролики с объяснениями.
• Пересмотрите свои ожидания: возможно, вы пытаетесь охватить слишком много за один раз.
• Делегируйте часть задач более опытным членам команды, если вы перегружены.

Установление границ

Некоторые подопечные могут слишком часто обращаться к наставнику, нарушая границы рабочего времени. Это может привести к выгоранию у наставника.

Как решить:

• На первой встрече обсудите, когда и как можно задавать вопросы. Например, договаривайтесь писать в корпоративном мессенджере только в рабочие часы или выносить нерешённые вопросы на регулярные встречи.
• Если подопечный пишет слишком часто, честно объясните, что вам нужно время на выполнение своих задач.

Разнообразие стилей обучения

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

Как решить:

• Узнайте, как подопечному удобнее учиться. Удобно ли ему разбирать задачи самостоятельно или лучше, чтобы вы работали в паре.
• Используйте разные форматы: статьи, видеоуроки, живые обсуждения.

Эмоциональные сложности

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

Как решить:

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

Начинающим специалистам наставничество помогает быстро адаптироваться в новой роли. Вместо того чтобы тратить недели на поиск информации, подопечный может получить ответы и поддержку от опытного коллеги.

Наставничество полезно и для самого наставника. Оно помогает развивать лидерские навыки, учиться объяснять сложные вещи простым языком и видеть привычные задачи с новой точки зрения.

В итоге это помогает не только отдельным специалистам, но и всей айтишке двигаться вперёд.

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

Как Джеймс справился с техническими вызовами?

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

PS1 имеет процессор с архитектурой MIPS, графический процессор (с очень скромной производительностью) и всего 2 МБ оперативной памяти.

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

Этот SDK включает компилятор, ассемблер и другие утилиты, которые позволяют создавать и тестировать игры на реальном железе.

Что такое Notris и как она работает?

Notris — это не просто клон Тетриса. Джеймс внедрил в игру уникальные механики, добавив, например, новые формы блоков и уровни сложности.

Программирование под PS1 потребовало от него глубокого понимания низкоуровневого кода и умения работать с ограниченными ресурсами.

Например, для оптимизации графики он использовал спрайты и тайловую карту, чтобы эффективно управлять ограниченным количеством памяти и мощностей процессора.

Почему это важно для сообщества разработчиков?

Notris вызвала волну интереса в сообществе разработчиков и ретро-геймеров.

Проект показал, что программирование под старые платформы — это не просто ностальгия, но и способ отточить свои навыки, работая с ограниченными ресурсами и специфическими инструментами.

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

Постарались подобрать довольно неочевидные вопросы, ответы на которые должен помнить только настоящий олд.

Пишите в комментариях, удалось ли нам угадать ваше десятилетие?

Всем привет! Меня зовут Александр Ватолин, я геймдизайнер и преподаватель Московской школы программистов (МШП).

Этой весной мы проводили ежегодный Весенний фестиваль, темой которого был пиксельный мир 8 bit. Нас вдохновила ушедшая эпоха с ее перфокартами, тетрисом, post it’ами и аркадными автоматами. Мы решили полностью погрузиться в 80-е и собрали несколько своих аркадных автоматов, к которым написали игру. Вот, что из этого получилось:

Рассказываю, как мы это сделали.

Этап 1. Создаем проект автомата

Сначала решили, что сделаем простенький проект автомата и закажем его нарезку и сборку на пилораме. План был шикарный, но ненадежный. Но мы этого тогда не знали.

Я получил примерный вид автомата, открыл Inventor и уже после вечера работы была готова первая версия сборки. Вот она:

Этап 2. Сборка

Как только проект утвердили, мы обозначили масштаб: 3-4 игровых автомата. Нам это казалось вполне выполнимым, и мы приобрели электронные компоненты любого автомата – кнопки и манипуляторы.

Потом появился вопрос: а что будет основой автомата? Путем недолгих поисков мы остановились на моноблоках. Они дешевы, дают неплохое изображение (мы брали с мониторами на 24”), да и в целом неприхотливы. Пара поездок по складам в Москве и пара доставок с маркетплейсов – и у нас появилось все необходимое. Что мы выбрали:

– Старые офисные моноблоки Samsung TC241. На их борту был CPU:AMD G-T40N + GPU: AMD R HD6290 с невысокими частотами и 4 гб оперативной памяти.

– Плюс этой машины заключался в матрице. Монитор моноблока дает неплохую картинку, да и скромное железо – решаемая проблема: моноблок можно использовать как монитор, подключив к нему полноценный компьютер. Для нашей 2D-игры этого железа вполне достаточно, но возможность апгрейда – важная деталь при разработке.

– Второй плюс был в цене – 7000 руб. за один моноблок. Всего у нас вышло без учета трудозатрат в районе 30 000 руб. за один автомат. По-моему, ценник вполне адекватный.

Но у нас возникла проблема с корпусами, потому что мы получали десятками отказы – объем работы был небольшим. И тогда решили, что выпилить 3 автомата руками не проблема. Заехали за инструментами и доработали чертежи. Выезжали с трудом, вывозя более 200 кг лдсп. Вам интересно, как это выглядело? Вот!

На этом этапе мы перешли к сборке автоматов. Все самое веселое ждало нас впереди.

Сразу скажу: если вы захотите собрать аркадный автомат – подумайте о помещении. Потому что ко второй неделе офис нас немного возненавидел. Я ожидал, что получится выпилить абсолютно все при помощи лобзика и пары других инструментов. Но я был не прав… В итоге нас спас фрезер. Фрезер в офисе? Легко, если вы делаете уникальный проект!

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

Процесс сборки был рутинным, но результат был вполне неплохим. Вот так по итогу выглядели автоматы!

К слову, автомат разбирается на две части и может работать в настольном варианте. Но делали мы это прежде всего для более удобной транспортировки. Из неочевидных решений – установлены пилот и usb-выходы на крышу автомата.

Этап 3. Пишем игру

Тогда же началась активная проработка игры. Я решил выбрать что-то хорошо знакомое и удобное в разработке. После недолгих мучений был выбран Unity, а в качестве игры-референса Ice and fire – старая браузерная игрушка. Там вы играете за огонь и воду, разгадывая головоломки. В МШП мы даем детям фундаментальное IT-образование, поэтому хотели выбрать что-то мирное, но при этом сложное и полезное для мышления.

Архитектурно игра представляла из себя двух персонажей, которые могут параллельно перемещаться и взаимодействовать с другими объектами. Изначальный список фич был достаточно большим, мы хотели разработать 10 уровней. Однако поджимающие сроки и долгие тесты поставили крест на этой идее. Мы оставили всего 3 уровня, одна игра длилась 5 минут.

Потом возник вопрос, как заставить управление с кнопок аркадного автомата взаимодействовать с Unity-приложением. В основе управления лежала какая то китайская плата, которая мимикрировала под джойстик. Решение пришло из гугла – приложение joyToKey, которое прекрасно решило проблему преобразования.

Графика есть, управление тоже, остался левел-дизайн. И тут возникли сложности. Каждый уровень сначала рисовался в блокноте, потом в фотошопе, а затем я пытался его повторить в движке. Сейчас понимаю, что 10 нормальных уровней действительно трудно придумать. Так что, если соберетесь делать левел-дизайн, имейте ввиду – это сложнее, чем кажется. Вот, что получилось:

Уровень 1

Уровень 2

Уровень 3

Дальше самое интересное – скрипты. При разработке появлялось множество странных решений. К примеру, механика перехода с уровня на уровень. Основная сложность была в том, что уровень происходит только при нахождении каждого из персонажей на месте своих выходов. Поэтому система была сделана максимально простой: каждая дверь при входе героя изменяла свой статус и опрашивала вторую о наличии второго игрока. Если оба персонажа находились в дверях, включалась анимация дверей и запускался переход на следующий уровень. Именно за счет этого решения появилось два различных скрипта для каждой из дверей. В целом, можно было создать универсальную дверь, но при наличии всего двух игроков наше решение оказалось на удивление рабочим.

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

Управление:

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

Тот самый выход:

А что получилось на выходе?

Итоги

Проект оказался удачным! На мероприятии автоматы заняли первое место по популярности. На этом они не остановились: после фестиваля отправились на мероприятия во ВШЭ и на ГикПикник.

Вместо итогов хочется сказать очень банальную и простую вещь: не бойтесь пробовать. Этот проект был сделан за 5 недель. Мы не отбрасывали свои основные обязанности и это было этаким хобби, но все получилось! Так что, верьте в себя, если вдруг захотите повторить наш опыт и поностальгировать.

Узнали эту милую скрепку? Это — Clippy, он же Скрепыш, который был помощником в Microsoft Office.

В версии 2007 он был «уволен» из-за огромной нелюбви к нему у пользователей, назойливости и полной бесполезности.

Та же судьба ждала пса Ровера — пса-помощника из Windows 95 и XP, который будто бы помогал искать нужные файлы, но на самом деле просто отвлекал пользователей анимациями, пока система отчаянно и тугодумно обрабатывает запрос.

Однако прошло время, и — парадоксально, но факт — пользователи стали скучать не только по Скрепышу и Роверу, но и по диалапу, по установке программ с 20 дискет и по прожигу дисков.

В общем, ностальгировать по тому, что вряд ли поймут нынешние дети, к счастью или к сожалению.

Вот, по чему больше всего ностальгируют читатели Типичного Программиста в VK.

Чтобы поиграть в CS, нужно было зайти в Half-Life

Это — самый популярный коммент под записью.

Когда-то, чтобы поиграть в CS, нужно было скачать мод в виде архива, распаковать его прямо в папку с Half-Life, зайти в игру и переключиться на CS через меню.

То же, например, касалось и Team Fortress.

Кнопка Turbo на системном блоке

Раньше на системных блоках было три кнопки: включение, перезагрузка и турбо.

Обычно кнопка встречалась на компьютерах от IBM, а её функция заключалась в том, чтобы переключать частоту процессора. Проще говоря, «разогнать проц» можно было одним нажатием.

Есть и нюансы: частота процессора по умолчанию была высокой (если 16 МГц можно назвать высокой), а кнопка Turbo уменьшала частоту до 8 МГц.

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

То же самое можно наблюдать и сейчас, если, например, установить Fallout на современный ПК. Если игра запустится, всё в ней будет работать на скорости 3-10х.

Позже кнопка Turbo появилась и на клавиатурах, но отвечала она за скорость печати символов при зажатии клавиш.

«Блин, привод только R-ка, вот почему алкоголь не пашет»

Чаще всего CD-приводы на компьютерах предназначались только для чтения и обозначались как CD-ROM. Приводы, которые могли записывать данные на диски, обозначались как CD-RW.

Чтобы записать данные на диск, нужно было смонтировать образ в программе Alcohol, а потом «прожечь» диск через программу Nero.

Ещё можно было и записать, и прожечь диск в Alcohol 120%, но с прожигом он справлялся нестабильно.

В общем, на этом пути могла возникнуть куча сложностей: то диск не тот, то привод, то программа всё залажала… В нашем случае возникла беда с приводом.

C:\nc\nc.exe

В далёкие-далёкие времена, когда на ПК ещё не было Windows, все пользовались Norton Commander.

Это файловый менеджер для операционной системы DOS, который позволял управлять файлами. Собственно, в его определении уже всё сказано.

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

На постсоветском пространстве даже был клон Нортона — Volkov Commander. В чём была принципиальная разница, вспомнить уже сложно.

Куплю шестизнак!

Тут речь идёт о номерах ICQ. У пользователей были идентификаторы, состоящие из цифр.

К примеру, у автора этой статьи номер аськи был 605 698 929 — девятизначный номер и совсем не крутой. Позже номер зачем-то угнали, а теперь номеров в ICQ и вовсе нет.

Крутым же считалось обладать шестизначным номером, поскольку это был самый короткий из возможных. Люди месяцами откладывали деньги для покупки шестизнака, после чего слонялись по чятикам и искали продавцов фразой «Куплю шестизнак!».

А по чему соскучились вы, чего никогда не поймут дети?

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

Затем девушка начала свой рассказ о том, что она использует компьютер для хранения важной информации. Например, какие продукты есть в холодильнике, номера телефонов и адреса людей.

Но самым «волнительным» она назвала возможность отправлять электронные письма. Именно тем, как это делать, закончился выпуск Database:

Источник: YouTube / Life Before

Игровой сервис Plex создан с помощью нового партнёра Parsec и его технологии потоковой передачи с низкой задержкой. Компания долгое время отказывалась от идеи добавления игр, но в 2020 году решила всё-таки запустить стриминговый сервис из-за личного интереса команды и необходимости отвлечься. К тому же технология, делающая его доступным, была уже построена на 95 %.

К сожалению для пользователей, из-за партнёрских и лицензионных сборов Plex Arcade не станет бесплатным дополнением. Действующие подписчики Plex Pass могут приобрести доступ к игровой платформе за 2,99 доллара в месяц. Для тех, у кого нет подписки, стоимость составит 4,99 доллара в месяц. Также предусмотрен бесплатный тестовый доступ на 7 дней.

Как это работает?

Один из участников проекта Джейсон Скотт (Jason Scott) заявил, что все программы проверены, однако при запуске некоторых возникают ошибки или некорректная работа. В частности, это касается игр, большинство из которых «заточены» под джойстик, поэтому они хуже работают с клавиатурой и мышью. К примеру, игра Space Invaders, по его словам, работает лишь иногда.

Для запуска используется бесплатный эмулятор VICE с открытым исходным кодом, который позволяет играть в классические игры в браузере. Для тех, кто живёт в США, есть вариант в виде современной реплики C64 Mini за 80 $.

Что ещё есть в Архиве?

На сайте размещены тысячи игр под MS-DOS, первые компьютеры Apple Macintosh, также есть аркадные игры с собственным эмулятором и так далее. Сборник программ под Commodore 64 — далеко не первый подобный проект.

Не только Архив Интернета занимается сохранением и эмуляцией старых программ. В Университете Карнеги — Меллона была разработана клиент-серверная система для запуска устаревших программ под названием Olive.

Как работает система?

Представить Olive можно с помощью схемы из 8 уровней. В самом низу находится железо настоящего компьютера, затем идет операционная система Linux, на которой запускается специальное ПО под названием VMNetX (Virtual Machine Network Execution). Благодаря этой программе пользователю необязательно хранить у себя виртуальную машину в полном объеме, включая ее жесткий диск. Вместо этого все необходимые файлы будут находиться на сервере, а передаваться будут только те, которые нужны в конкретный момент.

В качестве 4-го уровня выступает монитор виртуальных машин (гипервизор), позволяющий запускать несколько виртуальных машин одновременно. После этого идут эмуляторы старого железа и операционной системы, на которых уже запускается соответствующее приложение. В конечном итоге программе остается лишь предоставить данные в устаревшем формате.

Что способна запускать система?

Olive содержит 17 виртуальных машин, часть из которых создана для серьезных целей, а часть — для развлечения. Так, например, с помощью Olive возможно запустить игру Doom для DOS, которая вышла в начале 1990-х годов. Из прикладных программ можно выделить Microsoft Office 4.3, которая была выпущена в 1994 году, или Chaste, программу для моделирования сложных задач из биологии и физиологии.

Почему это важно?

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

Это не первый случай, когда энтузиасты пытаются запустить старые приложения на современных компьютерах. В конце августа 2018 года один из разработчиков мессенджера Slack выпустил Windows 95 в виде программы, которую можно запустить на Windows, Linux или macOS.

В нем можно запустить все стандартные программы, такие как WordPad, MS Paint и Minesweeper. К сожалению, Internet Explorer отказался загружать страницы. Желающие могут использовать приложение на компьютере: для этого необходимо скачать установочный файл, дважды кликнуть на него и пользоваться полноценной ОС.

Ностальгия периодически охватывает разработчиков, в результате чего в Сети появляется что-то интересное. В конце июля 2018 года Дилан Битти создал динамический типизированный язык программирования под стиль песен 80-х. На это его вдохновили не только лирические рок-композиции, но и менеджеры по персоналу, которые стремятся найти «рок-звезд» среди разработчиков.

The Amazing FishCam

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

Purple.com

Нельзя подобрать пример более «минималистичного» веб-дизайна, чем purple.com.

Как назвать свою группу

Архив для людей, которые не знают, как назвать свою рок-группу. Как на счет «Роющиеся карлики»? Занимательно? Да. Полезно? Ни капли.

Виртуальная рвота

Сайт-опросник, в котором вы заполняете таблицу о том, где вас последний раз тошнило и что вы ели перед этим.

Иллюстрированное руководство по крекерам

Сайт черно-белый? Как же узнать какой из крекеров с сыром?

Поисковая система ALIWEB

Сайт ALIWEB  считается первой поисковой системой в Интернете.

Информационный портал для малого бизнеса

Каталог сайтов для малого бизнеса ENTERWeb. Каждый желающий может добавить на него свои услуги. Только зачем?

Вам письмо (1998)

Возможно, вы помните фильм с Томом Хенксом «You’ve Got Mail». Так вот, этот сайт полон цитат из него и призывает вас к покупке видеокассеты.

Космический джем (1996)

Веб-страница, посвященная фильму с Майклом Джорданом «Космический джем». Глядя на него, начинаешь задумываться: «Неужели уже прошло 20 лет?»

Страница лучших новостей CNN за 1996 год

Небольшая страничка из 90-х, которая затерялась на серверах CNN.

А какие сайты, застрявшие в 90-х, знаете вы?

NeXTcube

Компания NeXT была основана Стивом Джобсом в 1985 году. Форма системного блока NeXTcube представляла из себя куб со стороной 30 сантиметров. Его аппаратное обеспечение было предназначено для работы в области бизнеса и науки. Он работал на ОС NeXSTEP и продавался в период с 1990 по 1993 годы.

Кстати, год назад мы составляли подборку необычных корпусов ПК, и если вы видели в Сети какой-нибудь крутой системный блок, который мы упустили, делитесь изображениями и видео в комментариях — мы добавим их в подборку.

Windows 3.1

В 1991 году Microsoft выпустила Windows 3.0. Именно после этого релиза IBM-совместимые ПК получили возможность соперничать с Apple Macintosh и Commodore Amiga. А вот и сама реклама, которую показывали по ТВ в 1991 году:

Compaq

Знаменитая за рубежом реклама Compaq 1990 года, которая гласит: “Он попросту работает лучше”:

486 With Zero Wait

Компания CSS Laboratories представила сервер под управлением серверной системы 486 с нулевой задержкой:

Logitech

Реклама мыши от Logitech с изменённым дизайном трекбола:

Commodore 128

Отличная реклама Commodore 128. К сожалению, компания объявила себя банкротом в 1994 году. Заголовок гласит: «Спасибо за воспоминания» (memory — англ. «память» или «воспоминание», игра слов).

Apple Power Mac G4

Apple также отличилась своей креативностью при создании слоганов. В 1999 году, к выпуску Apple Power Mac G4 они придумали ряд интересных слоганов вроде «Скорость света, подвинься» или «Подсказка: на постере действительно изображен компьютер»:

Сегодня, почти через 17 лет после выхода телефона в продажу, автор VentureBeat Эван Бласс (Evan Blass), известный публикациями о готовящихся к выходу устройствах, сообщил со ссылкой на источник в компании, что владелец бренда Nokia собирается объявить о перезапуске устройства на конференции MWC 2017 в Барселоне.

Телефон поступит в продажу по цене 59 евро (примерно 3500 руб. на момент написания новости) и будет позиционирован как почти неуязвимый телефон с долгим зарядом батареи. Несмотря на то, что телефон не выпускали в течение долгих лет, он до сих пор пользуется популярностью и продается в таких интернет-магазинах, как eBay и Amazon.

Помимо этой модели, на конгрессе будут представлены еще три модели смартфонов Nokia. Ожидается, что Nokia 3, 5 и 6 будут работать на Android 7.0 и продаваться по цене от 9 до 15 тысяч рублей.

Стоит отметить, что телефоны, продающиеся под брендом Nokia — это устройства не той же компании, что выпустила модели 3310, N95 и N-Gage. Авторские права на бренд были выкуплены финской фирмой HMD Global в декабре прошлого года.

Пентагон

В 1958 году министерство обороны США запустило компьютеризированную систему управления контрактами, предназначенную для отслеживания действующих контрактов и платежей. Она находится в эксплуатации и сейчас, 59 лет спустя.

Данная программа, названная MOCAS (Mechanization of Contract Administration Services), написана на языке COBOL. Изначально интерфейс MOCAS работал на перфокартах или ключ-картах. В последующие десятилетия программа была обновлена для работы с системой, которая широко использовалась в авиакомпаниях, туристических агентствах, и банках вплоть до недавнего времени.

Пентагон опасается менять эту систему на более современную, так как в данный момент она работает с 1,3 трлн. долларов в облигациях и 340 000 контрактами. Сейчас она запущена на мейнфрейме IBM 2098 модели E-10, который способен обрабатывать 398 млн. команд в секунду. Он имеет скромные 8 гигабайт ОЗУ и большое количество оборудования для хранения данных.

Перфокарты

Если отнестись к понятию “программное обеспечение” менее строго, то старейшим действующим ПО пользуется компания Sparkler Filters, производитель оборудования для фильтрации воды, которая была основана в 1927 году. До сих пор производство зависит от системы IBM 402 для инвентаризации (она была выпущена в 1948 году и работает на перфокартах), сортировщика IBM 83 и клавишного перфоратора IBM 129. IBM 402 даже не имеет памяти. Система программируется вручную через коммутационную панель, которую переключают в зависимости от задачи. По словам механика компании, в 2013 году фирма собиралась приобрести ПК, но по сей день так этого и не сделала.

Межпланетная программа

1972 год послужил началом самому долгому космическому исследованию. Вояджер-2, а затем и Вояджер-1 были запущены в 1977 году. Оба зонда продолжают отправлять данные на Землю из самых далёких уголков космоса. Оба корабля практически идентичны. Они используют три компьютера: один обрабатывает данные о полете, второй — компьютерные команды, а третий — следит за управлением.

Спустя 39 лет ПО Вояджеров всё ещё функционирует. Зонды имеют лишь 70 килобайт памяти, из-за чего программный код приходится менять на каждом этапе миссии. Однажды, в 2010 году, на Землю начали приходить искаженные данные. Дело было в одном бите, который поменялся с нуля на единицу. Программа была перезапущена и по сей день находится в эксплуатации.

На сайте можно написать исполняемый 6502-код и тут же запустить его, либо изучить любой из многочисленных образцов программ: например, можно увидеть код типичной таблицы результатов или реализацию стартовой заставки. Из более сложных примеров стоит отметить подобие арканоида и 3D-дорогу (на скриншоте выше).

На Stack Overflow был задан вопрос:

Почему во многих примерах кода (в частности, в руководствах) используются имена foo и bar? Например:void foo(char* bar) { printf("%s", bar);}

Вот лучший пользовательский ответ:

Foo и bar произошли от армейского акронима времён Второй мировой, FUBAR — “Fucked Up Beyond All Recognition” (англ. “Разбито в хлам”). Во время кампаний в Северной Африке и Сицилии (1942–1943) возникло целое семейство таких сокращений, которые можно найти в книге Рика Эткинсона Day of Battle: The War in Sicily and Italy, 1943-1944. Например, сокращение JANFU означает “Joint Army Navy Fucked Up” (англ. “Союз армии и флота облажался”), и применялось, в частности, для описания инцидента 11 июля 1943 года, когда британский флот сбил 23 транспортных самолёта США с десантом.

Вот описание Эткинсона (в оригинале):

Their pervasive “civilianness” made them wary of martial zeal. “We were not romantics filled with cape-and-sword twaddle,” wrote John Mason Brown, a Navy Reserve lieutenant headed to Sicily. “The last war was too near for that.” Military life inflamed their ironic sensibilities and their skepticism. A single crude acronym that captured the soldier’s lowered expectations — SNAFU, “situation normal, all fucked up” — had expanded into a vocabulary of GI cynicism: SUSFU (situation unchanged, still fucked up); FUMTU (fucked up more than usual); JANFU (joint Army-Navy fuck-up); JAAFU (joint Anglo-American fuck-up); FUAFUP (fucked up and fucked up proper); and FUBAR (fucked up beyond all recognition) [Atkinson, p. 36].

А вот ответ Википедии:

Термины foobar, foo, bar и baz часто используются как метапеременные в программировании или документации. В основном они означают неизвестные переменные, обычно в случаях, когда их цель известна, а значение не важно. Их используют в качестве названий переменных, функций, команд и т.д. Сами по себе они бессмысленны и являются простыми логическими представлениями чего-либо, как x и y в алгебре. Foobar обычно используется один, в то время как foo, bar и baz используются вместе и именно в таком порядке.

Вот что говорит RFC 3092:

Совместное использование вместе с “bar” берёт начало в сленге армии США времён Второй мировой войны в виде FUBAR (“Fucked Up Beyond All Repair”), впоследствии изменённом до foobar. Раньше считалось, это изменение было вызвано оцензуриванием аббревиатуры FUBAR, но похоже, что сама аббревиатура произошла от “foo”, возможно, под влиянием немецкого “furchtbar” (ужасный), то есть вероятно, что слово “foobar” было исходной формой.

Игра называется Donkey и предлагает игроку избегать столкновений с ослами на дороге, меняя свою полосу при езде на автомобиле. При столкновении происходит простенькая анимация взрыва. Исходный код на BASIC занимает всего 131 строку. Предупреждаем слабонервных, в нём активно используется GOTO (впрочем, в то время это было нормальным для BASIC).

Для тех, кто хочет потратить ещё больше своего свободного времени на ностальгию, вот ссылки на подходящие веб-эмуляторы:

• PC DOS во всевозможных конфигурациях;
• Apple II с загружаемыми дисками.

Эта игра входила в комплект поставки ранных версий PC DOS, распространявшихся с оригинальными IBM PC в то время. Сейчас в неё можно поиграть даже на iOS (искать по словам Donkey bas). Побробнее про историю игры можно почитать на Wikipedia.

Выпущенный в 1977-ом году «девайс» имел 4К RAM, процессор MOS 6502 с частотой 1MHz, встроенный кассетный привод и одну из худших клавиатур — «слепая» печать на ней была просто невозможна. Также пользователей частенько вводил в заблуждение 9″ дисплей, который с первого взгляда казался внешним монитором, но на самом деле был встроенным в корпус.

Не обошлось в ПК и без пасхалок: при вводе команды WAIT 6502 экран заполнялся надписью MICROSOFT. Говорят, эту «фичу» добавил лично Билл Гейтс после конфликта с основателем Commodore Джеком Трэмилом.

Несмотря на свои недостатки, PET был довольно популярен, особенно в школах и других учебных заведениях.

Возможно, все недостатки перекрывал низкий порог вхождения, простота использования и низкая по тем временам цена — «всего» $795 за устройство.

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

Для начала ему потребовался корпус от самого контроллера, который он смог достать на eBay. Внутрь решено было поместить Raspberry Pi Zero — модификацию одноплатного компьютера размером с банковскую карту стоимостью $5, залив в него прошивку RetroPie.

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

В итоге для игры нужно подключить только монитор (или современный телевизор) по mini-HDMI кабелю, а также внешнее питание по micro-USB. Прошивку для эмуляции популярных ретро-консолей пришлось несколько обновить, чтобы поддерживать кнопки, подключенные к GPIO-выводам Raspberry Pi, а также работу светодиода.

Подробнее о проекте можно почитать в оригинальном посте. Там же есть код и схема сборки для желающих собрать себе такую же игрушку.

По задумке разработчиков, коричневый корпус должен был стать имитацией кожи, хотя на деле он, скорее, напоминал тонкий пластик. Во время транспортировки клавиатура защелкивалась к передней панели компьютера. Вероятно, это должно было быть удобно, но на деле кабель от клавиатуры, который ничем не держался, свободно болтался и царапал всё вокруг. И, в конце концов, кто придумал назвать компьютер Zorba?

Как вы уже, наверное, догадались, продажи шли медленно и Zorba сняли с производства всего через год после релиза в 1982 году.

Но, скорее всего, причина провала была в другом — Zorba стал последним компьютером, который работал под управлением операционной системы от Intel под названием CP/M, которая вышла из моды с приходом MS-DOS и нового портативного компьютера Compaq Portable, который, естественно, работал под управлением MS-DOS.