В рамках проекта Watson (http://nhmood.github.io/watson-perl/) развивается инструмент, позволяющий формировать сообщения об ошибках, отчёты о проблемах, рецензии, планы на будущее и примечания не отрываясь от работы с кодом. В отличие от других систем контроля за исправлением ошибок, добавление и отслеживания состояния уведомлений производится в процессе редактирования кода в форме специальных меток-комментариев (например, добавив "// [fix] сообщение" перед проблемной строкой). Watson выявляет подобные правки и позволяет завести добавленные в коде уведомления в системах отслеживания проблем на сервисах GitHub или Bitbucket, а также синхронизировать состояние имеющихся в данных сервисах уведомлений. Код watson распространяется под лицензией MIT и доступен в реализациях на Perl (https://github.com/nhmood/watson-perl) и Ruby (https://github.com/nhmood/watson-ruby).<center><img src="http://www.opennet.me/opennews/pics_base/0_1385320813.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>
<center><img src="http://www.opennet.me/opennews/pics_base/0_1385320828.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></center>
URL: http://nhmood.github.io/watson-perl/
Новость: http://www.opennet.me/opennews/art.shtml?num=38507
Не уверен, что прямов таком виде - но идея очень правильная - не отвлекаться на 100500 окошек и сторонних инструментов, а всё делать в окне кода.
Ять, даже простенький Geany умеет показывать todo и fix вписанные в код таким макаром. Это чо, инновация? Укушенные гитхабом скрипткиидсы озверели!
Ну можно к мантису добавить привязку, суть не в этом - а в том, что это такие штуки из "тасков второго сорта" становится полноценными. И это правильно - исходник должен быть единственным источников всего, что есть в продукте - от документации до багтрекера, которые есть просто различные интерфейсы к коду.
> Не уверен, что прямов таком виде - но идея очень правильная
> — не отвлекаться на 100500 окошек и сторонних инструментов, а всё
> делать в окне кода.это всё от того, что plaintext — фигня. ну вот совсем фигня. пока документ не будет естественной частью системы (как в обероне, например) — так и останутся костыли над костылями.
Для Vim'щиков хороший плагинчик
Товарищ Сталин, что вы курите? Какой vim?
любая современная IDE показывает в отдельном окошке строки с комментами TODO/FIX/BUG/HACK. А так да, сабж для хэлловордщиков в виме полезен.
Действительно, зачем автоматизировать и делать удобным создание тасков и управление ими, давайте лучше в окошках мышкой тыкать.
Вы принципиально ответили не прочитав/не поняв предыдущего мнения?? Интересный подход.
Я как раз прочитал и понял. Суть не в показе в окошке. Суть - в том, что из этих маркировок порождаются/редактируются реальные таски. Одним росчерком, не покидая окна редактирования кода, вообще не отрывая руки от клавиатуры и не прерывая текущий процесс мышления/писания/редактирования/просмотра кода.
>Суть - в том, что из этих маркировок порождаются/редактируются реальные таски.суть в том, что из этих маркировок максимум можно только самые низкоприоритетные таски сомнительного качества (т.к. контекст кода решает).
реальные таски, типа добавить фичу или пофиксить баг, таким методом сделать/делать нельзя.>не покидая окна редактирования кода
что в этом такого хорошего?
>не отрывая руки от клавиатуры
в нормальных DE есть комбинации клавиш, в нормальных IDE есть комбинации клавиш, в нормальных IDE есть плагины для работы с issue трекерами
Если вы не знаете, куда добавить фичу - то это не фича, а богатая фантазия.Но и специальный файл под это дело завести можно. Лично я вижу огромный плюс в том, что история тасков/багов хранится вместе с кодом, не завязываясь ни на какие внешние системы.
А комбинации клавиш - это хорошо, но когда всё лежит прямо в тексте и ты видишь, что можешь зацепить, правя код - лучше.
а что делать если для новой фичи надо внести измения в 10 файлов ?:)
вы точно работали с проектами в которых больше 1 тысячи строк?
Сунуть её в отдельный файл (например - TODO), а его - в версионник.
> Сунуть её в отдельный файл (например - TODO), а его - в
> версионник.вот тебе пример :)
http://wiki.lustre.org/images/3/39/20080612165106%21Ver...подумай как много файлов затрагивает такое изменение - и куда ты его прицепишь ?:)
никто не говорит что документировать код не надо, какой-то DLD - ты в doxygen вполне можешь сделать, какие-то базовые вещи для напоминания можно тоже туда нарисовать. Но есть очень много ситаций - когда это не применимо. Ты еще предложи тест планы туда рисовать - как бы напоминаю что тест план это часть набора документов по разработке любой фичи.
> Если вы не знаете, куда добавить фичу - то это не фича,
> а богатая фантазия.кстати о фичах и фантазии - вы точно уверены что этими тэгами можно описать таску которая требует страниц 20-30 детального описания дизайна? и в какую точку кода добавлять данное описание (со всеми use cases, state flow, сценариями тестирования и тп..).. подскажите неумехам?
Уверен. Фича такая-то, см. каталог такой-то для детального описания.И в чем я точно уверен - что всё это как минимум для опенсорсного проекта должно лежать рядом с исходным кодом в версионнике. Потому что тому, кто когда-нибудь форкнет эту штуку, все эти юз кейсы и прочее rationale будут важны. В том числе - то, от чего отказались и от чего не осталось никких следов полсе переезда со второго на третий багтрекер.
> Уверен. Фича такая-то, см. каталог такой-то для детального описания.Каталог ?:)
> И в чем я точно уверен - что всё это как минимум для опенсорсного проекта должно лежать рядом с исходным кодом в версионнике. Потому что тому, кто когда-нибудь форкнет эту штуку, все эти юз кейсы и прочее rationale будут важны. В том числе - то, от чего отказались и от чего не осталось никких следов полсе переезда со второго на третий багтрекер.
почему отказались в документах не будет. Никогда :) А ситуации когда фича размазана под 40 файлам - я уже видел.
PS. doxygen вещь хорошая для низкоуровневых дизайнов - но с дизайнами верхнего уровня - она не справится.
>давайте лучше в окошках мышкой тыкатьх-спади, какое стереотипное вы однако!..
> любая современная IDE показываетДаже простой и легкий geany умеет показывать такой список. Wtf, seriously.
отличный метод превращения багтрекера в помойку
Конечно же, лучше помойка в коде, а не в багтрекере!
> Конечно же, лучше помойка в коде, а не в багтрекере!В данном случае помойка будет и там и там :P.
А почему оно не использует каноничные TODO, FIXME и XXX?
Боится лопнуть при задействовании в уже существующих проектах
Интересно, имя специально взяли похожим на Dr.Watson? http://en.wikipedia.org/wiki/Dr._Watson_(debugger)
мда. что только люди не делают, лишь бы не использовать literate programming.что характерно — в итоге получаются мегакостыли, которые превращают код в нечитаемую кашу. а многие разработчики начинают считать, что doxygen — это документация.
Ну, чистый literate programming не уверен, что применим. А так - в нужную же сторону шаг. А вот насчет доксигена - согласен. Зайдешь, глянешь - функции с классами задокументированы, а какая общая архитектура, почему так и что будет каноничным решением, а что против шерсти - только на своих шишках узнавать. как по мне - лучше бы уж наоборот. Если нормально именовать то деревья классов и IDE построит, а вот high level overview ты из неё никак не выдерешь... С другой стороны - чтобы его написать оно должно, как минимум, быть в голове у разработчика.
это ужасный шаг. это такой доксиген, только для трекера. фигня-фигня-фигня-фигня.дело в том, что задачи, которые тривиальней одной строчки, в коде описывать и замахаешься, и намусоришь изрядно. а однострочники — им место совсем в другом месте. :3 это раз.
два: в коде отсутствует ссылка на багтрекер. что делать? иди, ищи, куда и что оно там занесло.
три: в код не приходят комментарии, уточнения и ты пы. иди, ищи.
да вообще, глупость. не надо, совсем не надо использовать код в качестве хранилища всего-всего. получается свалка фигни.
и вообще: зачем столько хайпа вокруг того, что реализуется наипримитивнейшими скриптами в любом нормальном редакторе?
фу такими быть.
Скажем так - это лучше, чем когда документация в одном месте, багтрекер в другом, код в третьем. Тут хотя бы issues ходят рядом с кодом, а в [todo] можно воткнуть see issues/xxx for details.А хайпа много потому чо вроде вот оно наипримитивнейшими скриптами развивается, а по факту - нигде нет. Может, проект замутить - эдакое "всё в одном" для открытых проектов на базе гита, с формированием на основе этого дела статического сайта? Чтобы от issue tracker до генерации бинарников.
> Скажем так - это лучше, чем когда документация в одном месте, багтрекер
> в другом, код в третьем.а что поменялось-то? документация по-прежнему в одном, багтрекер в другом, код в третьем.
так здесь багтрекер генерится из кода, насколько я понимаю
> так здесь багтрекер генерится из кода, насколько я понимаюи? что потом с ним делать? иметь, пардон май фрэнч?
Видеть состояние независимо от любых внешних багтрекеров, вестимо.
> Видеть состояние независимо от любых внешних багтрекеров, вестимо.лол. чего состояние-то? ну ок, я взял код. а потом в багтрекер написал. откуда в коде возьмётся изменения состояния — это раз. и два: а если принесут — за это надо убивать.
перестань ты уже. дубовая это идея, дубовая. это то же самое, что и «приложения в браузере» — натягивание совы на глобус.
то, что связь трекеров и документации с кодом удобна — факт. то, что это невозможно нормально реализовать средствами «чистого текста» (так, чтобы и связи не ломались, и не мешали, и *удобно* редактировать можно было в любом редакторе чистого текста) — тоже факт. вот и начинают пытаться использовать инструменты не по назначению.
я уже неоднократно говорил: нужен универсальный движок «составных» документов, на том же уровне, на котором glibc живёт. и API как типа fgetc() для тех, кому неинтересно форматирование и «не-буквы», так и посложнее (в том числе с возможностью редактирования документа без переписывания всего файла) для тех, кому нужны расширеные возможности. даже эмулятор fread() можно поверх сделать, который будет тупо буквы вытаскивать.
и вот когда это появится — тогда счастье из «прекрасного далёка» переместится на расстояние протянутой руки. а до тех пор мы будем продолжать слышать из разных концов планеты вопли сов, которым в задницы пихают глобусы.
