У них из-за глюка один ежемесячный платеж с Нового Года постоянно обрабатывается не как +$40, а как -$5. В саппорт им писал раз 10, на форум, реакции нет или весьма невнятная. В итоге я так и не понял, видят ли они этот глюк, собираются ли исправлять и когда вернут долги с начала года. Посмотрел на форуме - там несколько свежих постов про то, что задерживают выплату денег по непонятной причине, все без ответа.
Периодически клиенты спрашивают, зачем у нас изменение ответственного, состояния или ввод затраченного времени делается через сообщения. Почему бы просто не отредактировать поле в задаче ? Смысл тут в том, что при возникновении какого-то события в реальном мире часто требуется менять сразу несколько полей, причем эти изменения логически связаны друг с другом (т.е. нужны транзакции).
Шансы на то, что вышеупомянутая четверка уложится в 3000 дней - примерно 0.01%, т.е. 1 из 10 тысяч. Шансы уложиться в 3005 дней - порядка 0.02%. Даже шансы уложиться в 3100 дней относительно невелики - порядка 37%.
Дело тут в том, что каждый следующий работник в цепочке не может обрабатывать задачи быстрее, чем все предыдущие, а вот быть медленнее их - запросто. Т.е. для зависимых задач не происходит взаимной компенсации колебаний производительности, задержки не уравновешивают друг друга, а накапливаются.
Предположим, в компании работают 4 сотрудника - аналитик, программист, тестировщик и техписатель. Им нужно написать проект, который состоит из 3000 отдельных функций (задач), производительность каждого сотрудника - случайная, 0, 1 или 2 задачи в день (средняя - 1 задача в день).
При этом программист может реализовывать только уже описанные аналитиком фичи, тестировщик - тестирует только реализованные, а техписатель описывает только протестированные. Для простоты считаем, что если аналитик опишет сегодня какие-то задачи, то они могут "пройти" всех остальных участников процесса в тот же день.
Как думаете, какие шансы на то, что эта четверка уложится в 3000 дней ? Ну, ориентировочно, плюс-минус 5% ?
Есть у нас такая странная проблема - периодически у кого-то из клиентов начинает валиться 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 внушает сомнения.
