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

Наверное, каждый разработчик рано или поздно задумывается о том, что же происходит в операционной системе на уровне ядра. Для ОС на базе ядра Linux относительно простой точкой входа является написание своих модулей. Модули по своей сути — это драйверы устройств (символьные char device, блочные block device, сетевые network device и другие).

В книге Linux Device Drivers (LDD) подробно описано, как создать свой модуль ядра для интересующего класса устройств. Однако эта книга очень устарела, поскольку в ней рассматриваются случаи, справедливые для ядра версии 2.X.X. А в 2025 году третьему изданию Linux Device Drivers исполняется 20 лет!

На сегодняшний день большинство устройств используют ядра 5.X.X или 6.X.X, в которых многое изменилось. Так и появилась идея этой статьи — адаптировать информацию из LDD под современные ядра.

Под катом рассмотрим следующие классы устройств: char device, block device и network device.

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

Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».

Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».

Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же автор серии видео про его устройство.

Я продолжаю свой цикл статей на хабре про детали реализации питона. Сегодня я хочу рассказать, как tuple устроен внутри.

Под катом будет про: мутабельность кортежей (и планы по отмене такого поведения), дичь с ctypes, переиспользование памяти и другие оптимизации.

Ну и конечно – мое полное видео на полтора часа, где будет множество дополнительной информации о деталях работы VM.

Если вам такое интересно или целиком незнакомо – добро пожаловать!

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

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

▍ Навигация по частям

• Часть 1 < — вы здесь.
• Часть 2
• Часть 3
• Часть 4
• Часть 5

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

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

Меня зовут Евгений Грибков. Я ведущий программист в центре технологий VK. В этой статье мы рассмотрим одно из возможных решений создания скрипта перезаливки заданных таблиц из одной БД в другую на примере MS SQL.

Как разработчик я ежедневно сталкиваюсь с большим количеством данных, которые нужны для принятия каких‑либо решений. Логи, конфиги, данные профилирования, аналитические выгрузки из БД и даже сведения о том, когда был написан данный код — это всё данные. Иногда бывает достаточно посмотреть глазами, и картина станет ясной. Но чем больше данных, тем меньше помогает «метод пристального взгляда», и тем нужнее какие‑то инструменты анализа.

Иногда можно собрать нужную информацию, просто скомбинировав несколько линуксовых команд пайпом (cat data.log | grep … | awk … | sort | uniq -c | sort -r | head), иногда пригодятся электронные таблицы, иногда проще написать небольшую программку для анализа данных. Но когда я освоился с языком R и его экосистемой, то всё это стало ненужным.

«Работает — не трогай!» — знакомая фраза? Звучит как девиз стабильности. Но в наше время все меняется со слишком большой скоростью, а такой подход может стать настоящей ловушкой Джокера. Оставленный без внимания проект рискует превратиться из мощного инструмента решения проблем в неподъемный багаж, неспособный соответствовать новым требованиям.

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

Добрый день, уважаемые хабровчане! Я хочу поделиться с вами очень интересным проектом, над которым работал в последнее время.

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

Готовы? Тогда — вперед!

Внимание! Тяжёлые гифки под катом.

Как часто вы ловите ошибки в VBA?
А как часто вам приходится пытаться понять откуда ноги растут?

Если макрос состоит из одной процедуры, это немного другая история...
Но вот если у вас полноценный стек вызовов, когда:

Main() -> NestedSub1 -> NestedFunc -> NestedSub2 ... -> NestedSubN

как отловить, в каком произошла ошибка?

Окей, вы скажите "Поставим On Error GoTo Catch и в Catch: Debug.Print "Function name"", да?

А если эту функцию вызывают несколько разных Sub/Function, как понять в каком из них произошла ошибка?

Представляем вам реализацию игры в крестики-нолики на С с помощью одного вызова printf. Написана для участия в IOCCC в 2020 году.

echo AB> foo.txt
echo CD>> foo.txt

• Открываем foo.txt
• Записываем «AB»
• Закрываем foo.txt
• Открываем foo.txt
• Выполняем поиск на один байт назад от конца файла
• Считываем один байт
• Записываем «CD»
• Закрываем foo.txt

Недавно я ушёл из компании, где проработал почти три года на позиции тимлида. Сначала я руководил продуктовой командой, а затем UI-kit командой. В итоге я принял решение уйти и устроился на позицию senior фронтенд-разработчика в зарубежную компанию. Это было осознанное решение — выбрать именно роль разработчика. И спустя несколько месяцев я убедился, что поступил правильно.

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

Не могу подобрать идеального названия для этого явления, так что буду называть его просто «эффект Makefile». Эффект Makefile не назовёшь однозначно порочным — просто нужно иметь его в виду при проектировании инструментов и систем.

Суть эффекта Makefile сводится к следующему:

Работа с крупными устоявшимися кодовыми базами — один из самых сложных навыков, осваиваемых разработчиком ПО. Его невозможно практиковать заранее (нет, опенсорс не даст вам этого опыта). Личные проекты не научат этому, потому что они по определению маленькие и реализуются с нуля. Нужно уточнить, что когда я говорю «крупные устоявшиеся кодовые базы», то имею в виду следующее:

- От одного до десятка миллионов строк кода (допустим, примерно пять миллионов)

- Примерно от 100 до 1000 разработчиков, работающих над одной кодовой базой

- Первая работающая версия кодовой базы была выпущена как минимум десять лет назад

Я уже больше десятка лет работают с такими кодовыми базами. В статье я поделюсь теми знаниями, которые бы мне очень пригодилось в начале.

Всем привет! С помощью этой статьи хочу поделиться результатами своей работы по переводу книги Мартина Фаулера «Analysis Patterns». Все оригинальные части книги и диаграммы переведены, всё готово для чтения онлайн. Однако работа не завершена, потому что хочется ещё добавить комментариев, пояснений и примеры кода (которых по сути не было) от себя, после многих лет использования «шаблонов».

Книга «Аналитические шаблоны» была написана в 1997, однако, на мой взгляд (и не только) сохраняет актуальность и по сей день. По сути, Мартин в книге рассматривает как строить мета‑модели системы, т. е. такие модели, которые будут актуальны на очень долгое время жизни системы. Мета‑модели также заключают в себе очень многие возможности, которые система может поддерживать в теории без значительных концептуальных переделок. Если созданная мета‑модель достаточно корректна, то она может помочь провалидировать предположения и поставить\ответить на многие вопросы о системе.