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

У нас в Siyelo две распределённых команды, одна в Кейптауне, вторая в Скопье. Нам приходится придумывать, как заниматься удалённым парным программированием между офисами. Существует много возможностей (отличный обобщающий пост здесь).
Раньше мы постоянно пользовались Skype'ом для разделения экрана, но у нас при этом возникали следующие проблемы:

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

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

Кратко сказка сказывается, да долго дело делается, MelonCard сегодня был представлен на TechCrunch вместе с другими компаниями, как вдруг всё внезапно сломалось. Каждая. маленькая. мелочь. Мы только что обновили сайт, чтобы он выглядел и ощущался более отзывчивым, используя long-polling NodeJS, с крутейшим динамическим фронтендом на jQuery Templates и KnockoutJS. Приложили все усилия и провели ручное и юнит-тестирование с помощью Vows. Все системы готовы, полный вперёд и всё такое? Не тут-то было.

В противовес к этой статье. Мне удалось немного покопаться с rbenv, наткнуться на несколько граблей, и решить копнуть поглубже. И очень ко времени попалась на глаза вот эта статья, перевод которой я на ваше обозрение и предоставляю.

На сегодняшний день уже не осталось тех, кто не слышал о RVM или rbenv. Как содействовавший разработке RVM, я подумал, что стоит выяснить, что именно делает rbenv. Чтение исходного кода дало мне представление об rbenv, и, к сожалению, я не нашёл никакого нового трюка для работы в оболочке командной строки. Тем не менее, я понимаю, как обе этих утилиты работают, и могу найти разницу в их работе. Обе утилиты предоставляют возможность переключать активную версию Ruby.

Основная разница состоит в способе переключения Ruby.

RVM велик и могуч, здесь тяжело поспорить. Но тому, кто занимается локальной разработкой, возможно хочется иметь что-то менее монструозное. Такой вариант есть, в базовом варианте это набор из двух утилит, а имено rbenv и ruby-build.

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

Итак, задача:
Хочется, чтобы каптчу вводить не приходилось. Хоть если играешь сам, хоть если играет за тебя бот, если ты спишь.
Дополнительное условие: 40 часов времени (ибо паника на корабле).
Желательное условие: установочный файл под Windows.
Ещё одно желательное условие: результат должен занимать не более мегабайта.