При разработке Jabber2Twitter-гейта, получил от бета-тестров жалобу на то, что не удается добавить бота в список контактов с не-Google-овских клиентов/доменов (Ya.Online, Qip, etc).
(Google тут при том, что Jabber-демон “живет” на его серверах)

Тогда в мозгу родился вопрос: А откуда Jabber-клиент должен знать, что при коннекте к Jabber-серверу нужно идти не на тот IP-адрес, куда указывать DNS, а на Google-евый сервер?

Грубо говоря, если у меня DNS-запись домена jabber2twitter.com находится на одном сервере (ServerA), а Jabber-демон – на другом (ServerB), то откуда Jabber-клиент знает, что нужно открывать сокет на ServerB:5222 ? 

Вот тут как раз в дело вступают DNS SRV-записи, которые указывают размещение сетевых сервисов для конкретного доменного имени. 
Опять же на грубом примере это выглядит так: в SRV-записи домена указывается что искать FTP/LDAP/etc. сервисы, привязанные к этому домену нужно искать вот по такому вот адресу.
Почти также как MX-записи указывают на то, где искать почтовые службы, привязанные к доменному имени. 

Возвращаясь к теме Jabber-протокола, спецификация RFC 3920, в разделе “14.3. Client-to-Server Communications”  говорит что, что перед тем, как клиент производит DNS-resolve IP-адреса, он должен проверить SRV-запись с именем ”_xmpp-client._tcp.example.com.”
И только в случае неудачи подключаться к тому серверу, на какой указывает A-запись домена.

Кому это может понадобиться, кроме разработчиков Jabber-клиентов/серверов? 

Отвечаю: Например тем, кто использует Google Chat на своем домене и хочет добавить возможность чатится с jabber-пользователями вне пределов этого домена.

В таком случае необходимо добавить SRV-записи так, как это описано тут.

В моем же случае, добавление SRV-записей вроде как решило описанную вначале заметки проблему.
Буду благодарен, если кто пользует не Google-овские Jabber-клиенты, попробует добавить в контакты bot@jabber2twitter.com и сообщит мне видит ли он бота online

При управлении доменными именами, зарегистрированными на GoDaddy, возникла проблема, которая убила у меня 2 часа полезного времени.
(вот только не надо мне рассказывать что GoDaddy это не труЪ – сам знаю)

При попытке назначить определенному домену собственные (custom) nameservers (например ns1.myzone.com и ns2.myzone.com), получаем ошибку “Nameserver not registered.”
Аналогичная ситуация наблюдается если пытаемся создать профиль с указанием custom nameservers.

Пользовательская справка GoDaddy по поводу решения этой проблемы скромно умалчивает (хотя раньше лично мне всегда помогала).

Решение оказалось немного нетривиальным:

Необходимо в настроках домена myzone.com кроме того, что создать DNS-записи для субдоменов  ns1 и ns2, ещё и добавить аналогичные записи в “Host Summary” (прямоугольный блок внизу слева, на странице с информацией о домене).
В первом поле ввода указать ns1, а в поле “Host IP 1” – IP-адрес, куда должен указывать NS.
Аналогично и для записи ns2.

И только после этого, GoDaddy позволит указывать ns1.myzone.com и ns2.myzone.com в качестве Custom Nameservers для своих доменов и использовать их в профайлах.

Вот такой вот интересный запрос случайно выудил из документации MySQL:

SELECT
    table_name AS table_name,
    engine,
    ROUND(data_length/1024/1024,2) AS total_size_mb,
    table_rows
FROM
    information_schema.tables
WHERE
    table_schema=DATABASE();

Показывает обьем и количество строк в таблицах MySQL.
Результат выглядит приблизительно так:

+-------------------+--------+---------------+------------+
| table_name        | engine | total_size_mb | table_rows |
+-------------------+--------+---------------+------------+
| categories        | MyISAM |          0.00 |         17 |
| downloadlinks     | InnoDB |         13.02 |      19158 |
| errors            | InnoDB |         15.02 |      84104 |
| lastdownloads     | MEMORY |          3.19 |        524 |
| providers         | MyISAM |          0.00 |         17 |
| starstags         | InnoDB |          1.52 |      14323 |
| tagids            | InnoDB |         35.59 |     759694 |
| tags              | InnoDB |       2036.00 |   21971934 |
| vars              | InnoDB |          0.02 |         51 |
| videocategories   | InnoDB |         49.58 |    1583675 |
| videos            | InnoDB |       1864.00 |    1954427 |
| videos_deleted    | MyISAM |         56.33 |      75889 |
| videostats2       | InnoDB |        271.88 |    3417776 |
| videostats2_daily | InnoDB |          0.02 |        266 |
+-------------------+--------+---------------+------------+

Правда есть один нюанс: на InnoDB-таблицах показывает количество незалоченных в данный момент строк.

P.S. А кто-то пробовал использовать ARCHIVE storage engine?
Как он в плане fail-over и repair?
Поделитесь good/bad experience?

или история одного маленького и противного бага.

Сегодня убил некоторое время, отлавливая мерзкий баг. Баг был наглядно продемонстрирован юнит тестом, который, помимо всего прочего, проверял два объекта на эквивалентность. Сами объекты – простые java-бины с парой полей – одно типа int, второе типа String[][]. Код для equals и hashCode поручил сгенерировать eclipse’у. Подвох оказался в том, что метод equals попросту не работал – он всегда возвращал false. При детальном рассмотрении проблема нашлась:

if (!Arrays.equals(fieldTwo, other.fieldTwo))
	return false;

Все ведь просто, Arrays.equals сравнивает типы массива и количество элементов в каждом из них. Затем проверяет эквивалентность поэлементно. Первые две проверки проходят, а вот третья проваливается с треском. Ведь никакие два объекта-массива в java не эквиваленты:

System.out.println(new int[]{1}.equals(new int[]{1})) // Выведет false.

Для проверки эквивалентности многомерных массивов нужно использовать метод deepEquals, который, кстати, находится в том же классе Arrays.

Ради интереса я попробовал сгенерировать код equals и hashCode в IntelliJ IDEA. Idea отказалась учитывать многомерный массив при создании кода equals. По крайней мере, это честнее, чем создавать нерабочий код.

Учитывайте эти грабли, когда в следующий раз будете нажимать кнопочку кодогенератора.