Два простых правила для предотвращения взаимных блокировок на мьютексах

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

Два простых правила для предотвращения взаимных блокировок на мьютексах

И у Вас ошибка в записи 2-й последовательности. Должно быть:
0-L-U-0-L-U-0-L-U-0-L-U-0...

Два простых правила для предотвращения взаимных блокировок на мьютексах

Хм я как раз думаю что можно записывать и 2-ю последовательность а приводить к нормальной форме как один из этапов обработки графа, разве нет?
Иначе механизм сбора долен быть очень сложным сам по себе

Два простых правила для предотвращения взаимных блокировок на мьютексах

Для более сложных программ мы сделали библиотеку, которая подменяет вызовы libpthread по созданию и удалению потоков, а также по обращению к средствам синхронизации

Вот это уже интересно надо будет попробовать :)

Два простых правила для предотвращения взаимных блокировок на мьютексах

принципиально иное средство синхронизации — сигнальная переменная

А можно здесь подробнее? в чем принципиальное отличие?
Механизм вроде бы тотже… или вы имеете ввиду что не используются механизмы синхронизации ядра?

Два простых правила для предотвращения взаимных блокировок на мьютексах

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

Весёлые (сосисочные) рефакторинги

Участвую! :)

Кастуем магией PHP

Собственно именно так работает обычный view в ZF.
HTML со вставками PHP включается внутри класса View, просто обычно вы не видите метод обертку

Для чего нужны шаблоны проектирования

«Refactoring to Patterns» от Джошуа Кериевски.

Как раз эта книга помогла мне лучше понять некоторые сложные паттерны которые остались недопоняты на уровне Shu :).

Решение задач на определение фальшивой монеты взвешиванием

Для того чтобы не возникало такого вопроса полезно вспомнить историю:
Монеты чеканились из драг. металлов (в основном золото)
Фальшивые монеты содержали меньше золота чем настоящие и в них добавлялись другие металлы для того чтобы обьем был тот же. Соответственно фальшивые монеты всегда были легче т.к. в качестве примеси использовался металл легче золота.

HOWTO: Одна из возможных реализация Модели (MVC) в Zend Framework

Промахнулся ответом :(
Не совсем согласен с Вашей реализацией сервисов и на мой взгляд она содержит следующие недостатки:
1) public static function login (array $params) — передавать все параметры в виде массива это плохая привычка, если использовать такой подход со временем окажется что в ваш сервис надо передать массив из 20-100 параметров
в Вашем случае достаточно обьявить функцию:
public static function login ($email, $password)
Согласитесь что это намного понятнее чем массив и позволяет использовать сервис без необходимости читать его код или документацию (которую кстати надо сначала написать, а потом поддерживать)
Кроме того передача параметров явно очень полезна т.к. если вдруг вам понадобиться сервис в котором более 3-х параметров вы уже задумаетесь о разделении ответственности.
2) Статические сервисы хороши только для логина в вакууме — во всех остальных случаях лучше все же создавать обьект и пользоваться нестатическими методами. Это даст гораздо большую гибкость если Вам понадобятся более сложные сервисы. Например можно будет легко декорировать сервисы дополнительным функционалом (кеширование, изменение формата данных для разных версий АПИ например). Для того чтобы облегчить создание сервис обьектов советую посмотреть на паттерн DependancyInjection Container и как он реализован в Zend2 и Symfony2 хотя я и не считаю их реализацию очень удачной (в основном изза ограничений самого пхп)

Десять вещей, которые я терпеть не могу в ООП

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

Сходство и различие между Mercurial и Git

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

Вот здесь думаю вы не правы:
у каждой системы контроля версий свои особенности и свой «дзен». Пытаясь унифицировать их все к одному интерфейсу вы тем самым ограничиваете их функционал, кроме того в отдельных случаях это может быть не возможно, либо ввести пользователя в заблуждение
(к примеру команда pull в Git и Hg делает разные вещи).
Поэтому я считаю что стоит придерживаться юникс подхода к таким плагинам — Write programs that do one thing and do it well.
Я лучше поставлю 3 отдельных плагина для разных систем контроля версий для того чтобы максимально использовать возможности каждой.

Сходство и различие между Mercurial и Git

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

Сходство и различие между Mercurial и Git

Очень удобно — тоже через diffsplit справа открывается рабочая копия, слева оригинал.
Переносите изменения налево, сохраняете и получаете это в staging.

Сходство и различие между Mercurial и Git

Попробуйте плагин для вим — github.com/tpope/vim-fugitive
Он как раз решает все проблемы перечисленные вами :)

EVE Online, битва при Asakai, что же произошло на самом деле

Попробуйте поиграть в Silent Hunter 5 от Ubisoft. Это симулятор подводной лодки и мне очень понравился геймплей в нем:
Вид от первого лица, перемещение по подводной лодке (дойти до перископа, отдать команду боцману и т.д.).
Ну и кроме того на максимальной сложности торпедная атака сильно напоминает решение задачи по матану :)

Об идеальном коде и суровой реальности

Меня тоже очень раздражает такой подход. Для меня писать максимально качественный код (в рамках имеющегося бюджета и ресурсов) вопрос профессиональной гордости.
А говорить что можно писать плохо т.к. поддерживать все равно не вам это все равно что наложить кучу соседу под дверь — убирать то все равно не вам. Просто однажды вы найдете такую же кучу и под вашей дверью.

Ну и как уже сказали сверху:

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

Качественно обычно и бывает быстро просто это становится заметно ближе к концу проекта.

Об идеальном коде и суровой реальности

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

Раз стоит проблема покупать новые сервера или оптимизировать то явно потребляет больше 3-х процентов ресурсов.

Кроме того есть разные уровни оптимизации:
Можно оптимизировать путем внедрения низкоуровневых оптимизаций и т.д. — такой подход действительно может ухудшить читаемость.
Но на самом деле самые важные оптимизации это как правило структурные (закешировать результат тяжелых вычислений, минимизировать обращения к БД, удаленным обьектам, убрать дублирование логики) и на мой взгляд такие оптимизации только улучшат читаемость.
Если код на 1 полезное действие выполняет 100500 бесполезных операций но при этом хорошо масштабируется добавлением железа то этого железа достаточно никогда не будет

Типажи в PHP: хорошо это или плохо?

Я специально привел 2 варианта: с изменением и без. Во 2-м варианте исходный код класса не изменяется:

class Decorated:
    def speak(self):
        print "Hello"

test = Decorated()
test.speak = decorate(test.speak)
test.speak()

Прошу прощения если в первый раз привел недостаточно подробный пример