Клиентская оптимизация *

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

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

Рассматриваем различные «приколюхи» из C++20 на примере хеш‑мапы!

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

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

Здравствуйте, дорогие читатели! Сегодня мы рассмотрим policy-based routing (маршрутизацию на основе политик) и его практическое применение в лабораторной работе с использованием GNS3. Вся информация будет представлена на практике. Вот наша топология, с которой мы будем работать. Маршрутизация будет осуществляться с помощью протокола OSPF.

Наша топология:

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

Теперь, с высоты уже немалого времени докладываем: 1) идея себя оправдала и даже превзошла самые смелые ожидания; 2) работа по совершенствованию технологии была проделана; 3) работы было и будет очень много. Собрали для вас хайлайты этой увлекательной и яркой истории.

Я написал на C# консольный клон Wordle, но попытался сделать двоичный файл максимально крошечным.

Я взял популярную игру Wordle с такими правилами:

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

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

В работе с консолью мне помогла игра Console Games - Snake

Проект запускается в новой консоли dotnet.

Сериализация

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

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

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

Обычный день нарушений на ratpstatus.fr.

В репозитории GitHub сайта ratpstatus.fr содержатся все файлы JSON, запрашиваемые из open-data API каждые две минуты. Данные сохраняются там уже почти год. Репозиторий с 188 тысячами коммитов и более чем 10 ГБ собранных данных всего лишь в одном последнем коммите (измерено при помощи git clone --depth=1) — это определённо интересный выбор для реализации базы данных! Уточню, что в этом посте я не собираюсь критиковать эту систему. Веб-сайт статуса сети RATP — превосходный веб-сайт, мгновенно и стабильно предоставляющий полезную информацию без обычного сегодня раздувания веб-сайтов. [И нет, сайт не написан на Rust. Веб-сайт на PHP тоже может быть невероятно быстрым!]

Тем не менее, размер базы данных (10 ГБ) заставил меня призадуматься: а можно ли сжать её лучше, потратив на это приемлемое количество времени (скажем выходные)? В этом подробном посте я расскажу, как использовал шаблон проектирования interning в Rust, чтобы сжать этот датасет в две тысячи раз! Мы посмотрим, как лучше структурировать сам интернер, как настроить схему данных для оптимальной работы с ним и как сделать так, чтобы сериализация использовала interning наилучшим образом.

Если у вас в хранилище накопилось множество файлов JSON, то вам стоит прочитать эту статью!

Зимой 2024 года я восстанавливал IBM PS/1 486-DX2 66Mhz, «Mini-Tower», model 2168. В подростковом возрасте я мечтал о таком компьютере, но не мог себе его позволить. Не могу выразить словами, насколько меня радовала работа над этой машиной.

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

В эпоху цифрового контента каждая миллисекунда загрузки страницы может существенно повлиять на пользовательский опыт. В Hikasami, платформе, предоставляющей потоковое аниме и азиатские медиа для пользователей СНГ, наша цель — обеспечить мгновенную загрузку страниц, минимизировать задержки, а также гарантировать актуальность данных. Для этого мы внедрили Next.js 15, который открыл перед нами возможности глубокой оптимизации:

Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.

В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.

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

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

Привет, хабрачитатели! Server-Driven UI (SDUI) — это подход, при котором сервер управляет отображением интерфейса на клиенте. Важное преимущество SDUI — возможность внедрять изменения без выпуска новых версий приложений. Но это же преимущество есть его недостаток, ведь передача всех данных по сети зависит от качества соединения и увеличивает объём данных. 

Качество связи мы не можем контролировать, а вот уменьшить количество передаваемой информации посредством сокращения JSON, — вполне.

Сегодня я хочу поделиться с вами советами по использованию Udim, текстурных сетов, texel density, padding, mipmapping и других техник в различных ситуациях и при возникновении ошибок.

Этот материал создан автором самостоятельно, однако в него также включена информация, полученная из других источников.

Редактор и создатель идеи: Daniil Lipin (lipa_l1).
Благодарю за помощь в написании статьи замечательных художников высокого уровня: _Shelest_, Titan_Fair, Alexey Yarmola, nikiost, trasnik.
Отдельное спасибо:
Dmitriy Bogumil — за предоставление файлов/скринов модели монстра.
gRen — за предоставление скринов с ошибками запекания карт id на оружии.

Сайты, откуда была взята маленькая часть информации:
1) https://www.youtube.com/watch?v=55sGQLX7iho
2) https://www.artstation.com/artwork/Xg3reL
3) http://wiki.polycount.com/wiki/Edge_padding
4) https://dtf.ru/gamedev/202100-kak-uluchshit-kachestvo-tekstur-razbor-metodov-optimizacii-uv
5) https://en.wikipedia.org/wiki/File:Mipmap_Aliasing_Comparison.png
6) https://gtaforums.com/topic/750681-skygfx-ps2-xbox-and-mobile-graphics-for-pc/page/287/
7) https://vk.com/@anatolii994-teksel-prostoi-universalnyi-metod
8) https://www.artstation.com/artwork/x3B5YX

Буду признателен, если вы поможете мне исправить опечатки, а ещё, если есть вопросы, пишите, пожалуйста, на почту: lipindan2003@gmail.com, в телеграмм — @lipa_l1, в дискорд — @lipa_l1.

«Все материалы данного сайта являются объектами авторского права (в том числе дизайн). Запрещается копирование, распространение или любое иное использование информации и объектов без предварительного согласия правообладателя»

Сорванные дедлайны, работа в выходные, недовольный клиент — знакомо? Если да, то вы, вероятно, сталкивались с некорректной оценкой проекта. В прошлой статье я рассказывал о риск-факторах в задачах разметки и сбора данных:

Часть 1

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

«Это просто задача отсечения»

Свет внезапно выключается. Вы сидите в огромном конференц-зале. Кто-то включает проектор. На экране сам Майкл Абраш! Похоже, это знаменитый доклад Quake Postmortem с GDC 1997.

Он говорит о порталах.

Мы берём плоскости отсечения, ограничивающие максимальный объём видимого, и отсекаем их по всё более дальним порталам, пока они не пропадут.

Я занимаюсь фронтенд разработкой на React последние 6 лет (в роли full-stack разработчика). Я знал и слышал, что существуют хуки useCallback и useMemo, которые нужны для оптимизации рендеринга. При этом про их использование я слышал только в теории или на собеседованиях.

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

За годы работы с клиентами я видела разное. Когда-то, на своей прошлой работе в госструктуре, была на стороне заказчика. Казалось бы, где ещё прокачать диктаторский талант, как не там? Но, знаете, у меня всё было как-то по-человечески: я уважала экспертов, была открыта к диалогу, решала задачи, а не играла в «кто тут главный». Но потом я стала предпринимателем и окунулась в мир, где адекватность — это что-то вроде редкой валюты. И вот тут я осознала, что не только исполнители бывают всратые, но и заказчики далеко не святые.

Так что, предприниматели, давайте называть вещи своими именами: говорить «нет» клиентам не только можно, но и нужно. Вот мой личный список ред флагов, которые я с годами чую за версту. Кстати, в комментах можно поговниться на исполнителей (ну или меня) и написать свои ред флаги, го!

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