ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.

Пока все Интернет сообщество со всех сторон продолжает обсуждать, как же можно приспособить iPad для работы, я бы хотел все же вернуться к iPhone. По профессии я программист и люблю новые технологии. И очень мне уж хотелось сделать приложение для своего телефона, но вот как-то душа к Objective C не лежит пока что, да и макбука с лицензией разработчика тоже пока нет. И мне стало интересно, могу ли используя знания html и js написать что-нибудь. Оказалось что да, и способов очень даже много. О них – под катом.

… или как перейти с PHP + JavaScript на JavaScript + JavaScript

Идея реализовать проект на сервер-сайд JavaScript была уже давно. Проблема была в отсутствии подходящего серверного программного обеспечения. Существующие открытые проекты не устраивали по разным причинам. Устанавливать дополнительный модуль для Apache было не самой хорошей идеей, потому что производительность и оптимизация использования памяти при этом были бы не на высоте. С помощью jslibs можно настроить FastCGI, но очень не хотелось оставлять ни малейших шансов «502 Bad Gateway», проект ngx_http_js_module так и остался в зачаточной стадии, а ngxv8 недостаточно развит для реализации реальных приложений. Поэтому я решил сделать собственную реализацию серверного javascript. Причем постараться сразу запрограммировать всю базовую функциональность, чтобы можно было ее тестировать в условиях, близких к реальности.

В качестве основного веб-сервера было решено использовать nginx, в качестве «движка» javascript — TraceMonkey (javascript-движок из Mozilla Firefox, бывший SpiderMonkey), и написать модуль для nginx, который бы их «склеил». Ничего сложного, на первый взгляд, но очень хотелось иметь определенную функциональность (и это получилось!), чтобы можно было нормально работать дальше. Большинство идей заимствованы, кстати, из PHP.

• Корректная работа в multi-thread условиях
• Возможность выполнять скрипт, указанный в URL, а не настраивать отдельно скрипт-обработчик и функцию-обработчик для каждого location
• Возможность вызывать include(), sleep(), alert() из скрипта, использовать __FILE__ и __LINE__
• Ограничение памяти, выделяемой каждому скрипту, и времени работы скрипта
• Защита открываемых скриптом файлов, указав в настройках список разрешенных папок. Примерно как open_basedir в PHP
• Автоматический разбор данных запроса (параметров GET, POST, и, конечно же, cookies), чтобы не писать обработку данных на javascript
• Поддержка запросов application/x-www-form-urlencoded и multipart/form-data
• Поддержка basic-авторизации
• Работа с базами данных (в первую очередь, MySQL и SQLite)
• Работа с файловой системой: чтение и запись файлов, проверка существования файлов, и т.п.
• Кэширование байт-кода скриптов, как, например, в eAccelerator

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

От слов — к делу! Как скомпилировать и настроить, как протестировать и сравнить...

Мало найдеться программистов (особенно начинающих), способных держать в голове названия всех нужных методов а так-же количество, порядок и назначение передаваемых им параметров. Для этого существуют справочники по API.

В этом посте я хотел бы собрать вместе несколько полезных, посвященных Ruby on Rails, справочных ресурсов (в том числе и по API), которые всегда удобно держать под рукой, в соседней вкладке браузера.

Речь пойдет о:

• http://api.rubyonrails.org
• http://wiki.rubyonrails.org
• http://guides.rubyonrails.org
• http://railsapi.com
• http://apidock.com/rails

Сказка

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

К счастью, транспортная компания (которая не удосужилась составить четкого расписание) содержит сайт, на котором в реальном времени с помощью Google Maps можно узнать, где сейчас находится тот или иной автобус. И вот в один прекрасный день Ваше терпение лопается и Вы садитесь писать скрипт, который будет отправлять ту желанную SMS-ку. Но все не так просто. Придется долго повозиться, чтобы по карте и маленькому кружочку на ней оценить скорость и время прибытия реального транспортного средства на Вашу остановку. Вы ведь не можете просто написать: «хочу получать SMS, когда вот эта точка попадет вот в этот прямоугольник на карте». Или все-таки можете?

Скорее всего вы уже знаете о том, что в Rails 3 по умолчанию добавлена защита от XSS атак. Это значит, что отныне вам никогда не придется вручную фильтровать ввод пользователя используя хелпер h, потому что рельсы всегда будут делать это за вас.

Тем не менее, всё не так просто, как кажется на первый взгяд. Рассмотрим следующий код:

Привет <strong>друзья</strong>!

<%= tag(:p, some_text) %>
<%= some_text %>


Каждый раз, когда вы ограничиваете в чём-то пользователя, спросите себя, зачем вы это делаете и кому от этого станет лучше. Нарушение этого правила ведёт к странным, а иногда и вредным ограничениям. Один из примеров — максимальная длина пароля.

С ограничением длины снизу всё понятно, но кому нужно ограничение сверху? Пусть пользователь вводит хоть 200 символов, если ему хочется, фрику будет приятно. Жалко байтиков в POST-запросе? Место в базе данных? Но вы же (я надеюсь!) храните хэш от пароля, который всегда постоянной длины! Считаете, что хэширование 200-символьных паролей убьёт производительность сервера? Не смешно.

При всём при этом создатель сайта заставляет пользователя:

• Воспринять и осмыслить лишнюю информацию;
• Поволноваться, не превышает ли его любимый пароль указанное ограничение;
• Дважды пересчитать символы в 12-символьном пароле, чтобы убедиться, что всё нормально;
• Придумать новый пароль, если любимый оказался длиннее (не всем живым людям придёт в голову чисто компьютерное решение убрать последние символы пароля: он может стать неблагозвучным).

Здравствуй, хабрасообщество. Я знаю, ты любишь халяву. А еще ты любишь учиться. Ведь так? А что может быть лучше для хабравчанина бесплатного образования? Вот и решил собрать специально для тебя подборку из ссылок, где можно набраться уму-разуму в области IT.
Все нижеперечисленные ресурсы абсолютно и официально бесплатны и свободны, что не может не радовать.

UPD. Переранжировал сайты. В категорию «Компьютерные науки» попали те сайты, которые можно внести более, чем в одну из нижеперечисленных категорий. Ранжировка производилась по большинству содержимого, то есть в некоторых сайтах, отнесенных к определенной категории, могут попадаться статьи не относящиеся к определенной, но они будут составлять абсолютное меньшинство

Большое спасибо в помощи добавлении ресурсов vansickle, RedFox, kagen, theinterman, sM1Le.

Англоязычные ресурсы

Компьютерные науки

OpenCourseWare MIT

Одно из самых больших хранилищ учебных курсов. Здесь собраны практически все курсы, которые преподаются в Massachusets Institute of Technology, который по праву считается одним из лучших в мире. На сайте всего 1900 курсов, а тех, которые преподаются на факультете Electrical Engineering and Computer Science я насчитал более 200. Состав большинства курсов: краткие конспекты лекций, подробное описание курса, календарный план, задания на лабораторные работы, задания на курсовые проекты и экзамены, промежуточные модули. К некоторым курсам прилагаются и видеолекции.

Вольно-сокращенный перевод статьи 15 Time Saving CSS Tools You Should Be Aware Of
Под катом текст, графика, ссылки

Обратите внимание на вот эту иллюстрацию:



Красиво, правда?

Появилось желание сделать сервис подобный letitbit.net в отдельно взятой стране на окраине Европы.
Требовалось:

• позволять загружать/отдавать большие файлы;
• не позволять перепубликовывать прямые ссылки на файлы;
• ограничивать количество одновременно скачиваемых файлов.

Для реализации выбрали NGINX в связке с PHP через fastcgi.
В NGINX добавили:

1. великолепный Nginx upload module, который позволяет избежать многократное копирование загруженного файла на пути NGINX-PHP. К тому же, при небольшой доработке, возможна загрузка сразу в нужную папку, что позволяет использовать простое переименование вместо копирования в PHP
2. нужную заплатку к модулю secure_link, позволяющую делать безопасные ссылки действительными ограниченное время

PHP взяли самый обычный и запустили через spawn-fcgi.
Поставили сервачок, напихали туда штук 12 терабайтных дисков.
Программист написал PHP код, а Марис Рускулис придумал следующий трюк с rewrite для NGINX, позволяющий избежать обращение к PHP при скачивании файла.
В результате, конфигурация NGINX выглядела примерно так:
http {
limit_zone regular $zonekey 10m;
limit_zone premium $zonekey 10m;
server {
root /www/oursiteishere;
location / { try_files $uri @files; }
location ~ \.php$ { try_files $uri @files; fastcgi_stuff_here; }
location @files { rewrite ^(.*)$ /index.php?$1 last; }
location /storage/ { root /storages/; internal; }
# Location for regular users
location ~ /download/.+/(.+)/0/.+/.*/(.+)$ {
set $fname $2;
set $username $1;
set $zonekey "$binary_remote_addr $username";
limit_conn regular 1;
limit_rate '100k';
secure_link_secret megasecret;
secure_link_ttl on;
if ($secure_link = "") { return 403; }
add_header Content-Disposition "attachment; filename*=UTF-8''$fname";
rewrite ^/download/([a-f0-9]+)/([\.~0-9a-zA-Z_]+)/([01])/([0-9]+)/(.+)/.+$ /storage/$4/$5 break;
}
# Location for premium users
# Location for upload using upload module
}
}

Замечательной вещью в данном конфиге является тот факт, что при скачивании файла по сгенерированной защищённой от подмены временной ссылке (проверку осуществляет secure_link) не вызывается PHP с последующим X-Accel-Redirect.
Возможно, данное решение накладывает ограничение на присутствие логики перед непосредственной отдачей файла, но тем не менее, на мой взгляд, является довольно оригинальным трюком, позволяющим немного сэкономить на fastcgi.

Недавно на Хабре была опубликована статья под провокационным заголовком и призывом к прекращению изобретений велосипедов в API-строении. Поскольку тема мне интересна, то я просто не мог пройти мимо.
Увы, реальность за хабракатом меня сильно разочаровала — я увидел очередной велосипед, да еще и с квадратными колесами. (Коллеги, ничего личного, только техническое обсуждение.) Правда, авторы честно сказали, что увидели на нескольких сайтах модное слово REST и решили сделать по нему. Только вот поняли они этот «РЭСТ» по-своему, примерно как Дед Щукарь читал и понимал толковый словарь.
В этом топике я призываю по-настоящему покончить с велосипедами в API сайтов. Ведь получается какой анекдот: АПИ разрабатывается для упрощения доступа к сайту и легкости подключения внешних систем, а получается такой, что с ним еще сложнее, чем без него :)

Чуть ниже под катом я подпишу смертный приговор всем велосипедам в универсальных API. Чтобы не быть голословным, я все проиллюстрирую примерами.
Но должен предупредить сразу — после прочтения статьи вы не сможете без рвотного рефлекса смотреть на очередной велосипед Васи Пупкина под гордым названием «универсальное API сайта».

В повествовании будут рассмотрены следующие вопросы:

1. Базовые технологии: XML-RPC, REST, SOAP и краткое сравнение
2. Дао вебсервиса
3. Просветленные API
4. Как отличить сайтовое API от говна
5. Выводы

Немного статей на хабре посвящены новому движению в IT индустрии — NoSQL. Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get, put и delete. Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

Быстрый и мощный jQuery может помочь дизайнерам и разработчикам в создании прекрасных интерактивных сайтов, которые будут привлекательными и совместимыми с большинством из браузеров. Ваш сайт будет и интересным и развлекательным. Навигация, галереи и слайдшоу являются теми компонентами, которые могут блистать на вашем сайте.

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

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



Данная статья содержит список нескольких преимуществ простого дизайна сайта, также некоторые легкие методы для упрощения процесса дизайна.

NPAPI это набор API, позволяющий создавать плагины для Firefox, Chrome, Safari, Opera. В этой статье я хочу дать первоначальные сведения о создании плагина на базе NPAPI. Будет приведен пример плагина под Windows, но и разработчикам на Mac и Unix статья будет полезной, т.к. описывает общий подход к созданию плагинов, использующих NPAPI.

NPAPI плагин это модуль, который «цепляется» к браузеру и отвечает за обработку определенного content type (например application/x-shockwave-flash).

О том как появился и менялся NPAPI вы можете прочитать на странице в Wikipedia
Полное описание API можно получить на странице Gecko_Plugin_API_Reference

В IT индустрии все чаще встречаются проекты с распределенными командами. Это удобно — спецификация, код, баги, мануалы легко перемещаются из одного конца планеты в другой за доли секунд. Это выгодно — аутсорсинг проектных процессов, будь то разработка, тестирование или саппорт, в Индии или Китае обойдется в 3–5 раз дешевле аналогичных сервисов в странах Европы или США.

Никого не удивишь проектом, в котором сейлз, маркетинг и бизнес анализ находятся в Англии, разработка в России, тестирование и саппорт — в Индии. Компания, в которой я работал, специализировалась именно на таких проектах. Наиболее слабыми местами в них, я бы назвал коммуникации внутри проекта и мотивацию его участников. Эта статья описывает эффективный подход к решению этих проблем в проектах с распределенной командой.

Dklab_multiplexor — это инструмент, который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Например, если на вашем сайте находится одновременно несколько сот тысяч посетителей, каждый из них может быть связан с сервером постоянным соединением, установленным из JavaScript. Это например, полезно при организации онлайн-чатов или мгновенных уведомлений.

Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях). Это лишь простейший инструмент, который наконец-то дошли руки опубликовать.

Зачем это нужно?

Предположим, посетители вашего сайта могут посылать друг другу сообщения. Если получатель в момент отправки находится на сайте (просматривает какую-либо страницу), ему немедленно выдается уведомление (всплывающее окошко на JavaScript).

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

Быстрая разработка

Вдохновленный постами на западных блогах вроде «Clone TinyURL with 40 lines of Ruby» или «Clone Pastie in 15 Minutes with Sinatra & DataMapper» я решил попробовать пройти и заодно описать весь процесс реализации легковесного веб-приложения на руби, от проектирования до деплоймента.

Не секрет, что пользователи любят, когда контент на сайте обновляется чаще, чем раз в год. Эту любовь пользователей к динамическим страничкам разделяют и поисковики. Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).

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