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

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

Меня зовут Артем Лакомов, я филолог из МГУ. Да, вы не ослышались. И сегодня я хочу поговорить с вами о самой главной (и самой дорогой) боли в IT, но с совершенно неожиданной стороны.

Каждый из вас хоть раз в жизни видел код, от которого хотелось плакать или же тихо ненавидеть свою работу. Код с переменными вроде data, res, temp. Код, где есть один гигантский класс, который делает абсолютно всё, и коллеги с любовью (или ужасом) называют его godObject.

Все привыкли думать, что это просто «плохой стиль» или «технический долг». Но что, если я скажу вам, что это — не техническая, а языковая проблема? И что у монструозного godObject гораздо больше общего со школьным прозвищем «Толстый», чем вы думаете?

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

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

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

Если вам интересно, давайте попробуем разобраться вместе.

Вам когда-нибудь хотелось создать собственный системный вызов? Может быть, вы получали такое домашнее задание, пытались сделать это из интереса или просто для того, чтобы узнать что-то новое о ядре. В любом случае, системные вызовы – крутая штука, чтобы подробнее разобраться в Linux.

Недавно я написал Space Invader Generator в рамках соревнований по кодингу Creative Coding Amsterdam. Разумеется, я сделал это ради развлечения... но и для господства над галактикой тоже! На скриншоте показано, как он выглядит, а в посте я объясню, как он работает.

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

Сегодня в сети есть много дискуссий о мессенджере Макс. Недавно я наткнулся на один пост в гитхабе с анализом Android-приложения, где приводятся страшные выводы о слежке за пользователями. Поскольку интерес к этому вопросу лично у меня велик, я решил разобрать важный файл приложения — его AndroidManifest.xml — и проверить факты. 

Сам по себе AndroidManifest.xml — это своеобразный декларативный контракт приложения с Android: в нем зашиты его идентичность, модель доступа, поверхность атаки, аппаратные и сетевые зависимости, а также внешние взаимодействия. По одному этому файлу уже видно, к каким данным приложение может проситься, что оно имеет право делать в фоне, какие входные точки открыты наружу и под какие правила безопасности платформы оно подпадает. Манифест задает границы возможностей и рисков, а код и выданные пользователем разрешения решают, воспользуется ли приложение этими возможностями.

Это первая статья из планируемой серии про succinct data structures - класс наиболее компактных структур данных. Канонический пример такой структуры - это представление дерева в виде правильной скобочной последовательности, дерево извершин таким образом представляется с помощьюбит в то время как типичная динамическая реализация требовала бы как два указателя по 64-бит на каждый узел (разумеется можно немного сократить простыми оптимизациями, но даже близко 2 бита не получить). Фундамент подобных структур - это rank-select словарь, представляющий собой битовый вектор и дополнительную структуру для выполнению двух операций ранг и селект. В указанном примере с деревом с помощью ранга и селекта можно сделать базовую навигацию: найти номера потомков/родителей, узнать размер поддерева. В статье расскажу как делать эти операции быстро используя при этом всего 3,6% дополнительной памяти.

Привет! Я — Александр Дудукало, автор базового курса по JavaScript. В этой статье мы продолжим изучение работы с данными в JavaScript. Если в прошлом материале мы говорили о массивах, то теперь пришло время познакомиться с объектами. Я расскажу, как они помогают эффективно организовать и обрабатывать связанные данные. Подробности под катом!

Здесь не будет песен и сказок о том какой крутой и недооценённый язык Forth:) По совокупности обстоятельств он скорее уже история. Однако некоторые связанные с ним аспекты поучительны и перспективны (например, для энтузиастов и разработчиков языков и компиляторов) — и хочется их записать на память, да и поделиться с коллегами.

-

Я устроился в Apple в октябре 1995 года. В это время Apple кружилась в сливном отверстии раковины, готовясь отправиться в канализацию. Возможно, вы помните все эти разговоры о том, что Apple скоро закроется. Немного странно, что она продолжала нанимать сотрудников, но, очевидно, в Apple считали, что им всё равно нужен ещё один «графический инженер» для работы над технологией QuickdrawGX. Тогда мне был 31 год, я жил в Канзасе и программировал игры для Macintosh. Разумеется, в компании решили, что я хорошо подойду на эту должность.

Процесс собеседования оказался для меня совершенно неожиданным и новым (подробно о нём написано здесь), но в конечном итоге мне предложили работать графическим инженером QuickdrawGX в Apple Computer, Inc.

Переезжать с моей девушкой, всеми вещами (и двумя кошками) из Канзаса в Калифорнию было безумно сложно, но мы справились. Как окажется позже, мне предстояло ещё многое узнать о программировании, да и о профессионализме в целом. И тут я сразу понял, что, возможно, взялся за задачу, которая мне не по зубам (как программисту). Другие инженеры Apple были дружелюбными, но и очень умными. (Наверно, мне стоит подробнее написать о панике, которую я ощущал первое время; казалось, будто я случайно забрёл в глубокую часть бассейна.)

Впрочем, постепенно (примерно через полгода) я, так сказать, вошёл в колею, и начал справляться с работой немного увереннее. Но вскоре я всё равно понял, что по-прежнему остаюсь недисциплинированной деревенщиной, не совсем отвечающим стандартам Профессиональной Корпорации™.

Вскоре после моего прихода в компанию проект QuickdrawGX расценили провалившимся, меня перевели в новую команду (ColorSync) и чуть позже выдали новый проект. У Apple было стандартное окно, в котором пользователь мог выбирать цвет, оно называлось Color Picker («Палитра»). Кроме того, в то время Apple начинала переход с чипов Motorola 68K на новые, более быстрые чипы PowerPC (PPC). Моя задача заключалась в том, чтобы проект Color Picker, написанный для чипов 68K, компилировался для новой архитектуры PPC.

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

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

TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.

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

Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.

Не торопитесь пролистывать эту статью. Я не собираюсь, подобно множеству других статей на Хабре, рассказывать о плюсах или минусах вайб-кодинга и сравнивать это с плюсами и минусами традиционного программирования. Потому что сравнивать нечего, ведь не случилось ничего такого, что бы как-то значительно изменило ситуацию. По сути, я буду говорить о том же, о чём говорил в предыдущей статье ( https://habr.com/ru/articles/938028/ -Михаил Елисейкин «IT-лягушка и новая нормальность» ) - о том, что мир меняется, а наши о нём представления от этих изменений отстают.

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

Привет! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этой статье расскажу, как стрелочные функции помогают сокращать записи функций, делают код визуально чище и как использовать их без потери смысла. Также покажу, чем обычные функции проигрывают стрелочным и почему одно нельзя заменить другим.

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!

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

Всех, кто заинтересовался — прошу под кат.

Привет! На связи  Леша Жиряков, руководитель направления backend-команды витрины онлайн-кинотеатра KION. Сегодня хочу рассказать о горячем пирожке от Astral Software. Если вы следите за экосистемой Python, то наверняка знаете Astral по их хитам вроде ruff и uv. Теперь они выпустили pyx — реестр пакетов для Python, который обещает упростить жизнь разработчикам, особенно в проектах с машинным обучением и большими зависимостями. Давайте разберемся, что это за проект такой, почему стоит обратить на него внимание и как его использовать на практике.

Показываем на практике, как с помощью ChatGPT можно за несколько минут преобразить реально существующие фрагменты легаси-кода на Python.

На фоне общего хайпа вокруг ИИ холодным душем стали июльские результаты исследования METR о том, как LLM замедляют работу опытных разработчиков в опенсорсных проектах. Напомним, что использование LLM увеличило время выполнения задач на 19%, хотя сами разработчики ощущали противоположный эффект.

Учёные затруднились объяснить причины когнитивного искажения.

Факт в том, что многим разработчикам очень нравятся их инструменты для автодополнения и генерации кода, особенно Claude Code. Он настолько удобен, что от него буквально возникает зависимость. По опросам, чем больше люди используют такие инструменты — тем больше им нравится. Код «магически» генерируется сам собой, зачастую даже корректный.

Но это не обязательно улучшает или ускоряет разработку.

Более того, есть признаки, что в 2025 году наконец-то наступило некоторое охлаждение ожиданий в отношении к LLM.

Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений.

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

Под катом – анимация, демонстрирующая сборку приложения для macOS в режиме реального времени:

Я расскажу, как она получилась, но для начала обрисую контекст этого проекта.

Компиляция конкретного софта может быть очень длительной просто потому, что в этой программе очень много кода — как, например, в проекте LLVM. Но бывает и так, что сборка идёт медленно по глупым и вполне устранимым причинам. Подозреваю, что большинство сборок просто тормозят из-за ерунды, но проверить это мне пока не удавалось. Поэтому я разработал кроссплатформенный инструмент для визуализации сборок (пока он существует в приватной бета-версии, ссылка в конце статьи). Он работает с любой системой сборки и с любым языком программирования (а не только C/C++/Rust).

Вероятно, вам уже попадались подобные руководства по CUDA: хрестоматийный пример «Hello World», в котором перемешан код для ЦП и графического процессора. Всё это сложено в один гетерогенный файл с исходниками на CUDA C++, а для запуска ядра применяется синтаксис NVCC с тройными угловыми скобками <<<>>>, который уже стал культовым:

Всем привет! Недавно я вновь сменил свою основную LLM-модель. Долгое время пользовался Claude, потом перешел на ChatGPT, затем на Gemini, и вот я опять оплатил Claude и снова отменил подписку. Почему? Потому что Gemini, который поначалу казался невероятно мощным, в какой-то момент просто перестал справляться с моими основными задачами, а до этого так же сделал Claude и ChatGPT. Они стали лениться, игнорировать части промпта и выдавать поверхностные ответы.