7 трендов веб-разработки 2011: Инструменты прогрессивных девелоперов. Статья для журнала Хакер.
Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант, без правок или ограничения на объем материала.
К современным сервисам и в том числе стартапам, которые только набирают аудиторию, предъявляются колоссальные требования по части отказоустойчивости. Они должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных SQL баз данных и переход там, где это возможно, к технологии noSQL. Это было сложно представить еще несколько лет назад, когда был только один memcache, теперь же настолько очевидно, что многие не перестают удивляться: "Как это мы не дошли до этого ранее?" Ведь для большинства веб-приложений вовсе не нужны все эти множества типов данных и средств их выборки. Иногда ты просто хочешь сохранить данные и иметь к ним доступ с минимальной задержкой и высокой надежностью. SQL-запросы, как ни крути, даже при оптимизации, выполняются относительно медленно (если взять профайлинг работы MySQL, то даже самый простой запрос на выборку почти 45% времени занимается парсингом SQL-а). При этом зачастую для хранения данных вполне достаточно самой простой структуры - пара "ключ-значение". Это фундамент любой noSQL технологии: memcached, Membase, Riak или CouchDB – все работают именно так. Интерфейс доступа к такой базе также максимально прост – обычно это простейшие команды типа get (получить данные по ключу), set (записать данные с ключом), delete (удаляет ключ и его данные), update (обновляет уже существующие данные). Решения noSQL оказались не только очень быстрыми, но еще и легко масштабируемы. На низком уровне такие базы строятся на базе хеш-таблиц и их разновидности – распределенной хеш-таблицы (DHT). Свойства DHT такие, что можно присоединять новые сервера постоянно, и такая база будет расти и расти. Столько - сколько надо. При этом в самих приложениях ничего менять не надо, все делается автоматически! Если очень нужна сохранность данных, можно пожертвовать несколькими серверами, тогда они будут хранить дубликаты данных. Например, Riak-у можно указать, сколько минимум серверов должно сразу сохранить данные, прежде, чем сервер ответит тебе, что все ок. Это очень важно, потому что если приложение не может одинаково хорошо работать и на одном, и на тысяче серверов, то оно не масштабируемо. А значит при неожиданно высокой нагрузке, оно ляжет и уже не сможет восстановить работу, даже при покупке новых серверов. В то время как обычные СУБД просто рвутся на части и подпираются костылями, чтобы работать хоть на паре десятков серверов сразу, то практически любое noSQL-решение может спокойно масштабироваться хоть на тысячу серверов. Значение – это стоки, числа или обычное сериализированные данные, например, в формате JSON или более продвинутой структуре вроде messagePak, Google ProtoBuf или Apache Thrift. MongoDB пошла еще дальше – придумав подмену для удобного JSON в виде двоичного формата. Другая разработка - Redis - перевернула понятие key-value хранилищ, добавив к ним простые, но оказавшиеся эффективными и востребованными списки, хэши, сортированные массивы и даже такую чертовски удобную штуку как publish/subscribe. И все это на скоростях более 100 тысяч операций в секунду, над гигабайтами данных и миллионами ключей на обычном железе. Правда, SQL тоже не сдается. Последние версии MySQL достаточно быстрые, а умные головы, поняв, что noSQL не потеснить, решили возглавить движение отказников, включив в версии 5.6.2 memcache-плагин для доступа к данным через простой протокол, а для особых случаев есть HandlerSocket Plugin, который может работать с таблицами гораздо эффективнее, используя легковесный сетевой слой и простой протокол без всякого SQL-а.
Веб-разработчики давно поняли всю мощь JavaScript. Во многом благодаря этому языку стало возможным реализовать в веб-окружении самые разные приложения, которые ранее существовали только в виде десктопных программ. В то время как для реализации бэкэнда используется самый разный набор технологий, в создании фронтенда (т.е. внешнего вида приложения) все равно так или иначе всегда используется JavaScript. Пытливые умы почесали голову и подумали: а не будет ли легче использовать JS более универсально: и на клиенте, и на сервере? Он гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. Но, что важнее всего — это асинхронность и неблокируемость. Сравни это с обычным PHP-скриптом, которые непременно блокируется: например, в ожидании выборки из базы данных или ответа от другого сервера. Код выполняется последовательно: пока не будет получен ответ, сценарий будет тупо простаивать. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Чтобы работать с событиями и обработчиками событий было проще, были разработаны специальные платформы. Одним из самых продвинутых фреймворком для серверного JS стал Node.JS (подробнее о нем ты можешь прочитать в #139 номере ][). В основе его лежит V8, движок JavaScript, который используется в браузере Google Chrome и благодаря которому он работает невероятно быстро. Конкуренцию ему составляет другое решение, RingoJS. Этот движок работает поверх Java-машины, а многие из стандартных библиотек вполне совместимы с Node.JS. Java многим кажется более интересным решением, так как для нее написано великое множество библиотек и даже серверов, а работа с памятью, множеством процессоров и потоков гораздо более оптимизированная, чем у новичка Node. А вот кто лучше, пока не известно.
Облака — главный тренд не только в разработке, но и вообще всей отрасли ИТ в принципе. Cloud-технологии во многом сильно упростили жизнь при создании новых сервисов. Взять хотя бы всем известный Dropbox, разработки которого не стали изобретать велосипед с изобретением технологии для хранения данных, а использовали облачный сервис Amazon S3. Да и понятие «облако» сильно преобразовалось. Раньше можно было купить кучу серверов, объединить их в сеть, поставить поверх Xen и говорить: «вот это и есть cloud». Так и сейчас делает Amazon с их сервисом EC2. Но для многих вообще не нужны никакие серверы, им важна готовая инфраструктура для развертывания разработки из «коробки». Хостинг платформы — вот что модно сегодня. Что это такое? Добрые дяди за тебя уже поставили и настроили все, что может пригодиться для твоего супер-пупер приложения. Взяли несколько языков, типа PHP, Ruby вместе с Rails, обязательный Python и выскочку Node.JS, прицепили традиционную базу данных MySQL, а чтобы эстеты замолчали, добавили немного перчинки в виде NoSQL – MongoDB, Redis или Riak. Поверх поставили memcached, а вместо анахронизма в виде FTP теперь предлагают юзать Git. Управлять этим надо через красивый веб-интерфейс, где просто говоришь им – хочу 5 серверов memcached, два РНР и еще базу данных заверните. Тебе тут же выдают ключи доступа и пароли – и все, git clone && git push и твое приложение уже вольготно себя чувствует на серверах, а ты даже не подозреваешь на чем и где оно крутиться. Это называется Platform as a Service (PaaS) и сегодня самый модный тренд в сфере хостинга и разработки – посмотри на PHPFog, Jelastic (между прочим, продукт наших отечественных разработчиков!), CloudControl, Aptana Cloud, Heroku или Cloudbees. И конечно, все предлагают API, чтобы твоя программа могла сама себе выделять ресурсы, например, добавляя еще одну базу данных или новый инстанс приложения, если у тебя пользователей прибавилось. Просто вызываешь специальный URL или даже работаешь через библиотеку для любимого языка – а хостинг повинуется сам, выделяя все, что запросишь. А создание таких библиотек, которые бы прозрачно работали с разными интерфейсами разных провайдеров, само по себе тренд в разработке.
Обрати внимание, что такие раньше традиционные друзья разработчика как FTP и SVN стремительно теряют популярность. Теперь многие делают это через систему контроля версий Git. Поправил файлик, добавил немного гениального кода и хочешь его выкатить на сервер? Сначала закоммить его в git-репозиторий, напиши комментарий, что там хорошего ты накодил, а потом только разверни на сервере, снова-таки при помощи git-а. И ведь реально удобно – и разработка, и деплой идет при помощи одной системы. Все в командной строке. Посмотрев на популярность сервиса Github (github.com), многие провайдеры, чтобы привлечь разработчиков и облегчить им жизнь стали разворачивать у себя git-репозитории как единственную возможность что-то залить на сервер. Ну, теперь хоть не будет криков, что снова Вася не то залил на сервер и все перестало работать. Да и чего таить, сам подход к разработке кода немного поменялся. Если раньше все твои друзья сидели уютно и кодили что-то там втихаря, теперь большинство перебралось на сервисы вроде GitHub-а и занимаются «социальным кодингом». С приходом Git-а стало намного проще следить за прогрессом твоих любимых библиотек. Если что-то надо срочно поправить в чужом коде, так без проблем: кнопка «форк» теперь так же близко, как и кнопка создание тикета. А чтобы автор заморского чуда принял твои правки, не нужно долго на ломаном английском объяснять, что ты сделал конфетку из его непонятного кода. Просто отправь ему пулл-реквест и если все хорошо, твой код быстро попадает в основную ветку. Github стал настоящим прорывом, потому что собрав в очень удобном веб-интерфейсе все, что надо матерому гику-программисту. И что еще важно он добавил острое блюдо социальщины. Теперь не нужны все эти твиттеры и фейсбуки: для многих разработчиков (прежде всего OpenSource) Github стал местом жизни, общения и тут же, не отходя от кассы, кодинга. А все потому, что выстраивая все же среду для совместной разработки кода, Github не прячет людей за всеми этими коммитами и чекаутами, а активно их выталкивает на поверхность. Согласись, очень приятно видеть свою аватарку или фотку возле каждого принятого патча в важный проект.
Да и работать с кодом можно прямо в браузере – например, через систему Cloud9 (c9.io). Это такая среда для кодинга прямо в браузере, которая изящно дополняет GitHub и позволяет реально вести разработку с любого места, где есть интернет. Теперь не важно, какой у тебя комп, хоть даже нетбук с GoogleOS, на который ничего не поставить, а программировать все равно можно. Одним кликом подключаешь к ней свой GitHub-аккаунт - и продолжаешь работу.
Любой веб-приложение теперь должно работать в браузере. Без задержек и тормозов, иначе все пользователи сразу разбегутся. Сейчас есть немало решений, позволяющих реализовать реалтайм для веба, но самой прогрессивной технологией являются веб-сокеты (WebSockets). Ага, все уже устали, что в браузере у тебя есть только HTTP и ничего больше, да и тот урезанный и затиснутый в ограничения безопасности. Конечно, вражеский Flash заботливо подсуетился и предложил альтернативу, но кому он теперь нужен. В этом году все хотят полного реалтайма, чтобы ты только успел подумать, а на сервере уже все отправилось и обратно вернулось. Этого не может обеспечить привычный HTTP, так как ему нужно на каждый чих создавать новое соединение, а это снова и снова пару килобайт данных гонять туда-сюда и ждать в среднем полсекунды. Создатели обычных программ потирают руки - у них-то есть полный доступ к системе, ничем не ограниченый и они используют сеть сразу напрямую на низком уровне. Не долго они радовались, в HTML 5 появился раздел WebSockets, который почти те же сокеты только сразу у тебя в браузере, на любой веб-странице. Один раз соединившись с сервером, ты можешь держать открытым канал передачи (в обе стороны между прочим) как угодно долго и пересылать по нему любые данные. Без задержек, сразу, мгновенно, как позволяет твой интернет. Но вот в чем проблема – разработчики кинулись делать всякие штуки, вешать на них ярлык реалтайма (то есть – очень быстрые и без перезагрузки страницы), а сервера то для них нет. Любимый Nginx, хоть и добравшийся уже до версии 1.0.3, что в мире опенсорс и постоянной беты просто событие, увы, никак не умеет работать с сокетами. И дело не софте – все существующие веб-сервера просто не умеют рулить в ситуации, когда клиенты не просто пришли, сделали запрос и отвалились до следующего сеанса связи (пусть даже раз в секунду, по меркам сервера это очень много времени), а постоянно висят на связи. Даже когда данных нет, а все равно, сокет открой да держи, а вдруг в следующую секунду или полчаса что-то произойдет, о чем пользователь хочет узнать мгновенно! Вот тут то и пригодился новооткрытый JavaScript на стороне сервера – на Node.JS такие вещи делаются просто несколькими строками, а соединений пусть и постоянно открытых, он может держать столько, сколько позволит тебе ресурсы
сервера (размер памяти и настройки ядра ОС и сетевого стека).
Кроме обычных для всех языков, пусть и сдобренных примочками для поддержи новомодных технологий, сейчас трендово пробовать новые языки и приемы программирования, использующие асинхронность. Для Python-а придумали хорошие ребята Twisted и Tornado, но это уже отстой, для Ruby есть EventMashine, но оно никому не нужно, для РНР сделали phpDeamon с честным fastcgi, Java разродилась своим поделием – Netty, на котором можно сделать все, что угодно. Теперь все это забудь, выбрось – сегодня и завтра будут рулить функциональные языки и платформы. При каждом удобном случае раздвигай пальцы веером и говори, что Erlang рулит и обставляет все, что есть в мире, держа сотни тысяч потоков, гибко и главное, сам расползается, занимая все доступные ядра и даже сервера, а уж видео и прочие реалтайм штуки, так раздает так шустро, как только может железка. Но вот в коде сам черт ногу сломает, а если твой программер уйдет в запой, проект станет, так как людей, кроме пиара, могущих че-то написать и поддерживать на Erlang-е очень мало. Любишь Java? У меня для тебя хорошая новость – Scala, вот что реально круто и нужно всем в мире! Мощный, смешанный объектно-ориентированный и функциональный язык со статической типизацией и встроенной параллельностью поверх JVM, а для особо нуждающихся – к нему добавлен фреймворк Akka. Слышал булшит вроде многопоточность, устойчивость к сбоям, распределенная архитектура, реал-тайм? Иногда это правда - Akka, основанная на параллелизации вычислений в виде акторов (небольшие блоки кода, которые самостоятельно планируются для исполнения по разным ядрам, процессам и даже узлам кластера, ближайший аналог – grenlets из Python). Шутка ли, твиттер наконец слез с Ruby-иглы и переписал большую часть критичного софта на Scala!
И так, поехали!
- JavaScript на стороне сервере (Node.JS, RingoJS)
- Автоматизированные клауд-платформы (AppEngine, PHPFog, Azure, RackCloud)
- Разработка и развертывание кода через Git и Github
- Долой Eclipse, теперь IDE прямо в браузере (Cloud9)
- Real-time везде, где можно (websockets)
- Общий код для сервера и браузера (nowJS, Aptana Jaxer)
- Функциональные языки (Erlang, Scala/Akka, Haskell)
- Мобильные фреймворки для веб-разработки (jQuery Mobile, Dojo.mobile, Sencha Touch, Cappuccino) и приложений (PhoneGap, Appcelerator Titanium)
Тренд 7. Мобилизация - главный тренд года
Облачные интерфейсы на заметку
Apache Nuvem (incubator.apache.org/nuvem) – попытка создать кроссплатформенный открытый интерфейс для работы с разными cloud-платформами, включая Amazon EC2, Microsoft Azure и Google AppEngine. В идеале, твоя программа сможет использовать ресурсы сразу нескольких облаков.
Deltacloud (incubator.apache.org/deltacloud) – решение на Ruby, умеющее работать со всеми известными и не очень cloud-провайдерами. Предоставляет единый REST-интерфейс, который скрывает нюансы разных платформ.
libcloud (libcloud.apache.org) – библиотека для программ на Java или Python, которая работает чуть ли не со всеми в мире известными облачными платформами и унифицирует основные операции по созданию и управлению виртуальными машинами.
Simplecloud (simplecloudapi.org) – если ты все еще программируешь на РНР, то для тебя есть отличный компонент Zend_Cloud, который добавляет базовую поддержку хранилищ данных, очередей сообщений и другие фишки разных cloud-платформ просто в твое веб-приложение на Zend Framework или даже на чистом РНР.
Приветствуем наших читателей! Наконец, после многих проб и даже сомнений, я решил расширять медиа-присутствие нашего блога и завел официальный микроблог проекта на 
Приветствую всех наших читателей, как тех, кто читает с самого начала, так и недавно присоединившихся. У нас небольшой праздник - блогу исполнился ровно год с момента открытия и настало время подвести некоторые итоги и цифры, думаю будет интересно узнать:
Перед вами вторая часть материала о перспективных стартапах (
Приветствую наших читателей. Некоторый перерыв в публикациях был связан с моей командировкой в Киев и последующей срочной работой, впрочем, сейчас я уже могу выкроить время для новой публикации. На этот раз я вспомнил забытой мною рубрике интересных материалов и, посмотрев на открытые вкладки и закладки с тем, что меня заинтересовало, понял, что "забывать дальше" эту рубрику никак нельзя. Ведь сегодня в сети очень много материалов, вместе с этим качественные и интересные ещё нужно поискать. Этим то мы и займёмся. Приятного и, главное, полезного чтения. 
Приветствуем наших читателей. На этот раз пост будет вне всяких рамок нашего блога, от будет касаться личных впечатлений о прошедшем вчера у нас в городе фестиваля 
Свежие комментарии