TLDR: ИИ — это не ваш помощник, а разработчик-джун, имитирующий профессионализм. Доверяйте ему на свой страх и риск.

Я уже четыре дня занимаюсь своим хобби-проектом. Я был уверен, что реализую его. У меня был хороший план и большой интерес к проекту. Позвольте мне познакомить вас с Deskthang. Это настольный уведомлятор. Во время работы я хочу оставлять свой телефон в другой комнате и получать только важные уведомления. В случае сбоя конвейера развёртывания я хочу, чтобы устройство на моём столе загоралось красным и показывало мне логотип gitlab. Я не хочу, чтобы мне приходилось проверять телефон, почту или другие источники, которые могут отвлечь от работы.

Вы когда-нибудь хотели узнать, как работала предварительно вычисленная видимость в Quake? Я хотел, поэтому написал программу vis.py, воссоздающую этот алгоритм на Python. В этой статье представлена вся информация, необходимая для понимания vis, — инструмента, применявшегося в Quake, Half-Life и играх на Source Engine.

В процессе разработки Quake возникла проблема перерисовки (overdraw), то есть многократной записи одного и того же пикселя во время рендеринга кадра. Видимым остаётся лишь последний цвет, а все предыдущие записи оказываются лишней тратой ресурсов. Это плохо, если в вашей игре используется программный рендеринг, и так выжимающий последние соки из компьютера середины 90-х годов.

Как снизить объём перерисовки? Давайте начнём с высокоуровневого обзора возможных решений.

После выпуска ChatGPT в ноябре 2022 года количество задаваемых на StackOverflow вопросов стало быстро снижаться, и в 2025 году падение продолжается с угрожающей скоростью. Свежие данные, представленные разработчиком ПО Теодором Смитом из 1% лучших контрибьюторов StackOverflow, показывают, насколько плоха ситуация.

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

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

В своей работе я больше склоняюсь к стилизованной картинке, однако полученный в статье результат можно будет адаптировать и для реалистичного стиля/PBR. В этом посте мы поговорим о шейдере воды, относящемся к береговой линии, не касаясь материала песка и других деталей воды, например, преломления и каустики (о них можно прочитать в Water Shader Breakdown или по другим ссылкам в разделе Water на странице Resources). Впрочем, шейдер выполняет и смешение прозрачности/альфы, чтобы затенить материал под ним для симуляции мокрого песка.

Мы поговорим о двух способах наложения волн в сцене: при помощи текстуры глубин и ручных UV. Ниже я перечислю замечания, плюсы и минусы каждого способа. В последующих разделах мы поработаем над ними по очереди.

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

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

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

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

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

Одна из моих целей на 2025 год — создание завершённой игры. Завершённой, то есть её можно будет купить в Steam или App Store за $2,99 или около того. Я уже делал маленькие игры, но завершение и выпуск игры, вероятно, будет самым крупным моим проектом (если не считать блога).

В зимние каникулы я какое-то время писал прототипы игр на LÖVE — фреймворке для создания 2D-игр на Lua. Таким образом я хотел изучить инструменты разработки игр, подходящие к моему набору навыков, и определить свои сильные стороны, чтобы в 2025 году распоряжаться временем эффективно.

До работы над этими прототипами я написал примерно двести строк кода на Lua, но у меня не возникло никаких проблем в освоении нужного мне синтаксиса.

Оказалось, что API LÖVE простой и мощный. Одно из преимуществ использования фреймворка вместо игрового движка в том, что я могу показать вам полный пример всего в десяти строках кода (в отличие от игрового движка, где пришлось бы определять объекты сцены, прикреплять скрипты и так далее).

В праздничные выходные мне пришло в голову, что я давно не занимался чем-то бессмысленным. Представляю вашем вниманию... Regex Chess: набор из 84688 регулярных выражений, которые при выполнении по порядку генерируют ход (валидный, то есть не совсем ужасный) для переданного в качестве входных данных состояния шахматной доски. [Прим. переводчика: здесь в оригинале статьи есть интерактивный виджет, позволяющий сыграть с движком.]

Вот вся программа, которая делает ходы против игрока (серьёзно, я не шучу, она действительно такая короткая):

let regex_list = [/* очень длинный список регулярных выражений */]
let board = "rnbqkbnr / pppppppp / 8 / 8 / 8 / 8 / PPPPPPPP / RNBQKBNR w KQkq - 0 1";
for (regex of regex_list) {
board = re.replace(regex.pattern, regex.target)
}
display(board)

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

^{* Снобы могут заявить что-то типа «Вы сказали, что будете использовать регулярные выражения, но они не регулярные!" Но меня это не волнует.}

Как всегда, код проекта выложен на GitHub.

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

Давайте исследуем одну загадку: как Bethesda смогла сделать такие грибообразные облака ядерных взрывов?

Я ненавижу код бенчмаркинга, как и любой другой человек. Гораздо веселее притвориться, что твоё кэширование значения увеличило производительность на 1000%, чем проверять это тестами. Увы, бенчмаркинг JavaScript по-прежнему необходим, особенно потому, что JavaScript используется (когда не должен?) во всё более чувствительных к производительности приложениях. К сожалению, из-за множества базовых архитектурных решений языка, JavaScript никак не упрощает выполнение бенчмаркинга.

Деление — достаточно затратная операция. Например, на CPU Cannon Lake задержки 32-битного деления находятся в интервале 10-15 тактов, а на Zen4 — 9-14 тактов. Задержки 32-битного умножения на обоих CPU составляют 3-4 такта.

Ни в одном из популярных ISA SIMD (SSE, AVX, AVX-512, ARM Neon, ARM SVE) нет целочисленного деления, оно есть только в RISC-V Vector Extension. Однако во всех этих ISA есть деление с плавающей запятой.

В этой статье мы представим два подхода к реализации SIMD-деления 8-битных беззнаковых чисел.

Нашего клиента донимали отчёты о вылетах, показывавшие, что его программа ломается на самой первой команде.

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

Миф о RAM — это верование о том, что память современного компьютера напоминает идеальную память с произвольным доступом. Кэш люди считают оптимизацией для малых данных: если они умещаются в L2, то будут обрабатываться быстрее; если нет, то тут уж ничего не поделаешь.

Вероятнее всего, что самым быстрым разбиения данных будет такой код (я использую в качестве псевдокода Python; можете представить, что я пишу это на вашем любимом низкоуровневом языке):

groups = [[] for _ in range(n_groups)]

for element in elements:

groups[element.group].append(element)

Он и в самом деле линеен (то есть асимптотически оптимален), и мы всё равно должны выполнять доступ к произвольным индексам, так что кэш здесь нам ни в чём бы не помог.

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

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

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

«Очевидный» выбор для этой задачи — Python, но Python API не так уж чудесен, а из-за динамической типизации мне понадобится слишком много времени на отладку. Поэтому я попробовал Java. Я знаю её API назубок; по крайней мере, то, что касается коллекций, файлов, regex и так далее. Java статистически типизируемая, поэтому я защищён от глупостей ещё на ранних этапах кодинга. А её среды разработки просто потрясающие.

Что вы говорите? Действительно ли я хочу создавать отдельный файл POM и иерархию src/main/java для каждого скрипта? Хм.

Нет, я этого не делаю. К счастью, современная Java и её инструменты этого не требуют. Давайте разбираться!

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

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

Всё вроде должно быть просто

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

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

В последнее время я думала о том, что всё, происходящее в терминале — это та или иная комбинация

Работы операционной системы

Работы шелла

Работы эмулятора терминала

Работы той программы, которая у вас запущена (например, top, vim или cat)

Первые три (операционная система, шел и эмулятор терминала) — это достаточно известные переменные: если вы пользуетесь bash в GNOME Terminal Linux, то можете более-менее представлять, как всё это взаимодействует, а часть их поведения стандартизирована POSIX.

Но четвёртый элемент («программа, которая у вас запущена») как будто бы может делать ЧТО УГОДНО. Как узнать, что будет из себя представлять поведение программы?

Пользователи играют в игры на устройствах с разными размерами экранов, так что при разработке игр очень важен адаптивный пользовательский интерфейс (User Interface, UI). Продуманный адаптивный UI обеспечивает идеальный внешний вид на любом экране. В Godot Engine есть широкий выбор настроек и нодов, упрощающих создание адаптивного UI.

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

Sega Channel — это сервис games-on-demand, предоставлявший абонентам кабельного телевидения ежемесячный доступ к библиотеке из примерно пятидесяти игр для Sega Genesis за помесячную оплату (обычно 10-15 долларов, в зависимости от поставщика услуг кабельного телевидения). Он работал с июня 1994 года (общий доступ по всем США включили в декабре 1994 года) по июнь 1998 года. Абонентам предоставлялся картридж-адаптер, подключавший их консоль Genesis к линии кабельного телевидения. При включении консоли картридж искал сигнал Sega Channel, а затем скачивал меню игр. Этот процесс обычно занимал примерно двадцать секунд. Затем пользователь выбирал игру и примерно минуту ждал, пока она загрузится в ОЗУ адаптера. Далее игра работала точно так же, как картридж из магазина. Отключение системы или нажатие кнопки меню на адаптере удаляло скачанную игру, но данные сохранений игры оставались в нём, пока пользователь не скачивал другую игру. Наряду с продававшимися в рознице играми в Sega Channel был раздел «Test Drives», в нём пользователи могли играть в урезанные по времени или контенту версии игр, которые позже выпускались в розничную продажу. Кроме того, было несколько игр, доступных только через Sega Channel, хотя по большей мере это были проекты, в качестве которых Sega или издатель были не уверены, а потому не хотели выпускать их на физических картриджах. Успех Sega Channel был довольно умеренным, на пике популярности на него были подписаны примерно 250 тысяч абонентов.