Максим Крамаренко

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

2009-10-28T18:26:13Z

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

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

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

Про JIRA 4

2009-10-07T13:48:39Z

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

Судя по странице
http://confluence.atlassian.com/display/JIRACOM/Active+User+Count

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

PS. У нас в лицензиях на ограниченное количество активных пользователей считаются только те пользователи, которые работали (и работают) с системой с момента последнего перезапуска. Например, если пользователь просто создан в базе - он не считается за активного, если вот если входил в систему и сейчас его сессия активна (он не нажмал Logout) - считается.

Публичный багтрекер

2009-09-24T08:12:23Z

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

1) Проблему с генерацией What's new он все равно не решает, т.к. это лишь один из ресурсов. Многие все равно будут слать почтой, по аське, через форум, очень много багов с закрытой информацией (скриншоты, дампы, логи). Это все либо надо сводить в одно место самому, либо заставлять делать пользователей. А что делать, если бага была публичной, но потом для исправления понадобился бекап базы, "как повторить", скриншоты - к публичной баге все это уже не приложишь.

2) На каком языке вести этот публичный багтрекер ? У нас российских и иностранных клиентов - 50/50. What's new на русском и английском вперемешку мне не нравится :-)

3) История с JIRA показывает, что никто толком не знает, чего ждать после внесения баги в багтрекер. Если на e-mail не ответили в течение 24 часов, то получатель письма "наверное, умер".
Отвечать на каждый комментарий в трекере - глупо. Просто накапливать информацию и ничего не сообщать пользователям - еще хуже. Если бага висит в трекере на первом месте 3 года, то часть пользователей решит, что мы этим интенсивно занимаемся или займемся в самое ближайшее время, а другая часть - что мы этого вообще делать не будем.

Персональная лицензия TrackStudio - бесплатно

2009-07-13T10:54:35Z

В последней бете TrackStdudio 4 сделали поддержку персональных лицензий. Условия:
- полнофункциональная версия, ничего не урезано
- 5 активных пользователей
- бесплатно для частного и коммерческого использования
- саппорт и апгрейды бесплатно

Логин/регистрация для скачивания тут:
http://host.trackstudio.com/DownloadManager/jsp/login/Login.jsp

Про планирование работ

2009-05-24T20:03:13Z

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

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

Получается, что на самом деле у нас отношение 2-х случайных величин: оценок объема работ (например, строчек кода) и оценок производительности разработчика (сколько он может выдать строчек кода такой сложности в час). Отношение 2-х нормально-распределенных случайных величин характеризуется уже не нормальным распределением, а распределением Коши, которое похоже на графике, но имеет ряд существенных особенностей:
- для распределения Коши нет математического ожидания
- дисперсия равна бесконечности (возрастает с увеличением объема выборки).

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

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

А теперь вопрос - как решается эта проблема в методиках типа PERT ? Судя по тому что я читал, там просто обрабатываются оценки времени выполнения каждой подзадачи, а в итоге получается вероятность реального выполнения проекта к заданному времени. Evidence-Based Scheduling - из той же оперы.

Где ошибка ?

История про документацию

2009-05-03T15:15:39Z

http://gaperton.livejournal.com/32772.html

Очень перекликается с нашей ситуацией, особенно с этой
http://maximkr.livejournal.com/14109.html
и этой
http://maximkr.livejournal.com/12147.html
историями.

Может это судьба всех более-менее больших проектов ?

Раздача халявы

2009-04-24T12:38:25Z

Вопрос к разработчикам ПО: приходилось ли вам раздавать ПО нахаляву (бесплатные ограниченные, но функциональные версии, ограниченные по времени акции и т.п.), для достижения каких целей это делалось, были ли эти цели достигнуты ?

Украина

2009-04-14T20:15:54Z

Уже раза 3 видел комментарии клиентов, которые считают что мы украинская компания. Почему, интересно...

Кризис-2

2009-01-28T06:25:52Z

В продолжение http://maximkr.livejournal.com/15803.html

Был бы Васей - купил бы еврооблигаций. А сам я ограничился тем, что снял деньги с расчетного счета конторы в Связь-Банке и купил на них облигаций этого же банка, по ним сейчас около 50% годовых (в рублях).

В итоге риск примерно тот же, проценты больше и снять/доложить можно в любое время все сразу или частями.

До этого облигации КИТ Финанса держал с примерно теми же процентами, по ним погашение в конце 2008 года было.

ACH Account

2009-01-27T13:54:48Z

Регистратор предлагает за $100/год виртуальный ACH account для приема платежей без доп. комиссии, определиться нужно до конца месяца.

Коллеги, подскажите, зачем оно может быть нужно ? Можно ли через ACH принимать платежи от европейцев ? Насколько такие платежи сложны/удобны клиентам, многие ли захотят перевести через ACH вместо карточки ?

В общем нужны идеи полезного применения данной фичи. С одной стороны, оно окупится с 1 продажи. С другой стороны, у меня еще никто не просил заплатить через ACH.

Кризис

2008-10-02T21:32:26Z

Пусть некто Василий П., коренной москвич и менеджер звена чуть выше среднего купил несколько лет назад "инвестиционную" однушку на окраине Москвы, дождался нынешнего кризиса и вчера успешно продал квартиру за 250 тысяч долларов. Что с деньгами делать ?

Купить другую недвижимость ? Какую и зачем ?
Купить машину ? Какую ? На разумные модели много денег не потратишь, на дорогие - замучаешься страховку платить (а у нашего героя много наличных денег, но относительно небольшой постоянный доход).
Хранить дома наличными ? В какой валюте ?
В банк под проценты ? Там сейчас не спокойно, а на такую сумму страхование вкладов не распространяется.
Акции ? Колбасит не меньше.
Мелкая бытовая техника и прочие шубы ? Уже все давно есть.
Быстро проесть 250 штук ? Печень может не выдержать.
Свалить из страны ? Еще не известно, где кризис больнее ударит.

Ну т.е. получается странная ситуация, когда до яхт с вертолетами наш герой еще не дотягивает, а машины и прочие радости ему уже не интересны. Что бы вы делали в такой ситуации ?

Частая смена работы в Москве - хорошо или плохо ?

2008-09-25T19:31:29Z

Один мой знакомый написал вот такое:
---
В Москве принято каждые 2 года менять работу, каждые 5-8 лет - сферу деятельности. Имхо, это правильно. Человек, проработавший 10 лет в одном месте - уже подозрителен... Я например, жалею что засиделся на одной теме на целых 7 лет (правда, последние ~3 года сидел на ней уже очень условно т.к. основное время тратил и основной доход извлекал из других занятий). Первые 2 года очень перло и был большой прогресс, а потом все - стабилизец.
---
Знакомый вообще склонен к преувеличениям и эпотажу, но насколько он прав в целом ? Т.е. работа 5+ лет на одном месте - это хорошо, плохо или подозрительно ? :-)

Небольшие извращения на тему домашнего компа или устанавливаем Sun Fire X4150 дома

2008-09-22T07:08:27Z

У меня уже лет 10 не было домашнего десктопа, а в последнее время стал нужен - поиграться с линуксом и виртуализацией, потестировать TrackStudio на больших объемах данных. В общем, для экспериментов. Сначала дома по стечению ряда обстоятельств поселился X4150 в довольно базовой конфигурации. Я догадывался, что сервера в стоечном корпусе довольно плохо приспособлены для дома, но от меня тут мало что зависело и оставалось только преодолевать трудности по мере их возникновения. С данным сервером возникли такие проблемы:

заказ всей комплектухи - из Штатов через дистрибьюторов. Во-первых, от заказа до получения проходит около месяца. Во-вторых, дистрибьюторы обычно работают с оптовыми покупателями, а мне нужен был разовый апгрейд сервера. OCS очень бодро взялись, но потом куда-то резко пропали, а вот через verysell удалось купить 2 x Xeon L5420 и еще 16 гигов памяти, за что им огромное спасибо. Даже не знаю что делал бы, если бы они отказались...
в сервере стоит 15 маленьких вентиляторов, гудит он чуть тише пылесоса, напрягает даже в соседней комнате за закрытой дверью. А мне нужно было в этой комнате работать :-) Вытаскивал "лишние" вентиляторы - оставшиеся начинают крутится еще быстрее и шума еще больше, не вариант. Пробовал снять с вентиляторов лишние решетки (как кое-где советуют) - гудеть стал заметно громче. В итоге нашел какую-то научную статью с кучей графиков и формул, в которой авторы пишут, что если вот на такие вентиляторы поставить их хитрый патентованный диффузор, то сервер начинает шуметь на 5 дБ меньше и на 6% меньше жрет электричества. Стало понятно, что с вентиляторами мудрить бесполезно. Были даже мысли поставить сервер в каком-нибудь местном датацентре, но у них цены на траффик совершено нереальные.
он занимает слишком много места, держать на столе нельзя. "Обычная" стойка не решает проблему с шумом, а шумоизолирующая может запросто стоить несколько тысяч долларов, причем поставщиков таких железок в России найти не удалось (хотя, зная о цене, не очень-то и пытался).

В итоге сделал шумоизолирующую "стойку" сам :-) Каркас - 50 уголок на 8 и 10 болтах. Внутренняя поверхность ящика из перфорированного листа кровельного железа (перфорацию делал сам, готовые у нас, похоже, не продаются), закрытого спанбондом, внешняя - тоже кровельное железо, но уже без перфорации. Между внешней и внутренней поверхностью - маты из стекловаты. К вертикальным стойкам прикрутил рельсы, так что при необходимости сервер можно вытащить и засунуть обратно.

Выглядит это все вот так:

Пара комментариев к фоткам:
- большой черный мат со стекловатой на переднем плане второй фотки обычно стоит впереди сервера, на вентиляцию практически не влияет, а шум снижает существенно.
- коробка сверху - это шумоизоляционный ящик для UPS-а в виде обычного ящика для электрооборудования со стекловатой, проклеенной поролоном и фольгой. Без ящика UPS громко гудит и легко заглушает сервер в ящике :-)
- весит ящик (пустой) около 25 кг, времени на него ушло часов 15, материалы стоили около 1000 руб. Правда, пришлось купить вырубные ножницы по металлу, кроить листовой металл вручную или лобзиком мне совершенно не понравилось.

Итого: cервер в этом ящике слышно, но бук у меня гудит громче. Пару раз ловил себя на том, что вырубал UPS забыв выключить сервер - без ящика забыть о сервере было просто не реально :-) Температура тоже в норме. Cейчас знаю, как можно было сделать лучше и эстетичнее, но проблема в целом решена и времени/желания переделывать пока нет.

Про OEM

2008-08-03T20:03:02Z

По ходу работы приходилось несколько раз подписывать OEM соглашения, пару раз даже чуть сами не стали чужой софт распространять по OEM соглашению. Всегда суть этих договоров была такой: OEM партнер платит заранее большие деньги, за что получает скидку на последующие покупки нашего продукта и фиксированную цену (как вариант - можно увеличивать не больше чем на X процентов в год). Чем больше денег партнер платит при заключении договора - тем больше скидка.
Но сегодня у одной известной компании обнаружил довольно странное OEM-соглашение, причем размеры/известность компании не позволяют подозревать их в неадекватности.

Условия:

первоначального фиксированного платежа нет, партнер должен просто сразу купить X OEM-лицензий.

скидок на приобретаемые продукты нет. Наоборот, OEM партнеру они достаются в 2 раза дороже максимальной цены. Т.е. если для обычного пользователя самая дорогая версия продукта стоит 5 тысяч, то OEM партнер сможет купить ее для перепродажи минимум за 10.

если партнер продает свой продукт дороже какой-то фиксированной цены (скажем, дороже 30 тысяч), то вендор начинает хотеть половину. Т.е. если продукт ценой в 5 тысяч партнер включил в свой продукт и продал его за 50 тысяч, то он должен даже не 10 тысяч (цена*2), а 25.

саппортом конечных пользователей OEM-партнер занимается сам, минорные апгреды - бесплатно.

никаких гарантий цен нет, т.е. соглашение заключается на год, а через год цены могут стать другими.

В чем смысл этой бизнес-модели ? Какого рода компания может быть этим OEM-партнером ?

Публичный список клиентов

2008-07-20T13:50:18Z

Хочу вывесить на trackstudio.ru список наиболее крупных клиентов - их с 2001 года накопилось уже довольно много, среди них много очень известных компаний, особенно иностранных. Но до прошлого года в договоре/лицензионном соглашении пункта о возможности публикации названия компании-клиента не было, это просто никак не оговаривалось.

Посему вопрос: есть ли какие-то общепринятые правила по этому поводу или вопрос нужно согласовывать с каждым клиентом отдельно ?

Почему у нас нет Live Demo или немного об истории TrackStudio

2008-05-11T21:01:00Z

У нас частенько спрашивают, почему у нас нет Live Demo, иногда даже указывают на отсутствие Live Demo как на недостаток TrackStudio. Тогда почему нет и, может быть, стоит сделать? Скажу сразу, технических проблем с Live Demo нет - ведь мы начинали как hosted issue tracker, так что live demo у нас появилась даже на год раньше первой "скачиваемой" версии.

Обычно компании делают Live Demo чтобы клиенты могли быстро ознакомиться с продуктом и решить, нужно ли его скачивать/инсталлировать. При этом в некоторых компаниях (fogbugz, rmtrack) каждому демо-пользователю заводится отдельный экземпляр системы и его можно полностью администрировать, а в других (Atlassian Jira) пользователь может лишь "поиграться" с общим экземпляром с точки зрения обычного пользователя - чтоб ничего не испортил :-)

Оба варианта плохие:

в первом случае мы имеем большие проблемы с нагрузкой на сервера и администрированием. Легко подсчитать, что даже если каждый день на live demo регистрируется 30 человек (реально - значительно больше) и учетные записи действительны в течение 45 дней (как у FogBugz), то через 45 дней у нас будет 45*30=1350 экземпляров системы и столько же экземпляров БД. Как с этим справляются разработчики этих систем - понятия не имею, но мне идея держать одновременно 1000+ экземпляров системы в памяти, бекапить и апгрейдить их кажется довольно сложной задачей.

во втором случае для разработчиков все сильно упрощается, но пользователи не могут почти ничего, как-то поменять "свою" конфигурацию нельзя.

Если взять hosted-багтрекеры - там ситуация аналогичная: либо для каждой компании отдельный экземпляр со всеми возможностями конфигурирования за большие деньги (ведь масштабируется этот подход плохо), либо большое количество пользователей делят один и тот же экземпляр и конфигурацию задешево. Когда мы начинали писать TrackStudio, то именно на эту проблему и нацелились: мы хотели создать систему, в единственном экземпляре которой тысячи команд разработчиков из разных компаний могли бы работать независимо, при этом все должно было работать на одном сервере, а с администрированием такой системы должен был справиться один человек на part time :-) Тогда (2001 год) эта идея "не пошла" по разным причинам, но продукт остался и разделился на TrackStudio Host и "скачиваемый" TrackStudio Enterprise.

Как оказалось, для многих компаний проблема специфического конфигурирования багтрекера под каждую внутреннюю команду или крупного внешнего клиента весьма актуальна. Ведь обычно как бывает: разработчики багтрекера пишут, что поддерживают конфигурируемые категории/процессы. При этом отконфигурировать-то можно, но если в таком проекте нужна одна конфигурация, а в этом - другая, то нельзя. Многие поддерживают настраиваемые группы пользователей, но добавить еще одну группу пользователей именно для данного конкретного клиента - уже нельзя. Многие поддерживают настраиваемые шаблоны e-mail оповещений, но посылать разные уведомления разработчикам, менеджерам и клиентам опять нельзя.

Чтобы получить примерный список, что пользователи хотят настраивать для каждого проекта, пользователя или баги, наберите в jira.atlassian.com в строке поиска фразы типы "per project" (204 баги), "per user" (87 багов) или "per issue" (86 багов). Задним числом исправлять эти проблемы для разработчиков багтрекеров весьма сложно (см переписку по JRA-1602), а для пользователей - практически невозможно (даже при наличии плагинов и исходников). В такой ситуации пользователи обычно плодят экземпляры системы с индивидуальными конфигурациями, становятся важными клиентами и сурово мучаются с администрированием. Ситуация до смешного доходила - разработчики Seapine TestTrack в white paper гордились одним своим крупным клиентом, который на 200 пользователей и 20 проектов завел 60(!) экземпляров TestTrack.

В общем дело кончилось тем, что мы эту проблему решили, но TrackStudio стала не "просто багтрекером", а чем-то вроде виртуальной машины для багтрекеров (аналогично vmware или даже virtuozzo для операционных систем) - в рамках TrackStudio множество команд могут гонять самые разные процессы, при этом настройки конкретного процесса - это просто настройки, они не так интересны, и это не самое главное. Но как сделать Live Demo такой системы ?

можно сделать простую и понятную конфигурацию TrackStudio и давать доступ в Live Demo к ней с точки зрения админа. Собственно, в таком виде у нас Live Demo и существовала длительное время, но у пользователей было массовое непонимание относительно возможностей и ограничений такой Live Demo по сравнению с полной версией. В итоге нам надоело отвечать на вопросы типа "а в полной версии можно будет поменять имя корневого проекта?", "а почему номера задач такие большие ?", "а я пользователя с логином john создать не могу, хотя в системе такого нету".

можно сделать простую конфигурацию и давать к ней доступ в режиме пользователя, но работа в таком режиме не демонстрирует практически ничего.

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

Что бы вы стали показывать в live demo vmware, если бы такая была ? У меня хороших идей нет:

если просто доступ к одной из виртуальных windows - это никому не интересно, обычная операционка со странными драйверами - что там смотреть ?

если доступ к админскому интерфейсу, то проще скачать триал локально, чем ставить windows по internet-у через этот админский интерфейс.

И, самое главное: чтобы потенциальный клиент стал настоящим клиентом, он все равно должен будет скачать TrackStudio и настроить ее локально. Чем меньше времени у клиента уйдет на игры с live demo - тем быстрее он получит работающую систему. Зачем ему мешать ?

Корпоративные wiki

2008-04-13T20:55:22Z

Скажу сразу - идея использования wiki в качестве корпоративного хранилища знаний, вроде локальной wikipedia, мне давно и активно не нравится. Но так как сейчас использование wiki в таком качестве набирает популярность, то приходится рассказывать про негативные стороны этой затеи не только клиентам, но даже нашим сотрудникам.

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

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

Но ведь в корпоративных wiki никто не собирается хранить историю развития компании или биографию руководителей - это средство позиционируется для документирования проектов/продуктов, которые сейчас находятся в разработке/работе и постоянно меняются. Т.е. я могу написать детальную статью про то, как у нас работает генератор отчетов, но кто будет ее править при каждом изменении подсистемы кеширования или форматов вывода даты/времени ? Меня периодически ставит в тупик куда более простая задача - вот мы тут чуть подправили это, что теперь нужно перетестировать и какие скриншоты переснимать. Если я не знаю всю документацию и все скриншоты - я эту задачу решу только полным перебором, а если знаю - зачем мне wiki ?

По опыту работы: если разработчик что-то меняет в TrackStudio 3.5, то хорошо, если он аналогичную правку и в 4.0 сразу и правильно сделает. Про то, чтоб проверить пользовательскую документацию (а вдруг у нас там какой-нибудь скрипт из примеров отвалится) или перечитывать документы в духе "а как у нас генератор отчетов работает" и речи не идет. Если программист про существование описания работы генератора отчетов не знает - он его и проверять не полезет. После наступания пару раз на грабли типа "в wiki одно, а в коде - совсем другое" доверие к документации резко падает, ее даже читать перестают, не то что писать.

Второй важный момент: когда пишется документация, то важно понимать для кого именно она пишется, и как он ее будет использовать. Статьи энциклопедического плана ("как работает генератор отчетов", "как настроен Subversion", "что означают кнопки на странице Task") тут не годятся - нужны статьи, описывающие _действия_ конкретных людей в конкретных ситуациях ("как написать еще один отчет", "как вытащить исходник из subversion", "как создать/удалить задачу").

У нас есть один замечательный документ 2000 года под названием "Как у нас устроен CVS репозитарий" в котором на 3-х страницах описано на каких серверах что запущено, в какие конфиги что прописывалось при настройке, и как оно все работает. Теоретически, дока была бы полезна для админа, который настроил CVS, после этого отформатировал диск и хочет повторить процесс :-)
У нас такого админа не нашлось, мы уже года 3 назад переехали на Subversion, а про наличие этой доки вспомнили буквально несколько месяцев назад во время ревизии документации. Почему о ней все забыли ? Да никому не интересно, как у нас устроен CVS репозитарий, хотя пошаговые инструкции "как подключится к нашему репозитарию" и "как быстро настроить репозитарий для тестирования интеграции" были бы полезны.

Энциклопедии - это ведь развлекательная литература, они годятся для расширения кругозора, но не помогут, если нужно что-то конкретное. Скажем, та статья о микроволновках какое-то представление о них дает, почитать интересно. Но
- если я хочу купить микроволновку - мне нужна информация по производителям, характеристикам, ценам, наличии, условиям доставки.
- если я хочу собрать микроволновку - мне нужна принципиальная схема, информация о деталях и их производителях.
- если я хочу приготовить что-то в микроволновке - мне нужны рецепты.
и т.п.

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

Возвращаясь к корпоративным wiki, я не вижу их преимуществ перед CMS (типа Drupal) или ECM (типа Alfresco). Больше всего мне не нравится дураций язык разметки, совсем обычным пользователям понятнее Word, а IT-шникам - подмножество HTML.
Еще одна важная группа пользователей - переводчики. В большинстве своем они освоили тэгированные форматы и не пытаются переводить HTML-тэги, а системы translation memory хорошо понимают word, HTML и форматы издательских систем. Но разметку wiki практически никто не знает, софтом она не поддерживается, про зависимость форматирования от количества вставленных пробелов молчу, со времен Clarion такого "чуда" не видел.
Тогда зачем все это ?
Защита от вандалов ? Для корпоративных систем это не очень актуально.
Возможность коллективного творчества ? Практически не используется.

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

TrackStudio vs JIRA ? А может быть стоит интегрировать TrackStudio и JIRA ?

2008-03-05T10:42:38Z

Недавно мы переделали описание титульной странице на trackstudio.ru и добавили там (среди прочего) фразу "В отличие от Atlassian JIRA, оптимизированной для работы с внешними клиентами, TrackStudio позволяет эффективно организовать работу внутри компании (например, обработку обращений клиентов)." На самом деле это и есть главное отличие между TrackStudio и JIRA, у него исторические корни: основатели Atlassian до создания JIRA имели большой опыт работы в open source проектах (opensymphony) с большим количеством пользователей и неформальными внутренними процессами, а мы больше занимались заказной разработкой, где внутренних сотрудников с разными ролями и правами хватает, но вот с конечными пользователями общались не часто.

А уж все остальное следует отсюда:

JIRA проявляет себя с лучшей стороны именно в качестве продвинутого форума. Т.е. если мы на форуме сообщаем, что бага будет исправлена в 3.5.x, публикуем список изменений в 3.5.20 или план работ на следующую версию, спрашиваем, что клиентам хотелось бы видеть в следующих версиях - мы именно общаемся с клиентами, а не планируем. И Atlassian использует JIRA именно для общения с клиентами, для организации внутренней работы у них довольно необычный процесс, который описан тут:
http://maximkr.livejournal.com/8942.html
Грабли же начинаются, когда их клиенты пытаются использовать JIRA для внутренней разработки или (что еще хуже) для внутренней разработки и общения с клиентами одновременно. Если глянуть 50 их наиболее серьезных нерешенных проблем, то практически все они относятся к попыткам использовать JIRA для внутренней разработки:
- сокрытие полей нужно именно для сокрытия внутренней информации (которой там вообще быть не должно) от клиентов
- подзадачи нужны для организации внутренней работы, клиенты обычно не готовы вникать в глубокие иерархии и как там все расположено
- проблемы с учетом рабочего времени - аналогично, клиенты не учитывают свое рабочее время, это актуально только для внутренних работников
- пользовательские поля для проектов и компонентов, хранение вложений к проектам - аналогично, для общения с пользователями это не нужно, потому и не было вовремя сделано. У меня, например, никогда не возникало желание прилепить к форуму "TrackStudio Support" вложение с описанием TrackStudio :-)

Аналогично, вещи нужные для общения с клиентами (голосование, RSS, анонимный доступ к базе, генерация "что нового?" и т.п.) были сделаны в самых первых версиях JIRA, жалоб на них мало.

В TrackStudio ситуация обратная: еще в первых версиях была сделана функциональность, важная для управления работами внутри компании (иерархия всего и пользовательские поля для всего, ограничение доступа к полям, очень гибкий учет времени), а вот голосований, анонимного доступа к базе (без регистрации) или генерации "что нового?" в пригодном для публикации на сайте виде нет до сих пор.

Впервые мы с этой принципиальной разницей столкнулись несколько лет назад, когда пытались забесплатно раздавать TrackStudio open source проектам. Оказалось, что анонимный доступ к базе и багзилла-подобный интерфейс для них просто критически важная вещь, а вот поддержка сложных процессов или ограничение доступа к данным не нужны совершенно - процессы очень простые, а данные открыты всем. Т.к. для коммерческих организаций приоритеты обычно прямо противоположные, то мы на идею продвижения TrackStudio в open source быстро забили, хотя рекламные возможности тут просто огромные. По той же причине JIRA так плохо выглядит в сравнении http://www.trackstudio.ru/products-comparison.html - это повылезали проблемы корпоративных пользователей, попавшихся на слова "issue tracking" и "project management" в описании продукта. Де-факто это не целевая аудитория Atlassian, а задним числом можно исправить далеко не все, даже если очень захотеть (JRA-1330).

Может быть, вместо TrackStudio vs JIRA стоит попробовать интегрировать продукты: JIRA как frontend и TrackStudio как backend ? Ведь bug report и change request все равно должны быть разными сущностями и линковаться между собой (м.б. через permanent URL?), пользователи там и там будут существенно разные (в JIRA - клиенты и саппорт, в TrackStudio - саппорт и разработчики), типы задач/процессы - вообще не пересекаются. Имеет это какой-то смысл ?

О Java IDE и маркетинге

2008-03-04T10:36:53Z

Маркетинг советует при позиционировании продуктов выбирать какую-то целевую аудиторию и описывать не столько свойства продукта (features), сколько выгоды для целевого клиента (benefits) - клиент не всегда может понять, какие преимущества дает та или иная особенность, даже если продукт в целом ему знаком. Скажем, дрель видели все, но вот объяснить для каких целей нужны "2 скорости (хотя и не синхронизированные), БЗП, константная электроника, муфта расцепления" (цитата из прайса) - задача гораздо сложнее.

Посмотрел сейчас с этой точки зрения на сайты 3-х ведущих Java IDE: Eclipse/IDEA/NetBeans. Ключевые цитаты:

Eclipse: Eclipse is an open source community whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. A large and vibrant ecosystem of major technology vendors, innovative start-ups, universities, research institutions and individuals extend, complement and support the Eclipse platform.
IDEA: IntelliJ IDEA is an intelligent Java IDE intensely focused on developer productivity. Our code editor is consistently called the best in the industry, and we support all the major languages and technologies with your productivity and teamwork in mind.
NetBeans: The only IDE you need! Runs on Windows, Linux, Mac OS X and Solaris. NetBeans IDE is open-source and free.

Из описания IDEA можно понять, что эту IDE стоит выбирать продвинутым разработчикам, которые используют самые новомодные framework-и. Из описания Eclipse даже сложно понять, что это именно IDE, а не что-то еще. Описание Netbeans - вообще "ниачем", мне не нужно запускать IDE на 4-х ОС, и я не вижу в этом ничего полезного/уникального для себя.

Но ведь из трех продуктов не могут быть все три лидирующими и пытаться охватить всех разработчиков. Почему тогда не видно специализации (например, J2ME, web-разработка, desktop, индивидуальные разработчики, etc) ? Чем отличается типичный пользователь разных IDE и в каком случае я должен выбрать IDE X ?

Кто на самом деле пишет open source

2008-02-27T18:36:06Z

На it4business недавно была дискуссия по поводу коммерческих и open source багтрекеров. Я там писал, что open source разработчиках без стоящей за ними компании очень трудно новый продукт из-за "лебедь, рак и щука" среди разработчиков: вместо реализации идей и концепций получается реализация 300 новых фич, которые быстро губят продукт. Наиболее успешно open source работает в случае реализации стандартов (XML) или копировании какого-то другого продукта (разные вариации на тему Photoshop и MS Project).

А тут сегодня наткнулся на статью, в которой описано кто делает ядро linux. Цитирую:
===
Morton noted that “People’s stereotype [of the typical Linux developer] is of a male computer geek working in his basement writing code in his spare time, purely for the love of his craft. Such people were a significant force up until about five years ago ...” but contributions from such enthusiasts, “is waning... Instead, most Linux kernel code is now generated by corporate programmers.” Morton noted that “About 1,000 developers contribute changes to Linux on a regular basis... Of those 1,000 developers, about 100 are paid to work on Linux by their employers. And those 100 have contributed about 37,000 of the last 38,000 changes made to the operating system.” The article later notes “Even though anyone can submit changes, rarely does good code come from just anyone. Morton noted that it is rare that a significant change would be submitted from someone who is completely unknown to the core developers. And all submitted code is inspected by other members of the group, so it is unlikely some malicious function may be secretly embedded in Linux... Far from being a project with a vast numbers of contributors, about half of those 37,000 changes are made by core developer team of about 20 individuals, Morton said.”
===

Если коротко, то из 38.000 последних изменений 37.000 были сделаны всего сотней разработчиков, чья работа над Linux оплачивается работодателями. Половина из этих 37.000 изменений были сделаны командой всего из 20 человек.

Вот тебе и open source, и цена помощи разработчиков со всего мира: 20 человек на зарплате делают в 15 раз больше, чем вся open source community в одном из самых популярных проектов.

Багтрекеры, ссылки на 186 систем :)

2008-02-04T17:27:22Z

Нашел тут, отсортировал, удалил дубликаты и некоторые мертвые линки:

http://abuky.sunsite.dk/index.html
http://project-management-software.celoxis.com/
http://roundup.sourceforge.net/
http://samba.org/jitterbug/
http://scarab.tigris.org/
http://sourceforge.net/projects/bits/
http://sourceforge.net/projects/btnet/
http://sourceforge.net/projects/bugfree/
http://sourceforge.net/projects/bugs-bug-genie/
http://sourceforge.net/projects/bugsonline/
http://sourceforge.net/projects/hipergate/
http://sourceforge.net/projects/itracker
http://sourceforge.net/projects/kennwhite/
http://sourceforge.net/projects/mytracker/
http://sourceforge.net/projects/opinionplugin/
http://sourceforge.net/projects/projectbench/
http://sourceforge.net/projects/sitehelm/
http://sourceforge.net/projects/trackplus/
http://sourceforge.net/projects/zentrack/
http://taskey.com/
http://www.123bugtracking.com/
http://www.accurev.com/
http://www.aceproject.com/
http://www.adminitrack.com/
http://www.agileedge.com/
http://www.agstools.com/
http://www.alceatech.com/bugtrack/
http://www.aldon.com/
http://www.atlassian.com/
http://www.attrib.com/
http://www.avensoft.com/
http://www.axiossystems.com/
http://www.axosoft.com/
http://www.benham.net/debbugs/
http://www.berthume.com/
http://www.bestpractical.com
http://www.borderwave.com/
http://www.bruender.de/
http://www.bug-a-boo.org/
http://www.bugappliance.org/
http://www.bugaware.com/
http://www.bugbox.biz/
http://www.bugcentral.com/
http://www.bugcollector.com/
http://www.bug-defect-tracking-expert.com/
http://www.bughost.com/
http://www.bugimpact.com/
http://www.bugmonitor.com/
http://www.bugopolis.com/
http://www.bugroster.com/
http://www.bugsmanager.com/
http://www.bug-track.com/
http://www.bug-tracker-software.com/
http://www.bugtracking.com/
http://www.bug-tracking-guidelines.com/
http://www.bug-tracking-software.com/
http://www.bugvault.com/
http://www.bugvisor.com/
http://www.bugzilla.org/
http://www.compuware.com/products/trackrecord.htm
http://www.countersoft.com/
http://www.cowsultants.com/
http://www.cpts.com/
http://www.crimsonlink.com/
http://www.customerexpressions.com/
http://www.defectagent.com/
http://www.defecttracker.com/
http://www.defecttrackingsoftwareguide.com/
http://www.defectx.com/
http://www.desertware.com/
http://www.developersdex.com/vb/?p=1168
http://www.developwise.com/
http://www.devhound.com/
http://www.easybugtracker.com/
http://www.ebugtrack.com/
http://www.eden.com/
http://www.edenbt.com/
http://www.elementool.com/
http://www.elsitech.com/
http://www.excelsoftware.com/
http://www.exdesk.com/
http://www.extraview.com
http://www.fastbugtrack.com/
http://www.fesoft.com/bugcrack/
http://www.fogcreek.com/
http://www.fox.se/
http://www.frontzone.com/
http://www.geniesys.net/
http://www.gnu.org/software/gnats/
http://www.helis.org/
http://www.helpdesksoftwarecentral.com/
http://www.ic-soft.com/
http://www.intasoft.net/
http://www.issuebridge.com/
http://www.issuetech.com/
http://www.issuetrak.com/
http://www.issueview.com/
http://www.keboproject.com/
http://www.kemma.com/
http://www.lifecycletool.com
http://www.litwindow.com/buglister/?hk
http://www.logicsoftware.net/
http://www.logigear.com/
http://www.lynksoftware.com/
http://www.mantisbt.org/
http://www.math.duke.edu/~yu/wreq/
http://www.mccabe.com/
http://www.meadowdance.org/
http://www.metaquest.com/
http://www.mybugreport.com/
http://www.nesbitt.com/
http://www.neuma.com/
http://www.newatlanta.com/
http://www.newfire.com/
http://www.novosys.de/Buggy/Buggy.html
http://www.officeclip.com/
http://www.omninet.de/
http://www.ozibug.com/
http://www.pandawave.com/
http://www.pb-sys.com/
http://www.pcl-online.org/
http://www.pikoni.com/
http://www.plus-one.com/
http://www.pointinsight.com/
http://www.pragmaticsw.com/
http://www.prev.co.uk/
http://www.problemtracker.com/
http://www.profault.com/
http://www.projectinsight.net/
http://www.projectlocker.com/
http://www.projistics.com/
http://www.projxpert.com/
http://www.prostyle.com/
http://www.prtracker.com/
http://www.ptlogica.com/
http://www.rallydev.com/
http://www.red-gate.com/bug_tracking.htm
http://www.retisoft.com/
http://www.rmtrack.com/
http://www.rti-software.com/
http://www.scopetrakker.com/
http://www.seapine.com/
http://www.segue.com/
http://www.serena.com/
http://www.sesame.com/
http://www.skyeytech.com/bugtrack/
http://www.smartworks.us
http://www.soffront.com
http://www.softwareplanner.com/
http://www.software-testers.com/
http://www.softwarewithbrains.com/
http://www.solidgraphics.com/
http://www.sourceaction.com/
http://www.sparta-systems.com/
http://www.speedev.com/
http://www.sqatester.com/bugtracking/
http://www.squishlist.com/
http://www.stagsoftware.com/
http://www.taskcomplete.com/
http://www.taskland.com/
http://www.taskperfect.com/
http://www.teamatic.com/
http://www.techexcel.com/
http://www.testedok.com/bip/
http://www.thinmind.com/
http://www.threerock.com/
http://www.tierasoft.com/
http://www.tortuga.com.au/
http://www.t-plan.co.uk/
http://www.trackersuite.com/
http://www.trackplus.org/
http://www.trackstudio.com/
http://www.tuppas.com
http://www.ultraapps.com/index.html
http://www.unipress.com/
http://www.veronasystems.com/
http://www.visible.com/
http://www.vsoftdev.com/itemx/pc/itemaction_bugtracking.asp
http://www.webasyst.net/
http://www.websina.com/
http://www.woodpecker-it.com/
http://www.work-tracking.net/
http://www.ykap.com/
http://www.zambit.com/
http://www-306.ibm.com/software/awdtools/clearcase/cclt/features/index.html
https://www.e-spot.biz/

maximkr @ 2008-01-30T16:39:00

2008-01-30T13:44:48Z

В последнее время стало популярным занятием разработка "платформ" и стимулирование внешних разработчиков на написание плагинов. Eclipse целиком построен как платформа для плагинов, JetBrains и Atlassian не так давно проводили конкурсы разработчиков плагинов. Это единственный способ создания "целостного продукта" для массового рынка или есть альтернативы ?

Пара примеров:

в своем сравнении с TrackStudio Atlassian упоминает плагины дважды.
Jon Silvers из Atlassian упоминает о плагинах и их важности для создания экосистемы с "своим" продуктом в центре (т.е. платформы).

Но мы никогда не пытались сделать TrackStudio платформой. Наоборот, мы хотели сделать "маленький кирпичик", который бы умел очень хорошо делать issue tracking без всякой лишней функциональности типа wiki, forum, kb, CMS, ECM и умел бы интегрироваться с другими системами через SOAP API.

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

Но если массовый клиент не готов сам заниматься интегрированием, то как ему помочь ? Делать из TrackStudio платформу уже поздно, да и не хочется:

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

Пока идей 3:

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

Как тут лучше поступить - не знаю пока, думаю.

Сравнение TrackStudio и JIRA - обновление

2008-01-27T23:01:08Z

Только что обновил вот этот пост в связи с обновлением и переездом в другое место сравнения TrackStudio и JIRA от Atlassian.

Perl и Bugzilla

2008-01-11T06:55:30Z

Нашел вот такой интересный пост о проблемах разработчиков с поддержкой/развитием Bugzilla. Коротко идею можно выразить так: "Главная проблема bugzilla - она написана на Perl, имеет смысл переписать ее на каком-нибудь другом языке".

По-моему, переписывание Bugzilla на чем угодно - верная смерть проекта (или просто новый проект, не имеющий к старой bugzilla никакого отношения). Я понимаю, как их достал Perl, но проблемы bugzilla этим далеко не ограничиваются, делать тоже самое на другом языке сейчас уже никакого смысла нет: вряд ли результат будет лучше JIRA, которая и есть результат шестилетнего развития bugzilla, переписанной на Java.

Реляционные СУБД и TrackStudio

2007-12-13T15:39:27Z

kranov пишет, что наш способ хранения длинных строк в СУБД (с разбиением строк на кусочки и сборкой через SQL при необходимости) есть кривизна и об этом стоит помалкивать, а не рассказывать как о преимуществе TrackStudio при сравнении с JIRA:

"как говорит товарищ томзмей "вы заплатили деньги за субд, надо пользоваться ее возможностями".
В общем не знаю ваших мотивов изобретения велосипеда с семью квадратными колесами, но я бы на вашем месте не расписывал этот момент."

Проблема тут в том, что реляционные СУБД вообще плохо подходят для написания приложений типа TrackStudio по принципиальным соображениям:

Реляционные СУБД подразумевают работу с множествами записей. Т.е. берем множество этих записей, еще вот этих, находим их пересечение, а потом вот так фильтруем и сортирует. В итоге у нас 1 сложный запрос, который возвращает 1000 записей, реляционные СУБД отлично справляются с такого рода задачами.

Есть большой класс проблем, которые плохо/неэффективно реализуются за счет операций над множествами. Разработчики реляционных СУБД не пытаются их решать, даже в нестандартных расширениях:

работа с иерархиями: как получить все подзадачи (рекурсивно) данной задачи, все вышестоящие задачи ? Из всех популярных РСУБД только в ORACLE есть start with/connect by, работающий к тому же очень медленно.

в большинстве РСУБД крайне примитивная security, часто она просто игнорируется пользователями и разработчиками приложений. Например, нельзя ограничивать доступ пользователей к данным на уровне отдельного поля или отдельной строки таблицы: нельзя запретить пользователю A редактировать имя директора компании Б.

Решение обоих этих проблем (внутри СУБД или во внешних приложениях) требует другого паттерна доступа к данным: вместо обработки больших множеств нужна быстрая навигация по данным и быстрая обработка простых запросов. Большинство РСУБД делают то и другое крайне неэффективно.

Неадекватность реляционной модели для решения этих задач не позволяет решить эти задачи в рамках самой СУБД и означает невозможность решить эти задачи в рамках приложения, опирающегося на СУБД. Тут не помогает атомарности транзакций или поддержка гигабайтов данных - без кеша уровня приложения РСУБД за десятки тысяч долларов жутко тормозят на объемах, с которыми легко справляется Excel. А если мы начинаем делать кеш приложения - нам самим нужно думать о параллельном доступе к этому кешу, о состоянии кеша после облома транзакции, о синхронизации кешей 2-х экземпляров приложения в кластере и т.п.

Вывод: невозможность нормально хранить длинные строки в ORACLE - это еще цветочки. Для решения 90% задач из JIRA most popular issues реляционные СУБД вообще не подходят и нужно реализовывать другие методы доступа к данным поверх РСУБД. То, что большинство багтрекеров имеет "плоскую" организацию и поддерживает только самые простые правила доступа - это не потому что не надо никому (практика показывает, что как раз надо), а потому что разработчики таких систем ограничены особенностями реляционной модели, а их преодоление требуют весьма значительных усилий.

Маленький пример из другой области: у кассетных магнитофонов и DVD-плееров пульты почти одинаковые, но на пульте магнитофона нет кнопок перехода к следующей/предыдущей записи. Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов, а не досадная недоработка разработчиков пульта.