Повторное использование ранее размещенных в памяти строк, которые при прокрутке выходят за пределы экрана, ― широко распространенная техника оптимизации использования компонента ListView, изначально реализованная в iOS и Android. Реализация ListView как компонента React Native по умолчанию не содержит непосредственно эту оптимизацию, но имеет ряд других приятных преимуществ. Тем не менее, это отличный образец, достойный изучения. Рассмотрение этой реализации в рамках изучения React также будет интересным мысленным экспериментом.

Списки являются важной частью разработки мобильных приложений

Списки – это сердце и душа мобильных приложений. Множество приложений отображают списки: это и список публикаций в вашей ленте приложения Facebook, и списки бесед в Messenger, и список сообщений электронной почты Gmail, и список фотографий в Instagram, и список твитов в Twitter и т.д.

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

С одной стороны, вы хотите сохранить скорость работы вашего приложения, т.к. прокручивание со скоростью 60 FPS стало золотым стандартом нативного опыта взаимодействия (UX). С другой стороны, вы хотите сохранить низкое потребление памяти, потому что мобильные устройства не располагают избыточными ресурсами. Не всегда просто выполнить оба эти условия.

Поиск идеальной реализации элемента ListView

Основополагающим правилом разработки программного обеспечение является то, что нельзя предусмотреть оптимизацию для любого сценария.

В течение довольно длительного времени мы поддерживали приложение, которое обрабатывает данные в форматах XML и JSON. Обычно поддержка заключается в исправлении дефектов и незначительном расширении функциональности, но иногда она также требует рефакторинга старого кода.


Рассмотрим, например, функцию getByPath, которая извлекает элемент из XML дерева по его полному пути.

import scala.xml.{Node => XmlNode}

def getByPath(path: List[String], root: XmlNode): Option[XmlNode] =
  path match {
    case name::names =>
      for {
        node1 <- root.child.find(_.label == name)
        node2 <- getByPath(names, node1)
      } yield node2
    case _ => Some(root)
  }

Эта функция отлично работала, но требования поменялись и теперь нам нужно:

• Извлекать данные из JSON и, возможно, других древоподобных структур, а не только из XML;
• Возвращать сообщение об ошибке, если данные не найдены.

В этой статье мы расскажем, как осуществить рефакторинг функции getByPath, чтобы она соответствовала новым требованиям.

Асинхронный код – сложный. Все это знают. Писать асинхронные тесты – еще сложнее. Недавно я починил мигающий (flaky) тест и хотел бы поделиться некоторыми мыслями по поводу написания асинхронных тестов.

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

Тестируем throttler

Throttler (Ограничитель) – это класс, отвечающий за ограничение количества одновременных операций, выполняемых с некоторым ресурсом (например, пул соединения, сетевой буфер или ресурсоемкие операции процессора). В отличие от других инструментов синхронизации, роль ограничителя заключается в том, чтобы запросы, превышающие квоту, завершались ошибкой немедленно, без ожидания. Быстрое завершение важно, поскольку альтернатива, ожидание, потребляет ресурсы – порты, потоки и память.

При рассмотрении сценариев использования NoSQL, таких как хранение пар ключ-значение, оказывается, что MySQL более предпочтительна с точки зрения производительности, легкости использования и стабильности. MySQL – это основательная система с обилием онлайн-материалов, которые охватывают все темы от основных операций и разбора ошибок до репликации и различных паттернов использования. Это дает MySQL преимущество перед более молодыми NoSQL-системами, у которых нет такого опыта.

За последние годы NoSQL-системы стали господствующим направлением. Многие разработчики видят в NoSQL-системах, таких как MongoDB, Cassandra, Redis или Hadoop, оптимальный вариант для построения своих приложений, считая их единой семьей продуктов, которая обесценивает старые SQL-системы.

Зачастую, в основе решения об использовании базы данных NoSQL лежит рекламная шумиха или ошибочное убеждение, что реляционные базы данных не могут обеспечить такую же производительность, как базы данных NoSQL. Когда доходит до выбора базы данных, инженеры часто упускают из виду эксплуатационные расходы, а также соображения стабильности и зрелости технологии. Чтобы узнать больше об ограничениях и изъянах различных NoSQL (а также SQL) систем, обратите внимание на серию статей проекта Jepsen, опубликованную на Aphyr.com.

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

Это третья часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление и второй пост.

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

Развертывание новой версии нашей системы в некоторых случаях требовало изменения схемы MySQL. Поскольку Hibernate не прощает несовпадений между ожидаемой им схемой и реальной схемой базы данных (БД), мы использовали общую практику развертывания программного обеспечения: плановая двухчасовая остановка в период наименьшего трафика (полночь в США на выходных). За время этой плановой остановки мы должны были остановить сервис, выключить сервер, внести изменения в схему MySQL, развернуть новую версию и перезапустить сервер.

Эта плановая двухчасовая остановка часто превращалась в нечто более сложное из-за проблем, которые могли случаться при развертывании. В некоторых случаях внесение изменений в схему MySQL занимало заметно больше времени, чем планировалось (изменение больших таблиц, перестройка индексов, отмена ограничений на миграцию данных и т.д.). Иногда после изменения схемы и попытки перезапустить сервер он не запускался из-за каких-то непредусмотренных проблем с развертыванием, конфигурацией или схемой, которые не давали ему работать. А в некоторых случаях новая версия нашего программного обеспечения оказывалась неработоспособной, поэтому для восстановления сервиса нам приходилось снова менять схему MySQL (чтобы привести ее в соответствие с предыдущей версией) и вновь разворачивать предыдущую версию системы.

Это вторая часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление читайте тут.

Когда мы только запускали Wix, был использован стек Tomcat, Hibernate и Ehcache c базой данных MySQL и фронтендом на Flash. Почему мы выбрали этот стек? Да просто потому, что у нашего первого бэкенд-разработчика уже был опыт работы с ним. Частью этой архитектуры был Ehcache – отличная кэш-библиотека для Hibernate и JVM, которая создавала абстракцию в виде карты для кэша памяти и которая могла также быть сконфигурирована как распределенный кэш. Ehcache, в отличие от Memcached, запускается как процесс в JVM и в точности реплицирует состояние кэша для всех узлов кластера. Обратим внимание, что в то время (около 2006–2008 гг.) Encache все еще был независимым open source проектом и не был частью Terracotta (в рамках Terracotta модель репликации и дистрибуции может быть иной, но для данной статьи это не столь важно).

Аспекты использования кэша

Поскольку у нас уже были реальные клиенты, мы установили два сервера Tomcat для обеспечения дополнительной надежности. Следуя правилам выстраивания архитектуры, мы установили распределенный Ehcache-кластер между серверами. Мы исходили из того, что MySQL работает медленно (как и любая другая SQL-система), а значит кэш оперативной памяти обеспечит гораздо более высокую скорость чтения и снизит нагрузку на базу данных.

Привет! Сегодня мы начинаем серию постов от наших инженеров о масштабировании Wix. Наша аудитория росла динамично: конструктор сайтов Wix был создан в 2006-м году, в 2009-м году аудитория нашего сервиса составила 1 миллион пользователей, а сегодня эта цифра достигла уже 80 миллионов. О нашей архитектуре на каждом этапе разработки расскажет в серии постов о масштабированиии главный архитектор программного обеспечения Wix Йоав Абрахами.

Когда мы в 2006 году запускали Wix, не было четкого понимания, какая именно реализация конструктора Flash-сайтов окажется рабочей, и что на самом деле означает сделать WYSIWYG конструктор сайтов. Мы были заняты разработкой двух Flash-приложений: одно для редактирования сайтов (оно создавало представление сайта в виде XML-документа) и другое для отображения сайтов (на основе XML-документа). Большая часть разработки велась на Flash. Помимо этого, нам также был необходим сервер для хранения и обработки XML-файлов на основе шаблона URL или домена сайта. Наш первый бэкенд-инженер построил этот сервер на Tomcat, Hibernate, Ehcache и MySQL. Кроме того, в основе нашего сервера был его собственный фреймворк, который генерировал файлы-сущности Java из HBM-файлов Hibernate, что делало возможным добавление нового кода путем наследования из сгенерированных классов.

Привет, Хабр! Это первый пост конструктора сайтов Wix, сегодня мы расскажем о том, что представляет из себя наш продукт с технологической точки зрения, как работают наши инженеры и какие убеждения мы разделяем при разработке и деплойменте (который в Wix происходит каждые 7 минут).

Но обо всем по порядку.