В понедельник 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” в форме заказа потребовало более дюжины коммитов.”

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

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

Задача: создать в JavaScript массив из одного элемента, равного значению переменной x.

Очевидное решение var a = new Array(x); — неправильно.

Если переменная x имеет тип number и является целым числом (например, x=5), то вместо массива с одним элементом, равным 5, мы получим пустой массив из пяти элементов. А если x является дробным числом (например, x = 5.2), то мы вообще получим ошибку invalid array length. Если x — строка, то решение сработает.

Причина такого поведения браузеров в том, что при создании массива через Array(x) интерпретатор ведёт себя по-разному в зависимости от типа переменной x. Если он получает тип number, то он трактует этот параметр как длину создаваемого массива, а не как значение нулевого элемента.

Правильный ответ: var a = new Array([x]);

Задача: средствами PHP отправить письмо через smtp.gmail.com. Не просто с указанием адреса @gmail.com в поле From:, а именно через гугловский сервер.

Зачем это нужно? Во-первых, на многих хостингах существуют всяческие ограничения по использованию почты. Во-вторых, такое письмо должно выглядеть “белее” письма, отправленного локальным smtp: меньше шансов, что оно попадёт в junk folder.

Основная проблема, которая возникает при отправке письма через smtp.gmail.com и не возникает при отправке писем по smtp через другие, более обычные сервера, состоит в необходимости использования TLS соединения на 465 порт.

Отправить письмо из PHP напрямую через SMTP сервер (а не через mail() или sendmail) можно давно с помощью LGPL библиотеки PHPMailer.

Оказывается, начиная со второй версии, разработчики библиотеки добавили поддержку отправки почты по SMTP по безопасному соединению. Вот code snippet, формирующий правильный вызов метода отправки письма при использовании гугловского smtp:

     $mail->Mailer = “smtp”;  
     $mail->SMTPAuth = true;  
     $mail->SMTPSecure = “tls”;
     $mail->Host = “smtp.domain.com”;  
     $mail->Port = “465″;  
     $mail->Username = “email.address@gmail.com”;  
     $mail->Password = “1W0N’T_t3ll-U”;  

Разработчики библиотеки не волшебники: для отправки писем по безопасному SMTP-соединению необходим PHP с поддержкой OpenSSL.

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

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

Оценивать язык программирования абстрактно (и сравнивать его с другим) бесполезно.

Оценку можно дать тому, насколько удачно язык программирования позволяет решить конкретную задачу.

Т.е. для сравнения языков их сначала надо спроецировать на какую-то задачу.

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

Потому что WTF — это производная не от языка, а от программиста.

Профессионал решит задачу на том, на чём скажут. Поплюётся, но сделает VBScript для автоматизации в Excelе. Скривится, но допишет нужный функционал к PHP-шному скрипту.

А вот от кривизны рук никакой язык не избавит. Немного выровнит, но не избавит.

Если бы избавлял, то сидели бы все и писали на C.

Вот один из способов, которым можно реализовать мою идею о загрузке javascript из локальной зоны браузера: добавление тегу script атрибута shared, обозначающего каноническое расположение библиотеки:

<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js” shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”></script>

Если в кеше браузере уже есть скрипт с uri, указанном в shared, то его можно будет не грузить.

Это — потенциальное дополнение к тегу script, которое может появиться в HTML5. Об этом рассказывает создатель JavaScript Brendan Eich (via Alex Moskalyuk).

Основным способом ввода информации в CMS через веб являются элементы управления типа <textarea>.

Для удобства пользователей и увеличения скорости ввода информации эти контролы часто заменяют на WYSIWYG-редакторы (What You See Is What You Get).

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

Разработчикам же для внедрения WYSIWYG-редактора требуется установить на сервер сам редактор, настроить его и вставить в шаблон пару javascript строк для замены плоской <textarea> на неплоское поле на клиенте.

При этом разработчики часто совершают ошибку: внедрив WYSIWYG в свою CMS, они не дают пользователю возможности не использовать этот WYSIWYG.

Речь не идёт о тех клиентах, которые не поддерживаются WYSIWYGом — в них контрол выглядит старой плоской <textarea>. А вот если у пользователя нормальный клиент, но при этом, например, интернет по GPRSу, то бедный этот пользователь: чтобы добавить контент ему понадобится достаточно много времени и денег (WYSIWYG подгружает достаточно много дополнительных файлов: javascript, css, images).

WYSIWYG надо внедрять так, чтобы у пользователя всегда была возможность не пользоваться им. Переключение между WYSIWYGом и plain <textarea> должно происходить без перегрузки страницы.

При этом plain <textarea> не должна быть действительно plain: к ней необходимо прикрутить quicktags для гиков.

Из всех WYSIWYGов наиболее удобным является TinyMCE.

Рассмотрим некую предметную область, в которой имеются две сущности: category и object. Теперь рассмотрим два типа отношений, которые могут между ними существовать: один-ко-многим и многие-ко-многим.

Отношение один-ко-многим означает, что объект может принадлежать только к одной категории. В реляционной модели данных это отношение представлется добавлением поля category_id в таблицу объектов. При этом можно с лёгкостью:
1) узнать, к какой категории относится объект;
2) получить список объектов, принадлежащих категории.

Отношение многие-ко-многим означает, что объект может находиться в нескольких категориях. В реляционной модели данных это отношение отражается при помощи дополнительной таблицы отношений с полями object_id, category_id. Каждая запись в этой таблице содержит информацию о том “факте”, что объект с ID = object_id находится в категории с ID = category_id.

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

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

Формат этого списка может быть любым: ID с разделителями, bitmask, внутренний формат какого-нибудь языка (например, serialized array для PHP). Критерий к формату этого дополнительного поля один: удобство использования в CMS.

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

В идеале front-end CMS должен учитывать тот факт, что данные из этого дополнительного поля могут содержать ID категорий, уже несуществующих в системе, и обрабатывать их соответстенно.

Существует способ получить быстродействие без отказа от целостности данных: завести дополнительное поле не вместо дополнительной таблицы, а в дополнение к ней. Хранить в этом поле следует тоже самое — список ID категорий, к к которым принадлежит объект. В данном случае платой за быстродействие является приобретённая избыточность данных.

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

Три коротких заметки про PHP.

1. Kevin van Zonneveld разрабатывает библиотеку php.js — стандартные php функции, портированные на JavaScript. Естественно, не все функции портированы, на данный момент их 114. Не рекомендуется к просмотру людям, не знающим, как передать переменную из JavaScript в PHP — окончательное разжижение мозга (до состояния “каша в голове”) гарантированно.

2. Каким, по вашему, будет результат вызова in_array(”68_105″,array(68,16,123))? Оказывается, у функции in_array() есть третий параметр — [bool strict]. С его помощью можно включить поиск в массиве не только по значению, но и по типу.

3. Только начиная с версий 4.4.0 и 5.0.2 PHP функция sort() умеет использовать установки локали (с помощью флага SORT_LOCALE_STRING). Для более ранних версий (хотя пора уже проапгрейдиться) можно использовать костылик usort($array, “strcoll”)

Сделали релиз новой версии мозгоразминочного сайта.

По-прежнему без блекджека и шлюх, но зато с комментариями, регистрациями, извещениями, поддержкой openid. Перепёрли все лучшие идеи русской блогосферы. Да, дизайна там по-прежнему нет, руки до него так и не дошли. До чего дошли руки, так это до движка: реально симпатичная CMSина получается. Она, как любая настоящая CMSина, находится в стадии перманентной разработки. Более того, чем больше features реализовано, тем длиннее оказывается список новых, нереализованных.

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

У нас на эту CMSину далекоидущие планы, поэтому приходится её вылизывать. Например, хочется вместо вордпрессов использовать именно её, но при этом сохранить все существующие урлы (именно сохранить, а не повесить 301-й редирект). В то же время, нам нужна более широкая функциональность, чем предоставляет wordpress. Правда, у вордпресса две сущности: pages и posts, а нас всего одна: objects. Но у нас есть категории и теги, которые между собой перпендикулярны, а не параллельны, как в вордпрессе. Понятие “категории” мы трактуем несколько нестандартно, в результате кроссворды уживаются рядом с блогозаписями, редактируются одной админкой и обрабатываются одним фронт-ендом.

В user generated content я не верю, поэтому юзеры могут только комментировать. CAPTCHA простенькая: яка країна, такі й теракти. В общем, следите за обновлениями.