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

Здравствуй, сообщество.

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

Я сейчас тут код приложу, в принципе, там всё понятно. У меня и моих бывших коллег вчера был культурный шок. Сегодня немного набросал тестового кода, для проверки.
Работает в кодировках cp1251 и в UTF, проверяли на версиях php 4.4.7, 5.2.9, 5.2.10–2ubuntu6.4

Вообщем, вы посмотрите на это и выскажите своё мнение.

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

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

Redis — это очень быстрая key-value база данных. Может использоваться как memcached, но отличие от последней в том, что Redis сохраняет свои данные на диск, то есть может быть использован для хранения данных (что мы успешно и делаем). Основные отличии от других собратьев — более сложные структуры данных (списки, коллекции) и атомарные операции с ними. Читайте более подробный обзор Redis на Хабре.

     Я иногда сталкивался с тем, когда web-программист не знал CSS или, скорее, не хотел заниматься облагораживанием своего HTML, который являлся результатом работы разрабатываемого им скрипта. Это натолкнуло меня на мысль, что ему (программисту) не помешало бы иметь при себе некоторое средство для создания «красивых» страниц. Средство должно было бы включать в себя некоторый CSS, возможно, картинки, и подключаться к любому HTML (очевидно, созданному по некоторым определённым правилам). При этом смена CSS (и картинок) на альтернативные не должна была бы приводить к семантически некорректному отображению.
     Вышеобозначенные требования очень похожи на требования к составлению скина для какой-либо системы (в частности, CMS). Но, в отличие от скина, который заточен под конкретный HTML, в нашем случае хотелось бы максимально упростить правила написания HTML, чтобы разработчикам не нужно было держать в голове много сложных правил.
     Таким образом, оговаривая некоторые (небольшие) ограничения на HTML, мы с одной стороны гарантируем программисту, что его код, генерируемый с учётом этих правил, будет корректно оформлен любым сделанным для этих целей CSS, а с другой стороны, оговариваем шаблон изготовления самих этих CSS.

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

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

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

О NineSixty

NineSixty это тема для Drupal на основе 960gs, предназначенная для использования в качестве базовой темы.

Преимущества NS:

• контент-ориентированная разметка с использованием классов «push» и «pull»
• динамическая ширина блоков в зависимости от контента
• инструменты для отладки и визуализация сетки
• поддержка языков с направлением письма справа налево

По итогам поста, сделанного в июле 2009 и продолжительным испытаниям, мы пришли к простой и оптимальной для нас схеме межсайтовой авторизации.

В качестве распределенного хостинга возьмем классический пример — создание блогосервиса на основе mu-Wordpress.
Задача — при ограниченном бюджете собрать отказоустойчивую (насколько это возможно) геораспределенную систему. Соответственно все оборудование берется в аредну в различных Дата-Центрах.
И тут следует сказать что не все Дата-Центры одинаково полезны. Высококачественные сдают сервер за 800$, а у низкокачественных вполне можно взять примерно такой же сервер в аренду уже за 100$. И именно эти особенности надо учитывать при создании геокластера.

Теперь о небольших хаках. По умолчанию в mu-Wordpress функция отдачи загружаемого контента сделана крайне неудачно — через PHP. Соответственно она была заменена на загрузку отдельным сервисом и вставкой загружаемого контента прямой ссылкой на статику.
Вторым хаком была модификация контроля кеширования. Кроме указаний кешировать статичные элементы дизайна был введен еще такой хак, который запрещал кешировать запись на время ее обсуждения (по умолчанию — 14 дней), а уже после она отдавалась с заголовком разрешающим кеширование. Кроме того хитро кешировались фиды RSS.
Финальным хаком стала система синхронизации БД — каждый INSERT/DELETE/UPDATE выполнялся на «соседе». Получился такой себе софт-рейд в контексте MySQL+PHP.

О визуализация графов в вебе говорили здесь, навеяно этой статьей.

Под катом обзор JavaScript библиотек для рисования графов, диаграмм и прочей красоты.

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

Чарты работают со всеми популярными браузерами, включая Safari на iPhone.
Минимальная версия для IE составляет 6+. Также браузеры поддерживающие Canvas элемент, и в некоторых случаях SVG для графического рендеринга.

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

Dklab Realplexor — это Comet-сервер, позволяющий держать одновремено сотни тысяч долгоживущих открытых HTTP-соединений с браузерами пользователей. JavaScript-код, запущенный в браузере, подписывается на один или несколько каналов Realplexor-а и вешает обработчик на поступление данных. Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени и с минимальной нагрузкой для сервера.

^{Хотя идейным вдохновителем Realplexor-а был предыдущий проект, dklab_multiplexor, код Realplexor-а не имеет с ним практически ничего общего. Поэтому я и решил сменить название. Несопоставимы также возможности продуктов (см. ниже), да и размер кода увеличился в 7 раз.}

Realtime-направление сейчас довольно активно развивается на Западе, и в нем особенно выделяется продукт Tornado — событийно-ориентированный веб-сервер на языке Python. Правда, Tornado — это не столько Comet-сервер, сколько инструмент, с помощью которого можно запрограммировать «в том числе» и Comet-сервер. Ключевые слова: Comet, Push Server, Long polling, JavaScript, XMLHttpRequest.

Главные преимущества Realplexor-а:

• простота использования: наличие API для JavaScript, API для PHP (в будущем — и для других языков);
• простота конфигурирования;
• широкий функционал (либо отстутствующий, либо недоступный напрямую в аналогах).

Лучше один раз увидеть...

Я сделал отдельную онлайн-песочницу, чтобы продемонстрировать функционал нового Realplexor-а и то, для чего вообще нужны Comet-серверы (кстати, это физически тот же самый демон Realplexor-а, что использует мой новый стартап РуТвит). Песочница реализует что-то типа многоканального чата: зайдя, вы получите как будто бы 2 независимых «браузера», запущенных на разных компьютерах.

• Верхний «браузер» отображает каналы — в них моментально появляются новые сообщения, как только кто-то их туда отправляет на стороне сервера. Конечно же, эту страницу могут просматривать одновременно сотни тысяч пользователей, и они все будут видеть одно и то же (реализовано с использованием Realplexor JavaScript API). Можно «на лету» добавлять новые каналы (подписка) или скрывать уже имеющиеся (отписка).
• Нижний браузер содержит формы, позволяющие добавлять сообщение в произвольный канал, указав его имя. Форма AJAX-ом отправляется на сервер, и уже там PHP-скрипт записывает в Realplexor полученный текст через PHP API. (И да, так можно чатиться.)

По умолчанию на странице открыто 3 канала с именами Alpha, Beta и RuTvit. Но, конечно, вы можете закрыть эти каналы и открыть новые. Вот, например, страница с единственным открытым каналом по имени Habrahabr: http://rutvit.ru/realplexor/demo?ids=Habrahabr.



Песочница демонстрирует следующие функции Realplexor-а:

CodeIgniter предоставляет неплохие возможности по обработке ошибок, но мне они показались недостаточными по следующим причинам:

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

Будем это исправлять =)

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

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

В отличие от других протоколов передачи сообщений (XMPP STOMP или Memcache (MemcacheQ)) AMQP обладает большей гибкостью.

Приветствую читателей. Сейчас я веду разработку собственного фреймворка, основанного, в противовес главенствующей сейчас модели MVC, на базе сигнальной архитектуры (signal/slot). Пока он проходит боевую обкатку в нашем стартапе, и за это время я понял, что просто библиотеки мало — реальные задачи и виденье будущего показывает, что необходим разный функционал, но объединенный одной темой — обработка и доставка информации множеству клиентов в реальном времени (да, в чем-то схоже с Comet-ом, он там тоже есть). Поэтому решено было попробовать реализовать основной компонент — очередь сообщений, которая бы стала основной для следующих проектов, быстрой, гибкой и масштабируемой.

Что получилось? Альфа-версия SignalsyMQ — очередь сообщений на базе PHP/Redis/Zend Framework.

Целью статьи является демонстрация возможностей Python for s60 для работы с смс сообщениями и базами данных. Чтобы было интересней, разберем на реальном примере, создадим приложение, которое будет читать новые сообщения смартфона, парсить их, сохранять в свою базу данных номера телефонов с логинами и паролями, и постить твиты, пришедшие с этих номеров.

Для чего это еще может пригодиться? В наше время смс сервисы используются достаточно широко. Способов их реализации достаточно много. У меня недавно возникла необходимость реализовать сервис, при котором клиенты могли бы посылать смс сообщением номер заказа и в ответ приходил бы его статус. Задача решилась так: за 500 руб., на барахолке был куплен старенький Nokia 7610 в разваливающемся состоянии, у которого не работала половина кнопок, были проблемы со звуком и т. д. Туда была вставлена сим карта от местного оператора с безлимитным смс пакетом. Теперь этот аппарат будет играть роль сервера, который будет работать в режиме 24/7, с бесперебойным источником питания (аккамулятор), и не будет знать проблем с охлаждением :)

Появилось желание сделать сервис подобный 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.

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?