Григорий Добряков

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

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

Мы представляем первую в мире анатомическую гелевую ручку, которая изогнута в соответствии с естественной анатомией человеческой руки. Линия изгиба была с точностью вычислена исследователями кафедры высшей математики СПБ ГМТУ и преподавателями РГПУ им.Герцена – законодателями в сфере образования молодёжи.

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

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

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

Зачастую бывает так, что мы садимся осваивать новый программный продукт, и нас начинает мучать странное ощущение "некачественности". Я не говорю о случаях, когда явно что-то не работает – там всё понятно. Я о другом – когда это ощущение рождается где-то на задворках подсознания, и его никак не выразить словами. Когда тебя спрашивают: ну скажи ты конкретно, что тебя не устраивает? А ты и сказать не можешь – мучаешься, пытаясь выразить свою неудовлетворённость словами.

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

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

Весь мир насыщен обратной связью. Прокрутите в голове все события, которые происходят в вашей жизни повседневно, и вспомните определить фидбэк от каждого из них. А теперь представьте, как выглядела бы жизнь, если бы фидбэка не было. Представьте себе девушку, которая не реагирует на ваши ласки. Разберите мышку и извлеките щёлкающий механизм. Попробуйте поработать на сенсорной клавиатуре айпада вслепую. Каждый раз выходя из машины, проверяйте вручную – закрылись ли все дверцы и багажник.
Мир без обратной связи был бы адом. Именно таким адом выглядит программный продукт, который не поставляет достаточное количество обратной связи пользователю. Что происходит прямо сейчас? Я кликнул – и что изменилось? Начался ли фоновый процесс? Или уже закончился? А если он идёт, то почему так долго? А успешно ли он завершился? Ждёт ли от меня система каких-то действий, или это я должен подождать? Можно ли закрывать эту страницу – сохранятся ли данные?

Причины создания таких программных продуктов лежат глубоко в области психологии. Большинство "компьютерных гиков" настолько "продвинуты" в области разработки и программирования именно потому, что у них нарушена коммуникабельность и связь с внешним миром. Они играют в вов и линейку, сидят в социальных сетях и на профессиональных форумах, занимают всё свободное время чтением документации, отрицая реальный мир и создавая вокруг себя воображаемый. Они реализуют себя в жизни в общении с компьютерами, потому что общество их отторгает, а компьютеры бессловесны и принимают их "как есть". Даже само понятие "компьютерной грамотности" становится для них критерием для деления людей на достойных и недостойных. Возможно, в глубине души они уверены, что Ньютон, Галилей, Коперник и Чарльз Дарвин тоже были программистами.

С теми кто просто замкнут по своей природе – ещё можно найти общий язык и помочь человеку осознать, что никакая программа не ценна сама по себе. Ценной её делает полезность для потребителя. Но если человеку впору ставить диагноз "аутизм" или "социопатия" – то в результате становится страшно. Страшно от осознания, что ты сидишь перед экраном и пользуешься продуктом, но тебя как-бы нет. Для автора ты – пустое место, робот с запрограммироваными use-кейсами и встроенным аппаратом для чтения документации. Только так автор может допустить тебя к использованию продукта, но если бы тебя вообще не было – вот это был бы идеал.

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

Материалы для самостоятельного изучения:
Рекомендации компании Apple
Рекомендации по книге Джефа Раскина "Интерфейс"
Не позволяйте знаниям ослепить себя
 
 

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

Итак, вспомним как мы все начинали делать сайты. Структура взаимоотношений "человек-сайт" выглядела примерно так:

Запрос -> Интернет -> Сервер хостинга -> Apache -> PHP -> MySQL -> Ответ

Молодой разработчик, воодушевлённый умными статьями про ЧПУ, практически сразу вдохновляется идеей использовать htaccess для манипуляции запросами. Цепочка увеличивается на один шаг:

Запрос -> Интернет -> Сервер хостинга -> Apache -> htaccess -> PHP -> MySQL -> Ответ

Рассмотрим что здесь происходит внутри: первый запрос к сайту порождает множество действий. Сначала дёргается Apache, при этом он отнимает много процессорных ресурсов и памяти. Он проверяет, существует ли файл htaccess, и считывает его – тем самым провоцируя избыточную дисковую активность. Затем он поднимает PHP, который в свою очередь "ест" ресурсы, отсылает запросы к БД и генерирует ответ. Этот ответ – всего лишь исходный html-код страницы. Запрашивающий клиент анализирует этот код и посылает ещё массу запросов для получения картинок, стилей, яваскриптов.

На каждый из этих вторичных запросов снова дёргается Apache, который считывает htaccess, при необходимости аналогично поднимает PHP и так далее. Таким образом, всего на один безобидный запрос к сайту уже генерируется чрезмерная активность в памяти и дисковой подсистеме.

Наш молодой разработчик становится умнее и подключает Nginx. Смотрим на нашу цепочку:

Запрос -> Интернет -> Сервер хостинга -> Nginx -> Apache -> htaccess -> PHP -> MySQL -> Ответ

Сервер Nginx крайне нетребователен к ресурсам и способен отдавать ответы на миллионы запросов в сутки даже на слабеньком сервере. Он просто отдаёт статические файлы (те самые картинки, стили, яваскрипты) не пропуская запросы дальше и не дёргая Apache, а значит давая существенную экономию ресурсов. Уже выйгрыш, но рано радоваться.

Во-первых, Nginx-у пофиг на ваши правила в htaccess. Безусловно, внутри него есть свой аналог, но он не совместим с форматом htaccess Апача, и правила для него надо хранить/вести/обновлять независимо, причём в большинстве случаев для этого потребуются права администратора сервера. Поэтому все ваши хитрости – закрытые директории, автогенерация "превьюшек", счётчики на скачивание файлов, блокировка спамеров по IP и прочее – могут кануть в небытие. Если, конечно же, вы не предпримете дополнительных мер.

Во-вторых, вспомним, что для генерации html-кода страниц нам по-прежнему требуется PHP. Как он работает? Он считывает исходный код php-файлов, компилирует его в реальном времени в исполняемый байт-код, и исполняет. Каждый раз при запросе он всё это делает снова и снова. Умные люди догадались сократить эту операцию, и стали применять так называемые акселераторы. Их суть проста: они один раз компилируют php-файлы, и сразу подсовывают готовый байт-код. Это помогает.

Но прогресс не стоит на месте, наш молодой разработчик осознаёт что не всегда хорошо писать php и html-код вперемешку, и натыкается на модную технологию XSLT. Это же так клёво – использовать одни и те же шаблоны на разных сайтах, унифицируя "выдачу" системы в XML-формате и просто применяя к ней XSL-трансформацию. Но спустя некоторое время он понимает (а скорее – не понимает), что сел обеими половинками своей задницы на два подводных камня: избыточность выдаваемых данных и ресурсоёмкость XSL-преобразований. Рассмотрим их:

Любая работа с XML-данными – ресурсоёмкая по определению. XML-файл – это тупой огромный кусок текста, составленный определённым образом, чтобы обозначать для человека древовидную структуру данных. Собрать его – крайне ресурсоёмкое дело. Прочитать его, а тем более "пройти" по дереву в поисках элемента, подходящего под требуемое условие – ещё более "тяжёлая" задача. Всё, что связано с обработкой строк, по определению медленно. Поэтому когда дело касается обработки XML-данных, их преобразований по особым правилам, формирования новых XML-файлов – всегда съедается огромное количество ресурсов. А вспомните, что в описанной схеме это происходит при каждом запросе, а запросов бывает – десятки в секунду.

Второй подводный камень – избыточность выдаваемых данных. Когда разработчик не знает, какие данные у него хотят получить, он для упрощения собирает и отдаёт все. Спросишь у него одну страницу – он тебе отдаст и её, и её потомков, и её предков (я имею в виду конечно не лично человека-разработчика, а систему, которая эти данные выдаёт в ответ на запрос). Хочешь построить меню? Вот тебе все страницы-потомки. Хочешь построить навигацию по "хлебным крошкам"? Вот тебе всё дерево предков до текущей страницы. И по каждой, подчёркиваю, по каждой странице система лезет в БД и достаёт оттуда массу избыточной информации – разумеется, в целях универсальности. Мало ли, мне потребуется узнать какие права доступа указаны у над-над-страницы на вот этот зелёненький блок с баннером? И система отдаёт всё сразу. А это – сотни и тысячи запросов к БД. Снова и снова, каждую секунду.

Избыточность – зло, прикрытое универсальностью. Осознав это, наш уже немного повзрослевший разработчик пытается закэшировать объекты системы, чтобы быстрее получать их из БД. В качестве самого простого решения он пишет их в файлы. И спустя некоторое время и здесь он жёстко разбивается о твёрдые камни реальности: объектов так много, что файловая система не справляется с их объёмом, и ресурсоёмкость "доставания" объекта из файлового кэша становится равной или превышает таковую при "доставании" из БД.

Лирическое отступление: а как же оптимизация БД, спросите вы? –  Она за рамками данного поста. Здесь мы говорим обо всём, что не касается базы данных, потому что её оптимизация – это отдельная работа, и это просто очевидная необходимость, которой посвящена масса соответствующей литературы.

Наш разработчик тщательно гуглит и вытаскивает на свет божий так называемые key-value хранилища, среди которых популярны memcache и redis. Кратковременный экстаз от офигенной скорости их работы (а она действительно достойна уважения "на малых оборотах") быстро сменяется осознанием реальности: объектов опять так много, что весомого прироста скорости нет. Это всё равно что представить себе 20-этажный дом с 5-ю подъездами: легко найти квартиру, когда на каждом подъезде написаны номера. Но представьте себе 100-этажный дом с одним подъездом: вроде бы количество квартир то же самое, но легко ли вам теперь найти нужную?

На помощь первому разработчику, который уже опустил руки, приходит второй. И говорит: а нафига ты возишься со своими объектами? Давай кэшировать конечный результат: html-код страницы, который получается на выходе из системы. А давай! И вот разгневанные пользователи пишут: почему не работает сортировка? почему в разных категориях каталога одни и те же товары? почему я кладу товар в корзину, а в углу по-прежнему написано "у вас ноль товаров"? почему результаты голосования не меняются? почему счётчик комментариев не растёт?

Потому что кэшировать надо с умом. И разработчики осознают, что за казалось бы простой задачей "положить страницу в кэш" встаёт гораздо большая задача – верстать сайты так, чтобы динамические элементы подгружались аяксом. Аяксовая корзина, аяксовая сортировка, аяксовое голосование и так далее. А это – огого сколько перевёрстывать надо.

К тому же такое кэширование не всегда спасает. Для аудитории, которая преимущественно ходит на "морду" сайта, это вполне сойдет – "морда" для всех одинаковая. А как только пользователь авторизовался, в подавляющем большинстве случаев контент ему выдаётся динамический. Всем кэшировать каждому отдельно – кэша не напасёшься. Что же делать?

И тут на сцену выходит концепция так называемого partial caching, которая была известна уже несколько лет назад, но в российских продуктах практически не применялась. В чём её суть: всё, что вы видите на страницах сайта, подразделяется на логические блоки. Причём (что важно!) это блоки, понимаемые обычным человеком. Их очень легко назвать: главное меню, меню категорий каталога, таблица товаров-новинок, голосование или опрос…

Так почему бы не кэшировать их по-отдельности? Просто и тупо кэшировать куски html-кода, из которых "лепится" вся страница. Например, главное меню вы можете не менять годами: пусть лежит себе в кэше. Меню категорий, скорее всего, вы последний раз меняли больше месяца назад. Товары появляются чаще, но и таблицу товаров-новинок наверняка можно обновлять раз в час или раз в день. Поймите главную суть: время жизни кэша для различных блоков должно быть разным, подходящим каждому блоку по смыслу и предназначению. Когда вы задумаетесь, сколько на ваших страницах реально динамических данных, а сколько – безжизненного статичного контента, вы осознаете, что можете ускорить свою систему на порядки.

Конечно же, не бывает бочки мёда без ложки дёгтя. Нельзя тупо кэшировать блоки на N минут. Если я поменял, например, описание товара – то кэш с этим описанием должен обновиться тут же, а не завтра утром. Поэтому здесь перед нами предстаёт во всей красе вторая неотъемлимая часть partial caching – это так называемый cache dependency. В буквальном смысле он означает, что любая модификация объекта должна посылать сигнал для обновления соответствующего кэша (и возможно – надстоящего кэша, если данный кусок является частью большего).

В завершение скажу: самый быстрый сайт – это статический HTML под Nginx на рамдиске. Может быть вам такой и нужен? 🙂 Если нет, то все мероприятия по кэшированию должны производиться с трезвым расчётом и тщательным тестированием результатов.