Kurgan-Telecom Ru | Информационные технологии

13 февраля 2026 года ушёл из жизни 75-летний Хидэки Сато, легендарный инженер, а позже и топ-менеджер корпорации Sega. Именно он подарил миллионам миллениалов огромное количество впечатлений и тысячи часов за играми на приставке Sega Mega Drive — ибо Хидэки Сато был её главным разработчиком. При этом в самой Японии приставка не слишком «взлетела», оставшись в тени NES и SNES от Nintendo. А вот в США, Европе, а через пару лет и в России, уже Super Nintendo с большим трудом пыталась конкурировать с Sega Mega Drive, она же Sega Genesis на американском рынке. Как и почему Sega Mega Drive от Хидэки Сато и его коллег осталась вне Японии главной легендой 90-х среди 16-битных приставок?

Пролог: день, когда изменился рынок

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

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

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

В высоконагруженных системах балансировка трафика быстро перестаёт быть просто задачей распределения запросов. Сегодня на реальном опыте разбираем путь от BGP Anycast к L4-балансировке и XDP: зачем она понадобилась, как помогла справиться с ограничениями Anycast, повысить отказоустойчивость и производительность, а также почему балансировщик стал точкой входа для защиты от L4-DDoS. Статья будет полезна инженерам, которые проектируют и развивают инфраструктуру под высокий трафик и пиковые нагрузки.

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

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

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

«Я всегда отвечаю сразу: люди не должны меня ждать».
«Эту задачу лучше сделаю сам: так будет быстрее».
«Мне несложно отвлечься и помочь: тут дел на пять минут».

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

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

Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре) про шардирование и миграцию на YDB.

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

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

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

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

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

Именно поэтому в новом выпуске подкаста CrossCheck эксперты обсудили класс решений IDM (Identity Management) — система централизованного управления учетными записями и доступами.

Появляются результаты анализа образцов, доставленных китайской миссией «Чанъэ-6» с обратной стороны Луны. Они дают нам первое подробное представление о её геологии и истории, а недавняя статья, опубликованная в журнале Science Advances исследователями из Китайской академии наук, содержит очень интересные выводы об истории столкновений на Луне и даже в Солнечной системе в целом.

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

Мобильная разработка — довольно понятное направление в IT. Почти у каждого в кармане есть телефон с iOS или Android, и результат работы разработчика виден сразу: установил приложение — вот оно, работает. Ну, или не работает.

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

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

Команда «Нанософт» создала информационную модель исторического здания торговых рядов на Красногорской площади в Сергиевом Посаде Московской области. Здание, построенное в 1902–1903 годах по проекту А. А. Латкова в русском стиле, в 1920 году пережило пожар, а в 2014-м было полностью отреставрировано к 700-летию Сергия Радонежского.

На примере этой модели мы показываем, как создавать и настраивать пользовательские проемы в nanoCAD BIM Строительство – от базовых до более сложных методов.

Кому это будет полезно?

Архитекторам, конструкторам, руководителям проектов, студентам и всем, кто работает с nanoCAD BIM Строительство или изучает его, – для быстрого освоения программного продукта и решения реальных практических задач.

Привет, Хабр!
Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Несколько лет назад, пока облако росло, интеграционный слой между сервисами и брендами естественным образом усложнялся. Каждый новый сценарий требовал отдельного решения — и со временем стало понятно, что нужен общий подход.

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

Всем привет!

Я, Колядова Алиса, Senior дизайнер, работающая над B2B-системами внутри «одной из списка компаний, которые нельзя назвать».

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

Одной из самых важных задач медицины является не лечение заболеваний, а их предотвращение. Чем раньше будет проведена успешная диагностика, тем быстрее будут приняты необходимые меры, предотвращающие развитие заболевания. Проблема в том, что далеко не все недуги имеют выраженные и заметные симптомы на ранних стадиях, а когда они проявляются, то может быть поздно. К таким относится онкология, которая может долгое время развиваться, не давая о себе знать. Ученые из Университета Тунцзи (Шанхай, Китай) разработали световой датчик, способный обнаруживать чрезвычайно малые количества биомаркеров рака в крови пациента. Из чего сделан данный сенсор, как именно он работает, и насколько он точен? Ответы на эти вопросы мы найдем в докладе ученых.

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

Немного контекста. Когда в 2014 году компания Ли Цзяня установила себе планку «стать бизнес-школой мирового уровня», это звучало как шутка для своих. Рынок тренингов в Китае — поле боя без правил, конкуренция дикая, а продукт не тот случай, когда можно пощупать качество до оплаты. Но цифры говорят сами за себя: чистая прибыль 16,8 млн юаней в 2014-м, 38 млн в 2015-м, 68 млн в 2016-м, и за сотню в 2017-м. При этом 560 сотрудников делают выручку в полмиллиарда юаней. Даже в ковидном 2020-м, когда индустрию тренингов штормило так, что многих сдуло, Action Education умудрилась вырасти. Автор пишет об этом как о лабораторном подтверждении теории: работает.

На Хабре десятки статей про вайбкодинг. Есть переводы сравнений v0 vs Bolt vs Lovable, есть манифесты «вы всё проспали», есть личные истории «навайбкодил сайт за три дня». Но ни одной статьи, где кто-то берёт одно конкретное ТЗ и прогоняет его через все доступные AI-генераторы — западные и российские — с честными скриншотами результатов.

Я это сделал. Одна бургерная, восемь платформ, ноль иллюзий.

«На автотесты нет времени — релиз через неделю!» говорит зарубежная компания со штатом 500+ человек, зарплатами 5 000 €, баг-репортами по ISO. Разбираю, откуда берётся эта фраза, почему разработчики не могут объяснить бизнесу очевидное.

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

Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло.

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

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

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.