Мои внимательные читатели™ наверняка заметили, что я почти перестал обновлять свои блоги.

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

1) работа интересная и “по специальности”; 2) свой бизнес не закрыт, а задвинут.

Период акклиматизации на новой работе в новом офисе подошёл к концу, и я снова превращаюсь в среднестатистическего блогера™, который, согласно исследованию Яндекса, ведет блог в рабочее время!

Черновичков за время молчания накопилось прилично.

Сделать мелкую гадость: взять пульт от телевизора и переставить язык меню на арабский или японский.

(Hint: найти в меню на арабском пункт “язык” — челлендж для терпеливых)

Разработчик мега-плагина для вордпресса “SpamKarma” о вордпрессе:

I will really try to keep that one short, because I could probably write a novel of that. And it wouldn’t be a very interesting read.
In a word: Wordpress kinda sucks nowadays. Its retarded upgrade rate makes it nearly impossible to keep up, in turn making it a constant security threat on my servers. And each time I finally cave in and install one of those “mandatory security upgrade”, it also installs 600 Ko of other theme compatibility-breaking fluffy crap that I never asked for in the first place. Usually setting the ground for the next cycle of security-exploit-rushed-upgrade. To sum up, it’s become incredibly bloated and tedious to support. Replacing it on my own servers is very high on my list of things to do (which means somewhat in the first 1000 items).

В переводе на русский: вордпресс сосёт, причмокивая.

Причём сосёт причмокивая настолько громко, что единственным стимулом писать что-то под вордпресс для меня являются деньги. Потому что такое govno inside, что никакого терпения не хватает.

Вот вам и Open Source: ни одного нормального бесплатного блог-движка на php до сих пор нет. Палю нишу, типа.

На одноклассниках появился режим “Невидимка”:

Что такое режим «Невидимка»?

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

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

Режим «Невидимка» не распространяется на остальные Ваши действия: сообщения, комментарии, оценки.

Услуга заказывается с помощью SMS сообщения.

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

Не даёт мне мой внутренний параноик™ зарегистрироваться по-другому.

А вот российские военнослужащиепленные регистрируются без колебаний.

В частности, Windows.

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

Самый простой способ разобраться с ошибкой — вбить её текст в google и почитать, что написали пользователи, сталкивавшиеся с этой ошибкой раньше.

Этот способ позволяет разобраться с приблизительно 90% всех ошибок (не только пользовательских, но и программистских — дебажить с гуглом гораздо веселее, чем без него, хоть это и расслабляет, отучая мозги думать).

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

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

А винда у меня (к сожалению) русская, т.к. покупалась вместе с ноутом.

Столкнулся с необходимостью выбрать инструментарий для ведения документации по проекту. Получается, что если в команде нет отдельного (специально выделенного) человека, который ведёт всю документацию, то инструментарий должен поддерживать коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

Два ключевых слова — “документация” и “коллективная” приводят к очевидному решению — wiki. Решение настолько очевидно, что можно найти testimonials людей, использовавших wiki для документирования разработки software:

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

Очевидно, что сама по себе wiki не справляется с задачей: нужны костыли для привязки к багтрекеру, svn-у, php-docу (или его аналогу). Ещё более очевидно, нужен “архивариус” — человек, который будет поддерживать порядок в документации, реструктуризировать дерево. Похоже, что при определённой активности и дисциплинированности пользователей (т.е. разработчиков, тестеров и менеджеров) роль архивариуса удастся свести именно к поддержанию порядка.

При этом меня не покидает ощущение того, что wiki-разметка — это недо-html. А в компании, занимающейся web-разработками, основы html знает даже корпоративная морская свинка™. Спрашивается: зачем людям, знающим html, насиловать себя и писать вместо <i>привычных тегов</i> //какие-то недотеги//, которыми они нигде, кроме этой самой wiki не пользуются, в отличие от нативных html тегов?

Среди всех претензий к wiki её недо-htmlьность — самая мелкая.

А теперь самое время вернуться к тому, с чего всё это начиналось: нам нужен инструмент, позволяющий вести коллективную разработку документации. Как минимум — уметь делать versioning, diff и rollback.

А ведь у нас уже есть такой инструмент: это Control Version System, система контроля версий. Стандартная CVS позволяет делать versioning, diff и rollback для текстовых файлов.

Итак, самое дешёвое решение — вести документацию в текстовых файлах, контроль версий возложит на CVS, которая уже есть в проекте. Грубо говоря, если в CVS есть директория Source с исходниками проекта, то рядом надо сделать папку Docs с его документацией в текстовых файлах.

Беда в том, что документация — это не текст. Даже если обойтись без таблиц, иллюстраций и форматирования, документация — это как минимум гипертекст. Значит, надо вести документацию в формате html, и хранить её в CVS, ибо html файл — это текстовый файл. Редактировать документацию сможет каждый, как и в случае с wiki — для этого подойдёт любой html-редактор, даже блокнот.

Versioning для html файлов будет по-прежнему обеспечивать CVS. Единственное, что надо согласовать — это правила форматирования документации в html. Типа: для жирного используем <b>, а не <strong>; абзацы делаем с помощью <p>; ссылки ставим только относительные. Точно такие же соглашения существуют и в отношении кода: как ставим {скобки}, что используем для табуляции — пробелы или табы.

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

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

А вот вебмани не хотят, чтобы на них наехали, как на e-gold:

Арбитраж WebMoney Transfer устанавливает перечень в котором перечислены, но не исчерпываются, виды финансовых или платежных систем по которым, БЕЗУСЛОВНО, запрещается использовать WebMoney Transfer при расчетах по сделкам купли-продажи: e-gold.com/liberty reserve/pecunix.

Обменники реагируют:

В связи с изменением Соглашения Webmoney Transfer наш сервис UKRWEBMONEY.COM прекращает двусторонние обменные операции всех видов титульных знаков Webmoney Transfer с системами LibertyReserve, E-Gold, E-bullion и др. Обменом электронных валют отличных от Webmoney будет занимается обменный пункт UKRWM.COM.

ФБР сообщает: компания “E-Gold” и её три владельца признали себя виновными в отмывании денег и незаконных денежных операциях. Компания согласилась на конфискацию $1.75 миллиона до оглашения приговора.

Сам приговор будет оглашён 20 ноября. Компанию могут оштрафовать на сумму до $3.7 миллионов; владельцам светят разные сроки и штрафы (одному — до 25 лет и $750 тысяч, двум другим — до 5 лет и $25 тысяч).

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

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

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

Если вы используете 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.

В понедельник Google выпустил Protocol Buffers — формат хранения данных, позициниоруемый гуглом как частичная замена XML.

Вот как выглядит пример XML:

  <person>
    <name>Йа Креведко</name>
    <email>ja@kreved.co</email>
  </person>

А вот так выглядит та же информация, записанная с помощью Protocol Buffers (в текстовом формате):

  person {
    name = "Йа Креведко"
    email = "ja@kreved.co"
  }

Кроме текстового формата, Protocol Buffers может быть бинарным — т.е. Human Readability, как в случае с XML, не гарантирована.

Для любого файла в формате Protocol Buffers нужен файл формата .proto, в котором описывается структура данных:

message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

Google и сам пользуется этим форматом во многих своих проектах, и другим рекомендует его вместо XML для сериалайзинга структурированных данных, ибо Protocol Buffers по сравнению с XML:

• проще
• в 3-10 раз меньше
• в 20-100 раз быстрее
• менее неопределённые
• порождают классы для доступа к данным, которые легче использовать программно

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