Пути файловых систем в Windows страннее, чем можно подумать. В любой производной от Unix системе пути на удивление просты: если нечто начинается с /, то это путь. Но всё совершенно иначе в Windows, которая имеет озадачивающее разнообразие схем составления пути.

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

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

Всё началось с, казалось бы, обыденного изменения в моём домашнем сервере для хостинга бэкапов Time Machine: я хотел, чтобы он уходил в сон, когда находился в состоянии простоя, и пробуждался при необходимости. Уход в сон при простое — кажется, в Windows эта функция встроена с Windows 98? Насколько сложно будет это настроить на современной версии Ubuntu?

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

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

В статье приведены примеры в Shader Graph, однако есть и ссылки на документацию Shader Graph (Node Library), где можно просмотреть сгенерированный код на HLSL.

Эти методики могут использоваться в следующих случаях:

• Цвета игроков/команд, например, в RTS или в многопользовательских командных играх, или для изменения внешнего вида игрока.
• Вариации цветов на пропсах окружения, растительности/листве, вариантах врагов и так далее.
• Настраиваемые цвета и линейные градиенты, применяемые для VFX/эффектов частиц.
• Заменяемые цвета палитры для пиксель-арта (спрайтов/карт тайлов). Могут использоваться для эстетики или связаны с геймплеем.
• Эффекты постобработки, но это уже выходит за рамки моего поста.

Обычно в таких методиках в качестве входных данных используются какие-то текстуры (однако некоторые могут работать с шумами или процедурными формами, созданными из функций расстояний со знаком). Кроме того, неважно, будут ли использоваться текстуры для 3D-модели, 2D-спрайта, UI и так далее.

Задаётесь вопросом, стоит ли использовать GraphQL в своём проекте? Ваши разработчики спорят, выдвигая аргументы типа «GraphQL — это будущее» и «REST проще»? Мы с моей командой обсуждали эту тему бесконечно. В статье я приведу краткие выводы.

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

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

Конкретная реализация вектора сброса в системах x86 со временем менялась, но, по сути, это всегда были 16 байтов ниже верхушки адресного пространства, то есть 0xffff0 на 20-битном 8086, 0xfffff0 на 24-битном 80286 и 0xfffffff0 на 32-битном 80386. По стандарту в системах x86 ОЗУ начинается с адреса 0, поэтому верхушку адресного пространства можно использовать для размещения вектора сброса с минимальной вероятностью конфликта с ОЗУ.

Я много слышал о формате данных классического Doom, поэтому решил написать код на Rust для извлечения его карт и преобразования в векторную графику для лазерной резки.

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

Первый пункт руководства по разработке электронной почты MailChimp гласит: «Кодируйте всю структуру при помощи элемента table». В рекомендациях Cerberus (вероятно, самого популярного шаблона HTML-писем) говорится: «В случае сомнений встройте ещё одну таблицу». Прогресс не дошёл даже до структур на основе float. Кодинг электронной почты — это коллекция обходных путей, хаков и устаревших неподдерживаемых HTML-элементов.

Он долго был Диким Западом несогласованности, для решения задач на котором требовались тайные знания. Изучив таблицу поддержки на сайте look Can I Email (это аналог Can I Use для электронной почты), ты понимаешь, что клиенты электронной почты очень сильно различаются. Создание электронного письма для Apple Mail, Hey, Fastmail, Outlook for Mac, Proton Mail или Mail.ru не сильно отличается от кодинга современной веб-страницы. Однако, например, Yahoo Mail даже не поддерживает фоновые градиенты. Но гораздо сильнее, чем какой-либо иной клиент, электронной почте не давал вырваться из прошлого Outlook для Windows.

Этот пост будет довольно сумбурным. Несколько месяцев назад я написал Hard Mode Rust, исследуя стиль программирования allocation-conscious. В последовавшей дискуссии @jamii упомянул TigerBeetle — распределённую быструю и маленькую базу данных, написанную на Zig в схожем стиле. И теперь я после шести лет работы с Rust пишу на основной работе на Zig. В этом посте я вкратце объясню, почему так получилось. Подчеркну, что это не уравновешенное и тщательное сравнение двух языков. Для этого я ещё не написал свои 100 тысяч строк на Zig. (Если вы ищете ответ на более общий вопрос «что же такое Zig?», то рекомендую пост @jamii).

На самом деле, этот пост будет в основном посвящён не языкам, а стилям написания ПО (однако вам очень поможет знание Rust и Zig). Итак, давайте приступим.

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

Согласно моей теории, есть два типа разработчиков ПО:

Когда тип 1 узнаёт о задаче, он думает: «Это легко, люди просто могут делать X».

Когда о той же задаче узнаёт тип 2, он думает: «Это очень сложно, ведь для этого нужно, чтобы люди делали X».

Тип 1 предполагает, что задача проста, если она не техническая, потому что «можно просто попросить людей делать X». Тип 2 считает, что она сложна, потому что она не техническая.

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

На этапе планирования нагрузок мы обнаружили существенные траты памяти, о причинах которых я бы хотел рассказать в этой статье.

На прошлой неделе выкатили Safari 16.4, и для нас это стало кошмаром. Мы разрабатываем браузерное приложение для создания игр под названием Construct. Ранние версии Safari 16.4 ломали открытие проектов, предпросмотр проектов и весь контент, опубликованный при помощи Construct, каждый раз по-разному. Я захотела поделиться своим опытом, чтобы пользователи, разработчики, регуляторы и сама Apple знали, через что нам пришлось пройти из-за, казалось бы, рутинного релиза Safari.

Разработчики большинства браузеров предоставляют предрелизные версии для предварительного тестирования. Например, ежедневно обновляются Chrome Canary и Firefox Nightly, кроме того, существуют более редкие dev- и beta-релизы. Apple предоставляет Safari Technology Preview (STP), но она совместима только с macOS, и не обновляется по какому-нибудь открыто опубликованному графику. Похоже, это происходит примерно раз в две недели. Предрелизные браузеры обычно довольно шероховаты и содержат очевидные проблемы, которые достаточно быстро устраняют. Однако когда они начинают переходить в состояние беты, необходимо присмотреться повнимательнее. Поэтому когда 16 февраля было заявлено о выпуске Safari 16.4 beta 1 (тоже без какого-либо публичного графика), мы начали присматриваться и обнаружили множество проблем.

+10x-инженеры могут быть мифом, однако -10x-инженеры действительно существуют.

Чтобы стать -10x-инженером, просто тратьте впустую 400 часов разработки в неделю. Комбинируйте это со следующими стратегиями:

Обнулите результат работы десяти инженеров

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

Наведите 400 часов суеты

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

PostgreSQL (Postgres) — это мощная реляционная база данных, способная хранить широкий спектр типов и структур данных. Когда нам нужно хранить графовые структуры данных, мы часто обращаемся к базам данных, позиционируемым как подходящее для этого решение, например, к Neo4J или Dgraph. Но не торопитесь! Хотя при работе с графовыми структурами данных о Postgres обычно не вспоминают, она идеально справляется с эффективным хранением графовых данных и запросами к ним.

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



Planet — наполовину технологическое демо, наполовину игра, в итоге создающая настоящую магию. Не так уж просто разобраться, как она работает, однако, к счастью, мне удалось узнать основные подробности из постов в Twitter и статей самого Оскара.

Меня всегда потрясает, насколько творчески люди могут использовать утечки данных. Разумеется, есть много вредного (фишинг, хищение личных данных, спам), но часто данные, незаконно полученные из чужой системы, применяют удивительно положительным образом. Когда я создавал Have I Been Pwned (HIBP), моя мантра звучала так: «делай хорошее после того, как случилось плохое». И сервис делал именно это: позволял людям и организациям узнавать о том, что они подверглись утечкам. Однако применять сервис можно гораздо шире, и об одном из способов я давно хотел написать после того, как услышал о нём от первого лица. Пока я просто назову этот подход «Взломан или бот» и обрисую картину на примере другой проблемы: снайпинга.

Если вы новичок в экосистеме Arm, то считайте это кратким введением в терминологию, которую вы могли видеть раньше, но понимаете не до конца.

Архитектура Arm — это семейство архитектур с набором упрощённых команд (Reduced Instruction Set Architecture, RISC) с режимами простой адресации. Обработка данных выполняется над регистровыми операндами, в противном случае используются загрузки и сохранения для перемещения данных в регистры и из них.

Arm Limited — это британская компания, занимающаяся разработкой и поддержкой архитектуры Arm.

ARM — это устаревшая аббревиатура Acorn RISC Machine, а позже — Advanced RISC Machines. Как мы увидим ниже, в случае развития архитектуры предыдущую терминологию иногда переименовывают.

В предыдущей статье [перевод на Хабре] мы рассказали, как генерируются текстуры в демо H – Immersion. На этот раз мы изучим ещё один важный инструмент для создания демо нужного размера — процедурную геометрию.

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

Крисс проводит тебя в комнату для совещаний.

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

«Как дела?», — спрашивает он.

Сложный вопрос для начала беседы, придётся объяснять внутренний механизм, приводящий в движение твои действия. Возможно, он риторический?

«Действительно, как?», — улыбаешься ты.

«… хм, отлично. Ну, приступим?»

Ты утвердительно киваешь.

«Хорошо. Мы займёмся небольшой программной головоломкой, чтобы я понял, как ты умеешь решать задачи. Не волнуйся, если не получится сделать это упражнение, мне главное понять, как ты мыслишь и общаешься».

Волноваться? Ты с трудом вспоминаешь это ощущение. Возможно, оно осталось в твоей юности, когда ты зимовал на Свальбарде* с медведями. Ещё до того, как ты понял сейд.

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

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

А если вам понравилась статья, перейдите в репозиторий Dagster и поставьте нам реальную звезду GitHub!

С момента выпуска ChatGPT я видел достаточно много статей о его способности писать код. Люди рассказывали о том, как они попросили его спроектировать и реализовать головоломку с числами (не зная, что «изобретённая» им игра уже существует) и как бот клонировал Pong; и даже я сам использовал его для создания нескольких простых вспомогательных скриптов на Python. Это очень мощный и довольно полезный инструмент.

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

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