Если вы используете SVN под Windows, то почти наверняка это — Tortoise SVN.

В стандартную установку Tortoise SVN входит не только SVN клиент, с помощью которого можно делать Checkout, Update и Commit, но и SVN сервер.

Соответственно, если у вас стоит Tortoise SVN, то вы можете поднять свой локальный SVN сервер.

Зачем это необходимо? SVN — это удобно, и это реально сохраняет время. Максимум, на что хватает среднего девелопера при интенсивной разработке без системы контроля версий — сделать текущий бекап проекта, скопировав все текущие файлы в папку вида project_name.20080709.backup. Единственное, что позволяет такая система сделать удобно и быстро — откат к выбранной “версии” проекта. Никакого show differences, restore to revision и прочих прелестей.

В общем, если вы профессионально занимаетесь написанием программ и не пользуетесь никакой системой контроля версий, вы лишаете себя многих прелестей.

Итак, первым делом надо создать репозиторий. Для него подойдёт любая пустая директория, например c:\Repository\. В контекстном меню этой директории выбираем команду TortoiseSVN » Create Repository here. Файловая система FSFS подойдёт.

Пусть мы хотим добавить в репозиторий директорию d:\projects\megashit\source\. В контекстной меню папки c:\Repository\ вызываем TortoiseSVN » Repo-browser. Внутри Repo-browser у нас должна быть видна директория file:///C:/Repository/, в её контекстном меню выбираем add folder и добавляем директорию d:\projects\megashit\source\, которую затем переименовываем в megashit с помощью пункта контекстного меню rename.

Теперь делаем бекап директории d:\projects\megashit\source\ и удаляем из неё все файлы (они уже есть в репозитории). В контекстном меню делаем Checkout из file:///C:/Repository/megashit/.

Если Checkout отработал нормально, то в папке d:\projects\megashit\source\ окажутся те же файлы, что были в ней до удаления + скрытая папка .svn, которую не надо трогать.

Теперь в контекстном меню папки d:\projects\megashit\source\ должны появиться команды SVN Update и SVN Commit, с помощью которых можно работать с репозиторием (svn-адрес которого, напомню, file:///C:/Repository/megashit/).

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

Программа Programeter на основе анализа исходников проекта в репозитории позволяет оценить/измерить такие характеристики работы каждого программиста:

• уровень знакомства программиста со всей базой исходников;
• количество нового, привнесённого этим программистом кода в репозиторий;
• уровень “выживаемости” кода программиста;
• размер общего вклада программиста в репозиторий;
• уровень активности в течение одного месяца;
• ориентированность на сотрудничество с другими программистами;
• среднюю сложность написанного кода;
• соотношение объёма написанных комментариев к объёму написанного кода.

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

Почему менеджмент, принимающий решения на основе таких показателей маразматичен?

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

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

Сложность кода накручивается тоже очень легко; искусственное завышение размера общего вклада также не вызывает особых проблем у опытного программиста.

А накручивать обязательно будут, если накрутка приносит какую-то выгоду (повышение или непонижение з/п, например). Вот выдержки из реальной истории о том, как в одной конторе начали оценивать работу программистов по количеству коммитов в неделю (в переводе Сергея Можайского):

“С помощью его скрипта он мог сделать из одного коммита 20-30. Он вполне мог ожидать повышения, поскольку его продуктивность [по меркам системы] возросла более чем на 600%.

Несмотря на то что это длится уже два месяца, удивительно, что начальник и не подозревает о том, что большинство коммитов - однострочные изменения, или что исправление опечатки в слове “guarantee” в форме заказа потребовало более дюжины коммитов.”

Хорошо, если накрутчики будут просто не ухудшать код своими накрутками, а если начнут ухудшать? Выгребать и фиксить будет вся команда, а не только накручивающие.

В общем, если в вашем проекте решения о уровне полезности программистов принимаются не на основе мнения ведущего программиста, а на основе таких вот “показателей надоев”, то дело плохо.

Для восстановления паролей из всяческих виндовых программ я пользуюсь утилиткой “iOplus Password Recovery XP”.

Но она не работает с Miranda Instant Messenger.

Оказывается, на сайте Миранды есть чудесный Miranda IM Password Decoder 0.0.0.6, выдирающий все пароли из мирандовской базы (все = всех задействованных мессенджеров).

Разархивировать, скопировать в папку с профайлом (базой), запустить (из консоли) и ждать.

У меня выковыряла какой-то пароль (вдобавок к искомому), который я вообще не могу идентифицировать.

У меня в CMSине есть недоделка: в извещении о новом комментарии не указывается subject комментируемого материала, указывается только его URL.

Если в категории включены нечисловые урлы (вида /blog/scrabble-online.html), то никакой проблемы с идентификацией материала по урлу не возникает.

А если в категории используются числовые урлы (например: /blog/2008/06/25/167/), то очень часто не удаётся вспомнить, что же ты писал 25 июня 2008 года в блог.

В извещении приходит текст комментария целиком. Так вот, зачастую люди пишут такие комментарии (не спам!), по которым понять (не переходя по ссылке), какую заметку прокомментировал автор комментария не удаётся.

Мой главный браузер — это Firefox. Не потому, что я фанат open source, а потому что я занимаюсь разной веб-разработкой. Так что Firefox — это что-то вроде IDE (правда код я в нём всё же не пишу). При этом назвать Firefox любимым я не могу: слишком часто он уходит в запой, начиная бесконечно отжирать память так, что приходится убивать его процесс (я так думаю, что ему не хватает моих 512 мб на ноуте, т.к. на декстопе при тех же плагинах он себе такого не позволяет). Поэтому не любимый, а главный.

Главный ещё и потому, что кроме Firefox я регулярно пользуюсь IE и Opera, как второстепенными: для тестирования и для того, чтобы иметь возможность залогиниваться на разные сайты одновременно под несколькими аккаунтами.

Пару дней назад Opera сообщила о том, что можно было бы и проапгрейдиться до версии 9.50. Я согласился, как оказалось — опрометчиво.

Сначала я обнаружил, что мои любимые хоткеи (Alt+F6, Ctrl+Alt+W, Ctrl+Alt+Shift+W) больше не работают. Включить их в настройках я не сумел.

А потом опера и вовсе накрылась чёрным экраном смерти:

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

Если кто знает, как можно починить это чудовище, пишите, пожалуйста, в комментарии. Ну и хоткеи хотелось бы обратно, без downgrade.

Update: починилось переустановкой оперы (инсталлер предложил repair) в ту же папку. Даже куки не слетели, а чернота ушла.

КопроСмирнов дал ссылку на переписку администрации торрент-трекера ThePirateBay с различными правообладателями.

Ссылка баянистая, но я с удовольствием перечитал всю переписку снова:

You also have the right to institute sodomizing of yourself. Preferably with barbed wire, but retractable batons might also work if you push them far enough.

Общечеловеку™ может показаться, что благодаря попустительству шведского законодательства владельцы торрента нагло обворовывают правообладателей со всего мира (больше всего из США, т.к. Штаты лидируют по объёмам экспортируемого медиа).

Это “обворовывание” возможно исключительно благодаря национальному (в данном случае шведскому) законодательству. Такая ситуация в недолгой истории копирайта не нова. Более того, всего полвека назад в роли шведских законодателей выступали — верно! — законодатели американские:

В конституцию США вписан закон, аналогичный английскому копирайтному законодательству: “для развития наук и искусств, Конгресс может закреплять за авторами и изобретателями исключительные права по использованию их работ на ограниченный срок”. Впрочем, вплоть до 1950-х этот закон на практике относился почти исключительно к работам, авторами которых были американцы; до конца 1950-х, европейские писатели были бессильны воспрепятствовать распространению пиратских изданий своих книг в США.

Известное пиратское издание Хоббита и трилогии Толкиена (неполное и с идиотскими иллюстрациями на обложке) до сих пор встречается чаще других изданий в американских букинистических магазинах; Толкиен судился с пиратами много лет, но так ничего и не поимел - и на обложке следующего, авторизованного издания (1960-е) содержатся его предостережения не покупать книжки у пиратов.

Традиционно, основной экспортной индустрией США были сигареты и оружие; с конца 1970-х, продукция Голливуда и других медиа потеснила изрядно и оружие и сигареты. США стали основным экспортером интеллектуальной собственности и чуть ли не монополистом ее; немедленно Америка оказалась членом всех и всяческих глобальных организаций охраны копирайта. Для выкручивания рук и лоббистской практики на местах был организован амбициозный лоббистский консорциум - Business Software Alliance (1988).

Цитата — из совершенно гениального “Антикопирайта” Миши Вербицкого. Эту книгу надо не просто прочитать в обязательном порядке, её надо перечитывать раз в месяц.

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

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

Сейчас, вроде, проблема производительности решена; да и особого роста числа активных пользователей у ЖЖ нет.

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

Это объяснение вполне вписывается в нынешнюю политику СУПа, выдавливающего из пользователей деньги под угрозой уничтожения их контента. Такого себе не позволял ни Брэд, ни 6apart.

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

Единственный способ читать френдленту по RSS на сегодня заключается в добавлении в читалку синдикацию журнала каждого френда по отдельности.

Многие онлайн читалки умеют автоматизировать этот процесс: по введённому имени пользователя вытягивают с сервера LiveJournal список его друзей и добавляют все их RSS-потоки.

Тем не менее, синхронизировать эти подписки со списком друзей придётся вручную: при добавлении/удалении френда надо будет добавлять/удалять его RSS-трансляцию из читалки.

Более того, такой способ подписки не даёт возможности читать подзамки. Конечно, можно при подписке указать URL фида в виде http://ljusername:ljpassword@friendusername.livejournal.com/data/rss, но не все читалки принимают такой формат; а те немногие, которые принимают, не могут уследить за безопасностью вашего пароля — например, Яндекс.

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

RSS-поток френдленты раздаётся по адресу, например, http://ljusername.livejournal.com/friends/rss. Публичные записи транслируются as is, с учётом настроек журналов, в которых написаны эти записи (текст полностью, только первый абзац, только заголовок). Подзамки как таковые не транслируются, даже их URL не идёт в трансляцию в явном виде (чтобы не раскрывать конфиденциальность).

Вместо подзамка в трансляцию идёт пустая запись со ссылкой вида http://ljusername.livejournal.com/friends/9e107d9d372bb6826bd81d3542a419d6, при переходе на которую происходит редирект на сам подзамок.

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

Хеши достаточно хранить в базе в течение двух недель; во френдленту записи, опубликованные более двух недель назад, всё равно не попадают.

Не следует ожидать реализации этого функционала в ЖЖ, т.к. перспектив монетизации у него нет никаких, а значит кривые руки жж-программистов до него, скорее всего, не дойдут.

Update: оказывается, в ЖЖ изобрели костыли, позволяющие читать френдленту по RSS. Эти костыли основаны на стиле S1 (как я понимаю, в качестве шаблона используется xml/rss вместо html — я в своих движках часто использую этот трюк: получается, что для отдачи rss надо только сделать новый шаблон и передать ему стандартные данные) и доступны только платным пользователям.

Если вдруг начала тормозить (подвисать) SSH авторизация, то возможная причина — проблемы с DNS.

По умолчанию в sshd включен Reverse Lookup — сервер пытается определить hostname клиента, и в случае проблем с нейм-серверами авторизация может сильно подтормаживать.

Чтобы убедиться, что именно вызывает подвисание в SSH, надо запустить клиента с ключом -v или -vv (для большей детализации дебага).

Если подвисание происходит после “SSH2_MSG_SERVICE_ACCEPT received“, то проблема может быть именно во включённом Reverse Lookup.

Чтобы отключить Reverse Lookup, надо в файле /etc/ssh/sshd_config прописать “UseDNS no” и перезапустить sshd сервис.

Если ваш Firefox вдруг начал ругаться о том, что сайт “has sent an incorrect or unexpected message. Error Code: -12263“, не пугайтесь.

Это сообщение означает, что у сайта какие-то проблемы с SSL сертификатом.

Как пофиксить на стороне клиента, я не знаю. Если есть возможность, работайте с сайтом по опасному http:// соединению. Сообщите администрации сайта о проблеме, пусть они чинят.

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

Юзабилити сосёт.

В связи с техногенной катастрофой у нашего провайдера пришлось перенастраивать DNS на юниксе.

Локальный список соответствий IP => HostName хранится в файлике /etc/hosts (в Windows: C:\WINDOWS\system32\drivers\etc\hosts).

Список нейм-серверов хранится в файлике /etc/resolv.conf (в Windows для изменения этого списка надо редактировать свойства соединения):

nameserver 202.54.1.110
nameserver 202.54.1.112
nameserver 202.54.1.115

Я не очень понял, с какой регулярностью система перечитывает этот файл; возможны задержки: новые NS-сервера начинают использоваться не сразу.