В чём проблема?

Бывали ли у вас случаи, когда во время долгого заполнения нудной формы или написания красноречивого и пылкого комментария *внезапно* крашился браузер? Или вы закрывали вкладку, в которой работаете, или отключалось электропитание (а ИБП, по известному закону, нет)? Если нет — то вам повезло, но страховки от подобных происшествий ни у кого нет.

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

Введение

В жизни любого крупного веб-проекта, особенно на PHP, но, в целом, это касается любого серверного ЯП, пригодного для веб-разработки, обычно наступает понимание, что «так дальше жить нельзя», и что настал момент, когда нужно провести оптимизацию работы сайта, чтобы он перестал тормозить (хотя бы на production).

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

Если вы смогли определить, что это — ваш случай, и ваш проект на MySQL, то эта статья может вам помочь принять конкретные меры и исправлению ситуации с закреплением результата и предотвращением возникновения откровенных проблем с СУБД впоследствии.

Я уже писал о том, как с помощью 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. Заинтересовались?

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

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

Разработчикам мобильных приложений приходится непросто, портируя код под каждую ОС, разбираясь с SDK, компиляторами и эмуляторами. Создатели кроссплатформенного фреймворка PhoneGap постарались упростить задачу: тот позиционирует себя как единственный open source мобильный фреймворк с поддержкой шести мобильных платформ. Теперь они пошли ещё дальше и выкатили PhoneGap Build (бета) — простой онлайновый конвертер из HTML5. Достаточно загрузить приложение на html/js/css — и на выходе получаете готовый бинарник для Apple App Store, Android Marketplace, Palm, Symbian или BlackBerry.

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

Иногда нужно протестировать работу клиентского приложения в сетевых условиях, приближенных к боевым. Что при разработке, что при выборе софта. Как правило, сервер рядом, а нужно оттестировать и на таком канале, и на таком. Как ни странно, удобного средства управления трафиком (traffic shaping) под Windows мне долго не удавалось найти. Из поисков запомнилось: кто-то советовал для тестовых целей купить модем. Можно поставить роутером машину на Linux и на ней рулить трафиком, но мне такой подход кажется слегка чрезмерным.
Оказывается, не меньше года в проекте Dummynet есть бинарники для Windows, которые позволяют легко и непринужденно управлять, как минимум, полосой канала (bandwidth) и задержкой (latency).

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

Статья затронет весь цикл разработки приложения. Вместе мы напишем простенькую игру “Крестики-Нолики” с одним экраном (в ОС Android это называется Activity).

Отсутствие опыта разработки на языке Java не должно стать препятствием в освоении Android. Так, в примерах не будут использоваться специфичные для Java конструкции (или они будет минимизированы на столько, на сколько это возможно). Если Вы пишете, например, на PHP и знакомы с основополагающими принципами в разработке ПО, эта статья будет вам наиболее полезна. В свою очередь так как, я не являюсь экспертом по разработке на Java, можно предположить, что исходный код не претендует на лейбл “лучшие практики разработки на Java”.

Забегая вперед, вот что получилось:

Предисловие переводчика:
Недавно начал изучать PHPUnit (framework семейства xUnit) и с удивлением обнаружил, что на русском языке нет статей про автоматические тесты для самых-самых чайников.
В первой главе документации по PHPUnit на примерах очень доступно рассказывается, что такое автоматическое тестирование.


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

Requests — библиотека Python, которая элегантно и просто выполняет HTTP-запросы. Теперь не нужно осваивать urllib2 с излишне сложными программными интерфейсами.

Вот как выглядит HTTP-запрос с авторизацией с помощью requests:

>>> r = requests.get('https://api.github.com', auth=('user', 'pass'))
>>> r.status_code
200
>>> r.headers['content-type']
'application/json'

Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.

Upd: Для нетерпеливых: пошаговые инструкции по созданию переводов.

Русская документация PHP

Добрый день Хабрасообщество!
Как многим известно, вот уже долгое время на php.net нет русской версии документации PHP. Это не значит, что работа по переводу была прекращена, а результаты этой работы пропали.
Дело в том, что перевод документации — добровольное дело, и добровольцев, скажем так, не много. Один-два человека старались удержать перевод на плаву, но все равно в конце концов документация устарела и скорее вводила в заблуждение тех, кто ей пользовался, нежели помогала в освоении языка. Где-то в 2008 г. в команде переводчиков никого не осталось, потом документация устарела настолько, что процесс сборки (куда входит синхронизация с английской версией) сломался и русский мануал исчез с официального сайта до «лучших времен». Медленное и мучительное возрождение документации началось в октябре 2010 г., но с тех пор оно с каждым днем набирает обороты.