Category: it

Category was added automatically. Read all entries about "it".

Работа TrackStudio на многоядерных CPU - история вопроса

Когда-то давно (2001-2004 годы) TrackStudio все данных хранила в БД, для выборок использовала сложные SQL-запросы и практически ничего не хранила в памяти. Эти версии могли в полной мере использовать потенциал многоядерных CPU, но массовых многоядерных CPU тогда не существовало, а даже двухядерные сервера были весьма дорогими.

К 2003-2004 годам мы уперлись в производительность СУБД, для поддержки иерархии задач и нашей модели прав доступа требовалось буквально "бомбардировать" СУБД SQL запросами, СУБД не справлялись. Подробнее об этом я уже писал.

Тогда эту проблему решили путем создания внутренних кешей весьма сложной структуры буквально для всего, доступ к этим кешам обложили глобальными блокировками. На тот момент это было хорошее решение:
- многопроцессорных серверов все равно было мало, причем "много" часто означало два.
- использование локальных кешей позволило значительно улучшить производительность.
Collapse )

Переехали с локального SVN на GitHub

На выходных перетащил исходники TrackStudio и сопутствующих проектов на GitHub В начале планировали переезжать на Bazaar (в основном потому, что у него команды на svn очень похожи), но в итоге выбрали Git.  

Заодно в TrackStudio 4.0.11 приделали поддержку Git и Mercurial.

Про JIRA Most Popular Issues

Раньше в JIRA был замечательный отчет - Most popular issues, это список нерешенных проблем, отсортированный по количеству проголосовавших. Наше сравнение с JIRA в значительной степени было основано на анализе этого списка т.к. там были описаны наиболее серьезные проблемы JIRA. Большинство проблем из этого отчета были давно решены в TrackStudio, но их решение в JIRA даже не планируется.

Похоже, что сейчас этот отчет из JIRA убрали :). Т.е. отсортировать по популярности баги, которые были исправлены в какой-то версии можно, а вот получить отсортированный по популярности список открытых багов - нельзя.

Но не думаю, что это мы их допекли. Их собственные клиенты довольно часто "мотивировали" Atlassian решить ту или иную проблему т.к. она занимает одно из лидирующих мест в списке. Они же критиковали Atlassian за решение "проблем", которых вообще в список нет.

В общем, популярный был отчетик. RIP.

Сравнение с Redmine

Первый вариант писался по мотивам изучения сайта/документации, получилось не очень убедительно, как мне кажется. Но интерес к теме есть, поэтому вчера поставили Redmine локально и поигрались с ним, по итогам сравнение в значительной степени переписал.

В целом удивляет вот что. Redmine - это же достаточно свежий проект, на момент начала его создания грабли в Jira были уже известны, методы исправления этих граблей - тоже. Но в Jira их исправлять уже поздно, 4 версия вышла уже, а в Redmine - могли бы попробовать.
Collapse )

800 номер

Подумываю обзавестись 800-номером для TrackStudio, тогда звонки нам с городских и мобильных по России будут бесплатными. В b2c это используется часто и явно имеет смысл, а вот в b2b - не знаю. Вопросы такие:
1) при звонке "по работе" вы задумываетесь о стоимости звонка ?
2) часто ли вообще звоните по межгороду, или в принципе предпочитаете IP-телефонию ?
3) звонок на 800-номер воспринимаете скорее положительно (например, с уверенностью, что кто-то ответит и это будет не уборщица/охранник) или скорее отрицательно (предстоит выслушивание получасовой рекламы) ?

NoSQL и Lucene

Я писал когда-то, что не очень рад использованию реляционных СУБД в TrackStudio. Если коротко, то мы используем из всего SQL разве что поиск по первичному ключу, испытываем большие сложности с обработкой кастом-полей в задачах, плюс очень много всего приходится кешировать, чтоб не тормозило.  Т.е. интерес ко всякой альтернативщине был давно, а тут довелось поковыряться с NoSQL-базами и возникло некоторое непонимание:

Collapse )

Про планирование связанных задач и закон больших чисел - 2

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

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

Collapse )

Про планирование связанных задач и закон больших чисел

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

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

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

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

Странная проблема с foreign keys в реляционных СУБД

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

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

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