Alpha-Beta-Release Blog

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

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

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

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

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

Не просто JavaScript

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

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

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

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

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

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

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

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

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

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

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

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

Comet… чё за …?

Сегодня все в Интернете хочет быть быстрым, очень быстрыми. Ты даже не успел загрузить страничку в Facebook или вКонтакте, а твои друзья уже узнают, что ты онлайн и пытаются вызвать в чат. На других сайтах ты можешь видеть уже не просто ники пользователей, а сразу начать с ними общаться – и это не просто личные сообщения, как было в форумах в лихих 90-х, а полноценные чаты типа аське. Добавил Вася новую статью в блог, ленту новостей которого ты читаешь? Она должна сразу появиться у тебя в ридере, если, конечно, ты сейчас его читаешь. Задержка, любое промедление сразу ставит крест на любом ресурсе, нацеленном на общение. Посмотри на всякие конференции стартапов и первые страницы популярных ресурсов  - везде умные слова вроде real-time, collaborative и communication. Что за …?

Отвечаю! Если раньше веб-приложения были, как и обычные сайты – просто страницы и ты должен был ходить по ссылкам, чтобы обновить информацию, разве что по таймеру обновлялись фреймы, то теперь все иначе. Все хотят, чтобы информация приходила к нам сама в момент появления, а не ждать и тыкать сто раз в рефреш, ожидая, когда же твой друг наконец появиться в сети. Такие требования поставили перед разработчиками новые задачи, существенно усложнив жизнь, но, а что делать? Так и родилась технология Comet или, по простому, набор приёмов и средств для обновления данных (страниц или их элементов) в браузере без твоего участия. От тебя надо только залогиниться и зайти на сайт – в социальную сеть, онлайн игру или другой ресурс. От этого момента, если какая-то новая информация появляется, сервер сам отправит твоему браузеру новые данные. Читать далее...

Приветствую свои читателей. Да, у меня снова выдался сложный период и обновлений в блоге не было долгое время, хотя в твиттере я продолжал писать, пусть и не каждый день. Но сейчас праздники, все сервисы, над которыми я работаю, вроде более менее работают, поэтому можно, вместе с отдыхом, подумать при новую статью. Буквально неделю назад я наконец добрался до новой потрясающей штуки - серверного JavaScript и его платформы - Node.JS. Реально, это очень и очень мощная и приятная штука. За последнее время это первый раз когда от программирования получаешь просто удовольствие. Тем более, что писать различные асинхронные штуки на этом движке очень и очень легко.

Для тех, кто не в курсе - Node.JS это серверный интерпретатор JavaScript построенный на базе V8 от Google, дополненный системными библиотеками, неблокирующим асинхронным I/O и прочими вкусностями. И очень, очень быстрый. Несмотря на текущую версию 0.1.93, он уже вполне пригоден для промышленного использования, хоть и со многими оговорками, в первую очередь связанных с отсутствием или сыростью дополнительных библиотек. Также, поскольку развитие идет полным ходом, часть API не стандартизированная и поэтому вы можете запросто потратить полдня на то, что в этой версии часть функций перенесена в другой модуль или изменились параметры функции. Однако это просто детские болезни роста и при должном старании из этого даже получаешь удовольствие. Читать далее...

Приветствую читателей. Погода за окном просто требует чего-то горяченького, поэтому воспользовавшись возможностью что-то по исследовать в свободное время, я решил подумать - а можно ли не останавливая скрипт, подменить функцию, которая выполняется? С таким требованием я встретился чуть ранее, при разработке нашего стартапа. У нас был один из внутренних серверов, который заведовал всеми действиями между пользователями в реальном времени. Это обычный РНР-демон-роутер, который обрабатывал запросы от клиентских запросов (внутри сервера), но была одна сложность - в случае, когда я что-либо изменял в коде сервера или обработчиков отдельных команд, демон приходилось перезагружать, что означало отключение текущих клиентов и потеря информации о состоянии сервера (этот вопрос решаемый, конечно). То же самое было в случае ошибки в коде - все подключенные пользователи сразу это чувствовали на себе (хорошо, что все они такие же разработчики, а не реальные клиенты). Можно ли этого избежать?

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

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

Первым кинь камень в того, кто скажет, что делать новый суперпроект надо с SQL базой данных.

Скажи честно, тебе ведь интересно, как устроены внутри все эти суперсайты, на которых висишь сутками ты и еще сотни миллионов человек сразу? Ну, это я говорю о Facebook и нашем вКонтакте, Google, Amazon, ebay, Twitter и десятки других сайтов, которые самые посещаемые в мире. Если ты делал уже сайты, то знаешь, что большинство веб-сайтов просто странички на PHP вместе с базой данных мускула (MySQL). База данных нужна для всего – там и новости и товары из магазина, статьи и  комментарии, и даже самое вкусное – логины и пароли пользователей, которые взламываются за пару секунд. Ты же даже не мыслишь о том, что сделать сайт без применения базы данных вообще – я говорю о реальном сайте типа форума или социальной сети, ну, на худой конец, магазин хакерских программ?

База данных – вширь и ввысь

В реальности так и есть – очень многие большие дядьки разработчики и архитекторы также думали, что без базы не обойтись, продолжая делать все более и более мощные сайты. Но потом все столкнулись с тем, что, сколько ни тужься, не придумывай всяких хаков и умных штучек, а базы данных плохой выбор, если у тебя сто миллионов посетителей. Ага, они тоже слышали о кластерах и распределенных системах, или даже об облачных вычислениях (можно почитать и у нас). Если надо, чтобы больше людей скачало новый порно-ролик Берковой, достаточно поставить еще пару серверов и скопировать на них файлы. А вот базы данных так просто не работают. Тут и появилась проблема масштабирования. Каждый решает ее по-своему.

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