На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

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

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

Приложение работало в контейнерах, а оркестрация осуществлялась с помощью Docker Compose. Компоненты приложения не задумывались готовыми к запуску в кластерном режиме, что, разумеется, нормальная ситуация для раннего этапа многих проектов: бизнес требует быстрой доставки новых функций, и на преждевременную оптимизацию не всегда можно и нужно тратить время. Но в какой-то момент именно стабильность и быстродействие становятся самыми важными функциями. 

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

Всем привет! Я Денис Загаевский из Android-разработки Яндекс.Карт. Если вы развиваете многомодульное приложение или хотите разбить на части пока ещё одномодульное, этот туториал для вас.

Под катом расскажу, как удобно разбить приложение на модули, зачем это нужно и как потом приготовить в нём DI (dependency injection). Кто-то мог слышать мой доклад на Mobius 2021 Piter или в Школе мобильной разработки, а для всех остальных я написал эту статью.

Местами буду ссылаться на опыт Яндекс.Карт. Кстати, рабочий пример нашего подхода есть на GitHub.

• Модуляризация
  　Зачем разбивать приложение на модули?
  　Виды модулей
  　　App modules
  　　Feature modules
  　　Core modules
  　Требования к межмодульному DI
• Как feature-модуль получает свои зависимости?
• Предоставление зависимостей feature-модулям
  　Простой случай
  　Сложный случай
  　Использование Hilt в app-модуле
  　Итоги по предоставлению зависимостей
• Использование зависимостей в feature-модуле
• Минусы, ограничения, исключения
  　Связывание во время выполнения
  　Сложность восприятия
  　Ограничения на зависимость фич друг от друга
  　　Фичи зависят друг от друга по api
  　　Фичи зависят друг от друга по implementation
  　　Разрываем зависимость между фичами
  　Не UI-фича
• Подводя итоги

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

1. Kubernetes разработан для компаний типа FAANG

Не так давно я начал пользоваться Plex media server для просмотра видео на ТВ через Amazon fire stick. Plex server был настроен на десктопе, а файлы с видео были подключены через внешний USB диск и такая связка меня впринципе устраивала. Однако при выключенном ПК доступа к контенту нет и каждый раз включать ПК только для того что бы посмотреть фильм или послушать музыку уже стало напрягать. Поэтому решил настроить plex на raspberry и подключить к нему внешний USB с уже имеющимся контентом. А уже в процессе понял, что еще бы не плохо иметь доступ к файлам и качалку для торентов и заодно упростить процесс настройки с помощью автоматизации на Ansible.

Вы вряд ли найдете в интернете что-то про разработку ботов, кроме документаций к библиотекам, историй "как я создал такого-то бота" и туториалов вроде "как создать бота, который будет говорить hello world". При этом многие неочевидные моменты просто нигде не описаны.

Как вообще устроены боты? Как они взаимодействуют с пользователями? Что с их помощью можно реализовать, а что нельзя?

Подробный гайд о том, как работать с ботами — под катом.

Или, на что годятся монстрики Meklon'а?

• Беседа на французском в течение нескольких часов;
• Понимание различных видов французских СМИ (например, новости и видео на YouTube);
• Чтение статей, написанных для носителей французского языка;
• Построение мыслей на французском;

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

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

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

Введение

Решил написать о некоторых вещах, которых, по моему мнению, стоит и не стоит избегать при использовании корутин Kotlin.

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

Общие принципы

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

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