Программирование *

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

Прежде чем углубиться в детали, позвольте представиться. Меня зовут Анзар, я работаю фронтенд-разработчиком уже 9 лет, последние 3 из которых — в Ozon Tech, где я занимаю позицию тимлида. За это время я побывал на десятках, а может, и сотнях собеседований — и как кандидат, и как интервьюер. Кроме того, у меня за плечами многолетний опыт менторства и мне приходилось наблюдать, как различные факторы влияют на скорость роста. Все это заставило меня глубоко задуматься о системных проблемах найма разработчиков. Думаю, эта статья будет особенно полезна нанимающим менеджерам, рекрутерам и, возможно, HR-специалистам — она поможет пересмотреть подход к найму.

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

Задачи были такие: 1) проехать по известному «лабиринту» из двух комнат с фиксированными препятствиями, то есть запрограммировать фиксированный маршрут — кое‑кто бился над этим неделю и больше — но всё же решений около сотни; 2) проехать неизвестный лабиринт из стенок под прямыми углами — с этим справились вчетверо меньше команд; 3) проехать по змеевидной платформе, используя камеру глубины, и не упасть за край — мне известно примерно о двух с половиной решениях её.

Сейчас подробно рассмотрим какие были сложности и как с ними можно справиться. И да, организационные проблемы преследовали мероприятие до последнего дня, но об этом уже немало сказано, в том числе в сильных выражениях:) В любом это вне «фокуса» данной статьи. Сосредоточимся на задачах!

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

Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.

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

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

Поэтому важно создать надёжное решение классической задачи — двойного букинга.

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

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

Привет, Хабр! Модуль itertools мне известен многим вдоль и поперёк. Ну действительно, что там сложного? Пара функций вроде chain да product, и кажется, что ничего нового для себя уже не найти. Однако стоит копнуть глубже, и выясняется, что у itertools есть немало нюансов и даже новых возможностей, появившихся в свежих версиях. В этой статье рассмотрим многие функции itertools: от базовых до самых интересных.

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

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

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

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

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

Привет, Хабр!

«Давайте все будем на ассемблере писать. Зачем мы пользуемся фреймворками?» — эта фраза из недавней дискуссии о low-code платформах прозвучала как манифест. И она заставила задуматься: где граница между разумным использованием абстракций и откровенным vendor lock-in?

Коллеги устроили жёсткий разбор low-code платформ — без маркетингового глянца и дипломатии. Спойлер: никакой «серебряной пули» мы не нашли. Зато выяснилось, что low-code платформы прошлого и нового поколения — это принципиально разные вещи. И что конфликт между разработчиками и визуальным программированием — это на самом деле спор о том, как писать код в 2025 году, когда есть и мощные LLM, и микросервисная архитектура из сотен сервисов.

Привет, Хабр!

«Разработчики исчезнут, но не все» — когда я услышал эту фразу в дискуссии на канале Dev Q&A, она засела в голове надолго. Вот факт: за 10 лет средняя зарплата разработчика в России выросла с миллиона до 2,8 миллиона рублей в год. Стоимость часа работы — с $30-50 до $80-100, у крупных агентств доходит до $300-400. И это происходит как раз тогда, когда появились ИИ-ассистенты, low-code платформы и масса других инструментов, которые вроде бы должны всё удешевлять.

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

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

Привет, Хабр! На связи снова Сергей, ведущий фронтенд-разработчик из Центрального университета. В последнее время я преисполнился URL и опять хочу про него рассказать. 

В прошлой статье я рассказал о том, почему неправильно использовать URL API для валидации ссылок. В этот раз буду использовать инструменты по назначению. Речь пойдет про новый URLPattern API для сопоставления URL с шаблонами, который позволит валидировать ссылки без головной боли.

На Global Tech Forum в октябре 2025, я услышал историю от ИТ-директора компании Gulliver, производителя одежды. Он рассказывал, как инхаус команда 1С разработки автоматизировала процессы жизненного цикла продукта в группе компаний - от планирования коллекций, до размещения заказов в производства и учет реализации в сбытовую сеть. 

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

Пробуем собрать свой минималистичный starter-kit.

Туториал из трех частей.

В предыдущей части мы реализовали причудливый конфиг на webpack + собственный роутинг.

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

В следующей рассмотрим работу с web-компонентами.

В феврале прошлого года у интерфейса веб-серверов Rack, лежащего в основе практически каждого приложения Ruby on Rails, был обнаружен CVE-2024-26141. Уязвимость была простой: достаточно отправить запрос файла с сотней байтовых диапазонов, и Rack генерировал неожиданно большой ответ. Серверы продакшена можно было атаковать одиночными HTTP-запросами, пока у них не закончится ресурс памяти или канала.

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

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

Это третья статья в серии про DOM-подобные модели данных в различных языках программирования.

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

Сегодня мы проверим как с Card DOM справится С++.

Поисковая выдача по запросу «chrome extension for cheating in chess» переполнена. Инструментов для нечестной игры — десятки.

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

Удивительный дисбаланс, не правда ли?

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

Привет, Хабр! Меня зовут Дмитрий Овчаренко, я технический директор департамента разработки для финансового сектора IBS, более десяти лет создаю сложные ИТ-решения для лидеров рынка, а также преподаю в Учебном центре IBS.

Недавно мы провели внутрикорпоративный эфир Ask Me Anything («Спроси меня о чем угодно»). Коллеги могли задать любой вопрос о работе архитектора ПО. В этой статье поделюсь самыми интересными и неожиданными из них.

Аннотация. Статья посвящена анализу этически вызовов, возникающих при интеграции систем искусственного интеллекта (ИИ) в промышленность. На основе ключевых международных и национальных документов — Рекомендации по этике ИИ ЮНЕСКО, Спецификации этики искусственного интеллекта нового поколения Китая, Закона Европейского Союза об искусственном интеллекте и российского Кодекса этики в сфере ИИ — рассматриваются основные риски и принципы, которые должны лежать в основе проектирования, внедрения и эксплуатации промышленных ИИ-систем на всех этапах их жизненного цикла. Особое внимание уделяется вопросам безопасности, прозрачности, объяснимости и подконтрольности человеку промышленных ИИ-систем в контексте Индустрии 4.0.

Насколько популярные рейтинги соответствуют реальному спросу на рынке труда? Собрал данные о 150 000+ вакансий с hh.ru и других площадок. Результаты оказались неожиданными...