Заведующий концлагерем вызывает к себе 5 осужденных и говорит:

«У вас будет время до вечера чтобы создать план действий, но уже завтра вы будете находиться в разных камерах и никогда не будете встречаться. У нас в лагере есть Ленинская комната, в которой на столе лежат 2 книги: „Капитал“ Маркса и „Анти-Дюринг“ Энгельса.

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

Рано или поздно каждый из вас побывает в Ленинской комнате. Так вот, любой из вас в любое время может сказать „Мы все здесь уже были!“. Если окажется, что он прав, вы все будете освобождены. Если нет — расстреляны.»

Что же делать осужденным, ведь время до вечера еще есть?

UPD: Облегчаем задачу. Заключенных не 5, а 19.

UPD: Ответ достаточно быстро и четко сформулировал товарищ tunelix, на основании почти правильного варианта by FloppyFormator:
итак: у нас есть 1 счетчик и 4 исполнителя.
задача исполнителя: если маркс лежит обложкой верх — переворачиваем энгельса, если обложкой вниз переворачиваем маркса мордой вверх. каждый испольнитель считает количество переворотов маркса — если он перевернул его 2 раза — больше он его на мордой вверх не переворачивает.
счетчик: каждый раз когда он видит маркса перевернутого мордой вверх он увеличивает счетчик +1 и переворачивает маркса вниз лицом. если маркс лежите вниз лицом он циклически переворачивает энгельса.
когда счетчик дойдет до 8 — он может сказать что все побывали в комнате.
считать до 8 (а не до 4х) нужно чтоб обойти ситуацию когда 1м в комнату попадает счетчик, а там маркс лежит мордой вверх.


Несколько соображений по поводу задачи и ее обсуждения:
1. В оригинале (когда я о ней узнал) задача была про 2 выключателя и 23 заключенных. Пришлось переделать в патриотическом стиле, чтобы общественность не так быстро выгуглила ответ.
2. Задача была намеренно усложнена. Так, например, 5 заключенных вкупе с 2 книгами наталкивают на мысли о двоичной системе счисления, хотя с 23 заключенными в этом (неправильном) направлении даже и не думаешь. Кроме того, если свести задачу к одной книге (убрав обязательное условие о перевороте хоть одной книги), то тоже задача решается намного проще. Но поиск правильного направления — это тоже задача, поэтому не стоит предъявлять претензии о некорректной формулировке.
3. Условие о том, что каждый заключенный побывает в комнате несколько (да что там, много!) раз не было явно указано, т.к. если бы это было не так, у задачи очевидно не было бы решения.
4. Поиск 'альтернативных' вариантов (поворачивать книги вокруг оси, делать пометки, закладки, ложить Маркса под ручку с Энгельсом и т.д.) был совсем не обоснованным. Условий задачи вполне достаточно для того, чтобы ее решить.
5. Не всем было понятно, что собственно от них требовалось. Для меня правильное решение удовлетворяет следующим условиям: а) заключенные не будут расстреляны ни при каких обстоятельствах; б) заключенные имеют реальный шанс выйти. Даже при этих довольно общих критериях решение было найдено только одно.

Задача, подобная этой на использование совместных ресурсов:
1-го сентября 100 бессмертных эльфийских воркутинских зэков постоили на торжественную линейку и предложили им ускорить процесс своего освобождения. Итак, в тюрьме есть камера с висящей лампочкой. Лампочку можно включить или выключить. Каждый день, начиная с 1-го сентября тюремщик будет запускать одного заключённого в эту камеру. В этот момент зэк сможет увидеть, горит ли лампочка.
У каждого заключенного тюремщик будет спрашивать: «А все ли твои товарищи тут были хотя бы раз?» Если зэк отвечает «нет», игра продолжается.
Если зэк отвечает «да» и это правда — всех выпускают на волю в тундру. Если же это неправда — высшая мера наказания для всех.
Тюремщики могут выбирать заключенных вразброс и с повторениями. Заключенные сидят в одиночных камерах и могут договориться только один раз — 1-го сентября на обеде после торжественной линейки. После этого они сидят в «одиночках» без окон, совсем не видят друг друга и лампочки.
Найти оптимальную стратегию поведения каждого заключенного с тем, чтобы их выпустили пораньше.

Хочу написать о небольшом трюке с SSI, который недавно мне пригодился.

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

Для этой цели, мы можем воспользоваться nginx-овым SSI. Никаких изменений в конфиг nginx вносить не придётся, а сама страничка может выглядеть примерно так:

<!--# config timefmt="%d%m%Y" -->
<!-- мы только что установили, что переменная $date_local дожна иметь вид ддммгггг-->
<!--# if expr="$date_local = 01012010" -->
<!--# include virtual="/path/to/new_year_congratulations/" stub="Oops!" -->
<!--# else -->
<!--# include virtual="/path/to/usual/version/of/block/" stub="Oops2!" -->
<!--# endif-->
<!-- если переменные $date_local или $date_gmt используются где-то ещё, неплохо бы вернуть обратно формат по умолчанию, если он нужен -->


И теперь, ровно в полночь, 1 января 2010 года, ваши пользователи увидят поздравление с новым годом на месте какого-то обычного блока. Причём, вы в это время можете спокойно спать (ну или, пьянствовать с друзьями). :) Более того, ровно в полночь, второго января, поздравление исчезнет, без малейшего вашего участия.

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

Естественно, у него есть и недостатки:
— ваш if будет исполняться при каждой отдаче страницы — это может быть критично на серверах с очень медленным процессором, или на VPS;
— некоторые промежутки времени таким образом определить всё-же не получится, или это потребует не одного оператора «if»;
— что-то ещё… :)

Но, в целом — неплохое, удобное, а главное, быстрое решение.

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

Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях). Это лишь простейший инструмент, который наконец-то дошли руки опубликовать.

Зачем это нужно?

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

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

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

Недавно возникла задача получения чистого текста из различных форматов документооборота — будь-то документы Microsoft Word или PDF. Задача была выполнена даже с чуть более широким списком возможных входных данных. Итак, этой статьёй я открываю список публикаций о чтении текста из следующих типов файлов: DOC, DOCX, RTF, ODT и PDF — с помощью PHP без использования сторонних утилит.

В процессе работы с таблицами, для удобства восприятия, а также быстрого анализа, рано или поздно возникает вопрос вывода отсортированного содержимого этих таблиц. Эту задачу в web-программировании можно решить двумя способами:

• Сортировка на стороне сервера посредством SQL или backend'а;
• Сортировка на стороне клиента.

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

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

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

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

Раньше, эта проблема решалась увеличением количества процессов-воркеров. Теперь есть альтернативное решение. :) Однако, перед тем, как включать файловый AIO, стоит учесть ряд нюансов.

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

Во-вторых, файловый AIO работает только на FreeBSD 4.3 и выше, либо в Linux, с версии ядра 2.6.22 и выше.

В-третьих, AIO во FreeBSD имеет смысл включать только в версиях FreeBSD-6.4 STABLE, FreeBSD 7, или новее. В более ранних версиях, при включении AIO, сетевая подсистема начинает использовать Giant Lock, что означает невозможность одновременного выполнения какого-то другого системного вызова. Другими словами, почти никаких выгод от асинхронности мы не получим.

Ну и наконец, при использовании AIO под Linux надо также включать directio. Также, если я всё понял правильно, в линукс пока невозможно использовать AIO для подгрузки данных для sendfile, поскольку включение directio отключит использование sendfile автоматически.

Если вы по-прежнему считаете, что оно вам нужно, AIO включается очень просто. Для Linux, фрагмент конфига будет выглядеть примерно так:

aio on; # включаем AIO
directio 512; # включаем O_DIRECT для файлов, размером 512 байт или больше
output_buffers 128 512k; # зная размер и примерное количество одновременно отдаваемых файлов, можно подобрать более подходящие значения


Ссылки:
Описание AIO в документации на Nginx
Changelog

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


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

Некоторое время назад по работе пришлось изучить и настроить работу сайта заказчика с YouTube, после этого для своего, как это теперь принято говорить, стартапа, я применил практически те же знания и умения. В этом небольшом посте я расскажу, как используя youtube api загружать видео файлы.

Прошу простить за большую паузу между выпусками рассылки: мне нужно было время на подготовку к проведению большого тренинга и разгребание новых материалов. Что ж, много времени прошло, многое изменилось — даже слово “Интернет” теперь нужно писать с большой буквы! Больше такого не повторится, так что продолжим наше путешествие. Напомню адреса прошлых выпусков:

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.

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

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

Далее будут описаны основные техники, реализованные в подавляющем большинстве систем контроля версий. Как они реализуются в приложениях, которые использует читатель, оставим на откуп многочисленным руководствам пользователя, how-to, FAQ и прочим документам, коих можно найти без труда. Главное – понять, по каким принципам и зачем оно работает именно так.

Абоненты «МегаФон» Московского региона получат неограниченный доступ в мобильный Интернет с помощью браузера Opera Mini и специального пакета услуг

7 сентября 2009 г., Осло, Норвегия — Компания Opera Software сегодня объявила о том, что оператор мобильной связи «МегаФон» выбрал браузер Opera Mini как основу для предоставления неограниченного доступа в Интернет по технологиям GPRS/EDGE и IMT-2000/UMTS своим абонентам в Московском регионе.

C сегодняшнего дня, загрузив браузер Opera Mini на свои мобильные телефоны, абоненты «МегаФон» столичного региона могут активировать услугу «Безлимитный Интернет с Opera Mini» и просматривать любые сайты за 7 рублей в сутки без учёта объемов полученной и переданной информации круглосуточно.

Примечание: при просмотре любых Интернет-ресурсов через браузер Opera Mini версии 2.Х 3.Х и 4.Х Загрузка файлов и peer-to-peer трафик оплачиваются в соответствии с тарифным планом

Подробнее об услуге: moscow.megafon.ru/services/internet/megaopera.html
Загрузить браузер Opera Mini с мобильного телефона: mini.opera.com

Я часто читаю Хабр и другие ресурсы о том, как управлять временем, эффективно планировать, ставить задачи и т.д. и т.п. Но вот в реальной жизни, как-то трудно все идет. Казалось бы утром выходя в свой офис я знаю, что мне предстоит сотворить, и даже знаю каким образом и с какой очередностью это нужно бы сделать, и все вроде, как хорошо. Но после нескольких часов «усердной работы» прихожу к выводу, что и 20% от намеченного не сделано. Как же так?

Думая над тем, почему так происходит я наблюдал за своим поведением несколько недель (ну наблюдение весьма условное, т.к. мне кажется себя пронаблюдать полностью невозможно) и выяснил, что мешает мне именно многозадачность и распараллеливание выполнения этих задач. Что я имею ввиду? Казалось бы совсем логично по возможности выполнять одновременно две и более задачи, так кажется, что экономится время. Например, я знаю, что мне необходимо отыскать рисунки на заданную тематику, отправить смс трем людям, написать пост на хабр, сделать несколько звонков, составить доп.соглашение и акты к договору №n. На первый, беглый взгляд можно объединить некоторые задачи и сделать одновременно. Например, если звонки не официальные можно их сделать во время приготовления чая для брейка, зачем тратить отдельно время для звонков и смс, времени и так нет – в результате когда приходит время брейка в уме другая доминанта и никакие звонки не сделаны. Отыскать рисунки тоже просто, заодно и почту гляну, пока рисунки открываются. О-о-о, новый пост на Хабре (форуме и т.д.) о том, как правильно составилять доп. соглашения – как раз то, что мне нужно. А в дополнение к статье идет несколько примеров и ссылки на другие ресурсы – но мне же нужно написать доп.соглашения, нужно все хорошенько разузнать – и так далее. Думаю, что для многих знакомая ситуация. А поиск рисунков где-то болтается в открытой вкладке и загрузился уже миллион раз. В конце дня обнаруживается, что хотя задачи и супер легкие и времени для выполнения нужно не так уж и много, часть из них все-таки остается не сделаной.

Добрый день!

На хабре уже имели место несколько статей о том, как нужно учить английский, напомню:

• Практика разговорного американского
• Разговорный английский за месяц
• Как учить английские слова
• Английский для неудачников

Хочу дополнить этот список своими наблюдениями по поводу эффективных и не очень методов изучении английского языка.

Довольно давно использую связку Zend Framework и Doctrine и очень не хватало сортировки для коллекций получаемых по ссылке. Оказалось, что это легко реализовать.

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

Некоторое время назад создатель Yii и его главный разработчик Qiang Xue, обремененный большим грузом ответственности и забот связанных с развитием фреймворка, сделал объявление о том, что начинается набор новых людей в команду разработчиков, которая на тот момент состояла лишь из двух человек.

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

PHP один из самых широко используемых языков для создания вебсайтов. PHP фреймворки, такие как Zend, CakePHP, CodeIgniter и т.д и open source классы и библиотеки упростили разработку.
Независимо от того, являетесь ли вы опытным разработчиком или новичком, инструменты, которые вы используете, имеют прямое влияние на вашу продуктивность. Здесь собран список действительно полезных утилит и расширений для PHP разработчиков, которые помогут ускорить разработку, и улучшит итоговое качество кода.

Эту статью написал мой добрый приятель и бывший коллега fred, работающий в команде программистов над большим и сложным проектом, который должен работать 24х7. Если кто-то решит пригласить его на хабр — с удовольствием вышлю его email по хабрапочте. Пожелания и комментарии приветствуются, а я обязуюсь передавать ответы автора в меру своих возможностей.

Меня давно посещала мысль запустить CI-сервер для рабочего проекта. База модульных тестов уже достаточно внушительных размеров, а количество людей в проекте немного увеличилось. Можно было бы наблюдать за тем, как изменяется покрытие тестами кода и соблюдаются стандарты кодирования. И наказывать провинившихся. Шучу.
Некоторое время назад была прочитана книжка Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска и статья Quality Assurance Tools for PHP, которые и послужили отправной точкой.