Библиотека сайта rus-linux.net
От SocialCalc к EtherCalc
Глава 2 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: From SocialCalc to EtherCalc
Автор: Audrey Tang
Перевод: А.Панин
Выученные уроки
Ограничения освобождаютВ своей книге "The Design of Design" ("Проектирование процесса проектирования") Fred Brooks аргументированно доказывает утверждение о том, что ограничения могут помочь сфокусировать внимание на процессе проектирования системы и позволяют ускорить его. Это также относится к самостоятельно установленным ограничениям:
Искусственные ограничения задачи проектирования имеют одно замечательное свойство, заключающееся в возможности их пересмотра. В идеальном случае они позволяют разработчику раскрыть невидимые грани проекта, стимулируя творческий процесс.
В ходе процесса разработки EtherCalc такие ограничения были особенно важны для сохранения концептуальной целостности проекта на различных этапах.
Например, достаточно полезной могла показаться идея об использовании трех различных архитектур многопоточных систем с условием, что каждая из них могла применяться для работы с определенным типом сервера (за межсетевым экраном, в облачном окружении и с большим количеством владельцев учетных записей). Однако, такая поспешная оптимизация могла бы значительно повредить концептуальной целостности проекта.
Вместо этого я сфокусировала свое внимание на достижении оптимальной производительности EtherCalc без снижения требований к одному ресурсу и повышения их ко всем остальным ресурсам и, исходя из этого, одновременно работала над снижением затрат времени центрального процессора, оперативной памяти и сетевого трафика. В итоге благодаря тому, что для работы системы после оптимизаций требовалось менее 100 МБ оперативной памяти, она могла без лишних сложностей использоваться даже на таких встраиваемых системах, как Raspberry Pi.
Это самостоятельно установленное ограничение сделало возможным развертывание EtherCalc в окружениях PaaS (т.е., на сервисах DotCloud, Nodejitsu и Heroku), где ограничиваются объемы всех трех ресурсов вместо одного. Данное обстоятельство, в свою очередь, позволило сделать процесс развертывания людьми персональных сервисов электронных таблиц достаточно простым и, таким образом, привлечь независимых пользователей к процессу разработки.
Худшее является лучшимНа конференции YAPC:NA 2006 в Чикаго мне было предложено поделиться соображениями о будущем приложений с открытым исходным кодом и вот мое мнение:
Мне кажется, хотя у меня и нет доказательств, что в следующем году в рамках стандарта JavaScript 2.0 будет представлена возможность самостоятельного запуска приложений, их независимой работы, компиляции для работы с окружением JavaScript 1, причем этот язык заменит Ruby и станет основополагающим инструментом для создания приложений, работающих во всех окружениях.
Также мне кажется, что сервисы CPAN и JSAN объединятся; JavaScript станет стандартным языком для реализации всех динамических языков, поэтому вы сможете разрабатывать приложения на языке Perl для работы в браузере, на сервере и в базах данных с помощью одного и тем же набора инструментов разработки. Как вы знаете, худшее является лучшим, поэтому худший язык сценариев просто обречен стать лучшим.
Это предположение стало реальным в 2009 году после появления новых интерпретаторов языка JavaScript, работающих со скоростью, сопоставимой со скоростью исполнения машинных инструкций. На момент написания данной главы язык JavaScript может рассматриваться как язык для "однократной разработки и повсеместного запуска" приложений с использованием виртуальной машины - другие популярные языки могут компилироваться для работы с его виртуальной машиной практически без потерь в плане производительности приложений.
В дополнение к браузерам на стороне клиента и фреймворку Node.js на стороне сервера, JavaScript также применяется в системе управления базами данных Postgres, предоставляя огромную коллекцию модулей для свободного повторного использования, разделенных между этими окружениями исполнения.
Что же спровоцировало такой стремительный рост сообщества? В ходе процесса разработки EtherCalc и исходя из опыта взаимодействия с зарождающимся сообществом NPM, я сделала вывод о том, что рост сообщества произошел именно из-за того, что язык JavaScript устанавливает малое количество строгих правил и может адаптироваться к различным вариантам использования, поэтому лица, занимающиеся реализацией инноваций, могут сфокусировать свое внимание на конструкциях и идиомах (т.е., элементах, специфичных для фреймворков jQuery и Node.js), при этом каждая команда разработчиков может отделить важные элементы языка от стандартных элементов, которые могут использоваться достаточно свободно.
Новым пользователям предоставляется очень простой набор элементов языка для начала работы; опытные разработчики сталкиваются с задачей создания лучших соглашений на основе существующих. Вместо ожидания от основных разработчиков языка создания его завершенной реализации, подходящей для всех вариантов применения, процесс развития вспомогательных элементов языка JavaScript перекликается с широко известной максимой от Richard Gabriel: "Худшее является лучшим".
LiveScript, ReduxВ отличие от прямолинейного синтаксиса языка Perl в рамках программного компонента Coro::AnyEvent, API фреймворка Node.js на основе обратных вызовов функций требует осуществления глубоких вложений функций, которые впоследствии сложно повторно использовать.
После экспериментов с различными библиотеками управления ходом исполнения кода, я в конце концов решила данную проблему, применив новый язык LiveScript, который позволяет выполнять компиляцию кода в код JavaScript и имеет синтаксис, сформированный под вилянием языков Haskell и Perl.
Фактически, было произведено портирование EtherCalc с использованием четырех языков программирования: JavaScript, CoffeeScript, Coco и LiveScript. На каждом этапе портирования применялись более выразительные синтаксические конструкции, причем поддерживалась полная обратная совместимость благодаря таким проектам, как js2coffee и js2ls.
Из-за того, что код LiveScript компилируется в код JavaScript, а не происходит интерпретация собственного байткода, он остается полностью совместимым с профайлерами уровня функций. Производительность генерируемого его средствами кода сопоставима с производительностью оптимизированного вручную кода JavaScript, при этом используются все возможности современных интерпретаторов.
В плане синтаксиса LiveScript позволяет устранить вложения обратных вызовов функций путем введения таких инновационных конструкций, как обратные вызовы (backcalls) и кскады (cascades). Он предоставляет в наше распоряжение мощные синтаксические инструменты для совмещения функционального и объектно-ориентированного кода.
Когда я впервые столкнулась с LiveScript, я отметила, что он похож на "упрощенный подвид языка Perl 6, пытающийся выйти за рамки этого языка" - задача значительно упрощалась благодаря применению тех же семантик, что и в самом языке JavaScript, вместе с уделением внимания эргономичности синтаксических конструкций.
ЗаключениеВ отличие от проекта SocialCalc с четко сформулированной спецификацией и командой для осуществления процесса разработки, проект EtherCalc был экспериментом отдельного разработчика, продлившимся с середины 2011 года до конца 2012 года и предназначенным для получения практических доказательств готовности фреймворка Node.js к промышленному применению.
Неограниченная свобода этого эксперимента обусловила уникальную возможность исследования широкого круга альтернативных языков программирования, библиотек, алгоритмов и архитектур. Я очень признательна всем участникам процесса разработки, помощникам и пользователям, а в особенности Dan Bricklin и моим коллегам по проекту Socialtext за одобрение моих экспериментов с этими технологиями. Спасибо вам, ребята!
Вернуться к началу статьи.