Бэкенд

Все мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?

Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?

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

Я решила отойти от субъективности и спросить у самого рынка. В этой статье — результаты анализа 700+ актуальных вакансий .Net разработчика, графы связности навыков и ответ на вопрос: в какой момент количество выученных библиотек наконец-то превращается в качество инженера.

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

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

В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).

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

Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:

Привет, Хабр! Когда-то совсем недавно я, (пока что) зеленый джун, узнал о таком интересном языке, как Brainfuck. Даже не языке, а так, "язычке", с 8 командами. 8-битные лимиты чисел (т.е. не может обрабатывать числа больше 255), а синтаксис и процесс кодинга такой, что и тимлид там ногу сломит. Увидев сие чудо 1993 года (динозавер), меня постигла безумнейшая идея провести один веселый вечер за компов, породив полноценный калькулятор, использовав BF-код для вычислительных мощей в своей забавной разработке. Но сначала давайте по порядку...

Всем привет!

Мы гордимся тем, с каким успехом и рвением выпускаем на русском языке крутую литературу по языку Rust. Мы занялись этим, когда Rust ещё далеко не был мейнкуном мейнстримом - и нашим первым (и сразу же очень успешным) заходом в тему была ныне легендарная книга Тима Макнамары "Rust in Action". Она вышла в издательстве "Manning" в 2021 году, а на русском языке мы выпустили первый тираж "Rust в действии" в ноябре 2022 года. Очередная допечатка закончилась к новому 2026 году, и мы решили разместить здесь переводную статью о книге для привлечения внимания к свежей допечатке (тираж ограничен!)

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

Команда Python for Devs подготовила перевод статьи о том, как можно компилировать Python в быстрые, кроссплатформенные исполняемые файлы без изменения исходного кода. Автор подробно разбирает архитектуру компилятора, объясняет, зачем «понижать» Python до C++, как типы позволяют «приручить» динамику языка и почему эмпирическая оптимизация даёт лучший результат, чем ручной тюнинг.

Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.

От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.

В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.

Нейросети и LLM перестали быть абстрактным трендом — это полноценный рабочий инструмент, который помогает IT-специалистам писать код, автоматизировать процессы, улучшать качество продукта и даже усиливать кибербезопасность. Умение использовать нейросети поможет повысить продуктивность и качество инженерной работы.

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

Шариковые мыши и забитая в них пыль, колоритные сайты с гостевыми книгами, форумы и мееееедленный выыыыход в Сеть. А главное — писк диалап‑модема. Мы собрались с коллегами Сlevertec и вспомнили, как это было. Вот наши истории.

Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы развиваем платформу объявлений и их характеристики.

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

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

Перевод второй части статьи «A pragmatic guide to modern CSS colours - part two».

Автор: Kevin Powell, 2 декабря 2025

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

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

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

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

В этих условиях привычные абстракции требуют переоценки.

Сегодня я хочу напомнить об одной из самых распространенных в Java — autoboxing — механизме автоматической упаковки примитивных типов в соответствующие объекты-обертки.

Приглашаю вас посмотреть на знакомый Java-код не глазами разработчика, а глазами JVM, сборщика мусора и процессора, и разобраться, как незаметные на уровне синтаксиса решения превращаются в аллокации, давление на GC и раздувание heap.

В .NET есть обширный набор типов для работы с временем. Но нет решения для работы с интервалами времени. Я такое решение сделал и хочу о нем рассказать.

4000 строк в одном MR. Три часа на ревью, 12 замечаний, исправления - ещё 800 строк. На четвёртом заходе я закрыл вкладку и понял: проблема не в коде, а в том, что никто не знал, что именно нужно было написать.

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

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

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

На прошлой неделе моё внимание привлёк этот коммит:

858d2e434dd 8372584: [Linux]: Замена чтения proc для получения CPUtime потока на clock_gettime

diffstat выглядел интересно: +96 вставок, -54 удалений. В changeset был добавлен бенчмарк JMH из 55 строк, что означало реальное уменьшение кода продакшена.

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

Типичная картина ИТ-хакатона: команды тратят время не на продукт, а на борьбу с инфраструктурой. Документация есть, API есть – а собрать реальный сценарий нельзя: балансы не сходятся, переводы не оставляют следов, ответы статичные или ошибочные.

На пятом юбилейном API-хакатоне мы решили сделать иначе – собрать песочницу, которая ведёт себя как настоящий банк. Даже не один, а содружество трёх банков с клиентами, продуктами и межбанковскими сценариями. В результате появились реальные мультибанковские прототипы и ~1.5 млн вызовов API за месяц.

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

Как безопасно и эффективно вызывать C-функции из Java? Благодаря Project Panama — новому API из OpenJDK — это стало возможно без использования JNI. 

В новом переводе от команды Spring АйО познакомимся с основами FFM API, посмотрим на запуск Hello World на C, роль jextract, и на то, как управлять памятью вне кучи JVM.

Всем привет!

Вчера я выпустил крупное обновление 1.0.0 для своей библиотеки async_yookassa — неофициального клиента для асинхронного взаимодействия с API ЮKassa. О том, что изменилось, зачем я вообще взялся её писать и почему официальный SDK может "убить" вашего бота — в этой статье.

Привет! Меня зовут Алексей Сидоров, я Python-разработчик в команде краткосрочной аренды в Домклик. В этой статье разберём, как и зачем проверять код миграций схемы БД и как написать свой линтер.

Open Source проект может быть технически отличным и при этом оставаться неизвестным. Всё прекрасно работает, но репозиторий не привлекает ни пользователей, ни контрибьюторов. Причина чаще всего не в качестве кода, а в том, как проект представлен на GitHub.

Сегодня я хочу разобрать проект Tgin (инфраструктурная прослойка для Telegram-ботов на Rust). На его примере я покажу, какие элементы репозитория реально влияют на интерес к проекту, где чаще всего теряются пользователи и контрибьюторы.