Инструментарий/среда веб-разработки новичка Java

Для веб-разработки я использую (и рекомендую) следующее:

• JSP / Servlet API
• Spring MVC
• JQuery
• XHTML и CSS
• Fitnesse

Что касается ресурсов, все эти технологии хорошо документированы на соответствующих сайтах, за исключением XHTML и CSS, для которых я бы предложил http://www.alistapart.com .

] Что касается редакторов, как у IntelliJ, так и (я считаю) Eclipse есть очень хорошие редакторы HTML, CSS, JSP и JavaScript.

Также используйте Firefox (как предложил Брайан) как с плагином Web Developer, так и с Firebug - оба они незаменим.

Tomcat и Jetty являются хорошо известными / поддерживаемыми контейнерами сервлетов. Если вы создаете развертываемую версию для клиентов, вы можете захотеть протестировать на обоих, если вы не контролируете развертывание.

Для тестирования проверьте (вместе с вашими обычными средами модульного тестирования JUnit / TestNG) Watij и / или HtmlUnit . Это позволит вам автоматизировать фактическое взаимодействие с веб-браузером и в долгосрочной перспективе избавит вас от лишних хлопот. Обратной стороной является то, что вам придется потратить некоторое время на настройку ваших тестов.

Что касается автоматизированных тестов, я думаю, вам нужна автоматизированная система сборки / непрерывной интеграции. В мире Java их предостаточно. Двумя общими являются CruiseControl и Hudson .

Для многих из вышеперечисленных применяются стандартные инструменты Java / разработки, например, «стандартные» IDE (Netbeans / Eclipse / Intellij - за Intellij стоит платить, кстати). То же самое относится и к CMS, и на этом веб-сайте есть много ресурсов о плюсах и минусах SVN / Git / Mercurial и т. Д. Стоит убедиться, что выбранная вами CMS интегрируется с вашей IDE.

Я бы посмотрел Firebug для упрощения разработки (в Firefox). Это значительно упрощает фронтенд-разработку. LiveHttpHeaders упрощает диагностику проблем, связанных с передачей HTTP.

Я бы посмотрел Firebug для упрощения разработки (в Firefox). Это значительно упрощает фронтенд-разработку. LiveHttpHeaders упрощает диагностику проблем, связанных с передачей HTTP.

Я бы посмотрел Firebug для упрощения разработки (в Firefox). Это значительно упрощает фронтенд-разработку. LiveHttpHeaders упрощает диагностику проблем, связанных с передачей HTTP.

CMS

• Tortoise SVN

Редактор / IDE

• eclipse

Общие инструменты / утилиты

• Maven (инструмент для сборки и развертывания)
• Круиз-контроль
• GWT / ext-GWT / ICEFaces - технология веб-компонентов
• Spring - среда внедрения зависимостей
• Hibernate - ORM
• Комплект для разработки веб-сервисов Axis 2.0
• Jboss

Направленные (специальные) инструменты / утилиты

• log5j - для ведения журнала

Инструменты / утилиты / методы тестирования и обеспечения качества

- Watij
- Firebug
- QTP for automated testing
- Junit Perf (Junit test cases for performance testing.)

Справочные материалы (как в режиме онлайн, так и в автономном режиме)

• Документация Java по каждой из технологий
• Google, конечно:)

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

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

• использовать язык со статическим типом (например, java);
• использовать IDE, которая компилируется по мере ввода (например, Eclipse)
• любой XML должен быть проверен с помощью строгого xsd. Если в содержимом есть ссылки на другую информацию (например, код java), то его следует проверить (например, проверка Spring для классов компонентов).
• для технологии просмотра, поскольку это зависит от моего java-кода, у меня должна быть проверка, включающая мой фактический java-код. Идея могла бы заключаться в том, чтобы закодировать мое представление на Java. (как Wicket).
• мои свойства должны быть в файлах свойств для перевода. Но использование строковых ключей в моем коде (или представлении) недопустимо. Я бы запустил небольшой инструмент, который создает перечисления java из каждого файла свойств, и мой код будет ссылаться на перечисления.
• ... и так далее

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

• Maven - лучший инструмент сборки. Это наложит множество ограничений, но также предоставит множество готовых функций "сборки" ...
• Для веб-приложения я не мог использовать Struts 1, потому что они представляют собой огромные файлы конфигурации в struts-config.xml, в основном со встроенным кодом. Я бы определенно переключился на что-то вроде Spring MVC, у которого есть значения по умолчанию для сопоставления URL-адресов с контроллерами.
• и так далее ...

Другой пример, предположим, я так сильно верю в Model-View-Controller разделение, для ясности и повторного использования, я хочу его немного растянуть. Я мог бы использовать:

• в представлении, я бы чисто разделил свою модель (чистый HTML, без форматирования, без сценария), мое представление (или форматирование, только внешний CSS) и мой контроллер (javascript, используя ненавязчивый javascript policy).
• в веб-приложении я мог бы использовать Spring MVC для хорошего разделения этих слоев.
• в бизнесе (этот пример немного усложнен :-)), я мог бы иметь богатую модель предметной области, широко использовать шаблон команды ("контроллеры"), и открыто раскрываю мои бизнес-сервисы как интерфейсный API ("просмотр").