В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

В Symfony 2 появился совершенно новый компонент для работы с формами, который, насколько я знаю, легко заменит большинство подобных библиотек для PHP и по функционалу, и по возможности в расширении оного (конечно, если не брать в расчет небольшие недостатки при работе с JavaScript). Разработка этого компонента заняла более двух лет, хотя думать над ним я начал еще где-то в 2009-ом году или даже раньше. С каждой новой версией этот компонент становится все более и более стабильным, а полностью стабильная версия ожидается с выходом Symfony 2.2.

Данный пост приурочен к выходу Zend Framework 2 Form RFC, так как мне кажется, что его разработчики, по сути, сделали много того, что уже было сделано нами. Конечно же всем ясно, что Zend Framework 2 должен обладать прослойкой для работы с формами, который полностью учитывает особенности компонентов, поставляемых с фреймворком. Целью данного поста является попытка показать, что Symfony2 Forms прекрасно подходит под эти требования. Функционал, присущий Symfony2, может быть легко убран: код для обработки форм и все уровни абстракций полностью независимы. Привязать же поддержку особенностей компонентов Zend-а так же не составит труда.

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

В последнее время наблюдается рост платформ, построенных на асинхронной архитектуре. На асинхронной модели построен самый быстрый в мире веб-сервер nginx. Активно развивается шустрый серверный javascript в лице Node.js. Чем же хороша эта архитектура? Чем она отличается от классической многопоточной системы? На эту тему было написано огромное множество статей, но полного понимания предмета они дали далеко не всем. Часто приходится наблюдать споры вокруг Node.js vs PHP+apache. Многие не понимают, почему некоторые вещи можно сделать на Node.js, но нельзя на PHP или наоборот — почему вполне правильный рабочий код на PHP сильно замедлится в Node.js, а то и повесит ее. В данной статье я бы хотел еще раз подробно объяснить разницу в их архитектуре. В качестве примеров двух систем, возьмем вебсервер с PHP и Node.js.

Статья для людей, только начинающих знакомиться с эрлангом: как написать простой comet сервер.

Готовый код здесь: github.com/maxlapshin/comet

Описание

Комет-сервер будет написан с использованием cowboy, tinymq, и куска жабаскрипта.

Код выложен на гитхабе с тегами. Основные этапы помечены тегами, можно откатиться, чтобы посмотреть, что именно было сделано в тот или иной момент.

Сама статья пишется параллельно с кодом, что заметно из истории в гите.

Логика такая: по http постим сообщение на сервер, оно попадает в очередь сообщений, откуда его выгребает клиент через long-poll запрос.

Еще давно я хотел иметь свой автоответчик или бота для скайпа, называйте как вам угодно. В гугле я ничего найти не мог, да еще из-за того, что я пользуюсь Ubuntu, задача становилась сложнее в несколько раз. А если учесть, что я знаю только PHP, и то, не очень хорошо, моя мечта становилась нереальной.

Но недавно, просматривая официальную документацию по API скайпа, я обратил внимание на «D-BUS messaging», не знаю, почему я раньше не обращал на него внимание. Разобравшись со всем, я наконец сделал то, что давно хотел! Я получил доступ к Skype API на PHP. Об этом я и хочу рассказать в своей статье.

Надавно была опубликована библиотека node-fibers, вносящая в nodejs и v8 поддержку замечательного fiber/coroutine — тоесть, возможность использовать yield.
Параллельно, на nodejs groups прошел целый ряд обсуждений на тему всевозможных вариантов упрощения асинхронного синтаксиса.

Вдохновившись возможностями, которые дают «волокна», я написал библиотеку node-sync, которая делает разработку в асинхронном окружении nodejs значительно удобнее, а код — нагляднее.

Синопсис

// Обычная асинхронная функция, вызывает callback с результатом через 1 сек
function someAsyncFunction(a, b, callback) {
    setTimeout(function(){
        callback(null, a + b);
    }, 1000)
}
// Вызываем эту функцию синхронно, используя Function.prototype.sync(),
// работающий по тому же принципу, что и call()
// на этом моменте текуший поток "зависнет" на секунду, пока функция не вернет значение
var result = someAsyncFunction.sync(null, 2, 3);
console.log(result); // "5" через 1 секунду

(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.

Короче, мы застреваем в спагетти-коде. К счастью, есть современные JS-фреймворки (библиотеки, задающие, кроме функций, правила организации кода --прим. перев.), помогающие поддерживать структуру и организованность в проекте, облегчающие ремонтопригодность в будущем.

■ Что такое MVC или, лучше сказать, MV*?

Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Создание REST API это нелегкая задача. Нет, серьезно! Если вы хотите написать API правильно, вам придется о многом подумать, решить, быть прагматиком, или API маньяком. REST это не только GET, POST, PUT и Delete. На практике, у вас могут быть взаимодействия между ресурсами, нужно перемещать ресурсы куда-то еще (к примеру внутри дерева), или вы захотите получить конкретное значение ресурса.

В данной статье собрано все, чему я научился реализуя различные API сервисы, используя для этих целей Symfony2, FOSRestBundle, NelmioApiDocBundle и Propel. К примеру сделаем API для работы с пользователями.

Целью данной заметки я ставлю в подробностях описать организацию сервера для Rails приложений в самой популярной на данный момент связке: rvm + Rails + Nginx + Unicorn. К написанию статьи побудило отсутствие полной пошаговой документации по этой связке, понятной не только ядреным профессионалам этой области. Далее я попытаюсь подробно, шаг за шагом, описать идеологически правильный процесс организации сервера для обслуживания нескольких Rails приложений (на примере одного) — если у вас есть абсолютная уверенность в том, что на подопытной машине никогда не будет работать более одного приложения — настройка может быть существенно короче и проще. Хочу предупредить, что тонкости, касающиеся работы приложения под высокой нагрузкой в статье не описываются, т.к. цель ставилась иная — заставить работать приложение в связке и сократить количество конфликтов с другими приложениями до минимума.

Уже около полугода для разработки веб-проектов используем Symfony 2. Накопился список полезных библиотек и бандлов, не входящих в состав symfony-standard, но значительно экономящих время и избавляющих от изобретения велосипеда.



Обзор больше теоретический и включает следующие разделы:

• Админгенераторы
• Пользователи
• Импорт/экспорт xls
• API и OAuth 2.0
• Меню/навигация
• Мультимедиа
• Формы
• Поиск
• Пагинация
• Файловая система
• HTTP клиент

Примеры использования и код можно изучить на страницах каждого проекта на github.com или на официальных сайтах, но если будет интересно, некоторые решения можно рассмотреть отдельно.

От переводчика

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

Разрешается использовать любые инструменты для минификации компиляции или обфускации кода, при условии, что общее качество кода будет сохранено.

Чтобы сделать расширение достаточно минимальных знаний Javasctipt, HTML и CSS. Давайте добавим на хабр догрузку следующей страницы, а также систематическую проверку новых постов на текущей. Примерно как на twitter.

Полностью готовый экстеншн можно установить и проверить в работе через Chrome Web Store, а здесь разберемся как написать основной код с нуля (полный занимает всего 6 KB).

В данной статье я попытаюсь показать, как можно создать простой чат, используя Node.js в связке с Socket.IO. Изначально я хотел построить чат на чистых Websockets, но столкнулся с практически полным отсутствием готовых реализаций сервера для них в Интернете. Так что решил не изобретать велосипед, а использовать готовую библиотеку.
В моем случае сервер работает под Ubuntu, поэтому все примеры будут для неё (и ссылки в примерах — на него же).

Установка компонентов

Первым делом нам потребуются собственно Node.js (инструкция по инсталляции и ссылки на скачивание здесь) и Socket.IO. Модули для Node.js проще всего устанавливать, используя менеджер npm —

curl http://npmjs.org/install.sh | sh
npm install socket.io

Серверная часть

Структура серверной части такова: сервер принимает сообщение, если это команда — выполняет определенные действия, если просто сообщение — рассылает всем остальным участникам.

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)

Tinyicon это небольшая библиотека для манипуляции с favicon сайта для передачи информации о новых событиях. Для браузеров не поддерживающих canvas счетчик отображается в title страницы.

Во время разработки игры мы столкнулись с необходимостью обеспечения максимального риалтайм обмена данных между пользователями, что повлекло за собой эксперименты с различными comet библиотеками.
Первый велосипед был построен на dklab realplexor, который, при очередной попытке его использования, как и ожидалось, нас подвел. Может у нас руки кривые, но добиться получения ивентов без задержек в 5-10-15 секунд у нас, к сожалению, не получилось.
Танцы с бубном продолжались долго, в результате чего мы решили остановиться на nginx_http_push_module, и потраченное время все же стоило того.

Еще раз, если позволит сообщество, обращусь к теме паттерна Мост (Bridge), ибо последние статьи, на мой взгляд, объясняют его не так просто, как нужно.

Основная идея: «Используем Мост там, где нужно менять не только имплементацию, но и абстракцию».

Одна картинка стоит 1000 слов…

В последнее время в проектах часто приходится создавать демона, который периодически фоном что-то проверяет или отсылает.

Обычно подобную задачу решают с помощью таких пакетов как whevenever, daemon_controller, daemon_generator и т.д. и все казалось бы просто и понятно, но надоело каждый раз городить огород и писать одно и тоже. Мне нужно всего-лишь чтобы раз в час выполнялось какое-нибудь User.notify_all

Презентую loop_dance — gem для быстрого развертывания управляемого демона в рельсовом окружении.

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.