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

PhantomJS это все плюшки WebKit из консоли с управлением на JS и поддержкой различных стандартов и технологий: DOM, CSS, JSON, Canvas и SVG.

Внутри несколько примеров использования

Постановка проблемы

Некоторое время назад по долгу службы работы, встал на обсуждение вопрос «А нужно ли делать на новом проекте авторизацию через сторонние сервисы?». Мозг, взбудораженный красивыми всплывающими окошками, виджетами и прочими украшательствами, призывно требующими «Войди через меня!», конечно же обеими руками был за, да и современные вебдванольные (а то и, тьфу тьфу, вебтринольные, быть может?) тенденции развития крупных порталов, как бы, намекают. Однако, я не зря сказал, что началось всё с обсуждения, ибо, где есть споры, там есть и камни преткновения. Такой камень мы нашли и здесь.

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

Казалось бы, какая разница, регистрировать аккаунт на сайте, или входить через внешние ресурсы?

В 2002 году Марк Ньюхаус (Mark Newhouse) опубликовал статью «Укрощение списков» ("Taming Lists"), довольно-таки интересную часть которой он посвятил объяснению того, как создавать собственные списки, украшенные псевдо-элементами. Почти десять лет спустя Николас Галлахер (Nicolas Gallagher) изобрел технику, которая использует псевдо-элементы из спрайтов, для создания фоновых изображений.
Сегондя, основываясь на опыте гигантов, мы постараемся развить эту тему. Мы обсудим, как можно украсить элементы без дополнительной разметки, используя только технику CSS-спрайтов. Результат будет работать также в Internet Explorer 6 и 7 версии.

Жизнь была прекрасна и все было в этом мире хорошо, пока почта с моего сайта не стала активно посылаться в спам практически всеми крупными почтовыми серверами. Особенно усердствовал в этом Gmail. Частенько меня принимали за спамера в Yandex, реже в mail.ru и rambler.

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

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

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

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

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

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

Сервис Initializr позволяет всего в несколько кликов получить рыбу для типового проекта. Если более конкретно, то он может

• наполнить страницу базовым контентом;
• подключить jQuery в разных формах;
• подключить библиотеки типа Modernizr;
• сконфигурировать настройки сервера, создав например .htaccess.

Ребята активно развиваются и уже сделали русскую версию.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Добрый день, уважаемые хабражители. Я давно хотел опубликовать под GPL-лицензией свой «Текстовый анализатор» ([1]). Наконец, дошли руки. «Текстовый анализатор» — это исследовательский проект, который я разрабатывал три года на 3, 4 и 5-м курсах университета. Главная цель была: создать алгоритм распознавания авторства текста, используя нейросети Хэмминга или Хопфилда. Идея была такова: эти нейросистемы распознают образы, а к задаче распознавания образов можно свести задачу выявления авторства. Для этого необходимо по каждому тексту собрать статистику, и чем больше разных критериев, тем лучше: частотный анализ букв, анализ длин слов/предложений/абзацев, частотный анализ двухбуквенных сочетаний, и так далее. Нейросистема могла бы выявить, характеристики каких текстов наиболее сходны. Работы было — вал. Много кода, хитрые алгоритмы, ООП, паттерны проектирования. Помимо основной задачи я так же реализовал ещё одно ноу-хау: «Карту благозвучия». По задумке, такая карта должна показывать все плохо и хорошо звучащие места, выделяя их цветом. Критерии оценки благозвучия должны задаваться каким-то универсальным образом, например, правилами. Для этой цели я даже разработал специальный графический язык, RRL (Resounding Rules Language). Работы было — вал. Много кода, хитрые алгоритмы, ООП, паттерны проектирования. В итоге получилась большая и сложная программа, правда, с неприглядным интерфейсом. С этим проектом я даже выиграл в конкурсе дипломных работ, получил 1 и 3 места на университетских конференциях, а так же 2 место на международной научно-практической.

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

(У статьи есть продолжение и окончание.)

Структура статьи:

1. Анализ авторства
2. Знакомство с кодом
3. Внутренности TAuthoringAnalyser и хранение текстов
4. Разбиение на уровни конечным автоматом на стратегиях
5. Сбор частотных характеристик
6. Нейросеть Хэмминга и анализ авторства

Дополнительные материалы:

• Исходники проекта «Текстовый анализатор» (Borland C++ Builder 6.0)
• Тестирование нейросистемы Хэмминга в Excel'е ([xls])
• Таблица переходов для КА, разбивающего текст на уровни ([xls])
• Расчет благозвучия отдельных букв ([xls])
• Презентация дипломного проекта «Текстовый анализатор» ([ppt])
• Презентация проекта «Карта благозвучия» ([ppt])
• Все эти материалы в сжатом виде ([zip], [7z], [rar])

Предисловие

Загрузка файлов всегда занимала особое место в веб-разработке.
О трудности оформления стилями <input type=file/> уже сказано немало, почитать об этом можно, например, по ссылкам раз, два, три, четыре, пять, шесть.
Но и сам процесс загрузки файлов нетривиален, есть много разных способов – и ни одного идеального.

Я уже писал о внедрении на нашем проекте Файлы@Mail.Ru silverlight-загрузчика полгода назад. На тот момент у нас подерживались iframe, flash, silverlight и обычная загрузка файлов. Но прогресс не стоит на месте, и вот уже последние бета-версии всеми горячо любимых браузеров в полной мере поддерживают html5 FileAPI (справедливости ради, стоит заметить, что, как обычно, некоторые поддерживают своеобразно, но об этом — ниже).

Пока писалась статья, Chrome 9 был объявлен stable и форсировано обновился уже на 75% установок 8 версии. Так, что празднуем поддержку File API первым стабильным браузером, ура!

Мы подумали, что не использовать такую технологию было бы преступлением против юзеров пользователей.
Подумали — и внедрили html5 загрузку в дополнение к уже существующим вариантам.
В итоге наши пользователи получили множество плюшек:
— прозрачная дозагрузка после обрыва соединения (и даже рестарта браузера!);
— очередь загрузки;
— прогресс-бар (пользователи MacOS и Safari наконец могут видеть прогресс без всяких инородных плагинов), возможность удаления файлов из очереди, если передумал.

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

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Двоичная куча (binary heap) – просто реализуемая структура данных, позволяющая быстро (за логарифмическое время) добавлять элементы и извлекать элемент с максимальным приоритетом (например, максимальный по значению).

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

Введение

Двоичная куча представляет собой полное бинарное дерево, для которого выполняется основное свойство кучи: приоритет каждой вершины больше приоритетов её потомков. В простейшем случае приоритет каждой вершины можно считать равным её значению. В таком случае структура называется max-heap, поскольку корень поддерева является максимумом из значений элементов поддерева. В этой статье для простоты используется именно такое представление. Напомню также, что дерево называется полным бинарным, если у каждой вершины есть не более двух потомков, а заполнение уровней вершин идет сверху вниз (в пределах одного уровня – слева направо).

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

Продолжаем публикацию наиболее интересных глав из книги Magnus Lie Hetland «Python Algorithms». Предыдущая статья расположена по адресу habrahabr.ru/blogs/algorithm/111858. Сегодня же речь пойдет об эффективной работе с графами и деревьями и особенностях их реализации в Python. Базовая терминология теории графов уже обсуждалась (например здесь: habrahabr.ru/blogs/algorithm/65367), так что я не включил часть главы о терминах в эту статью.

Реализация графов и деревьев

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

Мой прошлый пост вызвал огромный резонанс. Комментариев было не много, но я получил множество писем, а некоторые читатели выступили даже с открытыми заявлениями (там, правда, преобладают наезды на меня лично и на хабр в целом, но есть и мысли по существу вопроса). Поэтому я решил продолжить писать в жанре «мои мысли по поводу вопросов известной компании». Этим постом я постараюсь решить две задачи: (i) ответить на вопросы и возражения читателей предыдущего поста и (ii) толкнуть в некотором смысле философскую мысль о безIFовом программировании. Букв получилось довольно много, но те, кому интересно только что-то одно из поста, могут пропустить половину.

И ещё: этот топик (как и прошлый) — не наезд ни на кого. Просто интересно порассуждать об интересных вопросах. Здесь нет подтекста, намёка, вызова. Параноиков и сторонников теорий заговоров попрошу расслабиться.

В этот раз хотел бы взглянуть на вопрос 4.

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

Демо тут

Постановка задачи поиска в строке

Часто приходится сталкиваться со специфическим поиском, так называемым поиском строки (поиском в строке). Пусть есть некоторый текст Т и слово (или образ) W. Необходимо найти первое вхождение этого слова в указанном тексте. Это действие типично для любых систем обработки текстов. (Элементы массивов Т и W – символы некоторого конечного алфавита – например, {0, 1}, или {a, …, z}, или {а, …, я}.)

Наиболее типичным приложением такой задачи является документальный поиск: задан фонд документов, состоящих из последовательности библиографических ссылок, каждая ссылка сопровождается «дескриптором», указывающим тему соответствующей ссылки. Надо найти некоторые ключевые слова, встречающиеся среди дескрипторов. Мог бы иметь место, например, запрос «Программирование» и «Java». Такой запрос можно трактовать следующим образом: существуют ли статьи, обладающие дескрипторами «Программирование» и «Java».

Поиск строки формально определяется следующим образом. Пусть задан массив Т из N элементов и массив W из M элементов, причем 0<M≤N. Поиск строки обнаруживает первое вхождение W в Т, результатом будем считать индекс i, указывающий на первое с начала строки (с начала массива Т) совпадение с образом (словом).
Пример. Требуется найти все вхождения образца W = abaa в текст T=abcabaabcabca.

Образец входит в текст только один раз, со сдвигом S=3, индекс i=4.

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

В компании был написан и запущен внутренний сервис под названием «Chaos Monkey» (Обезьянка Хаоса (не путать с Хаусом!)), который случайным образом убивает инстансы AWS или процессы на серверах, обслуживающих сервис. Как ни странно, такой подход не вредит, а помогает технарям улучшать качество сервиса и повышать аптайм, убивая несколько обезьян зайцев — системы Netflix проходят круглосуточную проверку на то, что:

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

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