В 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 секунд вполне достаточно).

Этот ролик нужно смотреть каждое утро, когда идешь на работу. Кузнец Пименов показал всем, что хорошо и качественно работать это возможно :)

Прелюдия

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

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

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

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

Так вот. В Kohana готового решения нет. Поэтому я и написал простой способ реализации компонентов который решается в три строчки кода.

И так. Пишем хелпер widget.php и кидаем его в папку application/helpers. Содержание хелпера следующее:

Copy Source | Copy HTML

1. <?php
2. class widget
3. {
4.     public static function paste($className,$functionName,$parameters = null)
5.     {
6.         $controllerName = $className.'_Controller';
7.         $controller = new $controllerName;
8.         $controller->$functionName($parameters)->render(true);
9.     }
10. }
11. ?>

В классе контроллера пишем метод обычного содержания только вместо рендеринга шаблона мы его возвращаем т.е пишет return. Я всегда использую немного переопределенный контроллер Template_Controller. Пример метода контроллера:

Copy Source | Copy HTML

1. public function widget_example()
2. {
3.     return View::factory('_example.php',array('var' => 'Привет мир!'));
4. }

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

Copy Source | Copy HTML

1. <?php widget::paste('Index','widget_example')?>

И все — теперь вместо этой строки у нас отрендерится наш виджет. Вот так вот просто. Если необходимо то можем передать в компонент необходимые значения третьим аргументом в виде массива.
Кстати partial (symfony like) реализовываются простым включением в шаблон

Copy Source | Copy HTML

1. <?php View::factory('template')->render() ?>

partial — это простое включение шаблона (для тех кто не знает)
P.S. Только давайте не будем разводить холивары по поводу Smarty(и т.п.) vs Native Template.
Есть много наработок по поводу Kohana — со временем опубликую цикл статей на блоге и здесь.
UPD. Перенести пост в блог Kohana немогу. Не хватает кармы

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

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

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

Рассказ рассчитан на подготовленную аудиторию и не является точным пошаговым руководством к действию.

Данная статья была создана по мотивам презентации, сделанной на конференции SQA Days. Статья впервые опубликованна на GUI.ru и теперь хотелось бы обсудить usability guideline с хабралюдьми

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

Что следует понимать под юзабилити? Определение юзабилити приведено в стандарте ISO 9241-11 как степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

Начинаю вести серию статей Это статья про вёрстку html css js, начинаю с самого простого, потом планирую описать более сложные вещи и всякие тонкости и этим видимо так и закончил

Продолжение этой статьи

Долгое время в ветках SVN был один существенный недостаток. Система не помнила мержей, и программисту приходилось самостоятельно заботиться о том, что бы сохранить номер ревизии, когда происходило копирование изменений из транка. Проблема частично решалась добавлением комментариев в лог, но все таки это было чревато ошибками, и целиком ложилось на совесть программиста.
В версии 1.5, наконец-то, программисты Subversion выполнили свое давнее обещание, и добавили несколько полезных фич для работы с ветками.
Итак, в версии 1.5 команда merge обзавелась двумя новыми опциями: --record-only и --reintegrate.
Теперь ответственность за контроль копирования изменений ложится целиком на плечи SVN (merge tracking), а программист может легко, и без боязни выполнять merge так часто, словно это команда update.

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

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

С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации Ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root'ового шелла предлагается писать sudo su -. Попробую объяснить, почему такое положение вещей кажется мне неправильным.

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

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

В преддверии Всемирного дня юзабилити (13 ноября) и предстоящей по этому поводу открытой конференция WUD 2008 (13 ноября, 10:00, Москва, конференц-зал компании 1С, вход свободный) на RuTube появилось видео с прошлогодней конференции WUD 2007.

Задачи, решаемые юзабилити — международный подход (Константин Самойлов)

Презентация (pdf)

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

Существует немалое число серверных библиотек и утилит, способных генерировать сложные графики. Однако я считаю, что такой подход не всегда оптимален. Если мы можем производить визуализацию на стороне клиента с помощью JavaScript, то почему бы нам не воспользоваться такой возможностью? Логика работы подобной связки проста: сервер генерирует данные, а клиент их визуализирует.

Разумеется, вы можете воспользоваться Flash, Silverlight или Java-апплетами, однако в этом обзоре я хотел бы вам показать библиотеки визуализации, написанные на чистом JavaScript.

Fugue Icons

Отличный пак из 1000 иконок в размере 16x16

Эти иконки распространяются по лицензии Creative Commons Attribution 3.0 license.

Ссылка на сайт
Скачать пак | Посмотреть иконки (1199.25 КБ)

Недавно, у меня случилась проблема с GD на сервере — он перестал понимать png, после получаса мытарств, решил посмотреть на ImageMagick и его PHP интерфейс IMagick
После недолгого гугления нашел замечательный блог посвященный Imagick. Там же нашел способ делать красивые превьюшки. Однако, способ, предложенный там, правильно отрабатывал только с png картинками. Я немного поковырялся и сделал свой.

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

1. Использование дефисов вместо тире em-dash.



Если вам нужно прервать мысль, то делайте это с помощью символа (alt+0151), а не парой знаков «минус». Это, пожалуй, главный источник раздражения для всех редакторов.

Часть 1.

Введение

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

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

Вообще elance.com — крупнейший и самый старый игрок на рынке бирж фриланса, вернее не совсем фриланса, а скорее аутсорса, так как на ней представлено очень много компаний средней величины и этим elance отличается, например, от российского freelance.ru И я думаю начинающему фрилансеру будет очень полезно там поработать и приобрести реальный опыт, отличный от опыта работы на российском рынке, со своими плюсами и минусами. Возможно кому-то просто стало тесно на freelance.ru, т.к. на оном дизайнеров как у меня волос на жопе, а заказов достаточно мало )

Дальше много букв для тех, у кого пустые карманы и большое желание поработать фрилансером :)

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

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

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

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

Давайте сразу же договоримся — эти советы подходят в основном программерам, ну и, скажем так, сильно технишн людям. Зададимся вопросом — что такое «продуктивность»? Не знаю как вы, а я вкладываю в это слово очень простое значение. Человек продуктивен, когда выполняет необходимые ему действия с минимальным напрягом для себя и максимальной отдачей для других. В случае программера идеально продуктивным является человек, который легко и непринужденно пишет хороший код за минимальное время. Хватит слов — вот вам советы:

1. Никогда не ищите глазами, пользуйтесь функциями поиска. Всегда, всегда используйте поиск, если вы печатаете быстро. Хороший пример — открытие файла в редакторе. Используйте поиск или комплишн (в зависимости от редактора) и вы увидите насколько это быстрее. То же относится к выбору таба/буфера, если редактор не позволяет перейти в нужный буфер — выкиньте его, иначе смотрите в пункт 4. Идеальный редактор работает так — нажимаем кнопочку (в моем случае Ctrl-X + b) и в строке ввода вписываем первые несколько букв открытого в другом табе файла. Завершаем всё нажатием tab и enter. Таким методом я переключаю открытый буфер за 0.2 секунды. Мышью и глазами я переключаю его за 1.4 секунды. Что приводит нас к следующему пункту.

2. Не повторяйте что-либо более 10 раз. Это критическое число для всех разное, для меня оно именно десять. Автоматизируйте. Больше. Чаще, но не увлекаясь глобализмом. Причем не только в коде, в редакторе, в среде, но и в жизни. Нужно разбить 20 куриных яиц? Сделайте коробочку с дырочками и отсекайте острую часть яйца. 11 раз написать триграмматон на заборе? Сделайте шаблон и купите балон с краской. Не забывайте, что клавиатурные шорткаты есть почти во всем софте. Каждый раз когда вы снимате руки с клавиатуры — теряете время.

3. Учитесь скриптовым языкам. Python, Ruby, Perl, Bash, Javascript, CMD, VBasic. Просто хватайте тот, который ближе к вам и пишите-пишите-пишите. Понятно, что выбрать просто, если вы работаете в windows — для вас только CMD и VBasic. Юниксоидам доступно чуть больше, думаю это одна из причин почему гики так активно пересаживаются на Linux. Я знаю, что учиться не легко — но надо. Есть один странный рецепт — попробуйте в течение 2-3 недель работать из консоли. Нет, не надо отказываться от окон и тп — просто откройте окно терминала или cmd и работайте из него, запустив нужный вам скриптовый интерпретатор. И ради бога, никаких far/mc/nc и тп. — ваша цель научиться писать скрипты. После этих 2х недель вы вернетесь к привычной среде с довольно большим знанием о том, как же устроен скриптовый язык. Напомню, для python и ruby есть ipython и iruby. Для perl есть mshell, остальные интерпретируемы сами по себе.

4. Изучите свой IDE настолько, насколько это возможно. В идеале — откажитесь от IDE в пользу хорошего текстового редактора. Я имею ввиду редактора. Например ViM или Emacs. Пользователи MacOS могут использовать и TextMate, однако мне он кажется жалким подобием левой руки (слабой пародией на MicroEmacs). Да, и уверяю вас — оба редактора, и ViM, и Emacs имеют столько возможностей, сколько не снилось любому другому. В то же время оба они прекрасно работают без донастройки, хотя я предпочитаю Emacs. Конечно многие еще помнят что Emacs раcшифровывается как Eight Megs And Constantly Swaping, но 8 метров памяти уже давно перестали быть чем-то из ряда вон выходящим. Окей, вернемся. Выберите редактор. И теперь используйте его везде, где только можно. Вбейте себе в голову — вы используете ТОЛЬКО этот редактор. Потому что достаточно хорошо знать два редактора невозможно. Знатоки утверждают что работая со своим редактором на полную катушку вы получаете буст к производительности в 200-500%. И глядя на Бацека, например, я в это верю. И единственный минус от этого знания только в одном — вы не сможете от этого отвыкнуть.

5. Изучайте технологии и пишите маленькие программки. Выделяйте себе 20-30 процентов времени на ковыряние в новых движках или базах данных. Да, двадцать-тридцать процентов времени. Я знаю что обычно на это выделятся куда меньше — но меня-то не надо обманывать, я ж сам такой был, и хорошо знаю сколько процентов времени программист пишет код. Подвиньте чуть-чуть время, выделяемое вами на чтение LiveJournal и закопайтесь по локоть в Django. Или сядьте и напишите скрипт для накручивания голосов на Хабре. В общем проводите время весело и с пользой. Это сильно помогает отдохнуть на работе не теряя темпа. А главное — это очень неплохо сказывается на структуре вашего кода — теперь вы знаете как и что делают другие.

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