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

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

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

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

Изменение в режиме работе саппорта

На прошлой неделе решили поменять режим работы саппорта по TrackStudio. Раньше было так: задачи сортировались по update date, самые последние вверху. Разработчик обычно брал самую верхнюю и ей  занимался, если там было что-то не понятно - смотрел следующую.

Этот подход приводил к следующим эффектам:

Collapse )

Странное совпадение

У нас контора называется ООО "ГРАН", название довольно редкое и вообще не про IT (это устаревшая единица массы). А тут выяснилось, что существует Колл-центр ГРАН, который был создан нашим в некотором роде конкурентом NAUMEN: http://www.gran-call.ru/category/about/

Это случайное совпадение ? Если нет - зачем это может быть кому-то нужно ?

Переехали с локального 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.