Я решил не затягивать выход обновления справочника и выпустил 2 версию «Работа с Postgresql: настройка, масштабирование».

Как и раньше, в книге иследуются вопросы по настройке производительности Postgresql, репликации и кластеризации.
Добавил пару слов о расширениях PostgreSQL, методики решения проблем, сниплеты(пока в процессе). Произвел коррекцию ошибок в манах настроек. Пока что только сконвертирован pdf. Все правки и замечания прошу на этой странице github.com/le0pard/postgresql_book/issues или в комментариях.

Страница книги: postgresql.leopard.in.ua
Исходники: github.com/le0pard/postgresql_book

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

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

Иногда происходит так, что над одним и тем же изобретением или, скорее, технологией, начинают работать в нескольких местах различные люди. Это то, что происходит с идеей децентрализованного веба. Международный Веб Консорциум (W3C) вчера объявил о создании рабочей группы по веб-коммуникациям в реальном времени (Web Real-Time Communications) для того, чтобы сформулировать API клиентской стороны, позволяющего выполнять подобные коммуникации, без имплементации серверной стороны.

В W3C эту группу возглавляют инженеры из Google и Ericsson, но оказалось, что Opera, по-сути, предлагала ту же самую идею два года назад, только не приобщенную к браузерам в общем, как к инструменту просмотра веб-страниц. Opera, как обычно, оказалась на несколько шагов впереди своего времени.

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

По-умолчанию эта функция в Google Analytics отключена. Для ее включения достаточно добавить одну строчку в код GA. Это вызов функции _trackPageLoadTime();, который нужно разместить после функции _trackPageview();

Вариант для асинхронного кода GA:
_gaq.push(['_trackPageview']);
_gaq.push(['_trackPageLoadTime']);

Вариант для стандартного кода GA:
pageTracker._trackPageview();
pageTracker._trackPageLoadTime();

После обновления кода отслеживания GA данные будут поступать в отчет «Содержание -> Скорость загрузки сайта». (! Данный отчет есть только в новом интерфейсе Google Analytics!) Отчет содержит список страниц сайта, отсортированный по среднему времени загрузки в секундах от большего к меньшему.

Очень полезный функционал, которому можно найти множество применений в веб-аналитике.

Более подробно об этой функции можно почитать в справке Google Analytics: http://www.google.com/support/analyticshelp/bin/answer.py?hlrm=en&answer=1205784&topic=112071

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

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

Все привыкли редактировать текст в текстовых редакторах, блокнотах, веб-формах и т.д. В процессе набора текста мы пользуемся привычными стрелками, кнопками «End» и «Home», более опытные зажимают «Ctrl» и стрелками шагают по словам (что, кстати, не всегда работает). И при переходе на консоль мы ориентируемся на те же самые правила, даже не зная, что bash предлагает очень удобные средства и комбинации клавиш, которые очень упрощают работу и минимизируют количество операций для выполнения задачи. К тому же, в bash есть удобные средства работы с историей, масса различных подстановок и других интересных функций. Самые часто используемые мной и любым опытным администратором я и опишу в этой статье.

Disclaimer
Этот пост появился здесь по нескольким причинам:
1) Меня попросил сам Boomburum
2) Есть предположение, что на хабре всё-таки есть люди, имеющие прямое отношение к IT, но при этом имеющие весьма отдалённое представление о пользе SSH и её извлечении из обычного домашнего роутера, и которым, надеюсь, будет весьма интересно и полезно об этом узнать.

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:
А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.
Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.
Специально для GrammarNazi:
Пишите пожалуйста об ошибках в личку — обещаю исправиться.

Бла-бла-бла, а топик-то о чём?
Итак, я обещал рассказать «как поднять ssh-туннель домой без необходимости оставлять включённым домашний ПК» и, как правильно догадался peter23 речь пойдёт про ssh-сервер на роутере.

Регулярные выражения (РВ) это, по существу, крошечный язык программирования, встроенный в Python и доступный при помощи модуля re. Используя его, вы указывается правила для множества возможных строк, которые вы хотите проверить; это множество может содержать английские фразы, или адреса электронной почты, или TeX команды, или все что угодно. С помощью РВ вы можете задавать вопросы, такие как «Соответствует ли эта строка шаблону?», или «Совпадает ли шаблон где-нибудь с этой строкой?». Вы можете также использовать регулярные выражения, чтобы изменить строку или разбить ее на части различными способами.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL, xpath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка xpath.
Очень удобно, не правда ли? Давайте посмотри какие возможности предлагает xpath для доступа к узлам веб-страниц.

Сегодня вышла новая версия OpenVPN Access Server. OpenVPN Access Server (OpenVPN-AS) это набор инструментов для установки и настройки, которые упрощают быстрое развертывание VPN-сервера удаленного доступа. Он основывается на популярном программном обеспечении с открытым исходным кодом OpenVPN, позволяя работать с настроенным VPN-сервером при помощи кроссплатформенного клиентского ПО. Предоставляемые сервером возможности — это тщательно подобранный набор из всех возможных конфигураций OpenVPN. Таким образом OpenVPN-AS упрощает настройку и последующее управление системой. Читайте далее, чтобы узнать, что нового появилось в версии 1.7.1.

Сегодняшние проблемы с аськой напомнили об одном простейшем способе запуска SOCKS-прокси. Многие этот способ знают, но подозреваю, что не все, поэтому решил поделиться.

Итак, что нужно:
a) SSH-клиент (любой, под Linux или под Windows, главное, чтобы он позволял задавать нужные нам параметры, под Windows вполне подойдет putty)
b) Доступ на любой сервер по ssh (в случае с аськой помогает любой буржуйский хостинг).

С самого начала «вебошрифтовой революции» мы полагались на неизящные хаки деклараций @font-face, чтобы шрифты из Паутины загружались во всех браузерах. Может ли существовать лучший путь? Вполне изящный и совместимый с будущими браузерами?

Вкратце об истории вопроса

В сентябре 2009 года Пол Айриш (Paul Irish) огласил пуленепробиваемый синтаксис для записи деклараций @font-face. Синтаксис был компактным и в то время действовал во всех браузерах. Недавно стали поступать, со временем усиливаясь, жалобы на отказ шрифтов загружаться в Android — поэтому мы стали вместо того рекомендовать синтаксис «Mo' Bulletproofer», сочинённый Ричардом Финком (Richard Fink). К сожалению, синтаксису «Mo' Bulletproofer» требуется двойная запись деклараций, так что поддержка его сложнее.

Синтаксис Fontspring @Font-Face

А вот таким этому коду следовало бы быть с самого начала. Чистым, ясным и простым:

@font-face {
	font-family: 'MyFontFamily';
	src: url('myfont-webfont.eot?') format('eot'), 
	     url('myfont-webfont.woff') format('woff'), 
	     url('myfont-webfont.ttf')  format('truetype'),
	     url('myfont-webfont.svg#svgFontName') format('svg');
	}

Что? Я не понял.

Хак Трюк, заставляющий этот код заработать — символ «?» вслед за именем файла EOT. Без шуток.

Как это срабатывает

Не так давно на хабре был топик, который привел на наш сайт 17 тысяч посетителей за два дня (11,828+5,100 on October 21, 2010). С 2009го года эта уже не первая волна, а последние иконки будут нарисованы в первой четверти 2012го года. Best reseller hosting providers.



Не хватает еще 1000 иконок для best email hosting. Готовы ли вы предложить метафоры, которых у нас еще не хватает? Тогда follow me…

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

Вы 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 на сайте.

С самого момента появления проверки орфографии в «обычных» программах (Firefox, Miranda, Opera) меня напрягала необходимость постоянного переключения словаря с русского на английский и обратно.

Для Firefox и Miranda есть (полу)решения, которые сами переключают словарь в зависимости от текущей раскладки клавиатуры. Уже хоть что-то, но всё равно не очень удобно — то одна, то другая половина слов остаются «красными» и затрудняют поиск настоящих ошибок.

Идеальным решением был бы словарь, объединяющий в себе орфографию обоих языков. И такой словарь был создан одним из пользователей Firefox (http://forum.ru-board.com/...). Но изучив его повнимательнее, я понял, что мне он не нравится (подробности см. ниже).

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

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

Предыстория

В ходе разворачивания стенда для экспериментов из нескольких идентичных серверов захотелось иметь возможность запускать нужные версии приложения без ручной работы по обновлению кода на куче хостов. Было решено запускать нужные программы с NFS-шары. Приложения были internal use only, одноразовые, причём написанные под конкретную задачу. Шара монтировалась в каталог /opt при загрузке и приложения оттуда запускались с помощью скрипта rc.local. Поскольку речь шла про экспериментальный стенд с очень частым изменением кода, играть в честного разработчика (пакеты, репозиторий, обновления, init.d скрипты) было лениво. Всё происходило под Debian Squeeze.

Шара была прописана в /etc/fstab, запуск нужных тестов — в rc.local. Казалось бы, всё сделано.

… И тут я наткнулся на Мистику. Приложения стартовали раз из пяти, причём версия «кривое приложение» была отметена почти сразу — ровно так же иногда не запускались любые другие исполняемые файлы. Причём, с /opt. Из других каталогов отрабатывали нормально. При этом руками rc.local запускаешь — 100% всё хорошо. При загрузке — успешный запуск раз из пяти, или даже реже.

В начале я не воспринимал эту проблему как серьёзную, и пытался её решить нахрапом. Поскольку проблема проявлялась только для /opt я дописал в rc.local команду ls -a1 /opt >/var/log/ls. Как и предполагалось, в /opt на момент выполнения rc.local было только два файла — точка и две точки. Другими словами, NFS-шара не подмонтировалась. Иногда. А иногда подмонтировалась.

В данной заметке, будет показано как поставить связку Nginx + php5-fpm (php5.3) на Debian Lenny и настроить безопасную конфигурацию.

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