TeamTrack vs адекватность

По работе переходим на использование TeamTrack (заказчик использует). Система уматная, поражает своей продуманостью с ходу и в лоб.

Для того что бы засабмитать багу надо выбрать компонент. Внимание: из всех продуктов что есть на серваке. Для этого предлогается натайпать кусок имени и нажать поиск. Если натайпать не точно, то в найденных результатах будет: More than 250 matches... Далее надо выбрать билд в котором бага найденна. Для этого предлогается комбик с, барабанная дробь, всеми версиями всех продуктов которые трекаются на сервере. Как отличить версию "0.1" от другой такой же "0.1" я пока что не знаю.
Когда фиксаеш багу и хочеш её заасайнить на кого-то конретного то это можно сделать, как вы уже догадались, используя всё тот же мега комбик со всеми человеками которые так или иначе зареганы на сервере.

В общем ребята уже выпустили версию #7 и до сих пор не знают что такое проекты и зачем они нужны.

З.Ы. Для того что бы добавить версию продукта в систему надо... написать письмо в саппорт! Те кто пользуют TeamTrack пишут письма с длинным списком версий которые они планируют выпускать. Понятно, что это только "облегчает" поиск в комбике. Интересно, сколько строчек виндовый комбик тянет?

XmlSerializer vs KeyValuePair

Собственно сабж. Неравный бой идёт не идёт уже как 3.5 года. То биш KeyValuePair помечен для сериализации, но результат получаем вот такой:

<?xml version="1.0"?>
<ArrayOfArrayOfKeyValuePairOfStringObject xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ArrayOfKeyValuePairOfStringObject>
<KeyValuePairOfStringObject />
<KeyValuePairOfStringObject />
<KeyValuePairOfStringObject />
</ArrayOfKeyValuePairOfStringObject>
</ArrayOfArrayOfKeyValuePairOfStringObject>

Допустим понятны причины по которым Key и Value property не имеют setter. Но какова причина помечать структуру для сериализации если по факту её нет - для меня загадка.

Sun-техники

Я относился с лёгким пренебрежением в духе: эти мамонты ещё не вымерли? По отношению к Sun. Однако поймал себя на мысли, что у них есть много интересных изделий, которые я так или иначе посмотрел или прочитал о них. В частности:
NetBeans - как хорошая Ruby IDE
OpenOffice - ну здесь понятно
ZFS - практически dream FS


Надо будет поплотнее присмотрется к конторке то. Совсем не мамонтами оказались создатели Java :).

Перечитывая Спольски

Попав вчера на rsdn перебрался оттуда на статьи Спольски и вот заново перечитываю их. Некоторое читаю впервые. Нашол отличную штуку:

Иногда встречается программист на Си, пишущий что-то типа if((0==strlen(x)), помещая константу слева от ==. Это очень хороший признак, означающий, что он уже столько раз попадался на путанице между = и ==, что выработал в себе привычку, исключающую подобное.

Аааааа, теперь я понял, почему плюсятнеги пишут константу слева в if-ах. Потому что это потенциальная дырка в коде вызыванная не совершенством Си/Си++.

Курьёзы программирования

Тут будут курьёзы программирования, с коротырми я лично столкнулся/породил.

Итак начали.

1. Оператор сравнения vs. лямбды

Классика: вечер, сижу, хочу дописать кусок кода/работы. Подтупливаю ещё не сильно.

if ((backLog.TimeStamp - lastTime).Minutes => minuteInterval) {Unexpected token. Expected ; -Mastro 27/11/2008 19:59 
    //...
}

Что решарпер от меня хочет в выделенном крассным!? Какая такая ;. Всё же правильно. Может скобку забыл где, да нет - всё на месте. Дай как скомпилю: опа, те же ошибки.
Чешу репу, и через минуту понимаю в чём дело :). Оператор сравнения пишется несколько иначе:

if ((backLog.TimeStamp - lastTime).Minutes >= minuteInterval) {
    //...

}

Вот теперь всё в порядке.