Переводчик-фрилансер
В этом посте я вкратце расскажу о внутреннем устройстве iMessage, изученном мной в процессе работы над pypush — опенсорсным проектом воссоздания реализации iMessage.
Ради краткости и понятности я не буду вдаваться в технические подробности. Если вы хотите узнать, как конкретно всё реализовано, то изучите репозиторий pypush.
За последние полгода я несколько раз писал о тонкой настройке (fine tuning). Fine tuning — очень соблазнительная технология, обещающая закрыть проблемы в функциях GPT-4, будучи при этом быстрее и дешевле. Однако как бы часто не обсуждали fine tuning, я нашёл на удивление мало контента о том, который бы помог мне понять, насколько эффективен fine tuning и насколько сложно встраивать новые возможности в языковые модели.
Поэтому я решил взять всё в свои руки, сдуть пыль с моих навыков ML и разобраться самостоятельно.
Выбор задачи
Меня особенно интересовала проверка возможностей модели рассуждать (то есть выполнять достаточно сложные задачи, требующие хорошего понимания контекста ) о данных вне распределения (то есть о тех, которые модель не видела). В конечном итоге я выбрал своё хобби: коллекционную карточную игру Magic the Gathering (и в частности, драфт).
Заявление о том, что большинство ИИ-стартапов обречено, может показаться довольно очевидным. В конце концов, большинство стартапов обречено, так уж сложилось.
Но я хочу донести нечто более провокативное. Почти все стартапы, возникшие после хайпа ChatGPT, и особенно те, которые называют себя «ИИ-стартапы», обреченыs.
Я венчурный капиталист, инвестировавший в ИИ уже долгое время; на самом деле, я даже ушёл и мира хедж-фондов, потому что увидел, насколько много всего интересного происходит в сфере ИИ. То есть я определённо не ИИ-скептик.
Тем не менее, я считаю, что большинство из того, что финансируется на текущем цикле хайпа, не имеет ценности с точки зрения инвестора.
Эта фраза, ставшая общеизвестным знанием программистов — напоминание о том, что человек, впервые пишущий фрагмент кода, не должен покупать своё удобство ценой неудобства людей, которые должны будут читать и изменять этот код в будущем. В более общем смысле эта фраза означает, что обычно стоит обеспечивать поддерживаемость кода, сохраняя его простоту, создавая тесты и документацию и так далее. Здесь вопрос касается точки зрения на цикл разработки ПО.
Позвольте мне выразить эту мысль более кратко:
мейнтейнер > автор
Я считаю, что такое мышление можно вывести за рамки написания кода и использовать как эмпирическое правило при выявлении проблем и принятии решений.
В этой статье я поделюсь с вами долгой историей, которая начинается с op.read() opendal, а заканчивается неожиданным поворотом. Это путешествие оказалось для меня достаточно поучительным, надеюсь, и для вас оно будет таким же. Я постараюсь максимально точно воссоздать свой опыт и дополню его выводами, которые сделал в процессе.
В этом месяце я решил узнать, как создать шрифт, который буду использовать в своём комиксе hakum. Раньше я рисовал текст в цифре на своём планшете. Результат оказывался хорошим, но иногда трудночитаемым (размер текста часто скакал на одной странице). Мне не хотелось использовать готовый шрифт, поэтому я решил создать собственный на основе своего рукописного текста. Шрифт повысит читаемость текста и сделает его однородным.
Примечание: это моя первая проба создания шрифта. Я не дизайнер, не освоил создание шрифтов в совершенстве и не специалист по программе FontForge. Возможно, существуют способы получше добиться того же результата. В этой статье я опишу свой процесс, который, вероятно, поможет другим начинающим создать свой первый шрифт (для личного пользования). Моя цель заключалась в создании шрифта TTF для применения в веб-публикациях с ограниченным набором символов (без полужирного и курсивного написания).
Очень часто нас спрашивают о хороших веб-сайтах для новичков по изучению программирования графики. Разумеется, мы бы с радостью порекомендовали GPUOpen, но правда в том, что основная целевая аудитория GPUOpen — программисты среднего или высокого уровня. Для только начинающих погружаться в мир графики есть более подходящие веб-сайты.
Как и во многих других сферах, в графике нет одного единственно правильного пути. В основном он зависит от имеющихся знаний, предпочитаемого способа обучения, личного выбора, доступного оборудования и так далее. Поэтому это руководство будет перечнем веб-сайтов, которые, по нашему мнению, полезны для новичков, и небольшим обсуждением плюсов и минусов этих веб-сайтов и их программы обучения.
«640 КБ хватит всем», — предположительно Билл Гейтс, примерно 1981 год.
Мы решили, что в нашей системе управления финансовыми базами данных TigerBeetle для хранения всех финансовых сумм и балансов будут использоваться 128-битные числа, и что мы откажемся 64-битных целых чисел. Хотя кто-то может заявить, что 64-битного integer, способного хранить в себе целые числа от нуля до 264, достаточно для подсчёта всех песчинок на Земле, мы осознали, что для адекватного хранения всех транзакций нам нужно подняться выше того предела. И в статье мы расскажем, почему.
Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Как-то я изучал release notes новой версии Python 3.12, и в разделе о депрекациях моё внимание привлекла следующая фраза:
utcnow() и utcfromtimestamp() из datetime.datetime устарели и будут удалены в будущей версии.
Если вы следили за моими туториалами по веб-разработке, то видели, что я часто использую utcnow(); очевидно, мне придётся переучиваться и использовать альтернативу, готовясь к неизбежному удалению этой функции (вероятно, это произойдёт спустя несколько лет, так что причин для паники нет!).
В этой краткой статье я подробнее расскажу о том, почему эти функции попали под нож и чем их можно заменить.
Intel недавно раскрыла спецификацию AVX10 как средство консолидации подавляющего большинства расширений AVX-512 в единую спецификацию. Целью этого было решение нескольких проблем, в частности, поразительного количества конфигураций, целевых платформ и спагетти из реализаций AVX-512 с несогласованной поддержкой команд. Следует помнить о том, что в первую очередь она используется как средство для объединения всех любимых преимуществ AVX-512 в более мелкие реализации, целевые платформы для которых — это потребительские машины, micro-edge и встроенные системы, у которых нет или не будет 32 512-битных регистров, необходимых для AVX-512.
После публикации спецификации я публично выразил свой энтузиазм, сделав доклад для сообществ разработчиков Easy Build/HPC с названием «AVX10 for HPC: a reasonable solution to the 7 levels of AVX-512 folly». Статья, которую вы читаете, изначально должна была стать частью доклада, но я решил написать её, чтобы ссылаться в дальнейшем (а ещё потому, что я уже с трудом могу урезать доклад до 90 минут, не говоря уже о предоставленных мне 60 минутах).
В прошлые выходные мне представилась возможность пообщаться с только что выпустившимися студентами. Сейчас они ищут свою первую работу в разработке ПО. В разговоре с ними я понял, что они довольно ошибочно воспринимают эту работу.
Причина этого в том, что реальность для этих новичков очень искажена. Они видят лишь высокие зарплаты, удалённую работу, тимбилдинг и вечеринки с пиццей.
Всё это приятные бонусы, но никто не говорит им, что на самом деле им придётся делать на этой работе.
Имея большой опыт работы в этой отрасли, я смог показать им, какова жестокая реальность. Я рассказал им о хорошем, но также поделился и неприятными истинами.
Прочитав эту статью, кто-то может сказать, что я слишком негативен, но я считаю, что все эти аспекты неотделимы от профессии и их необходимо принять.
Генерация скайбокса
В игре используется встроенная система неба 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 видно, как Сингх внёс в код изменение, добавляющее столбец в базу данных, и логику, исключающую счета с этим флагом из проверок, которые в противном случае позволили бы определить, достаточно ли у них средств для снятия.