pushBridge.IO — Единый API на РНР для всех облачных push-сервисов

15 Январь 2012 11 comments

Приветствую всех читателей. Сейчас в веб-разработках столько трендов, что не уследишь. Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта. Простейший способ - поставить один из широко доступных открытых comet-серверов, например, Dklab_Realplexor, Socket.IO или Faye - что кому по душе или в зависимости от стека технологий. Правда это путь достаточно сложных проектов, где команда может себе позволить такое решение.

Для многих проектов попроще (хотя это всегда вопрос конкретики приложения) логично будет использовать сторонние решения. А проще - арендовать как услугу функционал comet-сервера. Сегодня недостатка в таких сервисах нет, так что нам есть что обозревать.

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

Таких сервисов всего 6: Pusher, Pubnub, Partcl, BeaconPush, X-Stream.ly и ioBridge (с некоторыми особенностями). Под катом - кратки обзор всех сервисов, особенностей РНР-библиотек для них и описание библиотеки pushBridge.IO для унификации работы со всеми облачными пуш-сервисами.

Читать далее...

7 трендов веб-разработки 2011: Инструменты прогрессивных девелоперов. Статья для журнала Хакер.

27 Ноябрь 2011 Comments off

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Тренд 1. noSQL

К современным сервисам и в том числе стартапам, которые только набирают аудиторию, предъявляются колоссальные требования по части отказоустойчивости. Они должны выдерживать большие и очень большие нагрузки. Одним из самых трендовых способов увеличить быстродействие системы стал отказ от использования медленных 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-а.

Тренд 2. Serverside JavaScript

Веб-разработчики давно поняли всю мощь JavaScript. Во многом благодаря этому языку стало возможным реализовать в веб-окружении самые разные приложения, которые ранее существовали только в виде десктопных программ. В то время как для реализации бэкэнда используется самый разный набор технологий, в создании фронтенда (т.е. внешнего вида приложения) все равно так или иначе всегда используется JavaScript. Пытливые умы почесали голову и подумали: а не будет ли легче использовать JS более универсально: и на клиенте, и на сервере? Он гибкий, что позволяет писать код в разных парадигмах: от обычного процедурного до ООП в смеси с функциональным стилем. Но, что важнее всего — это асинхронность и неблокируемость. Сравни это с обычным PHP-скриптом, которые непременно блокируется: например, в ожидании выборки из базы данных или ответа от другого сервера. Код выполняется последовательно: пока не будет получен ответ, сценарий будет тупо простаивать. В случае с JavaScript ты просто указываешь, какую функцию необходимо выполнить, когда произойдет определенное событие, и все. В это время другой код может спокойно выполняться. Чтобы работать с событиями и обработчиками событий было проще, были разработаны специальные платформы. Одним из самых продвинутых фреймворком для серверного JS стал Node.JS (подробнее о нем ты можешь прочитать в #139 номере ][). В основе его лежит V8, движок JavaScript, который используется в браузере Google Chrome и благодаря которому он работает невероятно быстро. Конкуренцию ему составляет другое решение, RingoJS. Этот движок работает поверх Java-машины, а многие из стандартных библиотек вполне совместимы с Node.JS. Java многим кажется более интересным решением, так как для нее написано великое множество библиотек и даже серверов, а работа с памятью, множеством процессоров и потоков гораздо более оптимизированная, чем у новичка Node. А вот кто лучше, пока не известно.

Тренд 3. Развертываемость и расширяемость

Облака — главный тренд не только в разработке, но и вообще всей отрасли ИТ в принципе. 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 или даже работаешь через библиотеку для любимого языка – а хостинг повинуется сам, выделяя все, что запросишь. А создание таких библиотек, которые бы прозрачно работали с разными интерфейсами разных провайдеров, само по себе тренд в разработке.

Тренд 4. Социализация разработчиков

Обрати внимание, что такие раньше традиционные друзья разработчика как FTP и SVN стремительно теряют популярность. Теперь многие делают это через систему контроля версий Git. Поправил файлик, добавил немного гениального кода и хочешь его выкатить на сервер? Сначала закоммить его в git-репозиторий, напиши комментарий, что там хорошего ты накодил, а потом только разверни на сервере, снова-таки при помощи git-а. И ведь реально удобно – и разработка, и деплой идет при помощи одной системы. Все в командной строке. Посмотрев на популярность сервиса Github (github.com), многие провайдеры, чтобы привлечь разработчиков и облегчить им жизнь стали разворачивать у себя git-репозитории как единственную возможность что-то залить на сервер. Ну, теперь хоть не будет криков, что снова Вася не то залил на сервер и все перестало работать. Да и чего таить, сам подход к разработке кода немного поменялся. Если раньше все твои друзья сидели уютно и кодили что-то там втихаря, теперь большинство перебралось на сервисы вроде GitHub-а и занимаются «социальным кодингом». С приходом Git-а стало намного проще следить за прогрессом твоих любимых библиотек. Если что-то надо срочно поправить в чужом коде, так без проблем: кнопка «форк» теперь так же близко, как и кнопка создание тикета. А чтобы автор заморского чуда принял твои правки, не нужно долго на ломаном английском объяснять, что ты сделал конфетку из его непонятного кода. Просто отправь ему пулл-реквест и если все хорошо, твой код быстро попадает в основную ветку. Github стал настоящим прорывом, потому что собрав в очень удобном веб-интерфейсе все, что надо матерому гику-программисту. И что еще важно он добавил острое блюдо социальщины. Теперь не нужны все эти твиттеры и фейсбуки: для многих разработчиков (прежде всего OpenSource) Github стал местом жизни, общения и тут же, не отходя от кассы, кодинга. А все потому, что выстраивая все же среду для совместной разработки кода, Github не прячет людей за всеми этими коммитами и чекаутами, а активно их выталкивает на поверхность. Согласись, очень приятно видеть свою аватарку или фотку возле каждого принятого патча в важный проект.
Да и работать с кодом можно прямо в браузере – например, через систему Cloud9 (c9.io). Это такая среда для кодинга прямо в браузере, которая изящно дополняет GitHub и позволяет реально вести разработку с любого места, где есть интернет. Теперь не важно, какой у тебя комп, хоть даже нетбук с GoogleOS, на который ничего не поставить, а программировать все равно можно. Одним кликом подключаешь к ней свой GitHub-аккаунт - и продолжаешь работу.

Тренд 5. Даешь сокеты!

Любой веб-приложение теперь должно работать в браузере. Без задержек и тормозов, иначе все пользователи сразу разбегутся. Сейчас есть немало решений, позволяющих реализовать реалтайм для веба, но самой прогрессивной технологией являются веб-сокеты (WebSockets).  Ага, все уже устали, что в браузере у тебя есть только HTTP и ничего больше, да и тот урезанный и затиснутый в ограничения безопасности. Конечно, вражеский Flash заботливо подсуетился и предложил альтернативу, но кому он теперь нужен. В этом году все хотят полного реалтайма, чтобы ты только успел подумать, а на сервере уже все отправилось и обратно вернулось. Этого не может обеспечить привычный HTTP, так как ему нужно на каждый чих создавать новое соединение, а это снова и снова пару килобайт данных гонять туда-сюда и ждать в среднем полсекунды. Создатели обычных программ потирают руки - у них-то есть полный доступ к системе, ничем не ограниченый и они используют сеть сразу напрямую на низком уровне. Не долго они радовались, в HTML 5 появился раздел WebSockets, который почти те же сокеты только сразу у тебя в браузере, на любой веб-странице. Один раз соединившись с сервером, ты можешь держать открытым канал передачи (в обе стороны между прочим) как угодно долго и пересылать по нему любые данные. Без задержек, сразу, мгновенно, как позволяет твой интернет. Но вот в чем проблема – разработчики кинулись делать всякие штуки, вешать на них ярлык реалтайма (то есть – очень быстрые и без перезагрузки страницы), а сервера то для них нет. Любимый Nginx, хоть и добравшийся уже до версии 1.0.3, что в мире опенсорс и постоянной беты просто событие, увы, никак не умеет работать с сокетами. И дело не софте – все существующие веб-сервера просто не умеют рулить в ситуации, когда клиенты не просто пришли, сделали запрос и отвалились до следующего сеанса связи (пусть даже раз в секунду, по меркам сервера это очень много времени), а постоянно висят на связи. Даже когда данных нет, а все равно, сокет открой да держи, а вдруг в следующую секунду или полчаса что-то произойдет, о чем пользователь хочет узнать мгновенно! Вот тут то и пригодился новооткрытый JavaScript на стороне сервера – на Node.JS такие вещи делаются просто несколькими строками, а соединений пусть и постоянно открытых, он может держать столько, сколько позволит тебе ресурсы
сервера (размер памяти и настройки ядра ОС и сетевого стека).

Тренд 6. Использование функциональных языков

Кроме обычных для всех языков, пусть и сдобренных примочками для поддержи новомодных технологий, сейчас трендово пробовать новые языки и приемы программирования, использующие асинхронность. Для 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. Мобилизация - главный тренд года

 

Портативные устройства реально уже захватили мир, поделив его между яблочниками и роботами. А вот дизайнерам и разработчикам приходиться поддерживать оба лагеря. Хорошо, что им на помощь пришли программисты. Сегодня почти все топовые JS-фреймворки (jQuery, ExtJS, Dojo) имеют мобильные версии, часто совместимые по API с обычными, что позволяет просто заменой файла подогнать сайт под требования мобилок. Самым ожидаемым является jQuery Mobile (сейчас он в версии alpha 4.1), который заявлен по все платформы, включая экзотику для нас типа Blackberry и вряд ли существующий Windows Phone, webOS, bada и другие. Будучи расширением, а по большому счету, очень крутым плагином для jQuery, он стандартизирует API на различных устройства их и браузерах (а в мобильном мире браузеры это вообще кошмар, так что браузерные войны на десктопах это только цветочки), а также дает в руки нерадивым разработчикам строгий гайдлайн на интерфейс. Потому большинство веб-приложений будут выглядеть стандартно так, чтобы юзер не искал на своем маленьком экране минуту кнопку назад или отмена. Правда, есть еще проблемы с производительностью – если некоторые жалуются на тормознутость в обычных браузерах, то что говорить про маломощные мобилки. И конечно все эти библиотеки поддерживают модные нынче тач-экраны, так что смело везде тыкай – оно работает!

Облачные интерфейсы на заметку

Если ты хочешь использовать возможности облачных сервисов в своих проектах, советую тебе воспользоваться некоторыми полезными вспомогательными инструментами.
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 или даже на чистом РНР.

Жизнь после MySQL: выбираем замену для популярной СУБД. Статья для журнала Хакер

30 Май 2011 12 comments

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Oracle, купив Sun, подготовило закат солнца вручную, медленно убивая самую лучшую СУБД в мире – MySQL. Но что делать, если очень хочется быстрой и свободной базы, но без  призрака оракла за спиной?

Твой любимый форум работает на MySQL (на мускуле, если кратко), а на работе или в вузе крутиться система учета чего-либо, написанная твоими друзьями под пиво и за получение зачета? И тоже на мускуле? Да в вебе тысячи и миллионы сайтов используют MySQL как базу данных. Но что будет теперь, когда ненавистный и глубоко противный истинным опен-сорсникам Oracle купил многострадальную Sun, а заодно и наш с тобою любимый мускул? От неудачников, кинувших даже ЦРУ, не стоит ждать качественного развития свободных проектов. Да-да, я отвечаю за базар – первым проектом молодой компании Oracle была разработка по заказу разведчиков какой-то учётной системы, за которую на конкурсе другие компании просили под 2 млн, а молодой Ларри Элисон заносчиво запросил за все жалкие 300 тысяч. Стоит ли говорить, что проект был провален, зато компания получила стартовый капитал и начала свое восхождение. Хотя уже поздно бить тревогу, все пацаны давно в курсе, что лучший (читай – наименее ущербный) движок для хранения данных в мускуле – это InnoDB, права на который у Oracle были давным давно. Так что, если ты сейчас чешешь репу, что бы выбрать взамен MySQL, ты удачно открыл журнал, я расскажу, чем можно заменить поделие империи зла. Но не беги с криками «да ваш мускул г…, бери слона (PostgreSQL) и будет все зашибись» - сейчас столько кода написано с поддержкой мускула, и зачастую в виде единственной базы данных, что переписать или искать замену себе дороже, а часто просто невозможно. Хорошо, если это форум или блог, обычно там сразу поддержка нескольких систем, а если что-то самописное и заточенное под возможности именно MySQL? Так что задача у нас с тобой самая что ни на есть простая – сохранить мускулы, но прокачав их так, чтобы не зависеть от старшего тренера и его стероидов. Oracle, конечно же, выступила с заявлением,  что все в порядке и будут развивать все по старому, но никто как всегда не поверил. Даже быстрый выпуск версии 5.5, которую многие ожидали, не дал положительных результатов – старые баги как были, так и остались, но по маркетинговым заявлением все ОК.

Разработчики и идеологи самого мускула далеко не дураки и сами предвидели ситуацию, что после поглощения всем будет не очень сладко, поэтому некоторые решили покинуть от греха подальше компанию и основать свои проекты, прихватил тогда еще свободные коды MySQL. Таким образом, сейчас есть несколько проектов, которые взяли за основу оригинальный сервер, но постепенно дописывали или переписывали все, до чего могли дотянуться. И первым делом – освободились от бремени InnoDB, правами на который обладает тот самый Oracle. На замену ему выкатили несколько движков, основной из которых – MariaDB. Читать далее...

HTML5: да придет спаситель — статья для журнала Хакер

5 Апрель 2011 3 comments

 

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Интернет устарел и об этом все знают! Сначала думали, что все обойдётся, но когда в Сети появились толпы людей, которых не интересовали скучные технические отчеты и документация, это стало очевидно. Сеть требовала красоты и функциональности – изображений, анимации, видео и аудио. Чтобы показать на странице все, что взбредет в голову дизайнера, приходиться очень напрягаться и разработчикам браузеров и составителям стандартов. Так, из обычного формата разметки текста, HTML превращался в мультимедийного гиганта, на базе которого делали страницы интернет-магазинов, банковские системы, он-лайн игры и твои любимые порносайты. Возможностей стандарта HTML 4 уже мало, но как по мне, он устарел сразу в момент создания. Первыми фишку потребностей народа просекли в Macromedia, давно купленной гигантом Adobe, выпустив сначала Shockwave, а потом и Flash, теперь уже именуемой платформой (раньше это был всего лишь плагин к браузеру и уродский простенький язык программирования анимации).

Flash дал то, что всем так хотелось – видео, звук и анимацию, возможности программировать графику и создавать более-менее реальные приложения. Для особо одаренных есть возможности объединить javascript и Flash (замечу, очень по уродливому и ненадежно), таким образом дополняя упущения разработчиков браузера. Видео заполонило мир, Youtube, Фейсбук и вКонтакте стали самыми популярными сайтами - ага, из-за флеша, потому что без видео и приложений, которые почти все флешевые, они нафиг не нужны.

Но разработчики стандарта HTML тоже просекли фишку - надо дать народу новый стандарт, чтобы все делали свое дело не уходя из обычной платформы браузера во всякие Flash/Silverlight/JavaFx. А то иш ты, наплодили своих плагинов, соревнуются в разных фишках, хотя, по честному, все это костыли и предназначение у них лишь одно, пофиг какая технология, лишь бы видео и звук был. Ладно, еще 3D графику и будет круто! Пользователям это нужно ставить, обновлять и вообще, браузер из основного окна в мир сети стал ненужной прослойкой для запуска приложения на флеше или сильверлайте (а разработчики это давно смекнули, потому добавили возможность работы вообще вне браузера - Adobe AIR и Desktop-режим в Silverlight).

Короче, ну ты понял – сети потребовался новый стандарт взамен устаревшего HTML. Его и придумали, незатейливо обозвав HTML5. Это уже не только и не столько язык для разметки страниц и их форматирования, но и руководство для разработчиков браузеров, какие возможности они должны предоставлять странице и выполняемому там коду. Javascript хоть, хорошо, оставили как основной скриптовый язык. При этом вторгаясь в совсем не HTML область, поручили браузеру дать невиданные возможности скриптам. Отныне работа с видео и звуком, двух и трехмерной графикой, анимацией, эффектами, сетью на низком уровне – все это должно быть доступным в обычном JavaScript. Читать далее...

Twitter — построение высокопроизводительной архитектуры.

6 Март 2011 7 comments

Приветствую своих читателей. График новых постов совсем сбился, это всецело моя вина. В закромах есть уже два материала готовых, ожидаю когда будет публикация на сайте журнала Хакер, с которым я теперь сотрудничаю. А сегодня я предлагаю краткий но интересный пост об архитектуре Twitter-а. Основой послужил это  материал, крайне рекомендуемый для прочтения всем - Архитектура Twitter. Два года спустя (Иван Блинков, сайт http://www.insight-it.ru).

Cтатистика (взято из insight-it.ru):

  • 752% рост аудитории за 2008 год
  • 1358% рост аудитории за 2009 год (без учета API, по данным comScore)
  • 120 миллионов зарегистрированных пользователей
  • 9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
  • 70 миллионов твитов в день (800 в секунду в среднем, пики до 2000)
  • Каждый твит читают в среднем 600 раз, то есть 1.2 миллионов показов твитов в секунду
  • 600 миллионов поисков в день
  • Лишь 25% трафика приходится на веб сайт, остальное идет через API
  • 6 миллиардов запросов к API в день, около 70 тысяч в секунду

А с помощью чего это достигается? Читать далее...

Приложение из титана. Создаем программы с помощью новой платформы Titanium. Статья для журнала Хакер

12 Декабрь 2010 7 comments

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Развелось сегодня разных платформ, немеряно просто. У каждого уважающего себя пацана стоит Linux, у странных личностей все еще пыхтит винда, а вероотступники пересели на MacOS и смотрят на всех свысока. Черт, а загляни в карман – там этих гаджетов тоже немало. Кульный iPad, вместе с собратьями, Google лезет во все щели на рынок со своим Android OS, а еще есть никому не понятные но популярные у буржуев Balckberry и, тьфу тьфу, Windows Mobile. Зоопрак прям, верно? А ты просто бедный программист, потому что очень ведь хочется написать один раз программу, воплотить свой шедевр, и потом легким движением руки запускать ее везде. Да, есть java, на которой думалось, что все будет везде работать, но фиг там, не особо получилось. Если на десктопах еще более менее (а сколько ты знаешь массовых программ на Java, которые везде одинаково работают – Eclipse да и все), то с мобильной стороной у Java все очень плохо, и даже JavaFX не помогает. Хотя внутри Андроида и лежит Java, но и там она сильно урезанная и подогнанная под возможности мобилок. Так что, если захочешь писать под все это разнообразие, готовься учить под каждую платформу свой язык, компилятор, ограничения платформы и API, в отдельных запущенных случаях еще и среду разработки и саму платформу, ведь для iPad/iPod/iPhone особо не попишешь без реального устройства и железного мака (на виртуалку не надейся, много заморачиваться надо).

Но лень, как говориться, двигатель всей ИТ-мысли, поэтому появились предприимчивые парни из стартапа Appcelerator, которые выложили в открытом виде специальный фреймворк и систему разработки Titanium. С ним жизнь сразу становиться лучше и светлее – ты пишешь программу один раз, используя только одно API, а потом компилируешь одним кликом, а в результате все работает на любой платформе. Интересно узнать как?

Читать далее...

Атака на другой мир или серверный JavaScript. Статья в журнал Хакер

24 Октябрь 2010 5 comments

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Не просто JavaScript

Привет! Если ты сегодня, от нечего делать и летнего зноя решил вдруг чего-либо понаделать для веба, то кроме холодного пива, понадобится еще и выбрать себе язык программирования. Ты, конечно, крут и знаешь все модные течения – Ruby на своих рельсах гордо едет миром,  поклонники Питонов шарахаются в сторону и превозносят Django. Кучка людей в строгих костюмах – это любители Java, к ним не ходи, замучаешься писать и отлаживать код, прежде чем твоя поделка выдаст хоть бы Hello world. ASP.NET вообще не котируется, но, говорят, кто-то и на нем пишет.

Конечно, есть всеми любимый РНР – что может быть легче для веб-сайта! Но скажи честно, как-то не тянет, правда? Ведь чтобы сделать что-то стоящее, простого РНР не хватит, надо и Ajax прикрутить, чтобы на сайте кнопочки и формы сами грузились и работали незаметно. А ведь он не очень хорош, когда вдруг к тебе ломанется много народу. А все потому, что РНР (как и подавляющее большинство других языков, на которых пишут сайты) даже в 21 веке работает по классической схеме. Запрос страницы заставляет веб-сервер поднять указанный скрипт, выполнить его (линейно, строка за строкой весь твой код), а результат возвращает браузеру. После этого скрипт «умирает», а следующий запрос снова запустит всю эту адскую машинку. Если ты не в курсе, это называется CGI (интерфейс взаимодействия веб-сервера и интерпретатора твоего языка, на котором написана страница). Штуки вроде FastCGI, расширяют протокол, позволяя избегать выгрузки скрипта после первого запроса. Таким образом, когда второй пользователь запросит ту же страницу, для него будет уже все готово, останется только выполнить скрипт с новыми параметрами. Но это все не то…

Читать далее...

Очереди сообщений — современный тренд в области веб-приложений.

24 Август 2010 7 comments

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

The Art of Message Queues - для тех, кто хочет вообще понять, о чем речь, когда говорят про сообщения, очереди и брокеры. Хорошее введение в тему.


Читать далее...

Я убью тебя, Google Reader! Высоконагруженный сервис своими руками. Статья для журнала Хакер.

18 Июль 2010 Comments off

Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант,  без правок или ограничения на объем материала.

Шеф, что делать будем?

Получение новостей через фиды или RSS-ленты сегодня самый быстрый и простой способ следить за жизнью любимых сайтов или блогов. Твиттер, конечно, крут, но рсс-кам ещё рано умирать. Сегодня у тебя большой выбор - RSS можно читать кучей способов, начинаю  от почтового клиента (да, в Mozilla Thunderburd 3 встроен клиент) и браузера, заканчивая специальными программами и онлайн сервисами. Самым крутым из таких будет, конечно, Google Reader. Пользоваться им вроде бы легко - вводишь адрес сайта и отныне просто заходи и читай новости, никакой кнопки Refresh жать не надо, гугл сам позаботится о том, чтобы найти новые новости и показать их тебе. Но при этом у него есть много врождённых проблем, например, не очень интуитивный интерфейс, а также часто сильные задержки в получении новых сообщений. Особенно это касается лент из Твиттера. Ага, популярнейший сервис также вовсю использует RSS, транслируя туда твои сообщения. Но ведь ты уже в курсе, как быстро там все изменяется - написал о новом хаке винды, а через минуту уже весь интернет с криками "ура!" бросается ломать империю Билли. Но читатели через Google живут в параллельном мире и просто тормозят - там лента из твиттера обновляется часто с задержками в минуты и часы, непорядок!

Давай напишем для себя любимого (ну и друзей, куда ж без них) простую онлайновую читалку RSS-новостей. Фичами будет возможность автоматически находить фиды с любого адреса (если они там есть, конечно) и  полное игнорирование нюансов форматов ( мы сможем работать с любым фидом). Кроме этого, научимся высшему пилотажу РНР-программирования - созданию распределённых систем. Когда у тебя две-три ленты, с ними справиться даже твой нетбук, но когда друзья поймут, что гугл теперь отстой, и начнут добавлять свои ленты, станет плохо. А мы сделаем так, что читалка будет работать с любым количеством лент, просто успевай доставлять сервера! Помнишь, мы не раз рассказывали тебе про облачный компьютинг, Amazon EC2 и прочие заморские технологии? Вот с их помощью это сделать очень легко - нажав кнопочку и у тебя уже два сервера вместо одного. Используя РНР и немного магии, ты сможешь заставить работать на наше благо столько серверов, сколько достанешь. Читать далее...

Веб-приложения реального времени: jSocket,Node.JS, Redis, MQ. Часть 2.

Приветствую своих читателей. Сегодня мы продолжим начатую ранее тему о веб-приложениях реального времени и поговорим о серверной части. Буквально на днях по аське у меня состоялся разговор по теме онлайн игр и архитектуры движка для реалтайм игры. Оказалось, мы оба думали про одно и то же, а именно, использование NodeJS как сервера для ядра системы, обслуживающего клиентские подключения. Конечно, построить весь технологический стек современной браузерной игры полностью на NodeJS все ещё затруднительно, да и сам процесс написания масштабных приложений на серверном JS еще не изучен. А вот держать комет-подсистему, которая отвечает за мгновенную доставку нужных данных клиентам - для этого Node  подходит идеально. Но давайте отложим рассмотрение этой части, здесь тема не на одну статью, а поговорим про создание распределенной системы обмена данными для серверной платформы. Читать далее...

�������� ������� Developers.org.ua | BlogMemes.ru | | | ��� �������� ������ | ���������� ��������� ������ � ����� |