Комментарии 9
Спасибо за подборку. UML и вправду всегда головная боль а Visio отнимает много времени на красоту и борьбу.
Хотелось бы узнать как обстоят дела со связями требований с покрытием тестами ( приемочными да и regression тоже ).
По поводу GeSHi — хороший, но к сожалению правильный разбор пока в глубокой альфе. Требует напильника в каждом конкретном случае.
Хотелось бы узнать как обстоят дела со связями требований с покрытием тестами ( приемочными да и regression тоже ).
По поводу GeSHi — хороший, но к сожалению правильный разбор пока в глубокой альфе. Требует напильника в каждом конкретном случае.
Про покрытие тестами мы пока только мечтаем. В этом плане есть некая… безсистемность.
Относительно связей — в тесткейсах (мы используем Testopia) есть специальное поле для ссылки на документ. В частности — на спецификацию. Обратных связей (спец -> тест) нет.
А как вы это делаете? Может, посоветуете где почитать?
Относительно связей — в тесткейсах (мы используем Testopia) есть специальное поле для ссылки на документ. В частности — на спецификацию. Обратных связей (спец -> тест) нет.
А как вы это делаете? Может, посоветуете где почитать?
А использовать google docs для совместной работы не пробовали?
На сколько знаю, хранится и история документов, и вставка из офиса прекрасно работает. Совместная работа реализована на «ура» (во всяком случае с таблицами, документы я совместно не редактировал).
Правда надо иметь постоянный выход в интернет.
Но и как плюс заказчик всегда может посмотреть и исправить что-либо.
Не знаю как там с диаграммами разными: не пользовался.
Да и думаю, «свое» Вы уже нашли.
На сколько знаю, хранится и история документов, и вставка из офиса прекрасно работает. Совместная работа реализована на «ура» (во всяком случае с таблицами, документы я совместно не редактировал).
Правда надо иметь постоянный выход в интернет.
Но и как плюс заказчик всегда может посмотреть и исправить что-либо.
Не знаю как там с диаграммами разными: не пользовался.
Да и думаю, «свое» Вы уже нашли.
Первая часть находится элементарно, но всё же стоит явно указать прямую ссылку на начало.
Wiki мы тоже используем активно, правда другой движок — Moin.
Но используем для обзорных статей в основном, HowTo hotlinks, некоторой метаинформации о проекте и прочее.
Крупные, сложные, структурированные документы — например, SRS/SDS документы все же пишем в Ворде.
Но используем для обзорных статей в основном, HowTo hotlinks, некоторой метаинформации о проекте и прочее.
Крупные, сложные, структурированные документы — например, SRS/SDS документы все же пишем в Ворде.
Рад видеть людей со схожими взглядами.
Пару наших соображений.
* В свое время (еще до WikEd-а) тоже прикручивал FCKEditor к MediaWiki, но потом понял, что это концептуально неверно — должен быть режим автора в WYSIWYM-парадигме, а предпросмотр результата нужен не так часто, и отдельно — т.е. вариант LaTeX-верстки, когда автор работает с текстовой разметкой, а результат регулярно просматривает отдельно в DVI-вьевером — правильный. И мы сделали специальный режим просмотра с регулярным автообновлением — отдельное окно можно просматривать на втором мониторе.
* PDFBook/Экспорт в Word — мы столкнулись, что задача не только в том, чтобы как-то вытащить контент в Word, но и реализовать всякие фишки бумажной верстки — автонумерация и целостные «бумажные» ссылки (с номерами разделов и страниц), и т.п. Мы реализовали это на HTML-представлении спецполей MSWord… Тут в общем, было бы интересно посмотреть на код — вы планируете публиковать ваши доработки?
* PlantUML — интересно. В свое время, когда я делал «подход к теме», его еще не было, MetaUML (как основанный на динозавре METAPOSTе) был отвергнут, реализован UMLGraph, но он у нас не шибко идет — реализация через Java-компиляцию с рефлексией — идиотизм, пугает людей невнятными ошибками и вообще, завязка на Java-синтаксис, с выносом всего что не ложиться туда в комментарии — тупик. Я собирался делать свой UML-язык (с блекджеком и шлюхами), видимо, на основе YAML, но слава богу не стал — похоже появилось что-то стандартное (ненавижу изобретать колесо). Просмотрел синтаксис — немного funky, так что интересует ваше мнение — реально ли PlantUML удобен? Вменяемо ли ругается при ошибках в синтаксисе? Какие основные у него минусы?
P.S. Просьба заменить PDF-ссылку (там дурацкая двухколоночная верстка по требованиям организаторов на Web-версию).
Пару наших соображений.
* В свое время (еще до WikEd-а) тоже прикручивал FCKEditor к MediaWiki, но потом понял, что это концептуально неверно — должен быть режим автора в WYSIWYM-парадигме, а предпросмотр результата нужен не так часто, и отдельно — т.е. вариант LaTeX-верстки, когда автор работает с текстовой разметкой, а результат регулярно просматривает отдельно в DVI-вьевером — правильный. И мы сделали специальный режим просмотра с регулярным автообновлением — отдельное окно можно просматривать на втором мониторе.
* PDFBook/Экспорт в Word — мы столкнулись, что задача не только в том, чтобы как-то вытащить контент в Word, но и реализовать всякие фишки бумажной верстки — автонумерация и целостные «бумажные» ссылки (с номерами разделов и страниц), и т.п. Мы реализовали это на HTML-представлении спецполей MSWord… Тут в общем, было бы интересно посмотреть на код — вы планируете публиковать ваши доработки?
* PlantUML — интересно. В свое время, когда я делал «подход к теме», его еще не было, MetaUML (как основанный на динозавре METAPOSTе) был отвергнут, реализован UMLGraph, но он у нас не шибко идет — реализация через Java-компиляцию с рефлексией — идиотизм, пугает людей невнятными ошибками и вообще, завязка на Java-синтаксис, с выносом всего что не ложиться туда в комментарии — тупик. Я собирался делать свой UML-язык (с блекджеком и шлюхами), видимо, на основе YAML, но слава богу не стал — похоже появилось что-то стандартное (ненавижу изобретать колесо). Просмотрел синтаксис — немного funky, так что интересует ваше мнение — реально ли PlantUML удобен? Вменяемо ли ругается при ошибках в синтаксисе? Какие основные у него минусы?
P.S. Просьба заменить PDF-ссылку (там дурацкая двухколоночная верстка по требованиям организаторов на Web-версию).
Ссылку поправил.
* PDFBook/Экспорт в Word — мы пока про такие «фишки» не задумывались. Сейчас у нас выгрузка в ворд решает только одну задачу — отослать заказчику спецификации, получить от него реакцию в виде комментариев в тексте.
Про публикацию наших разработок — вот пока не спросили, не задумывались. В принципе не жалко. Сегодня еще раз посмотрел на «доработанный» нами PDFBook. Оказалось, общих вещей (для PDF и DOC) там очень мало, так что имеет смысл вынести наш экспорт в ворд вообще в отдельный плагин, а PDFBook оставить оригинальный. В ближайшие дни это сделаем, и куда-нибудь выложу. Думаю, польза будет всем :)
* PlantUML — насчет удобств могу рассуждать только в сравнении с Визио. Других вариантов «текстового» описания UML не пробовал.
Удобства:
1) простой, понятный язык. Даже наглядный — всякие стрелочки, кружочки.
Поэтому легко запоминается синтаксис.
2) без формализма (фанатизма). Не надо как-то специально описывать сущности. Они создаются при появлении в тексте.
Например: Child --|> Parent
сразу нарисует два прямоугольника-класса со стрелкой-наследованием.
Неудобства:
1) прожорливость реализации. PlantUML — это ява-приложение, которое на выходе дает опять-таки текстовое описание графа, которое подается на вход Graphviz. И вся эта цепочка запускается соответственно из PHP. Поэтому страница с 4 и более диаграммами сохраняется сильно долго.
2) непредсказуемость размещения блоков диаграммы. Нет никакой возможности «подсказать», что этот класс я хочу видеть наверху, а эти три — под ним. Часто по смыслу хочется расположить их иначе, чем предлагается программой.
Сообщения об ошибках — конечно не верх информативности, но максимум раза с третьего :) найти причину можно. Просто пишется строка, где по мнению программы есть ошибка. Без подробностей.
> мы сделали специальный режим просмотра с регулярным автообновлением
Можно ли об этом поподробнее? Как это реализовано? Как выглядит?
* PDFBook/Экспорт в Word — мы пока про такие «фишки» не задумывались. Сейчас у нас выгрузка в ворд решает только одну задачу — отослать заказчику спецификации, получить от него реакцию в виде комментариев в тексте.
Про публикацию наших разработок — вот пока не спросили, не задумывались. В принципе не жалко. Сегодня еще раз посмотрел на «доработанный» нами PDFBook. Оказалось, общих вещей (для PDF и DOC) там очень мало, так что имеет смысл вынести наш экспорт в ворд вообще в отдельный плагин, а PDFBook оставить оригинальный. В ближайшие дни это сделаем, и куда-нибудь выложу. Думаю, польза будет всем :)
* PlantUML — насчет удобств могу рассуждать только в сравнении с Визио. Других вариантов «текстового» описания UML не пробовал.
Удобства:
1) простой, понятный язык. Даже наглядный — всякие стрелочки, кружочки.
Поэтому легко запоминается синтаксис.
2) без формализма (фанатизма). Не надо как-то специально описывать сущности. Они создаются при появлении в тексте.
Например: Child --|> Parent
сразу нарисует два прямоугольника-класса со стрелкой-наследованием.
Неудобства:
1) прожорливость реализации. PlantUML — это ява-приложение, которое на выходе дает опять-таки текстовое описание графа, которое подается на вход Graphviz. И вся эта цепочка запускается соответственно из PHP. Поэтому страница с 4 и более диаграммами сохраняется сильно долго.
2) непредсказуемость размещения блоков диаграммы. Нет никакой возможности «подсказать», что этот класс я хочу видеть наверху, а эти три — под ним. Часто по смыслу хочется расположить их иначе, чем предлагается программой.
Сообщения об ошибках — конечно не верх информативности, но максимум раза с третьего :) найти причину можно. Просто пишется строка, где по мнению программы есть ошибка. Без подробностей.
> мы сделали специальный режим просмотра с регулярным автообновлением
Можно ли об этом поподробнее? Как это реализовано? Как выглядит?
>Можно ли об этом поподробнее? Как это реализовано? Как выглядит?
Ну зайдите на wikisandbox.custis.ru/ попробуйте редактировать какую-нибудь статью и включите галку Автопредпросмотр — тогда она будет показывать в отдельном окне-вкладке (можно утащить ее на второй монитор), предпросмотр, соответствующий вашему текущему, еще не сохраненному, тексту.
Ну зайдите на wikisandbox.custis.ru/ попробуйте редактировать какую-нибудь статью и включите галку Автопредпросмотр — тогда она будет показывать в отдельном окне-вкладке (можно утащить ее на второй монитор), предпросмотр, соответствующий вашему текущему, еще не сохраненному, тексту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем спецификации. Часть 2. Инструменты. Вики – всё под рукой