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

Покопавшись, можно найти что-нибудь типа связки xvfb (виртуальный фреймбуффер) с каким-нибудь браузером, например xvfb+opera, или khtml2png, который тянет за собой фигову тучу kde'шных либ. А ведь так хочется какого-нибудь легкого standalone скриптика...

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

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

В мире существуют тысячи CMS для самых разных целей, самого разного качества, самой разной перспективы, стоимости, распространённости и так далее. Серьёзно опробовать их все — нереально. Поэтому когда я только знакомился с миром движков для сайтов, выбирать приходилось наугад. Ниже я опишу свои впечатления от знакомства с теми или иными движками для тех или иных целей. К некоторым приложу краткое описание особенностей, впечатление о прочих состоит только из заглядывания в админку. Заметки эти составлялись и редактировались в течении долгого времени, но сейчас я решил, что лучше опубликовать их в нынешнем виде, чем ещё полгода-год по чуть-чуть редактировать не добавляя ничего принципиально нового.
Преимущество отдаётся бесплатным движкам. Платные будут рассматриваться только для сравнения или от безысходности, т.е. если нет бесплатных аналогов. Также ограничение на технологии: php. О движках на перле и питоне я не более чем слышал, на шарпе и джаве имел дело с самописными.
Итак, рассматриваются

• CMS общего назначения. Информационные сайты, визитки, блоги…
• Многофункциональные монстры.
• Галереи.
• Социальные сети.
• Форумы.
• Интернет-магазины.

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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

Это формат представления древовидных структур данных в виде одной строки в удобном для человека виде. Является обобщением формата «application/x-www-form-urlencoded» и как следствие — обратно совместим с ним. В основе Hiqus лежит всё тот же принцип представления данных в виде пар «ключ-значение» с той лишь разницей, что ключ может быть составным или пустым.

Данный формат уже используется такими монстрами как Яндекс (http://yandex.ru/yandsearch?date=within&text=hiqus&from_day=28&from_month=4&from_year=2009), Гугл (http://www.google.ru/search?as_q=hiqus&hl=ru&num=10&as_qdr=all) и многими другими, кому требуется передавать иерархические данные в строке запроса. Исключение составляют PHP-сайты, для которых традиционно используется свой, не слишком наглядный формат (пример, навскидку не нашёл, но выглядит он примерно так: ?user%5Bid%5D=123&user%5Bname%5D=Nick).

Недавно мы опубликовали историю появления на свет LinguaLeo.ru. Сервис запустился в бета-версии 1 марта. Меньше чем через месяц команда разработчиков возвращается в Москву. Но нам жаль просто так уезжать с острова Ко Чанг — уж очень много было вложено в создание комфортных условий для работы. Поэтому мы хотим поделиться своими впечатлениями, каково это — вести разработку на острове в Таиланде, и в подробностях рассказать, с чем придется столкнуться тем, кто отважится на авантюру и отправится в тропики, чтобы целиком посвятить себя реализации задуманной идеи. И объявляем акцию: мы передадим наше солнечное место хорошим ребятам с новым интересным стартапом!

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

Поискал на Хабре и не нашел ничего про использование такого модуля Drupal как cacherouter. Исправляю данное недоразумение, т.к. этот модуль позволяет значительно ускорить работу Drupal даже на таком требовательном хостинге как Majordomo (любит отключать весь аккаунт при превышении нагрузки).

Сам модуль ничего нового и кардинального не преподносит — только позволяет выносить таблицы кеша из БД в другие хранилища, как, например, файловая система, memcache, APC и пр.

Меня, конечно же, давно волнует вопрос, какого х… разработчики Drupal засунули кэш в БД, но рассказ не об этом.

Вступление
Drupal – довольная распространённая CMS и это отложило на неё свой отпечаток – базовая поставка Drupal является не готовым решением для определённого вида сайта, а фундаментом для его создания. Существуют “сборки” на базе Drupal специализированные под определённые виды сайтов, например: новостные сайты. Но подобные сборки в данный момент мало распространены и плохо поддерживаются. В связи с этим при создании Интернет сайта на основе стандартной поставки Drupal используется большое количество готовых дополнительные модулей и тем оформления для Drupal, либо разрабатываются новые модули и темы специально для создаваемого Интернет сайта. Последним этапом работ по созданию сайта является его оптимизация, которую условно можно разбить на 4 шага:

• встроенная оптимизация Drupal;
• оптимизация Drupal с помощью модулей;
• оптимизация конфигурации и обслуживания Drupal;
• оптимизация сервера.

Давно хотел вам рассказать о своем сервисе для вебмастеров — панели проверки показателей сайтов и доменов. Эта штука была создана несколько месяцев и сейчас обратывает показатели 6000-12000 сайтов ежедневно.



Откровенно говоря, сама идея проекта не является уж очень уникальной, однако я попытался взять не идеей, а сравнительно большим количеством функций (в том числе уникальных) и качеством реализации. Бета-версия создавалась примерно 3 месяца, но дорабатываться все это дело будет еще ближайшие полгода (как минимум). На сабж «работают» несколько десятков американских IP, при необходимости их количество я увеличиваю. Что интересно — количество страниц в Google — с американского IP отображается одно, а с русского другое. Поэтому планирую подключить и российские IP.

Целью же оного обзора будет выяснение следующих вопросов — «насколько удобно?», «чего не хватает?» и «где-то криво?».

Часть 1, Часть 2

Шаблоны

Шаблоны мы будем складывать в sites/all/themes/mytheme/templates. Создадим шаблоны page.tpl.php — для страниц, node.tpl.php — для контента, block.tpl.php — для блоков, comment-wrapper.tpl.php — для блока с комментариями, comment.tpl.php — для одного комментария, header.tpl.php — для шапки, footer.tpl.php — для подвала, region.tpl.php — для регионов. Также, по аналогии с препроцессами, мы можем создавать файлы типа node-story.tpl.php для отображения материала типа story или block-user.tpl.php для блока user. Это позволяет темизировать отдельно разные типы содержимого сайта.

Все, все будут писать тесты

Уже 3 года прошло, с тех пор как я увидел свою первую красную полоску. Что меня дернуло начать писать тесты, уже не важно. Я начал собирать информацию, перечитал весь wiki.agiledev.ru и торжественно запустил свой первый тест на SimpleTest. Конечно, эти тесты были ужасны, да и архитектура тоже (в моем сегодняшнем понимании). Тогда я, наверное, словил большинство ошибок, но зато замечательно провел время :)

Потом перешел на PHPUnit — просто было интересно, чем он отличается от SimpleTest и что в нем такого «навороченного».

А lime — гадость. Чего ребята из Symfony в него так вцепились? Понимаю ветка 1.*, наследие и все такое. Но 2.0 можно было бы и на PHPUnit начинать.

Да, мне это было интересно. Я активно писал тесты, даже честно пытался делать это перед тем, как писать код. Что-то не получалось, читал разные статьи на тему, как надо и не надо писать тесты, перечитывал wiki.agiledev.ru. Но внутри явно чего-то не хватало.

Под датасетом будем понимать массив записей JavaScript:

var dataset = [
  { foo: 'xxx', bar: xxx' },
  { foo: 'yyy', bar: 'yyy' },
  ...
  { foo: 'zzz', bar: 'zzz' }
];

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

Появилось желание воспользоваться CDN, но оставался вопрос, «а на сколько оно мне будет по карману?» В принципе можно посмотреть расценки на самом сайте или воспользоваться даже калькулятором, но всё же остаётся не понятным сколько оно может в итоге выйти $1 или $30.

Минимальный прайс

В обязательном порядке придётся заказать Amazon S3, т.к. облака могут работать только в связки с ними, он стоит минимум 4 цента (по центу за место + трафик + PUT, COPY, POST, LIST + GET и остальные запросы).

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

Итого минимум: 12 центов ( ~ 3.6 рубля)

Привет всем. Основываясь на предыдущем опыте, считаю нужным сразу расставить все точи над ё. Описанная ниже методика — не мое изобретение. Однако из собственного опыта могу уверить вас, что она работает. Ровно так, как обещано.
Идея, описанная в посте, появилась давно (под катом есть история), в том виде, в каком расскажу ее я, по большей части она представлена в чудесных книгах Тони Бузана Use You Head и The Speed Reading Book (в последней много воды).

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

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

Прежде чем приступить к самому главному, прошу вас пройти тест из шести вопросов на Да/Нет.

1. Чтение со скоростью свыше 1000 слов в минуту невозможно?
2. Медленная скорость чтения способствует лучшему пониманию текста?
3. Пропускать слова во время чтения — плохая привычка, ухудшающая понимание текста?
4. По умолчанию мы все читаем с «естественной» для нас скоростью, а следовательно, наилучшей?
5. Если вы не поняли слово или предложение, лучше перечитать его и понять?
6. Ваши глаза находятся в непрерывном движении во время чтения?
За результатами и, наконец-то, интересными штуками добро пожаловать под кат.

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

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

Таковы бывают неприятные проявления хабраэффекта — естественного DDoS, аналогом которого на Заокраинном Западе является слэшдот-эффект.

Ну а как противостоять естественному DDoS?

Первыми приходят на ум наиболее бесхитростные способы.

В данной статье рассматривается такой инструмент мониторинга, как Munin. Странно, но поиск уверяет меня, что статьи о нем на Хабре еще не было. Этот инструмент существует под *NIX (Linux, xBSD, Solaris) и Windows и позволяет централизовано отслеживать и наглядно отображать состояние подшефных систем. Изначально используется для отрисовки графиков, но также его можно использовать как чистое средство для наблюдения. Большой плюс Munin — гибкость (все графики рисуются плагинами, активными на целевых системах, и никто не запрещает использовать только те плагины, которые нужны) и возможность с одного сервера собирать информацию о множестве других. Соответственно, нагрузка на наблюдаемом сервере минимальна. Интересно? Добро пожаловать под кат

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

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

На протяжении уже 5-6 лет я использую только Firefox и никогда не думал, что захочу выбрать что-то другое. Firefox — отличный браузер, а делают его таковым все те тысячи расширений, которые каждый может скачать бесплатно. Можно найти расширение для чего угодно. Есть лишь один существенный недостаток — Firefox значительно медленнее, чем Chrome и сжирает больше ресурсов компьютера, чем остальные браузеры.

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

В этой статье я попытаюсь ответить на вопрос — могут ли дизайнеры, веб-разработчики, SMO-шники, SEO-оптимизаторы безболезненно перейти на Chrome. Есть ли расширения, которые могут послужить равноценной заменой на Хроме таким вещам как: Firebug, Webdeveloper, Color Picker, SEO для Firefox, Alexa Ranks, средства для отладки?

Как то стало интересно что значат разные буковки/цифарки через точку в названиях видеофайлов.

Пост — результаты гугления, обобщения, структуризации и некоторой правки орфографии.
Возможно, кому то пригодится. Я, например, перестал связываться с TC.