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

Мы захотели узнать, почему уходят игроки и можно ли предсказать их уход. Предмет исследования – ММОРПГ Аион, однако наши результаты оказались применимы к широкому кругу игр и онлайн сервисов.

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

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

Именно так выглядит Data Mining в клиентской аналитике. И именно так это уже работает на практике в сотнях крупных компаний по всему миру и в нашей стране.

Электронная коммерция в России все набирает обороты. Вчерашние
небольшие проблемы вырастают в глобальные.

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

Я думаю, довольно многим хочется иметь возможность записывать собственные телефонные разговоры на своём смартфоне за 20 тысяч рублей. Задача вроде бы банальная, и вроде бы API Android’а позволяют это делать. Но почему запись не работает почти на всех устройствах без всяких шаманств и танцев с бубном?

Закон

Всё дело в том, что в некоторых странах запись является нелегальной и производители не тратят время на добавление такой возможности. Но как же быть тем, кто живёт в странах, где записывать разговоры не запрещено. Например, в России нет запрета на запись собственных телефонных разговоров, даже не нужно предупреждать собеседника о записи. Только прослушивать записи ваших разговоров имеете право только вы, т.е. если вы дадите прослушать запись третьему лицу, то это будет расцениваться, как нарушение 23-й статьи Конституции РФ.

Телефон

В некоторых устройствах ядро не содержит нужного драйвера, в некоторых устройствах запись отключена в системных библиотеках. Поэтому на этих телефонах запись не работает ни в одной из десятков программ в Market’e. Оно и не удивительно, ибо все они пишут разговоры одним и тем же способом. Но на некоторых телефонах запись работает без всяких танцев с бубном, например, на Samsung Galaxy S II. Но не на каждой прошивке, например, на Android 4 ICS запись уже не работает, видимо, Samsung посчитал, что пользователям она не нужна и убрал её.

Я закончил разработку бета-версии своего оптимизатора загрузки JavaScript — jWidget SDK.

github.com/enepomnyaschih/jwsdk/wiki

jWidget SDK — это небольшой скрипт, сборщик (прекомпилятор) вашего JavaScript. Это обертка вокруг YUICompressor, которая автоматизирует сборку проекта и дает очень гибкую конфигурацию. Инструмент совместим с любой архитектурой сервера, со всеми JavaScript-фреймворками. Инструмент бесплатный, с открытым исходным кодом и имеет лицензию LGPL.

Инструмент успешно протестирован на нескольких коммерческих проектах с разной серверной архитектурой. В том числе (не имею права дать ссылки):

— Чистый веб-сервис на Java + AJAX + JS. Особенность приложения: весь-весь-весь контент рендерится динамически через JavaScript, и приложение грузится почти мгновенно благодаря браузерному кэшированию
— Один шахматный клиент на jQuery, встроенный в сайт на Zend Framework
— Клиент одного приложения на Adobe Air

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта). Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…

… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.

Рассмотрим процесс интеграции с точки зрения клиент-исполнитель. Сценарий продажи может превратиться в сущий адъ из-за пары неловких движений менеджера.



Так что знакомимся с горьким опытом и делимся своим:

В этой блогозаписи я намерена поделиться несколькими такими советами по увеличению юзабилити сайта, каждый из которых очень лёгок в реализации. Не все они кросс-браузерны, но всё равно они «глазурь на тортике»: читатель и не заметит, что их нет.

1. Отображайте нажатия кнопок и кнопкоподобных ссылок

Мой излюбленный совет. Когда стиль кнопки задаётся в CSS, или когда для отображения необычной кнопки используется рисунок (либо как фон, либо как элемент <img />), то кнопка не реагирует на нажатие во всех или в некоторых браузерах (зависит от ситуации). Вот какой простой уловкою вы можете дать знать посетителю сайта, что он и впрямь нажал на нечто нажимаемое:

.mybutton:active {
   position: relative;
   top: 1px;
   left: 1px;
}

Этим кодом кнопка смещается на 1 пиксел направо и на 1 пиксел вниз, когда её нажимают. Испробуйте: выглядит весьма убедительно.

Есть другие, не менее быстрые варианты: придать границе свойство inset, указать свойству text-indent значение 1px, изменить направление градиентного фона (что можно сделать быстро, если для этого не придётся прибегнуть ко графическому редактору, то есть если где-то ещё на сайте используется готовый перевёрнутый градиент), или комбинация нескольких из них.

2. Плавные переходы (CSS3 transitions)

Сегодня мы рады сообщить о добавлении панорам Москвы и Петербурга на Карты Google. Кроме этих городов пользователи Карт Google смогут посмотреть на Химки, Мытищи, Подольск, Домодедово, Петергоф, Пушкин, Павловск, Кронштадт и Ломоносов. Для того чтобы начать виртуальную прогулку по улицам, нужно либо максимально приблизить карту, либо перетащить оранжевого человечка с линейки масштаба на интересующую вас улицу.

Вид с Васильевского спуска в Москве
Теперь вы можете прямо на экране монитора изучать архитектуру двух столиц — посмотреть, например, как выглядит знаменитый Дом Зингера в Санкт-Петербурге или доходный дом Перцовой в Москве. А если вы готовитесь к поездке в Москву или Санкт-Петербург, то можете оценить внешний вид гостиниц в этих городах и “оглядеться”, что есть поблизости. Например, посмотреть на заново отстроенную гостиницу “Москва” или на “Асторию”, из окон которой прекрасно видно Исаакиевский собор.

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

«Вход» в Павильонный зал Малого Эрмитажа
Если вы прокладываете маршрут, то иногда словесного описания поворотов может быть недостаточно. Поэтому теперь при прокладке маршрутов в Москве и Санкт-Петербурге можно своими глазами посмотреть, как выглядит та или иная развязка. Панорамы также появятся в Навигации Google для смартфонов на базе Android — теперь пользователи прямо смогут с мобильного телефона посмотреть, как выглядят повороты, сложные развязки и пункт назначения.


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

Москва и Московская область

• Московский Кремль и Красная площадь
• Государственный музей-заповедник «Царицыно»
• Усадьба Кусково
• Усадьба Коломенское
• Сад «Эрмитаж»
• Центральный парк культуры и отдыха имени Горького
• Музей техники Вадима Задорожного
• Парк на речном вокзале, Cеверный речной порт
• Свято-Троицкая Сергиева Лавра
• Церковь Знамения Пресвятой Богородицы в Дубровицах
• Храм святителя Митрофания Воронежского
• Благовещенский храм

Санкт-Петербург и Ленинградская область

• Петропавловская крепость
• Государственный музей-заповедник «Петергоф»:

Казань

• Казанский Кремль
• Парк Тысячелетия Казани
• Улица Баумана

Борис Хвостиченко, менеджер по продуктам

В опубликованной накануне (февраль, 2012) статье озаглавленной «Определение страны по IP: тестируем скорость алгоритмов» сравнивались реализации на уровне БД и нативной реализации. Мы же предлагаем рассмотреть ещё более оптимальный и простой алгоритм, который может быть реализован как в БД, так и в нативном варианте – плоские диапазоны.

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

Задача: Бэкап данных в локальную директорию и на отдельный сервер, с использованием минимума стороннего ПО, логированием и оповещением администратора в jabber при сбоях. Все основные функции большинства ПО для автоматического бэкапа, но без установки оного, а следовательно без его багов (что, собственно, и привело к подобной идее).

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

Эти префиксы необходимы для того, чтобы во браузерах работали те свойства CSS3, которые ещё не до конца стандартизированы: считается, что отдельное задание свойства для каждого из нынешних браузеров поможет в дальнейшем обойти возможное различие между нынешней реализацией свойства в каждом конкретном браузере и окончательными требованиями страндарта. Во браузере Mozilla Firefox для этой цели употребляется префикс «-moz-», в Google Chrome и в Apple Safari (и в других браузерах на основе Webkit) — префикс «-webkit-», в Опере — префикс «-o-», в IE — префикс «-ms-», а в Konqueror (и в наиболее ранних версиях Safari) — префикс «-khtml-».

На практике, однако же, автор сайта чаще всего использует своего рода «общий знаменатель» возможностей нескольких браузеров — значения свойств CSS3, работающие одинаково (или почти одинаково) во всех современных браузерах. Да и записываются все они также одинаково. Указание префиксов сводится поэтому ко многократному повторению свойств. Например, чтобы придать нескольким кнопкам jQuery-плагина ColorBox закруглённые края и заставить их отбрасывать тень, поневоле придётся записать в CSS вот что:

#cboxPrevious, #cboxNext, #cboxClose {
   -webkit-box-shadow: 0 0 6px #000;
      -moz-box-shadow: 0 0 6px #000;
           box-shadow: 0 0 6px #000;
   -webkit-border-radius: 6px;
      -moz-border-radius: 6px;
           border-radius: 6px;
}

Во-первых, это задалбывает.

Во-вторых, это неэкономично.

В-третьих, всегда существует риск забыть о необходимости указать тот или иной префикс. (В списке «How to avoid common CSS3 mistakes» эта ошибка — на первом месте.)

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

И такое средство появилось — благодаря Lea Verou. Вот оно:

На тему оптимизации MySQL запросов написано очень много, все знают как оптимизировать SELECT, INSERT, что нужно джоинить по ключу и т.д. и т.п.

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

Предисловие

Давно хотел написать. Мысли есть, желание есть, времени нету… Но вот нашлось, так что привет, Хабра.
Здесь я собрал все идеи, которые помогали и помогают в разработке веб-приложений. Для удобства я разбил их на группы:

1. Память
2. Оптимизация операций
3. Выделение критических участков
4. Циклы и объектные свойства
5. Немножко о DOM
6. DocumentFragment как промежуточный буфер
7. О преобразованиях в объекты
8. Разбитие кода
9. События перетаскивания
10. Другие советы

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

Память

Хоть это и не должно волновать клиентского программиста, но не забываем, что память всё-таки не бесконечна и когда-нибудь может закончиться, например, когда запущено несколько массивных программ: офис, графический редактор, компиляция большой программы и др. Несмотря на то, что приведенный пример тривиален, у меня действительно такое случилось, хоть и не из-за браузера, но он тоже сыграл свою роль: 1,3 Гб оперативы (отладчик, около 30 вкладок), начались тормоза по перегрузке страниц ОП в файл подкачки.
Чтобы уменьшить расход памяти, я предлагаю несколько способов:

Инженер из компании Google, автор трёх книг по веб-производительности и оптимизации, Стив Содерс (Steve Souders) опубликовал презентацию "JavaScript Perfomance" о том, какие методы нужно применять, чтобы скрипты меньше тормозили загрузку страниц.

По статистике WebPagetest, блокировка загрузки файлов .js на сайтах из Alexa Top 100 снижает среднее по медиане время загрузки страницы c 3,65 с до 2,487 с, то есть на 31%. Если вы видите медленную загрузку веб-страниц и хотите улучшить этот показатель, то, по мнению Стива Содерса, первым делом нужно посмотреть на JavaScript.

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

Боевая задача.

Предположим нам хочется захостить небольшой проектик где-нибудь в надежном и не особо тормозящем месте. А поскольку сайт небольшой, то не будем заморачиваться и захотим от хостинга что-нибудь самое простое. Для наших целей вполне хватит PHP, MySQL и доступа по FTP.
Для решения этой задачи идеально подходит Веб сервис от Амазона в котором удивительным образом сочетается способность выдерживать большие нагрузки с бесплатным пакетом ресурсов на первый год после регистрации. В бесплатный пакет входит много чего, но в данный момент нас будут интересовать:

• Виртуальный сервер в формате micro на основе Linux с доступом по SSH.
• 30Гб места в Elastic Block Storage плюс 1Гб под бэкапы.
• 15 Гб трафика в месяц.
• Выделенный внешний IP адрес.

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

Как Вы знаете — в разработке объёмного JS-приложения где используется популярнейшая библиотека jQuery наступает момент когда остро встаёт проблема производительности. Все силы кидаются на амбразуру профайлера, каждый вызов скрупулёзно исследован, каждый функционально нагруженный кусок реализации обнюхан со всех сторон и выправлен. Но беда поступает не с той стороны, откуда её ждут 90% разработчиков. Селекторы — Как много в этом слове.
Давайте разберёмся — как работает эта магия и почему поиск DOM-элементов может стать причиной падения производительности приложения.

 

В последнее время в высоконагруженных сайтах стали все чаще применять технику Partial Caching или блочного кеширования. Достигается это, как правило, за счет применения, казалось бы уже давно забытого, SSI или близких ему технологий (например, ESI). Например, в связках Nginx + Memcached + SSI или Varnish + ESI.

Недавно и на Хабре тоже появился топик в котором автор описывал данный метод кеширования.

В данном топике в 3м варианте решения автор предложил читателям топика привести свои варианты решения относительно данной задачи.

Этому, собственно, и посвящается этот топик.

Известно, что следуя идеям старой школы, а именно, добавляя ссылки на JS и CSS в страницы, может обернуться большим временем загрузки страницы. Браузер отображает страницу по мере скачивания, но останавливается, если натыкается на тег script со ссылкой, до того момента, пока скрипт не будет загружен и выполнен. Сайты стали использовать всё большее количество скриптов, начальное отображение страницы занимает всё больше времени, к примеру, на этой странице, которую вы читаете, 13 скриптов, 7 из которых находятся в head'е. Ко всему прочему, некоторые браузеры по-прежнему придерживаются ограничений на одновременное количество загрузок с одного хоста.

Сразу предлагаю принять, что все JS файлы минимизированы, и передаются в сжатом виде.

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
— свой вариант…

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

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