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

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

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

Мы занимаемся разработкой на аутсорсе. Часто стартуем новые проекты. Не работаем с готовыми CMS – всё на фреймворках с нуля, обычно PHP, node.js у нас на бекенде. В таких проектах постоянно требуется создавать панель управления. 

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

Мы искали инструмент, чтобы клепать однотипные админки, но при необходимости создавать и кастомные решения. У нас были такие требования:

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

Всем привет, на связи dev.family. Хотим рассказать про интересный проект, над которым мы трудимся почти полгода, и до сих пор продолжаем. За это время в нем многое произошло, многое поменялось. Мы открыли для себя что-то интересное, успели набить шишек.

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

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

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

BonsaiDb – это новая база данных, которая должна стать самой удобной для разработчиков базы данных Rust. У BonsaiDb есть уникальный набор функций, предназначенных для решения большого количества распространенных проблем с данными. По ссылке можно узнать подробнее, что такое BonsaiDb?

tl; dr: BonsaiDb работает медленнее, чем сообщалось ранее 

Я настроил виртуальную машину сервера Ubuntu 20.04 под управлением ядра 5.4.0-110-generic и размышлял, как лучше отключить компьютер после вызова sync_file_range, когда @justinj снова пришел на помощь, указав, что существует /proc/sysrq-trigger. Он также поделился своим постом в блоге, где рассказывал о проведении аналогичных тестов против fsync. С их помощью он хотел изучить, как создавать надежный журнал базы данных. На следующий день после последнего поста @justinj сообщил, что они отследили один из примеров Nebari и не увидели ни одного выполненного системного вызова fsync. Это произошло из-за неправильного трактования термина "true sink" в std::io::Write. Оказалось, выполнение Write::flush() для std::io::File – это не операция, так как "true sink" было ядром, а не диском.

Я выпустил Nebari v0.5.3 в тот же день. Я запустил набор тестов Nebari и... ничего не изменилось. Я запустил пакет на GitHub Actions – никаких изменений. Я запустил пакет на своем выделенном VPS, который использую для более стабильной среды бенчмаркинга, чем GitHub Actions... никаких изменений. Я запустил пакет на своем Mac ... ужасное замедление. Я расскажу ниже, почему так произошло, но первоначальное впечатление было, что я каким-то образом увернулся от пули.

Я думал, что буду работать в Netflix вечно. Самые высокие зарплаты по рынку. Свобода и уважение. Нелимитированные оплачиваемые нерабочие часы. Чего еще можно хотеть?

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

“Просто не высовывайся и делай свою работу!” - говорили они.

“Будь благодарен за то, что у тебя есть!” - продолжали они возмущаться.

Никто из моих друзей также не мог в это поверить.

“А как же бесплатная еда?!”

”Ты работаешь в компании, которая входит в пятерку крупнейших IT-гигантов!" 

“Просто отдыхай и инвестируй, братан!”

Сейчас 3 часа ночи 10 августа 2013 года. Бесконечный приступ паники не дает мне сомкнуть глаз. Как сумасшедший, я раз за разом прокручиваю только что написанный код в голове. Внезапно я осознаю, что в архитектуре приложения есть серьезная проблема. Я вскрикиваю и скатываюсь с кровати, спотыкаясь о свою девушку, я бегу как сумасшедший к своему компьютеру, чтобы все исправить. 

Я знаю, что этот день будет прекрасной солнечной субботой. Я снова буду работать 12 часов подряд. А стресс и горящий дедлайн снова не дадут мне уснуть. Как я докатился до всего этого?

Данная статья представляет из-себя эксперимент с Rust'ом с последующей его компиляцией в WASM. Было интересно пощупать данные технологии на чем-то сложнее, чем вычисление факториала, поэтому выбор пал на всем известную игру 2048.