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

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

Всё это приятные бонусы, но никто не говорит им, что на самом деле им придётся делать на этой работе.

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

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

[Первая часть]

Генерация скайбокса

В игре используется встроенная система неба HDRP Unity, то есть она генерирует текстуру скайбокса (кубическую карту) в каждом кадре. Это занимает около 0,65 миллисекунды, что не очень много по сравнению со всем остальным, но если игра нацелена на генерацию 60 FPS, то это будет почти 4% от общего бюджета времени на кадр.

Предварительный проход

Теперь мы переходим к самому рендерингу. В C:S2 используется отложенный рендеринг: по сути, это означает, что рендеринг выполняется за несколько фаз и с использованием множества промежуточных render target. Первая фаза — это предварительный проход, создающий попиксельную информацию о глубине, нормалях и (преположительно) о гладкости, записывая их в две текстуры.

Этот проход на удивление затратен, он занимает примерно 8,2 миллисекунды, то есть слишком много, и именно здесь начинает проявляться одна из самых больших проблем рендеринга игры. Но для начала нам нужно поговорить о тех самых зубах.

Одна из самых долгожданных игр для PC Cities: Skylines 2 вышла в конце октября, но получила смешанные отзывы. По моим ощущениям, геймплейно и с точки зрения симуляции игра сделала шаг в правильном направлении, и по крайней мере, теоретически она выглядит более целостной по функциям, чем первая часть. Однако в ней присутствуют существенные изъяны, от проблем с балансом и спорных дизайнерских решений до багов, из-за которых экономическая симуляция игры становится практически бесцельной. Стала ли она достойным преемником оригинала — пока вопрос открытый, но все сходятся в одном: производительность проекта далека от должного уровня.

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

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

Спустя три года, выполнив несколько развёртываний в продакшен, написав электронную книгу и выпустив примерно сто пакетов на crates.io, я решил, что настало время поделиться своими мыслями о Rust.

Пару месяцев назад Steam выложил в Steamworks инструмент для разработчиков, позволяющий отправлять игры на сертификацию: Steam тестирует и проверяет игру, а затем решает, совместима ли она с Steam Deck. Так как я уже реализовал в своей игре поддержку геймпадов, то сразу приступил к делу. Мне понадобилось два месяца переписок со Steam, чтобы он наконец верифицировал полную совместимость игры со Steam Deck. Я не нашёл особо много информации об этом процессе, поэтому захотел поделиться своим опытом, чтобы другим разработчикам не приходилось совершать те же ошибки.

Примечание: у меня нет Deck и я ни разу им не пользовался. Разработка игры целиком зависела от помощи моего фаната и простоты разработки под сам Steam Deck.

Недавно компания Valve объявила о том, что Counter-Strike 2 не будет поддерживать macOS. Я инди-разработчик, в одиночку выпустивший игру с поддержкой macOS, поэтому поначалу меня удивило это решение Valve. Но вспомнив о своём собственном опыте поддержки шести платформ, я начал понимать точку зрения компании.

Думаю, будет полезно написать пост с перечислением полученных мной уроков. Надеюсь, он поможет другим инди-разработчикам в выборе поддерживаемых платформ. Небольшое предисловие: моя собственная игра Industry Idle в основном основана на веб-технологиях (WebGL + TypeScript). Это означает, что поддержка разных платформ — относительно простая задача, мне не приходится иметь дело с платформенными графическими API (DirectX, OpenGL, Vulkan, Metal) и в основном игра существует в браузерной «песочнице». Это практически идеальная ситуация для кросс-платформенной поддержки. Тем не менее, меня постоянно удивляют и одолевают проблемы, связанные с отдельными платформами.

Полосы прокрутки. Слышали когда-нибудь о них? Довольно крутая штука. Достаточно зажать и перетаскивать полосу прокрутки, чтобы перемещаться по контенту панели со скроллингом. Я это просто обожаю. Ежедневно целыми днями сижу за компьютером и тягаю полосу прокрутки. Но полосы прокрутки становятся мельче, и это оказывается всё более серьёзной проблемой. В статье я покажу скриншоты, но они настолько малы, что даже делать их было сложно. А разработчики продолжают делать их всё мельче, как будто не хотят, чтобы вы скроллили! Они говорят: «для этого ведь колесо прокрутки и существует». Друг мой, не у каждого есть колесо прокрутки и не каждый может свайпать по сенсорному экрану. И даже я, счастливый обладатель колеса прокрутки, хотел бы перемещаться по контенту быстро.

Hugging Face имеет полнофункциональный набор инструментов, от функций создания датасетов до развёртывания демо моделей. В этом туториале мы воспользуемся такими инструментами, поэтому полезно будет знать экосистему Hugging Face. К концу туториала вы сможете обучить модель GPT-2 генерации музыки.

Демо проекта можно попробовать здесь.

Источником вдохновения и фундаментом этого туториала стала выдающаяся работа доктора Тристана Беренса.

Впервые взглянуть на кодовую базу FTX мы смогли в прошлую среду. Сторона обвинения показала скриншоты с Github в процессе допроса сотрудничающего со следствием свидетеля Гэри Вана, бывшего CTO компании FTX, который в разные промежутки времени отвечал за кодовую базу, лежащую в основе и FTX, и Alameda Research. Ван признал себя виновным по четырём пунктам обвинения.

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

Наверно, этому способствовало и то, что инженеры FTX написали достаточно чистый код с описательными именами переменных и короткими функциями, а также выбрали человекочитаемый язык (Python).

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

Основная часть обсуждений касалась флага allow_negative, добавленного в кодовую базу FTX 1 августа 2019 года. Ван дал показания, что Сэм Бэнкман-Фрид попросил его и Нишада Сингха (бывшего технического директора FTX, тоже признавшего свою вину) добавить этот флаг. На скриншотах из Github видно, как Сингх внёс в код изменение, добавляющее столбец в базу данных, и логику, исключающую счета с этим флагом из проверок, которые в противном случае позволили бы определить, достаточно ли у них средств для снятия.

Память — достаточно дефицитный ресурс для многих компьютеров потребительского уровня, поэтому логично создать функцию, ограничивающую объём используемой процессом памяти; и Microsoft действительно реализовала такую функцию. Однако:

Компания её не задокументировала (!)

Её реализация на самом деле не экономит память

Реализация может иметь чрезмерно высокие затраты ресурсов CPU

Эта функция ограничивает рабочий набор процесса (количество памяти, отображённое в адресное пространство процесса) 32 мегабайтами. Прежде чем читать дальше, попробуйте предположить, какое максимальное замедление может вызывать эта функция. То есть если процесс многократно затрагивает больше, чем 32 МБ памяти (допустим 64 МБ памяти), то насколько больше будут занимать эти операции с памятью по сравнению с ситуацией без ограничений рабочего набора? Остановитесь на минуту и запишите своё предположение. Ответ будет ниже в посте.

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

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

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

Чтобы понять, как это сделать, нужно начать снизу. Цитата из раздела 6.3 стандарта IEEE 754-2019:

Большие числа != большим числам.

Число 100 большое? Зависит от ситуации. Сравниваем ли мы его с 0,001, или с 100000? Как и многое в жизни, понятие «большой» относительно.

В этом посте мы объясним, насколько большим должно быть «большое» и докажем, что вы, скорее всего, ошибаетесь насчёт закона больших чисел.

Примерно полтора года назад я попросил у своей бывшей компании разрешения поработать над проблемой, влиявшей на возможности отладки нашего проекта: gdbserver не мог отлаживать многопоточные приложения, работающие на архитектуре PowerPC32. Подключение к gdbserver было поломано, и он больше не мог контролировать сессию отладки. Разные люди исследовали эту проблему до меня, и у меня уже был неплохой фундамент, но мы всё равно не знали точно, в каком конкретно программном компоненте таится проблема: это мог быть тулчейн, gdbserver, ядро Linux или собственные патчи, которые мы устанавливали поверх дерева ядра. От нахождения первопричины мы находились довольно далеко.

Когда я рассказываю о своих исследованиях редактирования текста на мобильных в Google, то обычно сталкиваюсь с непониманием и немного враждебным «Разве на телефонах нельзя редактировать тексты? В чём проблема?»

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

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

Классический ответ на этот вопрос — та гипотеза, которую я буду называть Lines-As-Edges. Она гласит, что рисунки симулируют естественные образы, потому что признаки линий активируют рецепторы краёв в зрительной системе человека. Насколько я могу судить, такое убеждение широко распространено в среде исследователей зрения; многие люди вспоминают эту гипотезу, когда я говорю о восприятии рисунков, а также многие комментаторы под недавним постом в Twitter. Обобщением этой идеи становится то, что линии соответствуют некому внутреннему представлению, заставляющему нейроны реагировать на контуры объектов. Я называю эту гипотезу Line-As-Internal-Representation и расскажу о ней в этой статье.

Наверно, произошло что-то плохое, и теперь вы читаете эту статью. Сочувствую! Давайте начнём по порядку.

Меня зовут Джо Уинтергрин, я генералист Unreal Engine. Можете взглянуть на все мои ресурсы. В статье я приведу полезную информацию для новичков в Unreal, имевших опыт работы с Unity.

С чего начать?

• Прочитайте документацию по Gameplay Framework. Всю целиком! У Unreal есть Gameplay Framework. Прочитайте документацию и освойтесь в ней. Это правильное решение при разработке любого типа игры. Не пропускайте её. Держите её под рукой, чтобы перечитывать.

• Влейтесь в сообщество. Это учетверит вашу скорость обучения. Есть Discord для бывших Unity-разработчиков Алекса Роуза и есть мой Discord.

• Почитайте Epic Online Learning Library. Вот она. Делайте упор на статьи, написанные Epic Games.

• Скачайте последнюю версию Unreal Engine из Epic Games Launcher. На данный момент это 5.3. В общем случае всегда стоит начинать проект на самой новой версии. Кроме того, нет никаких причин больше пользоваться UE4 — UE5 лучше и имеет все возможности UE4.

• Изучите документацию «Unreal Engine for Unity Developers» компании Epic. Это хороший способ начать. Вот она.

• Прочитайте статью целиком. Я знаю, здесь много текста, но не ничего не пропускайте! Всё это очень важная и точная информация! В Интернете много некачественных сведений об Unreal, но не здесь. Здесь всё правильно.

Когда был максимальный курс доллара к евро?

Вот небольшая программа, вычисляющая это:

curl -s https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist.zip \ | gunzip \ | sqlite3 -csv ':memory:' '.import /dev/stdin stdin' \ "select Date from stdin order by USD asc limit 1;"

Результат: 2000-10-26. (Можете попробовать запустить её самостоятельно.)

Бунтарём себя можно считать только тогда, когда люди на самом деле защищают противоположную вашей позицию. Я не согласен с одной из best practices, недавно представленной в Google Testing Blog . Обычно это очень хороший ресурс, ведь этот пост не случайно попал в мою читалку новостей!

Авторы представили две версии функции и спросили, какая из них более читаема.