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

Глава 1: мой коллега, программист

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

«Постой-ка. У меня появилась идея. Дай мне клавиатуру.»

Идея. Ага. Как у младенца появляется «идея» засунуть вилку в розетку. Я почти доделал нечто прекрасное; стройную, изящную логику, пронзающую сложность подобно ножу, режущему масло. И тут появился он — бьёт по клавиатуре, как будто она ему деньги должна, копипастит код-франкенштейн из комментария на StackOverflow, написанный последователем Дяди Боба в 2014 году.

Знает ли он, что делает наша система? Нет.

Прочитал ли он тикет? Разумеется, нет.

Ощущает ли он уверенность, когда безрассудно корёжит глобальное состояние? Разумеется, да.

В своей предыдущей статье [перевод на Хабре] я говорил о множестве недостатков C++, которые, по сути, устранил Rust. Благодаря этому код теперь легко использовать правильно и сложно использовать неверно. Я не говорил о безопасности по памяти, просто привёл пример того, что пользователь функции не может случайно поменять местами аргументы количества и цены.

На написание статьи меня вдохновил доклад Мэтта Годболта о том, как можно сделать интерфейсы C++ более надёжными: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Вам стоит его посмотреть!

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

Но так ли это?

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

После прочтения этой статьи вы хорошо поймете следующее:

• как работает цикл событий (event loop) в Node.js, включая все его фазы
• как Node.js выполняет JavaScript в одном потоке (single thread)
• как Node.js использует библиотеку libuv и внутренние API для обработки асинхронных операций
• почему знание работы цикла событий так важно для написания эффективного серверного кода

Понять, как JS работает "под капотом" в браузере (см. эту короткую 15-минутную статью), проще, чем понять устройство Node.js. В браузере нет сложных фаз и многослойных механизмов, как в Node.js.

Но почему в Node.js все устроено сложнее? Зачем столько фаз, которые так непросто понять?

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

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

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

Возглавляя бэкенд-команду витрины в KION, я, Леша Жиряков, постоянно балансирую между скоростью вывода фичей и стабильностью работы системы. Сегодня решил перевести абстрактные технические дискуссии в конкретные цифры. А еще — поделиться расчетами, которые помогут принять экономически обоснованное решение: что выбрать для следующего проекта — Python или Java?

Привет! Меня зовут Газимагомед, я разработчик в PaaS-направлении Авито. Я прочитал книгу Ваутера Грунефелда «Креативный программист» и в этой статье рассказываю о своих впечатлениях. В тексте я сделал сжатый разбор всех глав книги, разобрал семь рекомендуемых автором качеств креативного программиста и провел параллели с собственным опытом.

Всем привет! Представляю вашему вниманию перевод статьи «Coding without a laptop — Two weeks with AR glasses and Linux‑On‑Android». Перевод сделал человек с помощью мозга, а не LLM.

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

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

Представьте: вы — инженер-программист из 60-х. Ваш код — это дикие прерии, где goto прыгает через функции как ковбой через барную стойку, а память — ваше личное ранчо. Вас внезапно переносят в 2023 год. Вас окружают фразы вроде «SOLID», «иммутабельность», «реактивные потоки». Вы пытаетесь написать пару строк на Python, но слышите: «Стоп. Мутировать переменные? В 2023-то? Это же грех!».

Что случилось с нашей свободой?

За последние 70 лет программирование из искусства постепенно превращалось в ремесло со своими жёсткими требованиями и правилами. Мы больше не взламываем реальность — мы строим мосты по ГОСТу.

Stack Overflow, некогда главная платформа для программистов, переживает кризис: за два года трафик упал почти на 90%. Что стало причиной — изменившиеся привычки пользователей или ошибки самой платформы? Давайте попробуем разобраться в происходящем. А еще посмотрим, что администрация делает для спасения и что ждет сообщества разработчиков в новой реальности, где ответы на вопросы находятся быстрее, чем успеваешь их задать.

Сегодня Java исполняется 30. Три десятилетия — это эпоха. За это время технологии успели смениться кардинально, а некоторые модные языки — появиться, поиграть мускулами и тихо исчезнуть. А Java по-прежнему тут. Она не просто "ещё жива" — она стабильно занимает лидирующие места в рейтингах, используется в крупнейших корпорациях и продолжает эволюционировать. Как так получилось?

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

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

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

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

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

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

Ещё пару лет назад моим основным стеком были: бутылка "Балтики девятки", пакет из «Пятёрочки» и лежание на скамейке под обновления погоды.

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

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

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

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

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

Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...

Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?

Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.

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

Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?

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