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

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

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

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

Вы любите смотреть фильмы? Я — да: «Теория большого взрыва», «The IT Crowd», разное аниме… Все это очень затягивает.
Для просмотра всего этого добра я пользуюсь консольной версией самого всеядного медиаплеера mplayer. (Давайте воздержимся от холивара по поводу красноглазия и GUI vs консоль) Но вот незадача, для каждой новой серии приходится заново набирать длинную команду вроде такой:

$ mplayer -ass -subcp cp1251 имя_сериала_01_еще_какая_то_чушь.mkv

Ясное дело, что я не набираю всю эту простыню с нуля, а просто стираю бэкспейсом до номера серии, пишу новый номер и табом дополняю до конца имени файла. Но это ведь долго и неудобно, можно промахнуться и стереть лишнего.
А еще часто смотрится несколько сериалов параллельно, по мере выхода новых серий. И помнить, на какой серии я остановился в прошлый раз, и с какими параметрами и ключами запускал mplayer, становится затруднительно. И поэтому я решил написать себе на шелле простую запускалку плеера, которая будет запоминать параметры, номер последнего просмотренного эпизода и уметь подставлять номер следующего в команду запуска.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Продолжая тему рассуждений про карьеру, мы с хабраюзером eagleson записали новое видео: «Карьерное плато».



Коротко и по делу (всего 18 минут) обсудили следующие темы:

• Динамика ИТ-специалиста: рост, рост, рост, ЗП, семья, ипотека…
• Почему так, где движение?
• С любого плато можно улететь: нужно строить самолет!

Подарите себе 18 минут времени, чтобы задуматься над вопросам «Сколько лет до вашего плато?» и «Строите ли свой самолет?»

Я, как, вероятно, и многие другие пользователи Linux, привык сохранять видео с сайтов вроде YouTube, копируя временные файлы, создаваемые Adobe Flash. Примерно так:

$ cp /tmp/FlashIBmQCU video.flv

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

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

Сразу скажу — топик — для тех, кто не разобрался что такое MapReduce. Для тех, кто разобрался — полезного тут ничего не будет.

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

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

Как посчитать все слова в Википедии (неправильный подход)

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

В самом простом случае мы можем завести хеш (dict, map, hash, ассоциативный массив, array() в PHP) и считать в нем слова.

$dict['word1'] += 1

Но что делать когда память под хеш кончится, а мы посчитали только одну сотую всех слов?

Что мы имеем:
1. компьютер с осью и установленными mysql, apache, php (тут ничего писать не буду, благо мануалов хватает)
2. интернет с присваиваемым динамическим IP, роутер.

Что мы хотим:
1. Что бы люди вбивая в адресную строку браузера доменное имя второго уровня (купленное нами или полученное на каком либо сервисе), попадали на наш сайт (в независимости от того на каком IP он сейчас находиться).
2. Хотим это бесплатно.

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

В топике я расскажу о нюансах использования тега <audio> в разных браузерах при разработке игр, о проблемах, с которыми я столкнулся и о том, как их решить. Объяснение будет идти паралельно с написанием обертки для удобной работы.

Это заключительная часть перевода статьи. Декораторы, switch для функций, некоторая информация о классах.

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

Некая программа (допустим, foo) не умеет писать вывод в stdout, только в файл. Даже "-" в качестве имени файла всего лишь создаёт файл с названием "-" [большинство умных программ под unix знают, что одиночный минус вместо имени файла означает вывод в stdout]. Аналогично она отвергает и /dev/stdout.

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

Нужно их объединить в конвеер.

Некрасивый вариант — использование обычного файла. Записал, прочитал.

Есть куда более красивый вариант — это именованные пайпы. Так как у пайпа есть имя, мы можем передать его как файл первой программе, а потом передать содержимое другой.

Выглядит это так:

mkfifo mypipe
cat mypipe | bar &
foo mypipe&
rm mypipe

Люблю Transmission по его простоте и удобстве в использовании. Но то, что бы я добавил — это возможность автоматического выключения компьютера при завершении всех закачек. Делал эту фичу для себя под Убунту, но тем, кому это станет интересно, думаю, могут свободно переделать под другую ОС.

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

Это продолжение перевода статьи Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python»

Начало и окончание перевода.


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

Столкнулись со следующей ситуацией. На форуме (свежий IPB) злоумышленник выкладывает картинку, которая находится в закрытой зоне. Пользователь запрашивает страницу и получает ошибку 401 со всем присущим — окошко ввода логина и пароля. Развод, понятное дело, рассчитан на крайне неопытного пользователя и скорее всего не нов, но тем не менее.

Тем не менее, IPB от этого не защищен, а вместе с ним, смею предположить, еще очень много ресурсов, в том числе и наш любимый Хабр. В последнем любой может убедиться, воспользовавшись черновиком; по понятным причинам сам приводить пример не стану.

Было бы интересно (и думаю, не только мне) узнать ваши мысли и предложения по этому поводу.

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

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

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

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

Ни для кого не секрет, что в Unix системах вся информация предоставляется в виде файлов.
В Linux есть файл /proc/kcore, который является «алиасом» на физическую память системы.
Мануалы говорят, что полная длина этого файла — это размер физической памяти (RAM) плюс 4KB, но повертев этот файл на разных системах я пришел к выводу, что размер файла равен размеру RAM + SWAP.
Аналогично этому файлу можно использовать устройства /dev/mem или /dev/kmem, но взаимодействие с ними в данном топике я не буду рассматривать.

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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