LINUX.ORG.RU
Ответ на: комментарий от vurdalak

Обычное веб-приложение, разбросанное на кластер. Хочется продебжить всю жизнь HTTP-запроса к нашей софтины, начиная от запроса пользователя (на веб-интерфейс или SOAP веб-сервис), и заканчивая непосредственно данными. Упрощаю, как если бы это был круд, хотя на самом деле сложнее :) Запрос пока дойдет в одну сторону - с помощью REST перебросится через несколько серверов, в зависимости от цели - разных. Ну и вот, ты примерно представляешь, что очередному запросику чтобы отработать - нужны данные примерно вот с этих десяти тачек. Запускаешь на них аппликейшен сервер (у нас jboss/wildfly и tomcat) в дебаг режиме, цепляешься к ним всем одновременно удалённой отладкой, подаешь запрос на самый первый из них (н-р веб-сервис) и спокойно дебажишь. Ну как спокойно, пока Идея окончательно не повиснет.

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

А что говорят на багрепорт? У них очень адекватные разрабы, все репорты которые я отсылал (даже один feature request, я хотел возможности ввода имя_файла:номер_строки в быстром открытии файла для открытия того что в стектрейсе) в следующей же версии исправили.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

ничего не говорят - я не писал. Очень сложно воспроизвести. Свои исходники по понятным причинам им показать нельзя. А сгенерить синтетический пример - еще надо постараться. Мне кажется, что тут причина в методе работы дебаггера. Сложность там примерно такая: нашего кода около 7500 классов, плюс зависимости (там 100500 классов, например только в Apache CXF недавно считал в их гите - тоже около 7000 классов, во всяких спрингах и того больше). Сложность повышается тем, что там всё на DI, и куча AOP-хаоса - каждый второй запрос делается не напрямую, а через прокси и интерцепторы. Когда пытаешься в отладчике по этому гулять, ему срывает крышу на, наверное, каких-то вполне конкретных местах. То есть чтобы зафайлить им баг, нужно написать прогу, которая автоматически сгенерит хитрозапутанный индусский код примерно такой же сложности. Мне тупо лень этим заниматься :(

stevejobs ★★★★☆
()
Ответ на: комментарий от foror

И чем поможет знание сборки JAR для «программы с GUI для себя»?

Тем что ты не будешь впадать в панику из-за малейшей ошибки и в принципе будешь знать «как оно работает» и что происходит внутри

nerfur ★★★
()

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

GblGbl ★★★★★
()

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

Eclipse - специфическая IDE. Это набор компонентов, все они разного качества, но критикуют обычно IDE в целом, что на мой взгляд не совсем правильно. Лагающее говно в Eclipse - это WTP (web tools), JSDT (js dev) и m2e (maven). Первые 2 тебе не нужны, так что вполне можно пользоваться, но придется некоторое время привыкать и учиться. Плагин WindowBuilder (это который для GUI) - довольно неплохой.

IDEA CE - самый норм вариант, но ей нужно железо помощнее.

emcode
()
Ответ на: комментарий от emcode

Я планирую писать код в ноутбуке и виртуалке на работе (так сложилось), поэтому вопрос требовательности к ресурсам важен. Какая IDE менее требовательна к ресурсам, но всё же обладает необходимым функционалом?

flyshoot
() автор топика
Ответ на: комментарий от flyshoot

От проекта зависит. На небольших учебных особой разницы не будет. Любой нужно 0.5-1Gb памяти. У Eclipse нативный UI, он пошустрее.

emcode
()

для новичка - любимый текстовый редактор.

ii8_ ★★★★
()

Использую Eclipse. Как в песне "..она нам нравится, хоть и не красавица.."

barberry ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.