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

Представьте: вы — инженер-программист из 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, но хотят выйти за рамки базовых практик. Мы не будем обсуждать синтаксис или настройку конфигураций. Вместо этого сосредоточимся на стратегиях, которые помогут:

Показанным ниже кодом вы можете проверить на високосность год в интервале 0 ≤ y ≤ 102499 всего примерно тремя командами CPU:

bool is_leap_year_fast(uint32_t y) {

return ((y * 1073750999) & 3221352463) <= 126976;

}

Как это работает? Ответ на удивление сложен. В статье я объясню процесс; в основном он связан с забавным битовым жонглированием. В конце мы обсудим применение этого кода на практике.

Названия музыкальных произведений, которые проигрываются на радиостанциях, можно получать прямо из радиоэфира с помощью radio data system (англ. Radio Data System, RDS). Представим ситуацию, когда из радиоприёмника играет музыка, которая очень понравилась, и стало интересно кто её автор. Конечно, можно "зашазамить", но ведь это не наш метод. Интереснее будет взять микросхему si4735 и подключить её к Arduino. Почему бы и нет. Есть хорошая библиотека SI4735. При таком подходе самым сложным будет качественно оформить устройство в корпусе с кнопками для изменения частоты и громкости, а ещё дисплеем и батареей, чтобы устройство было автономным. Далее будет описан способ с использованием Flipper Zero и созданием простого шилда для него. Тогда не надо терять время на кнопки и дисплей, но нужно немного потрудиться и перенести программную часть на Flipper Zero.

Работа с микросхемами SI473x очень хорошо описана в статье журнала Хакер. Всё, что там написано, проверено и работает. Но там нет работы с RDS. Так что эту статью можно считать просто продолжением той статьи в части работы с RDS.

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

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

Нас ждёт мозговыносящая смесь 64/32-битного ассемблера и старого-доброго C++. Мы сделаем собственную реализацию... Волокон (fibers) без вызова Win API и звонков в службу спасения.

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

Дональд Кнут (с)

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

Материал статьи предоставлен Владимиром Пинаевым

За годы работы я подробно изучил, как центральные процессоры (CPU) выполняют код и как они устроены внутри. Дело в том, что я участвовал в разработке ядра Linux и ScyllaDB, а этот код очень близок к металлу. Я даже немного баловался с Verilog, безрезультатно попытавшись собрать моё собственное ядро RISC-V.

Графические процессоры (GPU) в отличие от обычных в основном оставались для меня чёрным ящиком, несмотря на то, что поработать с ними всё-таки довелось. Помню, что экспериментировал с NVIDIA RIVA 128 или чем-то подобным, проверяя, как там работает DirectX. Тогда такие процессоры ещё не выделялись на фоне ускорителей 3D-графики. Я также пытался идти в ногу со временем и немного упражнялся в программировании элементарных шейдеров на современных GPU. Но я никогда глубоко не вдавался в работу с GPU, и мои взгляды можно назвать CPU-центричными.

Однако, поскольку сегодня наблюдается всплеск рабочих нагрузок, связанных с ИИ, и, в частности, приходится работать с большими языковыми моделями (БЯМ), графические процессоры становятся незаменимыми для современных вычислений. К задачам, решаемым с применением ИИ, относятся масштабные прикладные тензорные операции, в том числе — сложение и перемножение матриц. А это уже работа для GPU. Но как современный GPU выполняет их, и насколько при этом возрастает эффективность по сравнению с выполнением таких же рабочих нагрузок на CPU?

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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