Зарелизил плагин, скрывающий исходящие ссылки в вордпрессе: wordpress external links plugin.

Заодно поднял специальный сайт на отдельном домене: wordpress plugins.

Как всегда, без дизайна — нарисована только одна коробка, и та мною.

В субботу все влюбленные будут отмечать день всех влюблённых.

А в ночь с пятницы на субботу все гики будут отмечать 1234567890 seconds since the Unix Epoch.

По киевскому времени этот момент наступит в 2009-02-14 01:31:30. По GMT: в 2009-02-13 23:31:30.

Узнать, в котором часу этот момент наступит в вашем часовом поясе, можно с помощью такой команды:
<?=date(“Y-m-d H:i:s”,1234567890)?>

Следить за обратным отсчётом до круглой секунды можно в онлайне:

• 1234567890day.com
• coolepochcountdown.com

• Internet Explorer седьмой версии не обрабатывает посланную ему cookie, если имя домена написано заглавными буквами и содержит нечетное число букв;
• WinSock 2.0 в Windows 95 рушил систему при попытке отрезолвить NetBIOS имя длиной 15 символов, содержащее по крайней мере две точки;
• (баян) электронная почта не шлётся дальше, чем на 500 миль;
• понтиак не заводится, если водитель покупает ванильное мороженое.

Small Basic derives its inspiration from the original BASIC programming language, and is based on the Microsoft .Net platform. It is really small with just 15 keywords and uses minimal concepts to keep the barrier to entry as low as possible.

Тут вот соседи из Кривого Рога прутся от использования Zend Framework:

На работе проект разрабатываем с использованием Zend Framework […] основан на Model-View-Controller […] контроллер должен соответствовать правилам именования […] накладывает серьезные правила на структуру каталогов […] иногда фреймворк предоставляет мало свободы там, где стандартными методами тяжело обойтись и приходится сталкиваться с нетипичными задачами.

Я тут тоже встрял в один проект с использованием фреймворка, правда другого. Ощущения те же самые — да, фреймворк вынуждает писать код в парадигме MVC. Да, файлы надо разносить по соответствуюшим директориям.

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

Достоинства эти, кстати, довольно сомнительные.

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

А вот необходимость заюзать фреймворк нестандартно возникнет обязательно, на то он и фреймворк. И если для её реализации понадобится возиться с фреймворком длительное время, то ну его наверное нафиг.

На данном этапе наиболее удобным мне кажется использование самописного фреймворка с максимальным включением сторонних библиотек: шаблонизатора (BTW, Smarty рулят), форм-процессора, database access layerа (что-нибудь с поддержкой Active Records), мейлера (создателям PHPMailerа — риспект и уважуха), jquery и далее по вкусу.

Чувак плачется, что индусы убивают рынок фриланса в вебе, соглашаясь делать работу, которая стоит 100 баксов, за 10.

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

Почему копейки? Потому что очень много нубов, слишком большое предложение на рынке услуг.

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

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

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

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

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

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

В частности, 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.

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

В понедельник 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 подходят не для всего: например, хранить текстовый документ с разметкой с помощью этого формата будет неудобно, т.к. структура будет смешиваться с текстом.

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

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

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

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

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

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

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

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

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

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

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

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