Дорогие друзья! Сегодня я хочу поделиться с Вами 138-мью строчками кода, которые позволяют ссылки <a> и кнопки <input type='submit'> расширить атрибутом hotkey.

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

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

<a href='...' hotkey="Ctrl + Shift + D">удалить</a>
или
<input type='submit' hotkey='Ctrl + Enter' value='Отправить'>

От переводчика: я не нашел на хабре подходящего «низкоуровневого сетевого» блога и сначала даже сомневался, стоит ли делать данный перевод. Но всё-таки, все мы с вами разработчики (надеюсь, хотя бы большинство), и описываемая в статье проблема с IPv6 сейчас актуальна, как никогда. До сих пор я вынужден отказываться от любимого русского зеркала Debian (ftp.chg.ru), по причине того, что слишком передовое зеркало отлично работает по IPv6, а мой провайдер выдаёт IPv6 адреса, но IPv6 трафик не роутит, да. В общем, я связался с Оле Якобсеном (Ole J. Jacobsen), главным редактором The Internet Protocol Journal, и с его благословения публикую эту статью. Поехали.

Как много веселых ребят
И все делают велосипед.
А один из них как-нибудь утром
Придумает порох.
Виктор Цой.



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

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

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

Глава 4. Куда сеем? В контент!

Многие спросили, как я набрал первоначальную массу пользователей, после набора которой сообщество, собственно, как-то задышало. Было дело так: когда я на одном из бесплатных LiveStreet'овском (CMS моего проекта) дизайне только-только открыл проект, сразу же встал вопрос о привлечении на него аудитории. Но на что придёт аудитория, не на голое же место?

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

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

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

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

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

Сейчас мы попробуем провести нашего «сферического айтишника в вакууме» через «информационный» закон, выделив в нем наиболее важное.

Программа и данные

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

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

Мне было сложно пройти мимо статьи, изобилующей фразами вроде «эффективные реализации polling'а на сегодняшний день имеются лишь в *nix-системах» (как будто poll() есть где-то, кроме некоторых *nix). Этот пост начинался как комментарий, разъясняющий уважаемому inikulin ошибки в его статье. В процессе написания оказалось, что проще изложить предмет с самого начала, что я собственно и делаю отдельным постом.
В моем очерке нет срыва покровов или каких-то неизвестных трюков, здесь просто описываются преимущества и недостатки разных подходов человеком, который проверял, как всё это работает на практике в разных операционных системах.
Для желающих просветиться — добро пожаловать под кат.

Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:

как называть узлы и интерфейсы узлов в сети?

Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

Должен предупредить, что это ещё одна статья, не содержащая никаких откровений. Для тех супер-гиков, которые назубок знают весь perldoc, она будет абсолютно бесполезной, так что, уважаемые супер-гики, можете проходить мимо и не информировать, что всё это есть в доках. Я и так это знаю. :-) Моя статья для всех остальных, для тех, кто весь perldoc целиком либо не осилил, либо осилил, но не понял, либо понял, но не запомнил.

Я думаю, многие знают о так называемом операторе диапазона, записывающемся как .. (две точки), с помощью которого можно быстро создавать массивы из набора последовательных элементов. Например, следующий код создаёт массив из 35 чисел: 3, 4, 5, …, 37:

my @arr = 3 .. 37;

Помимо чисел можно использовать строки: в этом случае для генерации элементов массива будет выполняться так называемый магический инкремент (например, можно задать диапазон букв: 'a' .. 'z').

Однако оператор диапазона может использоваться и в скалярном контексте, принимая в качестве операндов булевские выражения и возвращая булевский результат. И вот здесь начинается самое интересное, потому что это оператор с состоянием: результат операции будет зависеть не только от значений левого и правого операндов, но ещё и от истории вызовов данного выражения!

Email

• Swift Mailer
  Swift Mailer легко интегрируется в любое PHP-приложение. Это гибкий и элегантный ООП-подход к отправке писем с множеством функций: отправка эл.почты, используя SMTP, SendMail, Postfix, поддержка серверов и др.
  
• PHPMailer
  Лучший класс для работы с эл. почтой. Поддерживает сообщения в цифровой форме, S/MIME шифрование, текстовые и HTML-письма, изображения, поддерживает несколько Email’ов, SMTP-аутентификация.
  

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный 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. Минусы оптимизации

Совсем недавно в ходе разработки одного проекта передо мной встала задача поиска удобного средства для написания юнит-тестов на C++. К каким результатам привело моё исследование подробнее в этой статье.

Здравствуй, хабра-сообщество!

Небольшое лирическое отступление

В этот замечательный день всех тех, кому не безразличны такие слова как разработка, код, компиляция и отладка, тех кто в данный момент набирает свою юбилейную 100 миллионную строку кода и тех у кого успешно скомпилировался и запустился первый в жизни «Hello, World!» хочу поздравить с профессиональным праздником. Желаю вам поменьше багов, быстрых компиляторов, взаимопонимания с дебаггером и самое главное, чтобы рядом были люди способные по-достоинству оценить Ваш труд!

А теперь — начнем

Недавно я начал писать свое приложение под WMC.
Заниматься переводом и цитированием SDK скучно и не интересно.
Поэтому сегодня я опишу пошагово создание простого плагина.
Давайте попробуем написать простенькие аналоговые часы.

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

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

О чем пойдет речь

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

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

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

Фанатам фреймворка Kohana — сделал клон репозитория (155+ модулей для v.3)

Если знаете еще модули для KO3 (пришлите в приват)

Текущие модули: