Пользователь
0,0
рейтинг
17 октября 2009 в 01:07

Разработка → 5 причин полюбить Mylyn перевод

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

Современные среды разработки подарили множество средств для ускоренной работы, когда множество действий можно делать всего пальцем. Интеграция редакторов и компиляторов для самых разнообразных языков, средства для работы с базами данных, инструменты разработки специфичные для того или иного фреймворка, а так же многие другие являются уже привычными для нас и основаны на более мелких, но ключевых вещах. Но зачастую в момент интеграции забывают о ключевой части, о конечном пользователе – разработчике.
Созданные на сегодняшний день различные инструменты разработки, с одной стороны надежно работающие, а с другой, не грамотно встроенные в интерфейс, помогают разработчику быть более продуктивным. Тем не менее, с ростом сложности интегрированных средств разработки, только наличие подобных небольших инструментов помогают ориентироваться в возможностях этих систем. В связи с этим современным разработчикам необходима такая среда, которая позволит сосредоточиться только на тех артефактах, которые представляют интерес для пользователя, и, кроме этого, будет отображать только тот функционал системы, который действительно важен пользователю. И здесь на сцене появляется Eclipse и плагин под названием Mylar, позднее переименованный в Mylyn. Mylyn меняет принцип разработки программного обеспечения следующим образом. Вместо того чтобы устанавливать массу инструментов для работы с артефактами, возникающими в процессе разработки, и использовать постфактум, Mylyn помогает обрабатывать эти артефакты в момент создания.
Итак, закрепив эту ключевую мысль в голове, перейдем к более детальному описанию возможностей Mylyn.

Номер раз

Mylyn позволяет вам сконцентрироваться на ваших задачах

Чтобы ощутить всю мощь Mylyn, вам нужно все ваши активности (как связанные с разработкой, так и непрофильные) переработать в задачи. Каждая задача содержит в себе небольшую часть всей работы, которая будет иметь конечный результат. Разумеется, вначале с формулировкой задач будут проблемы («Написать приложение» явно не лучший вариант, так как неясно, каким должно быть следующее действие), но со временем, придет опыт, и задачи станут более четкими («Поменять форму кнопки с квадрата на круг»). Подобное саморазвитие связано с тем, что вам самим становится проще выполнять и планировать задачи, которые сформулированы более грамотно (в принципе человек бессознательно стремится к подобному планированию деятельности). Понятное дело, что все задачи будут сформулированы по-разному, но именно наиболее четко сформулированные задачи показывают, насколько эффективен Mylyn.
Еще одно преимущество задач – они показывают, в каком состоянии находится работа. Всегда можно посмотреть, что уже сделано, а что осталось. Возможность фильтрации задач по типу поможет определить то же самое, но уже для какого-то конкретного направления. В то время как фильтрация по приоритетности показывает, как много ключевых задач было сделано. (рис. 1)


Номер два.

Mylyn показывает лишь то, что вам необходимо

В то время как вы находитесь в своем рабочем пространстве, Mylyn ведет запись всех ваших действий, как например редактирование файлов, классов, конкретных методов и так далее. Таким образом, каждый раз когда вы затрагиваете в ходе работы какой-то артефакт (открыв файл, отредактировав тип и так далее), Mylyn отметит данную активность, которая позволить ему организовать коллекцию все того, что вам будет интересно и необходимо. И уже в дальнейшем вы будете видеть только то, что касается сферы ваших интересов. В процессе роста количества артефактов, попадающих в эту сферу, будет меняться и их отображение, например, те классы и методы, с которыми вы работаете наиболее часто, будут выделены жирным.
Рисунок 2 показывает новую задачу, после открытия конкретного класса. Важно отметить, что в иерархическом списке (Package Explorer) показан только тот класс, который упоминается в задаче. Кроме этого, список методов (outline view) пуст, собственно, потому что еще не был затронут ни один и методов открытого класса.

На третьем рисунке показано то же самое рабочее пространство после небольших изменений, сделанных над классом. Метод drawImage() теперь виден как в иерархическом списке, так и в списке доступных методов. Как только будут изменены другие методы, они так же попадут в область видимости.

Существует и обратная реакция. Как только вы становитесь менее заинтересованным в артефакте, его выделение становится тусклым (из жирного переходит в нормальное, из нормального в серый), и постепенно артефакт пропадает из области видимости. Данный механизм основан на следующей точке зрения: если вы вносили изменение в артефакт, вы обязательно вернетесь к нему хотя бы еще раз. В дальнейшем, завершая задачу, вы возможно снова вернетесь к тем же артефактам, над которыми работали наиболее активно. Обратно так же верно: чем реже вы обращаетесь к артефакту, тем меньше будет необходимость в нем в будущем.
Данный режим с легкостью может быть отключен простым нажатием на кнопку «Focus on Active Task». Это сделано для того, чтобы вы могли найти артефакт, скрытый Mylyn, сделать его активным и вновь вернуться в прежний режим работы. Однако Java разработчики пользуются этим не так часто, в силу причин присущих Eclipse Java Development Tools (JDT), которые с легкостью позволяют просматривать родственные связи. Возможно так же отложить текущую задачу, с целью поработать над другими артефактами, или, например, другой задачей, и вернутся к первой.

Номер три.

Mylyn помнит,(что вы делали прошлым летом — прим. перевод.) что вы делали, пока переключались между задачами.

На следующих двух картинках можно видеть, как выглядит рабочее пространство во время работы над багами Eclipse: 138600 и 164658. Разница видна невооруженным глазом. Таким образом, мы подошли к еще одной важной особенности Mylyn: сохранение конкретного рабочего контекста для конкретной задачи.


Таким образом, переключаясь между задачами, вы будете видеть только те артефакты, которые касаются только этой задачей. Важно, что только одна задача может иметь статус активной, но никто не мешает переключаться между задачами. Задачу можно сделать активной массой способов: через выпадающее меню в редакторе задач, с помощью работы с записью в меню «Navigate» или нажатием на первую колонку строке, где описана данная задача. Чтобы все было совсем просто, вы можете переключаться между задачами используя выпадающее меню, появляющееся при нажатии на заголовок вкладки “Task List”, как показано на рисунке 6.

Название текущей активной задачи видно в верхней части вкладки “Task List”, а так же выделено жирным в общем списке задач.
Управляя контекстом для каждой задачи, Mylyn позволяет разработчику сфокусировать все свое внимание на хорошо сформулированной задаче и потратить как можно меньше времени, для переключения между этими задачами. Другими словами: как только вы переключились на другую задачу, вы видите тот материал, с которым надо работать. И никаких лишних временных затрат.

Номер четыре

Mylyn может подцепляться к системам управления

На сайте Mylyn помимо всего прочего можно найти плагины для интеграции с Bugzilla, JIRA, и Trac. Кроме того, есть возможности интегрировать Mylyn с XPlannerи другими подобными сервисами. Такой функционал позволяет управлять задачами вне сред разработки, а также видеть их другим разработчикам.
Например на рисунке 7 можно видеть список задач, полученных из различных систем. Наприме, пункт «Open Harmony Bugs» позволяет подсоединиться к JIRA, используемой командой ApacheHarmony. Другие пункты меню получают позволяют видеть задачи, получаемые из EclipseBugzilla.

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

Задачи, полученные из репозитория, регулярно автоматически обновляются. Те задачи, которые были изменены, помечаются в общем списке, что сразу делает их заметным. Mylyn позволяет добавлять к задачам дополнительную информацию, включая информацию, касающуюся времени (например когда вы начнете работать над задачей), как долго вы будете над ней работать и насколько она выполнена. Так же можно выставлять длительность работы над задачей.
Существует так же возможность присоединения рабочего контекста (см. рис 9), что позволяет заархивировать рабочий контекст задачи и отправить его как дополнительную информацию на сервер. Контекст содержит информацию обо всех артефактах, с которыми вы поработали. Помимо того, что все могут видеть область вашей работы, они так же могут расширить и свой рабочий контекст вашими артефактами. В последующем вы можете работать совместно над одними и тем же контекстом.

Создание дополнительных коннекторов для репозиториев задач возможно благодаря открытому API. Что касается коннекторов к другим источникам задача, включающим в себя веб-сервисы, базы данных и корпоративные программы управления задачами, то их создание так же возможно, что делает Mylyn единым средством для работы над задачами.

Номер пять

Mylyn имеет продуманный Look And Feel

Mylyn очень качественно интегрирован в интерфейс Eclipse. Разработчики Mylyn следовали правилу «Лучше меньше да лучше»и на выходе получили интуитивно понятный и достаточно мощный по возможностям дизайн, который при этом не является перегруженным. Mylyn можно найти повсюду, однако он нигде не кричит о своем присутствии. Большинство вкладок (включая Navigator, Package Explorer и Outline) содержат в себе функционал от Mylyn, но при этом их принцип работы остается прежним, Поэтому чтобы привыкнуть к Mylyn требуется совсем немного времени. Вместе с этим появились и нововведения (как например временное раскрытие спрятанных артефактов кнопкой Alt), но это служит больше для удобства. Продолжая эту стратегию, пункты меню, связанные с Mylyn просто добавились в список уже существующих, но при этом не внесли ничего нового.
Mylyn хорошо смотрится и при этом предсказуемо работает. Например, ненавязчивое мигание всплывающего окна в нижней правой части экрана, уведомляет вас об изменения, сделанных на сервере над задачей.
Таким образом, Mylyn –это изящное, но при этом мощное средство работы, понятное для пользователя.

Заключение

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

UPD. Перенесено в блог Eclipse.
Перевод: Wayne Beaton
Андрей Ребров @mythmaker
карма
152,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (51)

  • 0
    Для интеграции с fogbugz есть отличный (но платный) репозиторий-плагин — foglyn.
  • –15
    Ничего личного, я действительно хочу знать ответ на свой вопрос: а чем все эти свистелки-перделки реально лучше того же вима? (статью прочёл внимательно. предложение «попробовать» неактуально — перепробовал всё, начиная от Komodo и заканчивая Эклипсом)
    • +3
      Mylyn — это надстройка над эклипсом.

      Чем IDE лучше просто редактора? всем! Скорость работы — если не на порядок, то в разы точно больше. Меньше ошибок, особенно тупых. Автокомплит и резолвинг типов от стандартных и библиотечных до своих, индивидуальных, структура кода, исходник или переход на метод/функцию. Интеграция со всем что нужно — репозиторий и хелп как минимум. Шаблоны. Билд и дебаг.
      • –2
        Эм… А в виме всё то, что вы написали — есть. И не так, как захотели создатели IDE, а как захотел я сам.

        В общем, для себя ответ на свой вопрос я получил: ничем не лучше. Каждый пользуется тем, к чему привык.
        Продолжать не буду, дабы не холиварить и не троллить. Удачи.
        • +2
          Ну да, каждому — свое :)
        • +1
          Просто многим не хочется тратить массу времени на заточку под себя vim etc, их устраивают типовые решения, которые сделаны в большинстве IDE. Поставил — и работаешь.
        • +3
          >И не так, как захотели создатели IDE, а как захотел я сам.

          Вот в принципе и ответ на вопрос «чем лучше?». В vim'е (и подобных средах типа emacs) для эффективной работы (а не в стиле «гуглим, как вставить пустую строку») нужно:
          а) осознать что хочешь (нужно)
          б) понять как это сделать (включая, но не ограничиваясь курением кучи манов, гугление и т. п.)
          в) настроить это
          И многие в результате все равно получат лишь жалкое подобие привычных способов работы. Используя же GUI IDE типа Eclipse, NetBeans или VisualStudio (а так же их плагины, аддоны и прочие расширения) нужно только установить и посмотреть «нравится-не нравится, удобно- не удобно». В большинстве IDE программу типа «Hello world» можно написать и запустить через несколько минут после первого входа в неизвестную ранее IDE, владея лишь общими навыками работами с современными графическими интерфейсами, vim к таким программам явно не относится (включая даже последние GUI версии, про консольные вообще молчу)
          • +1
            С другой стороны, в IDE на пользователя набрасывается сразу целая куча вещей, в принципе для программирования некритичных.

            1)Интерфейс тяжел, перегружен элементами, часто пространства для кода совсем мало.

            2)Нельзя быстро посмотреть на несколько участков файла одновременно

            3) обычно нельзя удаленно редактировать файлы, скрипты, конфиги

            4) Нельзя просто подредактировать какой-нибудь конфиг с привычными биндами — приходится переключаться на текстовые редакторы

            5) Интеграция с системами контроля версий часто оставляет желать лучшего. Пример: git под eclipse.

            6) Пользователь за абстракцией проекта не видит реальных механизмов сборки программы.

            7) Программы иной раз просто-напросто медленно работают.

            8) Тяжело быстро и под себя добавлять на клавишы простые скрипты (хорошие примеры: TextMate, Emacs; плохие: VS, Eclipse и т.д.)
            • 0
              Идеала, конечно, нет, но в vim'е я бы сказал, что на пользователя набрасывается одна вешь, но большая — сам vim :) Все мои попытки освоить vim заканчивались одним и тем же — я, в принципе понимаю, что могу сделать из него идеальную для себя IDE (если даже не ОС, точнее оболочку :) ), вот только заняло бы это едва ли меньше времени, чем разработка такой IDE с нуля, скажем на C++, а использовать vim в режиме notepad++ или gedit вместо обычной (пускай и не идеальной для меня) IDE скорость разработки скорее уменьшит, а не увеличит.

              P.S. Весьма вероятно, что суть разногласий больше в не в функциональных возможностях сред (наверняка можно из vim сделать полный аналог того же Eclipse, как и наоборот, а вот нужно ли), а в подходе пользователя. Примерно как одни не понимают почему в винде не все можно сконфигурировать из панели управления, а другие не понимают зачем делали графические средства администрирования в никсах, если есть консоль. И ведь нельзя сказать, что кто-то прав на 100%, а кто нет.

              • +1
                Странно. Я не виммер, пользуюсь емаксом. Ценю в нем то, что он — не IDE. Иной раз слышу про какую-нибудь фичу, повторяю ее у себя в среде — и отключаю за ненадобностью.

                Что же вам не нравится?

                Возможность настроить все под себя?
                Быстрый запуск?
                Ускоренный набор текста и кода?
                Отсутствие неоходимости пользоваться мышью?
                Моментальное создание скриптов для обработки текста, запуска тестов и так далее..?
                Редактирование конфигов?

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

                И про консоль я ваши замечания прочитал… Конечно, гуй — это интуитивно. Но консоль дает больше свободы. Свобода всегда сложнее, чем жесткие рамки.
                • 0
                  Всё верно.
                  Вообще, зря мы эту тему начали.
                  Каждый приходит к виму и емаксу по-своему, а других насильно заставлять просто нет смысла. Насильно мил не будешь :D
                  • 0
                    Я вроде как добровольно, но вот никак :( То ли что-то важное во всех прочитанных манах и статьях пропустил, то ли еще что-то
                    • 0
                      Не нужно себя заставлять =)
                      Не идёт — значит не ваше просто ;)
                      Пользуйтесь тем, что нравится и будьте счастливы =)
                • 0
                  >Возможность настроить все под себя?
                  Необходимость всё это настраивать, изучать команды редактора, плюс, по сути, изучать еще один скриптовый язык для написания всего того, для чего одних команд мало. Подозреваю, что в vim'е, как и в emac'е в поставку не входят модули для полноценного (с учетом иерархии классов, интерфейсов и т.п. в ООП-языках) автокомплита (или я не смог понять как их запустить), а реализовать его без скриптов, анализирующих исходники по-моему затруднительно. Да даже бог с этим автокомплитом, мне кажется даже простую «панельку» слева от основного окна с деревом хотя бы файловой системы (про всякие «виртуальные папки» я вообще молчу) я настраивать буду ну не меньше недели чистого рабочего времени.

                  >Быстрый запуск?
                  Тут, конечно, не хватает :)

                  >Ускоренный набор текста и кода?
                  Не вижу причин для резкого ускорения, все активно используемые конструкции у меня и так забиндены, автокомплит работает, переходы по именам функций, классов и т. п. тоже

                  >Отсутствие неоходимости пользоваться мышью?
                  Вот тут, пожалуй, очень спорный момент, в vim'е мне очень не хватает возможности пользоваться мышью, от банального позиционирования курсора и скроллинга до навигации в файловых и прочих древовидных системах

                  >Моментальное создание скриптов для обработки текста, запуска тестов и так далее..?
                  Вот тут ничего не могу сказать, нужны ли мне такие возможности в принципе от редактора. Имеется в виду внутри редактора на его языке, при необходимости я напишу привычными средствами и запущу не выходя из IDE.

                  >Редактирование конфигов?
                  Что не так с конфигами? любой нормальный редактор подсвечивает распространенные форматы конфигов, если же нет, то настраивается быстро, синтаксис простой у них, как правило.

                  >становится вопросом нажатия пары кнопок.
                  Ну убейте, но не понимаю как без графического (или псевдографического а-ля нортон коммандер) открыть произвольный файл нажатием пары кнопок, особенно если его имени (и пути к нему) не знаешь, да и не знаешь есть ли вообще этот файл.

                  >Но консоль дает больше свободы.
                  С этим я даже не спорю, наоборот, выигрывал много пари о том, что под голой виндой в ее «консоли» сделаю что-то, что из гуи сделать нереально. Но вот для повседневных задач, таких как копирование или архивирование файла я предпочитаю гуи, хотя и знаю как это сделать в консоли и даже допускаю, что через год активного ее использования (и постоянного курения манов) буду делать это быстрее, чем сейчас в проводнике или наутилусе. Просто встречая задачу, которую я сходу не знаю как выполнить в гуи, я горестно вздыхаю «опять эта свобода» и лезу в консоль, привычка еще с MS-DOS :)

                  • +1
                    Да ладно, Emacs Code Browser (эт типа панелька) или Speedbar (панелька потупее, зато из коробки есть) уже двести тыщ лет существуют. и запускаются, и все такое, только я попробовал и перестал пользоваться.

                    Насчет автокомплита и все такое… Ну есть такое. Настраивать надо.

                    А про пару кнопок… Не поверите, есть много способов открыть файл именно парой клавиш. Что-нибудь вроде C-x C-f beg — и открывается файл bobberg.txt. Опять же, не про вим говоря, можно открыть и файловый менеджер в пределах емакса.

                    Ну ладно, с редакторами vs IDE все понятно. Это религиозное и все такое. Кому-то надо быстрее, кому-то — покомфортнее.

                    Но вот про консоль что вам скажу…

                    Я пользуюсь и mc, и емаксовым dired, и консолькой. Каждый нашел свое место в workflow. Dired дает возможность быстро сориентироваться в директориях проекта, mc — филигранно подкорректировать структуру файлов/директорий, удалить, скажем, или перенести.

                    Однако, в консоли есть чудная история, волшебные алиасы и дополнение по табу. Все действия запоминаются, к ним можно вернуться. сложные команды заальясить. Есть продвинутый поиск. Есть запуск команд по найденным файлам. Git действительно создан для использования из консоли, я просто оргазм получаю от его использования. Честно говоря, злюсь, когда вообще надо пользоваться интерфейсом.
        • +1
          Понял. Спасибо всем за развёрнутые ответы =) Это именно то, что я хотел услышать.
          От себя добавлю, что после того, как разобрался в виме, в его настройках и использовании — я никуда уходить больше не собираюсь (причём использую именно консольный, а не гуёвый вим ;) Но это только ИМХО =)
          • 0
            Много времени разбирание заняло, если не секрет? И приходилось ли в чем-то себя перебарывать или менять «мировоззрение»? Я вот, например, никак не могу заставить себя получать удовольствие от работы в консоли, если знаю как это сделать в гуи, консоль для меня досадная необходимость, свидетельство неидеальности мира :) А многие, я знаю, плюются от тулс, которые к части возможностей, как правило по тонкой настройке, пускают только через этот самый гуи, в принципе тоже не идеал, но у нас с ними полярные точки зрения. Мой идеал — «То, что можно сделать в консоли должно быть возможно сделать в гуи», а их наоборот.
            • 0
              Однажды я понял, что идеального IDE не существует, — всё, чем я пользовался так или иначе меня ограничивало. Наиболее близко мне подходил Komodo, но и у него была масса минусов. И тогда я поставил себе vim и начал в нём разбираться. Примерно через неделю я не испытывал никаких неудобств в работе, а примерно за месяц я настроил под себя всё, что только можно до такого состояния, что мне стало совершенно комфортно работать. Ни в одной IDE я не испытывал удовольствия от работы, работая в vim'e же я просто счастлив :D
              С тех пор я периодически узнаю что-то новое о нём и постоянно правлю свой конфиг — мне это нравится — не стоять на месте и не тухнуть.

              Перефразируя одну известную фразу я могу сказать одно: "All IDE suck. This one just sucks less." © И это самые правильные слова, которые можно сказать о виме и емаксе — после этого можно уже ничего не говорить ;)

              Для меня консоль — это свобода. Я не люблю, когда меня ограничивают и втискивают в рамки. Например, мне недавно довелось разбираться с одной программой в винде — и я очень долго не понимал, как же мне включить вывод отладочной информации (набрал уже по привычке «prog.exe -d» и обломался). Так и не смог с ней справиться и, в конце-концов забил на неё. Если программа работает идеально, то консоль не понадобится. Но таких программ просто не существует. И это — факт.

              «То, что можно сделать в консоли должно быть возможно сделать в гуи» — такого не будет никогда просто потому, что это невозможно. Это не хорошо и не плохо, это просто данность. Консоль априори всегда даёт большую свободу.

              Впрочем, каждому — своё. Никого ни за что не агитирую. Мне хорошо с вимом в консоли, а что у других — мне, собственно, пофигу ;)
      • 0
        > Чем IDE лучше просто редактора? всем!

        Только vim — не простой редактор. IDE, умный редактор(с автокомплишеном, анализом кода и т.д.) и простой редактор — разные вещи. IDE = умный редактор + куча инструментов, которые обычно используются в процессе разработки, но могут быть и самостоятельными без ущерба производительности программера.
        • 0
          Жалко, что народ этого не понимает. А со своим уставом в чужой монастырь не ходят.

          Мне вот даже какие-то малолетки защищая свои любимые IDE в карму успели насрать из-за моих комментов в этом посте :D

          Молодежь… Вырастут — поймут ;)
          • 0
            Интересно, а мне кто минуса ставил, малолетки защищающие свой любимый vim? ;)

            Молодежь… Вырастут — поймут ;) (с) :-D
            • 0
              Ну, я, во-первых, минусы в тех ветках, где я учавствую в обсуждении не ставлю — «религия» у меня такая — не оценивать своих собеседников, т.к. я могу быть не прав.
              • 0
                А во-вторых, я не защищаю vim — каждому своё.
                Ещё в начале ветки я написал, что просто хочу понять — может, я что упускаю? И никого не агитирую и не хочу ввязаться ни в холивар, ни в троллинг.
                • 0
                  Возможно Вы упустили то, что vim вне контекста языка разработки неспособен дать такие же эффективные инструменты (автокомплит, рефакторинг с учетом классов, типов и т.д.).
    • 0
      Рефакторинг, и статический анализ кода. Ну плагины в зависимости от области применения.
    • –1
      В виме можно сделать так?
      1) В браузере скачать либу.
      2) Перетащить ее из Download Manager'а браузера в папку lib в проекте (через IDE, не через файл-менеждер)
      3) Right-Кликнуть на либе и выбрать Add to build path
      4) Получить контекстно-зависимую подсказку по свежеподключенной либе
      5) Подключить к либе джавадок и получить его при наведении на классы из либы в коде
      6) Подключить к либе сорцы и легко переходить к имплементации метода из либы в коде
      • +1
        \troll{Вы всё ещё качаете через браузер? Тогда мы^W^WПора бы уже осилить менеджер пакетов}

        К сожалению под виндой это не вариант. А, скажем в Gentoo, достаточно установить либу с doc и source:
        USE=«doc source» emerge log4j

        Остальное (пункты 4, 5 и 6) — совершенно не проблема.
        • 0
          И что, после этого log4j добавится в класспуть всех моих проектов? :) Или мне все-таки придется вручную прописывать путь и переносить либу в проект? (я в курсе про мавен, если что :)).

          Насчет 4, 5 и 6 покажите мне скриншот как вим это делает и вы измените мой взгляд на этот редактор. :)
          • 0
            eclim использует возможности eclipse по анализу кода, чтобы сделать это возможным:
            eclim.sourceforge.net/_images/completion.png

            Но ввиду некоторых его недостатков я бы рекомендовал писать Java код в vim, а читать, рефакторить и т.д. — в NetBeans. ;)
            • 0
              Да, интересный трюк.
              Насчет писать и читать код в разных редакторах — это фантастика :)
              • 0
                Я именно так и делал. С точки зрения написания кода есть всего два хороших редактора — vim и emacs, но:
                1. У них ограниченные возможности по анализу кода, особенно java.
                2. Рефакторинг и т.д. для Java обычно реализуется частью IDE, а не отдельной программой.
      • 0
        Не знаю как для ждавы (не люблю её), но для того же Perl или Си все ваши пункты в виме делаются элементарно.
        За исключением пунктов 2 и 3 («перетащить», «right-кликнуть»… я в линуксе, тут всё гораздо проще ;)

        Что касается «в виме можно так, в виме можно сяк...». Скажите, сколько оперативки жрёт ваша IDE, и комфортно ли вам работать в ней? Меня эклипс просто убивает своей тормознутостью на вполне себе так современной машинке с двумя гигами ОЗУ и средних размеров проектом. А там более под виндой. Фу…
  • +1
    не хватает внешнего легкого планера для локальных задач… В принципе там xml файлики и api — надо время найти и написать. :)

    А так, после привыкания ( читай подстраивания стиля работы под тул ) — очень удобно шариться. Лучше всего работает для багов или изменений. Для последовательного девелопмента приходиться иногда копировать контекст последовательно для задач или активировать вернеуровневую задачу и матчить по списку как комплит.

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

    Вся прелесть раскрывается вместе с интеграцией. Локальный депозиторий какой-то малофункциональный.
    • +1
      Оох, мля! только сейчас увидел кнопочку «I'm feeling Lazy» в списке задач по Ctrl-F9 :)
  • 0
    Плагин для связки с траком у меня почему-то упорно не обновляет потраченное на задачу время.
  • 0
    Давно хочу попробовать Mylyn, но нет коннектора для используемой у нас системы учета багов (а учитывая, что она мало распространена никогда и не появится). Есть ли какие-нибудь подробные туториалы по написанию своего или адаптированию существующего коннектора для тех, кто мало что понимает в эклипсовских классах?
    • 0
      Для неподдерживающихся систем управления задачами существует Web Connector. Он работает на основе разбора html страниц — выкусывает с них список задач и описание отдельной задачи. Все шаблоны можно полностью заточить под используемую систему. Для добавления новой задачи просто напросто открывается встроенный браузер.

      По личным ощущениям — не фонтан, но лучше чем ничего.
  • 0
    А что, кто то сумел это прочесть? Меня этот перевод подкосил на излете.

    Как я понимаю перевод это не замена английских слов на русские, а скорее перевод это изложение текста на русском.
    • –1
      То, о чем вы говорите, это скорее пересказ. Перевод — это попытка передать мысль, язык, стилистику и слог автора на другом языке. Попытка потому, что только автор полностью знает, что он хочет сказать.
      Все переводимые книги в аннотации обязательно имеют описание, перевод это или пересказ. Разницу между тем и другим ощутить очень легко, найдя одну и ту же книгу, но одна должна быть помечена как «перевод», а вторая соответственно как «пересказ». Сам ощутил это различие в классе 4, когда сравнивали на литературе «Синюю птицу» в обоих вариантах. Разница была на лицо.
      • 0
        Хорошо, а вот этот образец это что? По моему явно не перевод.
        • 0
          Если вы начинаете критиковать, то хотелось бы, чтобы вы указали на то, что вам так не нравится. Да, я по профессии не переводчик, хотя у меня и заканчивал специальные курсы. И я сейчас учусь делать грамотные и правильные переводы. И, если перефразировать ваше высказывание, можно каждому начинающему программисту говорить — «Это не программа, а набор операторов». Имхо, это глупо и бессмысленно.
          • 0
            >> В связи с этим современным разработчикам необходима такая среда, которая позволит сосредоточиться только на тех артефактах
            Что за артефакты? Не смогли придумать русский аналог и оставили как есть?
            Меня больше всего умиляет, что вы не пытаетесь перечитать свой «перевод» и критически к нему подойти, вместо этого вы почему-то пытаетесь отстоять косноязычие промтобразного перевода. Воспринимайте критику как хотите, я собственно уже высказался, и спорить с вами мне не интересно.
            P.S. Артефактом там дело не ограничивается.
            • 0
              Артефакт, кстати, уже давно стал таким же термином, как и билд, бага и проч. В частности, он активно используется в scrum, да и вообще в agile.
  • 0
    Я может что-то не понимаю, но в статье попутаны Mylyn c Mylar'ом. По крайней мере К.О. подсказывает, что оригинальная статья называется «Five Reasons to Love Mylar»…
    • +1
      MyLyn и MyLar — это одно и тоже — просто MyLYn — новое название для MyLar-а (кстати переименовались уже очень давно)
  • +1
    Эхх, было бы еще что-то подобное для NetBeans — ибо Eclipse мне не понравился
    • 0
      Для НетБинс есть например TaskList, плагин для работы с JIRA или другой плагин для интеграции с Trac. А версия 6.7 поддерживает работу с Kenai. Они, конечно, не поддерживают всего функционала Mylyn, но хоть чем-то смогут и помочь.
    • 0
      CubeOn
  • 0
    Коннектор для интеграции с Redmine.
    • 0
      Хабр неадекватно выкинул линк: хттп://sourceforge.net/projects/redmin-mylyncon/
  • 0
    Хочу поделиться информацией, что для Mylyn есть расширение добавляющее поддержку MantisBT. Сайт расширения https://sourceforge.net/projects/mylyn-mantis/.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.