Немного про Deadlock

При уровне изоляции Serializable чтение точно также выставит X (эксклюзивную) блокировку

А в каком случае чтение выставит SHARED блокировку (кроме ручного указания LOCK IN SHARE MODE), при REPEATABLE READ? И если да, то для того, чтобы записи не блокировались при чтении, мне нужен уровень изоляции READ COMMITTED?

Немного про Deadlock

А при ReadUncommitted

Уважаемый, вы точно не спутали название уровня изоляции? Может вы имели в виду REPEATABLE READ? При ReadUncommitted происходят грязные чтения (чтения незакоммиченных данных из других транзакций), нужно совсем не переживать за консистентность данных, если используется этот уровень изоляции.

Разработка ПО: факты против мифов

Peopleware, оригинально )

Разработка ПО: факты против мифов

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

Python for Programmers

В каком разделе отличия 2 от 3? Может стоит это в отдельную главу вынести?

обновили материал с Python 2.5 до Python 3.3

А чего раздел до сих пор называется «Python 2»?

Темное программирование

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

Технология Real Time MapReduce в Яндексе. Как ускорить что-то очень большое

Изобрели CouchDB?

Google Chromecast

Второе замечание — Chromecast работает только в 2.4 ГГц диапазоне, Wi-Fi сети в диапазоне 5 ГГц он не видит.

Боюсь жители многоквартирных домов не смогут получить удовольствие от просмотра Full HD при помощи этого девайса.

Руководство по магическим методам в Питоне

Электронный текст имеет право быть семантическим, не так ли? Если затронули тему магических методов, то стоит упомянуть и о магических свойствах.

Отдельные темы оформляются отдельными ссылками (на соответствующие статьи).

Не кажется ли вам, что неправильно давать материал в отрыве от контекста? То есть без возможности продолжить изыскания на смежные темы. Уважение к читателю — важная составляющая работы любого автора.

Руководство по магическим методам в Питоне

Про __metaclass__ нет упоминания, и это, как мне кажется, большое упущение. На хабре даже есть подробная статья, посвященная этой теме: Метаклассы в Python.

Hadoop. Подробное руководство. 3-е издание

Купил электронную версию, PDF… Среди стольких прекрасных форматов для электронных книг не смогли выбрать более подходящий?

Вышел финальный релиз PHP 5.5.0

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

Тестирование производительности Python 2.7 при обработке списков различными способами

Может не совсем в тему, но это:

tmp.__name__ = f.__name__
tmp.__doc__ = f.__doc__

вполне можно заменить декоратором functools.wraps:

def howlong(f):
    @functools.wraps(f)
    def tmp(*args, **kwargs):

11 причин быть управленцем

Я как раз являюсь сторонником одной из ТАУ =) где менеджерам отведена второстепенная роль.

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

11 причин быть управленцем

И почему народ вечно делит программистов на менеджеров и собственно программистов? Нет в IT сферических менеджеров в вакууме, не-ту! Есть только программисты, настоящие и… не программисты вовсе. Навыки управления у программиста должны быть заложены в генах (ну в крайнем случае в каком-нибудь учебном заведении). Программисты, которых обычно называют менеджерами — они те же программисты, только сущностями у них являются не объекты всевозможных классов, а работники разных специализаций.

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

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

ЗЫ: мое деление на своих и чужих немного отличается от общепринятого. Есть программисты и:

• Менеджеры без навыков программирования (а значит без опыта управления сложными сущностями) — это на самом деле аналитики.
• Программисты без навыков управления — это тестеры (проектировать сложные системы без навыков управления невозможно).

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

Кто я: профессионал или недоучка? Исповедь программиста-непрограммиста

В начале года руководство поставило цель: до конца года довести размер команды, работающей над текущим проектом, с 3 до ~70 человек, включая тестеров, разработчиков, бизнес-аналитиков. Как ведущему разработчику мне было поручено проводить технические интервью новых кандидатов на должность программистов. Опыта проведения собеседований у меня не было, поэтому учиться приходилось на лету, благо в свое время прошел их сам не мало. И вот уже на протяжении нескольких месяцев я почти ежедневно общаюсь с новыми людьми, считающими себя талантливыми разработчиками. Учитывая срочность и нетривиальность задач на нашем проекте, кандидаты с уровнем Junior, нам не подходят. За все время с начала набора было проинтервьюировано около 50 программистов (резюме которых показалось интересным), из них в компанию было приглашено ~15 человек (четверо уровня senior), 2-3 отказались от предложенных условий, трое (в том числе двое senior) уже успели уволиться не выдержав нагрузки, еще несколько собираются выйти на работу в ближайшее время.

Да простит меня автор этой статьи, но скорее всего его навык программирования мной был бы оценен как Junior. И не только из-за моих субъективных ощущений. В нашей компании существует так называемая «матрица компетенций», в которой помимо строго определения какими именно навыками должен обладать разработчик определенного уровня, но также определено наличие опыта работы в команде, а это целый рой дополнительных технологий (UT, CI, VCS, CR и пр.) и паттернов поведения.

Модуль Mock: макеты-пустышки в тестировании

>>> [i for i in xrange(3)]
[0, 1, 2]

значит функция real() с «пропатченной» функцией permutations напечатает 0 1 3

Модуль Mock: макеты-пустышки в тестировании

Судя по приведенным в документации Flexmock примерам, он сильно смахивает на мой любимый Mox, но уступает последнему в функционале и удобстве использования.

PHPUnit: Mock объекты

Прошу прощения. Поправил.

PHPUnit: Mock объекты

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