Под катом — перевод первой части статьи What every programmer needs to know about game networking, об истории становления и принципах устройства мультиплеерных сетевых игр. Автор Glenn Fiedler.

Опубликовал сначала в своем блоге как ответ на вот этот топик. Спасибо доброму хабравчанину borisko, подарившему возможность перенести сюда.

Данный материал — компиляция (полная настолько, насколько это было возможно) из нескольких источников (см. ссылки внизу поста). Буду благодарен за ответы на вопросы (они в тексте), которые у меня возникли в процессе подготовки этого материала.

С тех пор как приобрел IBM Lenovo ThinkPad X61s (это такой маленький и удобненький лаптопик с диагональю 12 дюймов), всегда хотел его использовать в автобусе, пока еду на работу — ну и на обратном пути тоже. Однако в автобусе так трясет, что за жесткий диск становится просто страшно — его там покрошит в мелкий порошок. В связи с чем был приобретен Solid State Disk (примерно то же, что и обычная флашка, только по взрослому) фирмы OCZ, который (на тот момент) стоил безумно дешево и давал возможность попробовать все прелести SSD на собственном опыте. Был приобретен экземпляр OCZ Solid Series OCZSSD2-1SLD30G 2.5" 30GB SATA II MLC Internal Solid state disk (SSD) за фантастические по тем временам 220 долларов (все остальное начиналось с 400) и торжественно воткнут в вышеупомянутый лаптоп. Поскольку диск этот был одним из первых, так называемого первого поколения, то производительность на нем до сих пор оставляет желать лучшего. Но кое-что для улучшения как скорости работы, так и продления жизни диска, можно было сделать.

Приблизительно год назад в контакте администрацией был открыт топик (ссылка сохранилась, но по ней сейчас ничего нет), в котором пользователи предлагали свои варианты монетизации проекта. Варианты, которые на их взгляд более приемлемы, чем очевидные «платный вход» и «завесить всё баннерами».

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

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

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

1. Главная страница выглядит блекло и безлично
Что видит ваш посетитель, попадая на главную страницу магазина? Может ли со 100% уверенностью сказать, что это интернет-магазин? Может ли он узнать, чем торгует этот магазин? Типичной ошибкой является пренебрежение к законам коммерческого дизайна. Помимо мелкого шрифта и отсутствия должного описания, часто не всегда удается найти центр композиции. Все тексты и картинки выглядят или второстепенным или же каждый элемент пытается «перекричать» соседний. Вспомните, как выглядит газета бесплатных объявлений, заполненная массой пестрых рекламных блоков.

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

2. Видны ли способы связи с менеджерами?
Одним покупателям проще прийти в магазин и самим отыскать товар на полках, другим же удобнее прямо с порога спросить продавца о наличии и стоимости. Даже если ваш магазин создавал профессиональный дизайнер, проконтролируйте, чтобы тем, кому удобнее позвонить или написать вам, изложив свои вопросы, не пришлось долго искать, как это сделать. Идеальным вариантом будет номер телефона, который всегда навиду. Например, в верхней части страницы.

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

За хорошие манеры можно принять наличие пункта об оплате и доставке на видном месте.

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

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

В своем исследовании механизма хабракармы, проведенном в течение марта с.г., я использовал 75 виртуальных персонажей. Мощность кластера в составе 45 персонажей, задействованных в ходе предварительного эксперимента, оказалась недостаточной для того, чтобы из полученной статистики сделать надежные выводы. Сегодня же погрешность результатов исследования я оцениваю как 1,3%.

К концу эксперимента администрация Хабрахабра заблокировала 7 персонажей, но характер и масштаб проводимого эксперимента, похоже, не разгадала. В связи с чем заранее приношу администрации извинения и рассчитываю на понимание: если миры создаются, то разве не для того, чтобы их исследовать?

Я давно хотел проверить, насколько больше запросов сможет обработать C-процесс, в сравнении с Perl-скриптом.
Проверял на простом скрипте с одним SQL-запросом, дабы избежать влияния mysql. Веб-сервер nginx, использовалось FastCGI.

Samy Mamkar разработал систему, которая позволяет хранить куки в 8 местах, автоматически восстанавливая друг друга, и даже добиться того, чтобы куки, поставленное в одном браузере, действовало и в другом.

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

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

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

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

Надеюсь эти советы будут полезны и для вас.

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

В многопользовательские онлайн игры по всему миру играют миллионы человек, они тратят на это увлечение более 2 млрд. долларов ежегодно. Немалая часть денег приходится на сегмент игроков, которые общаются на русском языке. Но кто же они эти люди?
Неделю назад я инициировал исследование, с результатами которого хотел бы вас познакомить. Думаю, что выводы могут удивить многих. ;)

Бытует мнение, как среди игроков, так и среди людей посторонних, что мир многопользовательских онлайн игр населяют люди с крайне ограниченными жизненными интересами, так называемые «задроты». Однако по результатам моего исследования выяснилось, что среди любителей мморпг таких всего 10%. А доля школьников-«задротов» ни как не превышает 4% в общей совокупности игроков.
Основную часть сообщества любителей ММОРПГ составляют взрослые люди, которые осознанно выбрали это хобби. Кроме игр они увлекаются другими вещами от чтения книг и творчества до алкоголя и прочего «opensourec'a головного мозга».

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

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

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

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

Ниже пойдет текст достойный пера К.О.

Китайский трафик велик и беспощаден. Когда какая-нибудь смешная или не очень картинка попадает в китайские блоги, провайдер colocation начинает обижаться и рассказывать про несоответствие соотношений 3 к 2 российского и зарубежного трафика.

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

Примеров реализации есть несколько (ngx_http_geo_module, ngx_http_geoip_module или обычным deny), наиболее эффективный с помощью ngx_http_geo_module и базы wipmania (http://www.wipmania.com/ru/base/)

Облегчение на одном из серверов.

Привет, %username%
Тут я хочу рассказать о том, как я настраивал кеширование на одном сервере, точнее VDS. Характеристики сервера: 2000MHz, 2GB RAM, 80Gb HDD, технология виртуализации — OpenVZ.
Было решено использовать Nginx версии 0.7.64. На сервере находилось около 200 сайтов. И несколько высоко нагруженных проектов. Вот эти самые проекты и давали ощутимые тормоза и нагрузку на сервер. Мы будем рассматривать DLE в этом примере.

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

Наиболее простая схема «распараллеливания» нагрузки — вынос основной нагрузки на несколько frontend. Раньше приходилось мучиться (или наслаждаться, кому как) с webdav'ами, кластерными ФС и прочими хитростями чтобы обеспечить актуальную информацию, так было до тех пор, пока не появился nginx, а точнее proxy_store и proxy_cache в нём.

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.

Вчера на Хабре появился текст 10 полезных выводов и принципов юзабилити — перевод статьи с сайта Smashing Magazine.

Smashing Magazine славится своими гигантскими обзорами из серии «Еще 250 плагинов для Вордпресса, которые мы нашли на этой неделе». Такие тексты составляются по принципу «поискать в Гугле красивые картинки и придумать к ним подписи». Для серьезных статей такой метод не подходит.

Вчерашняя статья – прекрасное собрание спорных утверждений (часто дающихся без доказательств или ссылок на источники), перевирание результатов исследований, на которые даются ссылки и выдачи очевидных вещей за открытия.

Под катом будет подробный разбор каждого пункта.

Привет, хабралюди!

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

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