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

Роутер, как и любой другой девайс, нужно покупать под запрос. Например, линуксоиды привыкли покупать ноутбуки именно под Linux, а не первый попавшийся. Также и тут: если нужен OpenWrt, то роутер тоже надо выбирать с умом, а не надеяться на то, что кастомная прошивка сделает конфетку из роутера за 700 р.

В 2023 и 2024 появились интересные роутеры, которые уже поддерживаются проектом OpenWrt. Эти роутеры сделаны на базе ARM-процессоров. Такие роутеры появились у нескольких компаний, и дальше их количество будет только увеличиваться.

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.

Три месяца назад здесь на Хабре была опубликована статья “Интернет-цензура и обход блокировок: не время расслабляться”, в которой простыми примерами показывалось, что практически все популярные у нас для обхода блокировок VPN- и прокси-протоколы, такие как Wireguard, L2TP/IPSec, и даже SoftEther VPN, SSTP и туннель-через-SSH, могут быть довольно легко детектированы цензорами и заблокированы при должном желании. На фоне слухов о том, что Роскомнадзор активно обменивается опытом блокировок с коллегами из Китая и блокировках популярных VPN-сервисов, у многих людей стали возникать вопросы, что же делать и какие технологии использовать для получения надежного нефильтрованного доступа в глобальный интернет.

Мировым лидером в области интернет-цензуры является Китай, поэтому имеет смысл обратить на технологии, которые разработали энтузиасты из Китая и других стран для борьбы с GFW (“великим китайским файрволом”). Правда, для неподготовленного пользователя это может оказаться нетривиальной задачей: существует огромное количество программ и протоколов с похожими названиями и с разными не всегда совместимыми между собой версиями, огромное количество опций, плагинов, серверов и клиентов для них, хоть какая-то нормальная документация существует нередко только на китайском языке, на английском - куцая и устаревшая, а на русском ее нет вообще.

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

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

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

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

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

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

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

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

Что такое дизайн информационных систем

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

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

Ежедневно наши пользователи загружают десятки тысяч единиц контента. На таком объёме данных приходится применять ухищрения, чтобы сохранить приемлемое время ответа. Под катом расскажу, что именно мы делали, а в конце статьи поделюсь кодом на GitHub для ознакомления.

В эту тему пришлось детально погрузиться во время работы над обеспечением стандартных механизмов верификации устройств для разных мобильных платформ. Задача сводилась к разработке полноценной реализацию проверки JWS-токенов по протоколу SafetyNet на серверной стороне.

После многочасовых поисков и скрупулёзного изучения официальной документации Google решил поделиться полученным опытом. Потому что, кроме официальной документации, я нашел только отрывочные описания частных примеров реализации на разных ЯП. И ни намека на комплексное объяснение особенностей проверки по SafetyNet на сервере.

Статья будет полезна разработчикам, которые хотят подробнее разобраться с технологией верификации устройств по протоколу SafetyNet Attestation. Для изучения описательной части не обязательно знать какой-либо язык программирования. Я сознательно убрал примеры кода, чтобы сфокусироваться именно на алгоритмах проверки. Сам пример реализации на PHP сформулирован в виде подключаемой через composer библиотеки и будет описан ниже.

А в конце статьи — ссылка на разработанную мной библиотеку на PHP, которая обеспечивает полный цикл верификации JWS.

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

Единственное, о чем мы пожалели — что не применили это решение раньше.

• SBC — нормальный кодек
• У наушников есть свой эквалайзер и пост-процессинг на каждый кодек отдельно
• aptX не настолько хорош, как о нём говорят рекламные анонсы
• LDAC — маркетинговое фуфло
• Качество звука в режиме разговора всё ещё низкое
• В браузер можно встроить аудиоэнкодеры на C, скомпилировав в WebAssembly через emscripten, и они не будут особо тормозить.