Выпустили, наконец-то :-) Неофициально релиз был готов еще 2 недели назад, поэтому сразу выпустили и 4.0.1 с правками за последние 2 недели.

Что сделали: http://www.trackstudio.ru/whatsnew.html
Скачать можно тут: http://www.trackstudio.ru/products-edownload.html

У них из-за глюка один ежемесячный платеж с Нового Года постоянно обрабатывается не как +$40, а как -$5. В саппорт им писал раз 10, на форум, реакции нет или весьма невнятная. В итоге я так и не понял, видят ли они этот глюк, собираются ли исправлять и когда вернут долги с начала года. Посмотрел на форуме - там несколько свежих постов про то, что задерживают выплату денег по непонятной причине, все без ответа.

Пора валить ? Куда ?

Сейчас переводим все (почта, SVN, внутренний TrackStudio, сайт) с Sagonet на Amazon EC2. Первые впечатления:

( Читать дальше...Свернуть )

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

( Читать дальше...Свернуть )

Шансы на то, что вышеупомянутая четверка уложится в 3000 дней - примерно 0.01%, т.е. 1 из 10 тысяч.
Шансы уложиться в 3005 дней - порядка 0.02%. Даже шансы уложиться в 3100 дней относительно невелики - порядка 37%.

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

( Читать дальше...Свернуть )

Предположим, в компании работают 4 сотрудника - аналитик, программист, тестировщик и техписатель. Им нужно написать проект, который состоит из 3000 отдельных функций (задач), производительность каждого сотрудника - случайная, 0, 1 или 2 задачи в день (средняя - 1 задача в день).

При этом программист может реализовывать только уже описанные аналитиком фичи, тестировщик - тестирует только реализованные, а техписатель описывает только протестированные. Для простоты считаем, что если аналитик опишет сегодня какие-то задачи, то они могут "пройти" всех остальных участников процесса в тот же день.

Как думаете, какие шансы на то, что эта четверка уложится в 3000 дней ? Ну, ориентировочно, плюс-минус 5% ?

UPD. Продолжение тут: http://maximkr.livejournal.com/18971.html

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

Такое происходит из-за того, что при необходимости удалить что-то TrackStudio не пытается отслеживать связи между данными, а просто удаляет. Если удалилось - значит ссылок на объект нет и все нормально. Но почему-то иногда СУБД позволяет удалять данные, на которые ссылаются foreign keys. Когда-то давно видели эту проблему только на MS SQL Server 2000 без SP4, думали локальный глюк. Но за последние годы видели такое и на MySQL, и на DB2, и на SQL Server 2005.

Вопрос - что это может быть ? Как вообще может быть, что foreign key есть, а данные удаляются ? Может ли пользователь как-то случайно отключить проверку foreign keys ? Можно ли обойти проверку foreign keys ? Приветствуются любые идеи.

На сайте Atlassian появилась информация по JIRA 4. Они правильно сделали, что отказались от Standard/Pro/Ent (давно пора), сделали язык запросов JQL (у нас нет такого и в 4.0 не будет), но вот user-based pricing внушает сомнения.

( Читать дальше...Свернуть )

Один из клиентов предложил на форуме поднять публичный багтрекер, для генерации What's new. Публичный багтрекер не нравится вот по каким причинам:

( Читать дальше...Свернуть )