Эта статья выросла из идеи продвинутого обучения наших сотрудников технической поддержки работе с mod_rewrite. Практика показала, что после изучения имеющихся в большом количестве учебников на русском языке саппортам хорошо дается решение шаблонных задач, но вот самостоятельное составление правил происходит методом проб и большого количества ошибок. Проблема заключается в том, что для хорошего понимания работы mod_rewrite требуется изучение оригинальной англоязычной документации, после чего — либо дополнительные разъяснения, либо часы экспериментов с RewriteLog.

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

Правила турнира

• Результаты турнира определяются с помощью ПО написанного организаторами. Опубликованные результаты являются окончательными. Текущий рейтинг игроков не является официальным и может отличаться от опубликованных окончательных результатов.
• Каждый участник турнира может иметь единственную учетную запись. При выявлении участника управляющего несколькими учетными записями, и несмотря на то, что эти учетные записи зарегистрированы на других людей, нарушитель будет дисквалифицирован.
• Участники (или их программы), которые нарушают дух правил и спорта (вероятно не нарушая официального текста правил), отстраняются от участия в турнире, без возможности обжалования. В частности: сканирование памяти, умышленный проигрыш и изменение поведения в зависимости от имени оппонента — запрещены.
• Производить запись в файлы запрещено. Разрешено производить чтение из файлов которые вы высылаете для участия. Файлы располагаются в текущей директории.
• Использование нескольких процессов или потоков запрещено.
• Любая попытка нарушить нормальную работу программного обеспечения турнира или серверов приведет к немедленному привлечению сотрудников правоохранительных органов. Наш принцип — всегда преследовать нарушителей в судебном порядке.
• Организатор оставляет за собой право, изменить эти правила в любой момент, без предварительного уведомления участников турнира.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Я уже писал о том, как с помощью Nginx трансформировать контент на лету. С момента публикации статьи на базе описанного метода запущен и развивается реальный проект ecommerce. Помимо перевода и трансформации также реализован и SEO рерайт по заветам руководства для начинающих от Google.

Однако, до полной победы изделия русских программистов над заграничным контентом, не хватало одной небольшой, но очень важной вещи — проксирования Cookies.

В чем суть проблемы

Проблема заключается в том, что любой нормальный сервер приложений всегда выставляет Cookie, например для того, чтобы сохранять сессию клиента или корзину с его товаром. Если этот сервер (точнее его администратор) озабочен поддержанием определенного уровня безопасности, то он выставляет в теле Cookie домен и путь, например domain= backend.org; path=/path1. Наш Nginx запущенный в режиме Reverse Proxy замечательно меняет все ссылки в теле документов с backend.org на frontend.org, но не делает этого для кук! Это означает что браузер клиента отвергнет такие куки.

Этот вопрос с давних пор волнует умы администраторов nginx, в рассылках он всплывает по 1-2 раза в год. Большинство вопрошавших, по-видимому, решили свои проблемы подкручивая логику backendа, но не я! После очередного апдейта оригинального сайта стало понятно, что костыль с PHP + Curl тянуть больше невозможно и надо непременно найти решение с помощью Nginx!

Я вернул тему в рассылку, попутно перебирая варианты из ngx_http_perl_module и переменной $upstream_http_set_cookie, даже заглянул в дебри сорсов с призрачной надеждой написать модуль самому. Но все было неудачно пока в один прекрасный момент я не получил письмо от Mikhail Mazursky, который дал ценный совет. Благодаря этому совету я не только с легкостью решил задачу проксирования Cookie, но и получил новый инструмент, с помощью которого можно создать версию 2.0 своего проекта.

Решение

Название этого инструмента lua-nginx-module, который написан еще одним китайским самородком с корнями из Taobao. Из названия легко понять, что речь об языке скриптов Lua встроенном в Nginx — но это больше чем просто интерпретатор! Эти ребята создали полностью неблокируемую реализацию с производительностью десятки тысяч операций в секунду, которая имеет хуки ко всем событиям внутри Nginx. То что раньше можно было реализовать только написав свой модуль на C, теперь можно сделать несколькими строчками на Lua. Заинтересовались?

Пользуясь случаем, хочу провести небольшой соц-опрос на тему обозначенную в заголовке.

Дело в том что несмотря на огромную популярность «торрентов» степень их интегрированности в другие сервисы оставляет, мягко скажем, желать лучшего. И касается это не только рутрекера, а вообще практически всех трекеров.

А между тем, даже беглый анализ показывает, что в качесте хранилища файлов трекер куда удобнее, чем любой условно-бесплатный файловый хостинг: не нужно смотреть на бесконечные надписи «скачка начнется через 69 секунд» или «срок хранения файла истек» и закрывать постоянно всплывающую рекламу. На файлах больших объемов преимущества еще более очевидны

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

Также есть некоторое количество программ и плагинов, которые чтобы получить нужную информацию напрямую, старательно парсят странички форума.

Поэтому, давайте подумаем вместе, каким он должен быть, API рутрекера.

Мало найдётся людей среди пользователей и читателей Хабра, которым не доводилось бы пользоваться торрентами. И наверняка многие понимают уязвимость центральных звеньев этой системы — торрент-трекеров (истории с Пиратской бухтой и бывшим torrents.ru, ныне рутрекером, — тому подтверждение).

Однако не все знают, что уже давно существует альтернатива традиционным трекерам — DHT-сеть, позволяющая организовывать раздачи без трекера. До сих пор она не получила большого распространения из-за невозможности поиска внутри сети — нужный файл можно было скачать только при наличии magnet-линка раздачи. Однако недавно появился первый и уникальный пока поисковый сервис по DHT-сети BTDigg.org.

Сервис с весьма лаконичным дизайном заточен под одну функцию — поиск:

Поисковик по хэшам торрентов

Чтобы снизить зависимость от трекеров, в 2007 году разработчиками протокола bittorrent была принята его модификация на основе DHT-структуры, которая позволяла делать раздачи без трекера.

Что такое DHT-сеть? Фактически, это распределённая сеть торрент-клиентов, которая хранит идентификаторы (хеши) всех публичных раздач — т.н. magnet-link, которые представляют собой 160-битное случайное число. DHT-узлы клиентов отвечают за анонсирование своих торрентов и за поиск запрашиваемых. Благодаря тому, что все современные клиенты поддерживают DHT, можно сказать, что в этой сети есть практические все публичные торренты (приватные торренты сеть «не видит» и не позволяет скачивать). Практически — потому что DHT в клиенте может быть отключен. Поиск идёт по мета-информации, которую содержит в себе торрент-файл — то есть, проще говоря, он ищет по названию торрента и по названиям файлов входящих в него. Пользователь открывает magnet-линк в своём торрент-клиенте, тот находит всех раздающих файл и дальше качает как обычно — участия трекера в этой цепочке нет.

Итак, пришло время раскрыть некоторые карты и рассказать о том, как устроен Tactoom изнутри.

В этой статье я расскажу о разработке и выведении в production веб-сервиса с использованием:
NodeJS (fibers), MongoDB, Redis, ElasticSearch, Capistrano, Rackspace.

Надавно была опубликована библиотека 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 секунду

Многие из хабровчан, да и вообще айтишников, смотрят аниме. Еще больше видело его хотя бы краем глаза. Но как его создают?

Начинается все с идеи. Бывает, что устраивается мозговой штурм, где из целой кучи выбирают только одну, но зато лучшую. Бывает, решает все руководство. Но так или иначе, это самый первый и самый скучный этап. После выбора идеи решается состав команды, которая будет заниматься ее реализацией, ищутся спонсоры. Аниме на самом деле довольно дорогая вещь — стоимость показа 52 серий поздней ночью на 5-7 каналах телевидения приближается к 50 миллионам йен (около 21 миллионов рублей), а показ аниме Fullmetal Alchemist в 6 часов вечера стоил в 10 раз дороже!

Если вы строите ajax-cайт, то рано или поздно, вы сталкиваетесь с проблемой «не работает кнопки назад-вперед в браузере». Потому что ajax — асинхронный, он не выполняет переход на другие страницы, а всего-лишь меняет некую часть содержимого на текущей.

Вторая проблема, с которой борются все разработчики — проект перед сдачей в продакшн просто изобилирует кучами javascript (ajax) кода. Весь этот код по своей сути — всего лишь запросы страниц с севера «без шаблона», т.e., чистое содержимое страницы.

Обзор практически всех *top утилит под linux (atop, iotop, htop, foobartop и т.д.).

top

Все мы знаем top — самую простую и самую распространённую утилиту из этого списка. Показывает примерно то же, что утилита vmstat, плюс рейтинг процессов по потреблению памяти или процессора. Совсем ничего не знает про загрузку сети или дисков. Позволяет минимальный набор операций с процессом: renice, kill (в смысле отправки сигнала, убийство — частный случай). По имени top суффикс "-top" получили и все остальные подобные утилиты в этом обзоре.

atop

Atop имеет два режима работы — сбор статистики и наблюдение за системой в реальном времени. В режиме сбора статистики atop запускается как демон и раз в N времени (обычно 10 мин) скидывает состояние в двоичный журнал. Потом по этому журналу atop'ом же (ключ -r и имя лог-файла) можно бегать вперёд-назад кнопками T и t, наблюдая показания atop'а с усреднением за 10 минут в любой интересный момент времени.

В отличие от top отлично знает про существование блочных устройств и сетевых интерфейса, способен показывать их загрузку в процентах (на 10G, правда, процентов не получается, но хотя бы показывается количество мегабит).

Незаменимое средство для поиска источников лагов на сервере, так как сохраняет не только статистику загрузки системы, но и показатели каждого процесса — то есть «долистав» до нужного момента времени можно увидеть, кто этот счастливый момент с LA > 30 создал. И что именно было причиной — IO программ, своп (нехватка памяти), процесор или что-то ещё. Помимо большего количества информации ещё способен двумя цветами подсказывать, какие параметры выходят за разумные пределы.

PyQt4 это тулкит для разработки GUI приложений. Он представляет из себя смесь языка программирование Пайтон (Питон) и библиотеки Qt. Qt – одна из наиболее мощных библиотек на этой планете. Если не самая мощная. Официальный сайт PyQt www.riverbankcomputing.co.uk разработан Филом Томпсоном.
PyQt4 представляет из себя набор модулей Пайтон. Она содержит более 300 классов и почти 6000 функций и методов. Это мультиплатформенный тулкит. Он работает на всех основных операционных системах, включая Unix, Windows и MacOS.
Начиная с версии PyQt4 GPL доступна для всех поддерживаемых платформ.

Созданый Райаном Далем в 2009 году, Node.js — относительно новая технология, завоевавшая в последнее время большую популярность среди веб-разработчиков. Однако, до сих пор не каждый знает, что на самом деле Node.js это серверная JavaScript среда, использующая асинхронную событийную модель. Что это означает? Все просто: это среда, которая предназначена для написания масштабируемых, высокопроизводительных приложений. Почти как Ruby’s Event Machine или Python’s Twisted, но гораздо глубже — JavaScript реализовывает цикл событий, на уровне самого языка, а не как отдельная библиотека.



И это еще не все: то, что действительно круто в Node.js — это тысячи модулей, доступных для любых целей, а также активниешее сообщество этого молодого проекта. В этом обзоре вы найдете самые полезные ресурсы по Node.js, от просто удобных инструментов и подробных руководств, до углубленных статей и ресурсов о этой перспективной технологии. Используете ли вы Node.js? Поделитесь опытом в комментариях к этотому посту!

Как то поздним вечерком мне пришла мысль изучить Backbone.js и привязать его к уже написанному на jQuery сервису. Сервис уже серьёзно расширился и меня достало это нагромождение обработчиков кликов, запросов и логики. Поэтому, я как усердный школьник полез в официальную документацию. Но либо я тупой, либо мой английский меня подкачал, либо то и другое вместе, но я не черта не понял. Я прочитал уже второй раз, внимательно, и для особо одарённых мест использовал google translate. Прочитал также и пример ToDo List. Всё показалось понятно, ровно до той поры пока я не стал писать. После чего я взял всё что нашел по этой библиотеке, как на английском так и переводы. Прочтя кипу документации я решил, что сейчас вроде всё понял. Я напрягся, но… Не вышел каменный цветок у мастера Данилы, т.е. вышло, но это явно был не цветок, и камень как то неправильно пах. Тогда, как прилежный ученик, я решил написать «Hello, KittyWorld» с нуля. Попутно комментируя и сохраняя шаги в hg, у меня получилось введение в backbone.js framework для таких как я, особо одарённых.