Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 139
Спасибо за полезный топик! Как раз начал учить Java по справочнику Шилдта.
Пожалуйста (:
С Шилдтом у меня не сложилось. Мне кажется, он просто перепечатывает оф документацию, а мы это за деньги покупаем в его книгах.
Мне нравится читать туториалы от Sun. В печатном варианте в качестве учебника будет самое то.
С Шилдтом у меня не сложилось. Мне кажется, он просто перепечатывает оф документацию, а мы это за деньги покупаем в его книгах.
Мне нравится читать туториалы от Sun. В печатном варианте в качестве учебника будет самое то.
А я как раз сейчас потихоньку постигаю Яву по той же самой книге, только ее мне посоветовал другой хабраюзер.
Уже не первый раз натыкаюсь на упоминание об этой книге, рад что выбор сделан верный (хотя это смогу увидеть только в будущем).
Правда, я помимо самого 4 издания, беру еще примеры из второго издания (переведенного энтузиастами). К сожалению, в данный момент, сайт не работает.
Кстати, за сколько (по времени) вы прочитали книжку по Яве? И на каких этапах чтения стали писать свои программы, а на каких CMS? Кстати, как она поживает?
За статью, и за прекрасные советы, большое вам спасибо и удачи в начинаниях! :)
Уже не первый раз натыкаюсь на упоминание об этой книге, рад что выбор сделан верный (хотя это смогу увидеть только в будущем).
Правда, я помимо самого 4 издания, беру еще примеры из второго издания (переведенного энтузиастами). К сожалению, в данный момент, сайт не работает.
Кстати, за сколько (по времени) вы прочитали книжку по Яве? И на каких этапах чтения стали писать свои программы, а на каких CMS? Кстати, как она поживает?
За статью, и за прекрасные советы, большое вам спасибо и удачи в начинаниях! :)
Спасибо (:
Книгу прочитал поверхностно месяцев за 10. Старался набрать в и запустить весь приведенный в книге код. Полноценные программы стал пробовать после изучения Swing. CMS пока только на этапе проектирования.
Книгу прочитал поверхностно месяцев за 10. Старался набрать в и запустить весь приведенный в книге код. Полноценные программы стал пробовать после изучения Swing. CMS пока только на этапе проектирования.
Шилдт довольно хорошо писал о C/C++. С Java/C# у него как-то похуже получается.
Есть люди, которые с вами не согласны. :)
catb.org/jargon/html/B/bullschildt.html
catb.org/jargon/html/B/bullschildt.html
Кстати, да. По плюсам именно учебник был, я бы сказал, самый лучший, т.к. пришлось преподавать как-то и именно на нем остановился.
Когда начнете готовиться к экзамену, поймете что вы еще оч многого не знаете. Есть очень хорошая литература для подготовки. Она реально открывает глаза на некоторые аспекты.
Да, Вы правы, цельной картины по Core Java пока нет. Придется позубрить предмет, как в институте; пописать «обобщающие шпаргалки» на листах А4 — тогда начнет что-то вырисовываться. Уж очень хочется знать язык вглубину.
Для подготовки к экзамену приобрел книгу Sun Certified Programmer for Java 6 Study Guide by Kathy Sierra, Bert Bates. По-моему с ней сдам. (:
Для подготовки к экзамену приобрел книгу Sun Certified Programmer for Java 6 Study Guide by Kathy Sierra, Bert Bates. По-моему с ней сдам. (:
Извините, а писать на Java и работать Вы собираетесь? Почему спрашиваю, т.к. Мотивация, как по мне, странная для программиста.
Выбирал из двух платформ: Java и .NET. Прочитал вводные главы Thinking in Java — мне понравилось то, о чем пишут. Решил попробовать.
Я наверно излишне впечатлителен (:
Я наверно излишне впечатлителен (:
Я наверно излишне впечатлителен (:
та не. нормально :)
потом можно будет и .NET подтянуть. после Java будет проще чем с нуля. но может начать бесить Java, эдакий побочный эффект, наюлдал у многих, я сам в числе «пострадавших» :)
кстати, по Java обычно больше вакансий и прайсинг чуть выше, как мне кажется.
Постоянно приходится писать и на Java и на .Net
Если отбросить холиварные предрасудки, то во многих моментах переход от одного языка к другому просто не заметен
Если отбросить холиварные предрасудки, то во многих моментах переход от одного языка к другому просто не заметен
кому как. мне переход туда-обратно дается более болезненно. в Java постоянно не хватает пропертей и прочих плюшек, в C# вроде всего хватает, но раздражает студия которая умеет далеко не все то, что умеет IDEA. в итоге стараюсь не переключаться между ними в течении дня, а работать надо кодом в разных языках в разные дни.
Дал плюсик в карму, думаю стоит переместить это в тематические…
Для подготовки к SCJP очень хорошо использовать ExamLab. Да и для улучшения познаний в SE оно подходит хорошо. Важное отличие от других симуляторов экзаменов — оно бесплатное, причём отнюдь не в ущерб качеству.
я думаю основные трудности возникнут на этапе создания CMS, там и проверка знаний и терпение, ошибки, тестирование и опять поиск ошибок. Так что ждем часть №2. Осилите CMS, тогда вы верно выбрали свою будущую профессию…
Че-то не понял. Демо проекта на флэше. По сырцам, вроде ничего флешевого в проекте не нашел. Смотрел www.openmeetings.de/
в плане интерфейса/юзабилити просто адский ресурс уж простите :(
Вот Вам сервлеты.
Уважаемые читатели хабры, очень интересно узнать ваше мнение о книге
«Программирование на Java. Методическое руководство для преподавателей », год 2003, автор Вязовик.
Как бы собираюсь почитать эту книжку для освоения java, но, как говорится, «плюсы, минусы, нет ли подводных камней»? Спасибо за внимание, буду благодарен за отзывы.
«Программирование на Java. Методическое руководство для преподавателей », год 2003, автор Вязовик.
Как бы собираюсь почитать эту книжку для освоения java, но, как говорится, «плюсы, минусы, нет ли подводных камней»? Спасибо за внимание, буду благодарен за отзывы.
Лучше что-нибудь посвежее: habrahabr.ru/blogs/java/66568/ Я бы посоветовал Хорстманна.
лекции можно посмотреть на youtube
Lecture 1 | Programming Methodology (Stanford)
www.youtube.com/watch?v=KkMDCCdjyW8
Lecture 1 | Programming Methodology (Stanford)
www.youtube.com/watch?v=KkMDCCdjyW8
Интересно было бы про подобный опыт .net почитать. :)
А как насчет GWT? Пробовали? Планируете?
Слышал только краем уха. Возможно буду использовать.
Иногда жалко, что нельзя выучить все технологии и библиотеки сразу (:
Иногда жалко, что нельзя выучить все технологии и библиотеки сразу (:
Хе, как «джавист» с опытом (надеюсь не очень пафосно звучит) открою вам тайну. Огромный плюс джавы, а точнее ее направлений и технологий это «правильная» архитектура. Чем больше вы будете изучать технологий/фреймворков, тем проще и быстрее вы будете разбираться с новыми в будущем. Ну у меня по крайней мере практически сразу вырисовывается общая картина где/что/ и зачем. Там Синглтон, там фабрика,…
Не рекомендую, REST-бекенд, пара сервлетов c Velocity, обслуживающих шаблоны и Ext-JS или даже чистый jQuery дают лучший результат. GWT — чудовищно трудоемкий фреймворк
«Первые несколько месяцев я, следуя совету Брюса Эккеля, не использовал никаких IDE»
Полагаю, как и в случае с IDE, свои первые ajax запросы, а может быть и сериализацию объектов для передачи с сервера на клиент, автор выполнит «голыми руками». И лишь потом будет смотреть в сторону высокоуровневых инструментов, которые все умеют сами.
Кстати, не факт, что его выбор падет на GWT ^_^
Полагаю, как и в случае с IDE, свои первые ajax запросы, а может быть и сериализацию объектов для передачи с сервера на клиент, автор выполнит «голыми руками». И лишь потом будет смотреть в сторону высокоуровневых инструментов, которые все умеют сами.
Кстати, не факт, что его выбор падет на GWT ^_^
Спасибо за хороший обзор
Это точно. Меран Сахами отлично ведёт лекции.
Это точно. Меран Сахами отлично ведёт лекции.
Обязательная книга «Effective Java», Joshua Bloch
На каких технологиях будет CMS?
Spring? Hibernate? JMS? что еще?
На каких технологиях будет CMS?
Spring? Hibernate? JMS? что еще?
Мне показалось, или к яве в последнее время интерес вновь увеличивается? Я вот тоже засмотрелся в сторону явы. Недавно писал статью: habrahabr.ru/blogs/webdev/76043/
Видимо, показалось: www.google.ru/trends?q=sun+java&ctab=0&geo=all&date=all&sort=0
после прочтения книги Экела очень рекомендую Блоха Effective Java — доступно, интересно и глубоко
java.sun.com/docs/books/effective/
java.sun.com/docs/books/effective/
По Java EE ОЧЕНЬ хорошая книга Горький вкус Java Брюса Тейта
Книга тейта чуток старомодна, но большинство идей здравые. Я перечитываю её раз в пару лет (: Не думаю, что с неё надо начинать, но пожалуй, она могла бы быть второй прочтённой книгой по Java: всё-таки требуется для начала пощупать Java хоть чуть-чуть, а потом уже думать о «квадратных пробках к круглой дыре» и т.п. ;)
Спасибо. Я сейчас на стадии выбора литературы. Теперь буду знать направление.
Вопрос: чем обусловлен выбор j2ee, а не j2se?
Для реализации цсм j2se вполне хватает имхо — не судите строго, а лучше аргументируйте — мне интересно
Не увидел упоминание ни про oc4j или OAS ни websphere — используете ли вы их?
Сам вот последний год на j2ee работаю (до этого 2 года j2se) но работы по изучению еще вагон и тележка.
Для реализации цсм j2se вполне хватает имхо — не судите строго, а лучше аргументируйте — мне интересно
Не увидел упоминание ни про oc4j или OAS ни websphere — используете ли вы их?
Сам вот последний год на j2ee работаю (до этого 2 года j2se) но работы по изучению еще вагон и тележка.
простите цсм = CMS
Вопрос чем-то плох?
Я так понимаю у каждой редакции языка свое предназначение.
Меня интересует не будет ли энтерпрайс тяжеловесен для поставленной задачи? (вероятно что не будет но все же)
Я так понимаю у каждой редакции языка свое предназначение.
Меня интересует не будет ли энтерпрайс тяжеловесен для поставленной задачи? (вероятно что не будет но все же)
В качестве клиента мы планируем использовать браузер. Фронтенд хотим делать с аяксом. Информация будет храниться в БД. Само приложение размещается на отдельной машине — сервере приложений. Хочется разграничения доступа, расширяемости, простоты использования из разных рабочих мест. Для справочной системы однозначно нужен браузер.
Может я грубовато как-то описал, но разве я не описываю структуру типового web-приложения, для разработки которого нужны библиотеки и технологии, выходящие за рамки SE?
При использовании SE я должен разрабатывать апплеты или вообще настольные приложения на Swing c некими модулями, крутящимися на сервере.
Может быть масштаб задачи и маловат для промышленной технологии, это да.
Может я грубовато как-то описал, но разве я не описываю структуру типового web-приложения, для разработки которого нужны библиотеки и технологии, выходящие за рамки SE?
При использовании SE я должен разрабатывать апплеты или вообще настольные приложения на Swing c некими модулями, крутящимися на сервере.
Может быть масштаб задачи и маловат для промышленной технологии, это да.
Есть «легкие» альтернативы j2ee, это, это например, комплекс из tomcat+spring+hibernate. В браузере результат совершенно тот же, но все без WebSphere+EJB.
oc4j, OAS — не знаю, что это (:
Насчет среды (IDE) — IDEA only. :-)
Вот вам форум в помощь по SCJP. Там найдете все, что вам нужно.
> pinger
последний раз, когда имел дело с явой, icmp считался недостаточно высокоуровневым для нее протоколом и пингануть тачку из явишного кода было невозможно — только вызов внешней ping утилиты или стук на определенный тисипишный порт
а как с этим обстоят дела сейчас?
последний раз, когда имел дело с явой, icmp считался недостаточно высокоуровневым для нее протоколом и пингануть тачку из явишного кода было невозможно — только вызов внешней ping утилиты или стук на определенный тисипишный порт
а как с этим обстоят дела сейчас?
а условно поподробней можно?
а то кроме бесполезного isReachable или попыток коннекта на заданный порт ничего явишного не нашел
а то кроме бесполезного isReachable или попыток коннекта на заданный порт ничего явишного не нашел
> Для пинга — именно isReachable и есть.
isReachable — шлак
я пробовал его из-под винды и из-под федоры, в обоих случаях вместо честного пинга стучался на 7 порт (протокол ECHO)
> netresearch.ics.uci.edu/kfujii/jpcap/
403 Forbidden
> Т.е. так или иначе — это С и нативное прокладко
с и нативная прокладко — угу, пресловутая явишная кроссплатформенность во всей красе
isReachable — шлак
я пробовал его из-под винды и из-под федоры, в обоих случаях вместо честного пинга стучался на 7 порт (протокол ECHO)
> netresearch.ics.uci.edu/kfujii/jpcap/
403 Forbidden
> Т.е. так или иначе — это С и нативное прокладко
с и нативная прокладко — угу, пресловутая явишная кроссплатформенность во всей красе
> Про isReachable — ну, собсно, да. Шлак :) Но это icmp и задачу пытается выполнять. Просто ранее 1.5 и его не было, так что — имхо (!) лучше чем ничего.
на счет того, что изРичибл — это исмп — кагбы не совсем правда (как минимум в тех реализациях, которые я пробовал)
лучше конечно, чем ничего
просто жалко, что ничего не изменилось за два года
насколько я понял, разработчики явы не приемлют исмп по идейным соображениям
на счет того, что изРичибл — это исмп — кагбы не совсем правда (как минимум в тех реализациях, которые я пробовал)
лучше конечно, чем ничего
просто жалко, что ничего не изменилось за два года
насколько я понял, разработчики явы не приемлют исмп по идейным соображениям
> Прошу прощения за линк, из явадока выдрал :)
> netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html так правильно.
за линк — спасибо
такая либа очень даже может пригодиться
> netresearch.ics.uci.edu/kfujii/jpcap/doc/index.html так правильно.
за линк — спасибо
такая либа очень даже может пригодиться
Вы правы, я вызывал внешний ping. И по-моему icmp для Джавы так и остался недостаточно высокоуровневым (:
А почему выбирали только между Java EE и ASP.Net? Как же довольно дерзкие последнее время Django (Python) и Ruby on Rails. Они содержат много интересных идей, на них очень быстрая и ясная разработка и прочитать всего нужно одну книгу, вместе огромных томов по чисто корпоративным технологиям.
Область применеия Java гораздо больше, поэтому и книжки толще, а для простых вещей Grails есть.
Или JRuby с тем же Ruby on Rails.
Хотя для простых вещей сервлет-контейнер разворачивать гораздо сложнее. Rails можно запустить модулем в Apache, а многие VPS-хостеры делают авторазворачивание rails-сайта с git-репозитория одной кнопкой :).
Тем не менее поставленные в оглашённые в топике примеры гораздо проще и быстрее решаются с помощью Django и Rails.
Хотя для простых вещей сервлет-контейнер разворачивать гораздо сложнее. Rails можно запустить модулем в Apache, а многие VPS-хостеры делают авторазворачивание rails-сайта с git-репозитория одной кнопкой :).
Тем не менее поставленные в оглашённые в топике примеры гораздо проще и быстрее решаются с помощью Django и Rails.
> Или JRuby с тем же Ruby on Rails.
JRuby — для рубистов всё же. Grails _на порядок_ проще для Java-разработчиков: Spring, Hibernate, JSP/JSTL — Grails просто DSL ко всему этому, а Groovy — всего лишь обратно совместимое расширение синтаксиа Java.
> Хотя для простых вещей сервлет-контейнер разворачивать гораздо сложнее. Rails можно запустить модулем в Apache, а многие VPS-хостеры делают авторазворачивание rails-сайта с git-репозитория одной кнопкой :).
Вы с Java вообще работали?
library.linode.com/web-frameworks/tomcat/installing-apache-tomcat-ubuntu-jaunty
library.linode.com/web-frameworks/ruby-on-rails/installing-ruby-on-rails-with-apache
Где тут сложнее(2 команды vs 3 страницы)? Для Amazon EC2 есть CloudFoundry, так же Grails прекрасно работает с Google App Engine.
> Тем не менее поставленные в оглашённые в топике примеры гораздо проще и быстрее решаются с помощью Django и Rails.
Ну видно человек с прицелом на будущее.
JRuby — для рубистов всё же. Grails _на порядок_ проще для Java-разработчиков: Spring, Hibernate, JSP/JSTL — Grails просто DSL ко всему этому, а Groovy — всего лишь обратно совместимое расширение синтаксиа Java.
> Хотя для простых вещей сервлет-контейнер разворачивать гораздо сложнее. Rails можно запустить модулем в Apache, а многие VPS-хостеры делают авторазворачивание rails-сайта с git-репозитория одной кнопкой :).
Вы с Java вообще работали?
library.linode.com/web-frameworks/tomcat/installing-apache-tomcat-ubuntu-jaunty
library.linode.com/web-frameworks/ruby-on-rails/installing-ruby-on-rails-with-apache
Где тут сложнее(2 команды vs 3 страницы)? Для Amazon EC2 есть CloudFoundry, так же Grails прекрасно работает с Google App Engine.
> Тем не менее поставленные в оглашённые в топике примеры гораздо проще и быстрее решаются с помощью Django и Rails.
Ну видно человек с прицелом на будущее.
Но не отдавать же Tomcat’ом статику ;). Для нормальной системы надо вперёд пустить Apache httpd или nginx для статики, а уже за ним через проксирование контейнер сервлетов. С Passanger Rails можно интегрировать сразу в Apache и nginx.
Почему нет? NIO & APR в Tomcat 6 творят чудеса. Apache/Nginx поставить можно без проблем если нужно кому-то.
Есть 100 за и 100 против. У нас такой проблемы не стоит: Amazon EC2 с томкатами, а статика вся на S3. Ну и плюс есть оптимизаторы, GWT например из коробки жмёт всю статику в один файл.
Ну локально тестирую то без S3 и работает достаточно шустро.
У нас всё же бизнес-проект, и большинство хранящихся на Amazon файлов(фото) просматривается раз 5 за всю их жизнь. Да и инстансы EC2 + S3 идут клиенту отдельной строкой как хостинг, если брать reserved то получается недорого + очень удобно сопровождать и мониторить.
У нас всё же бизнес-проект, и большинство хранящихся на Amazon файлов(фото) просматривается раз 5 за всю их жизнь. Да и инстансы EC2 + S3 идут клиенту отдельной строкой как хостинг, если брать reserved то получается недорого + очень удобно сопровождать и мониторить.
Тоже так думал, но решил поставить перед ним Nginx — время отдачи страниц сократилось примерно в 5 раз, за счет статики в основном.
По-моему, удобнее изучить JavaSE и Rails/Gjango — всё таки для разных миров разные технологии :).
Чем конкретно удобнее-то? Учить 2 рантайма вместо одного? 2 языка? 2 набора библиотек?
Драйвера, ОС и прикладные приложения пишут же на разных языках. Тем более, что даже на одном языке разница в разработке desktop- и web-приложения гораздо существеннее — в вебе другие задачи, нужно понимать вёрстку и так далее. Ну а какой-нить бекенд сетевого чата удобнее на Erlang писать.
Даже единый язык разметки XML не прижился — конфиги удобнее в YAML, обмен объектами в JSON, в простой вызов процедур в RESTfull.
Вполне, единой технологии для всего не существует — это утопия, для реализации которой мы будет тратить больше средств, чем выигрываем.
Даже единый язык разметки XML не прижился — конфиги удобнее в YAML, обмен объектами в JSON, в простой вызов процедур в RESTfull.
Вполне, единой технологии для всего не существует — это утопия, для реализации которой мы будет тратить больше средств, чем выигрываем.
Что-то вы мысью по древу. Блогерам-хакерам может и удобнее с 10 языками и форматами, а крупным компаниям удобнее со стандартизированными вещами. Именно поэтому тот же Google жёстко определил список возможных к использванию языков среди сотрудников, и на Java они пишут всё: от Mobile(Android) до Web-интерфейсов(GWT), не говоря уже о приложениях(Docs, GMail, AdWords, YouTube и т.п.).
У Google как раз три языка — C, Java и Python (о котором я говорил как альтернативе Ruby) ;).
И что? На Python они пишут всё меньше и меньше:
groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1 И никаких особых бонусов по сравнению с Groovy для Java-разработчика он не несёт. Или несёт? Какие?
Тот же BigTable может быть реализован на Java: Hadoop/HBase(Yahoo), Cassandra(Facebook), Voldemort(LinkedIn).
groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e?pli=1 И никаких особых бонусов по сравнению с Groovy для Java-разработчика он не несёт. Или несёт? Какие?
Тот же BigTable может быть реализован на Java: Hadoop/HBase(Yahoo), Cassandra(Facebook), Voldemort(LinkedIn).
Не рад holly war’а, а ради интереса: какие задачи для JavaEE, нерешаемы или неэффективны в Django/Rails?
Любые, где нужна многопоточность, производительность, возможность синтаксического анализа и безболезненного рефакторинга большой кодовой базы, тех поддержка вендора(Oracle, Red Hat, SAP, IBM, Sun etc.)
Хм, не считая производительности (мы ведь понимаем, что в вебе главнее масштабирование) и вендорной поддержки, всё это есть у Rails (а у Gjango и со скоростью неплохо).
Многопоточность в Rails, например, можно сделать с помощью delated_jobs, что будет гораздо эффективнее запуска отдельного Thread.
Про синтаксический анализ сказать правда много не могу (не занимался и не знаю хороших библиотек), но многий синтаксис можно представить как DSL к Ruby, да и у Cucumber (описание тестов обычным языком) проблем тоже вроде нет.
Рефакторинг в Rails не сложен, так как рельсы сразу идут с хорошей архитектурой. С хорошим unit-тестированием, это не проблема, а в рельсах очень хорошо с тестированием ;). И поскольку кодовая база часто унифицирована, то проще использовать множество готовых решений.
Многопоточность в Rails, например, можно сделать с помощью delated_jobs, что будет гораздо эффективнее запуска отдельного Thread.
Про синтаксический анализ сказать правда много не могу (не занимался и не знаю хороших библиотек), но многий синтаксис можно представить как DSL к Ruby, да и у Cucumber (описание тестов обычным языком) проблем тоже вроде нет.
Рефакторинг в Rails не сложен, так как рельсы сразу идут с хорошей архитектурой. С хорошим unit-тестированием, это не проблема, а в рельсах очень хорошо с тестированием ;). И поскольку кодовая база часто унифицирована, то проще использовать множество готовых решений.
> Хм, не считая производительности (мы ведь понимаем, что в вебе главнее масштабирование) и вендорной поддержки, всё это есть у Rails (а у Gjango и со скоростью неплохо).
Что вы делаете, когда упираетесь в производительность? Пишите на Си? Нет уж, спасибо. Если вы с этим не сталкивались, не значит что этого нет. Или вы думаете Shopify можно без проблем смасштабировать до размеров Amazon, оставив его на Ruby?
> Многопоточность в Rails, например, можно сделать с помощью delated_jobs, что будет гораздо эффективнее запуска отдельного Thread.
Чушь. Это не многопоточность.
> Про синтаксический анализ сказать правда много не могу (не занимался и не знаю хороших библиотек), но многий синтаксис можно представить как DSL к Ruby, да и у Cucumber (описание тестов обычным языком) проблем тоже вроде нет.
Я про FindBugs, IntelliJ IDEA, Eclipse…
> Рефакторинг в Rails не сложен, так как рельсы сразу идут с хорошей архитектурой. С хорошим unit-тестированием, это не проблема, а в рельсах очень хорошо с тестированием ;). И поскольку кодовая база часто унифицирована, то проще использовать множество готовых решений.
Если вы ни разу не вылезали за масштабы Rails приложения, вполне вероятно, что Rails вам достаточно для работы. Речь о более крупных. Что касается тестирования — прогнать все тесты у инжинеров GMail занимает 5 часов, я не знаю, сколько бы заняло это если бы их писали на Ruby.
Что вы делаете, когда упираетесь в производительность? Пишите на Си? Нет уж, спасибо. Если вы с этим не сталкивались, не значит что этого нет. Или вы думаете Shopify можно без проблем смасштабировать до размеров Amazon, оставив его на Ruby?
> Многопоточность в Rails, например, можно сделать с помощью delated_jobs, что будет гораздо эффективнее запуска отдельного Thread.
Чушь. Это не многопоточность.
> Про синтаксический анализ сказать правда много не могу (не занимался и не знаю хороших библиотек), но многий синтаксис можно представить как DSL к Ruby, да и у Cucumber (описание тестов обычным языком) проблем тоже вроде нет.
Я про FindBugs, IntelliJ IDEA, Eclipse…
> Рефакторинг в Rails не сложен, так как рельсы сразу идут с хорошей архитектурой. С хорошим unit-тестированием, это не проблема, а в рельсах очень хорошо с тестированием ;). И поскольку кодовая база часто унифицирована, то проще использовать множество готовых решений.
Если вы ни разу не вылезали за масштабы Rails приложения, вполне вероятно, что Rails вам достаточно для работы. Речь о более крупных. Что касается тестирования — прогнать все тесты у инжинеров GMail занимает 5 часов, я не знаю, сколько бы заняло это если бы их писали на Ruby.
Задачи решаемы каждым языком, но в одном случае возьмешь готовую технологию, которая стандарт де-факто, а может и де-юро(а значит у заказчика не будет вопросов, админы имеют опыт ставить и мониторить, и в уже имеющемся ИТ отделе есть специалисты умеющие поддерживать технологи и т.д.), а в другом будешь придумывать что то свое, обосновывать отличие от зарекомендовавших себя подходов (то почему журнал CIO до сих пор не сделала выпуск посвященный предлагаемому вами решению, с кучей success stories в компаниях из Fortune 500), потом обучать ИТ-службу заказчика (за свой счет) и т.д. В общем это вопрос совсем не уровня языка.
Навскидку это различные распределенные транзакции, интеграции внешних систем (SOA, ESB и SOAP, XML-RPC, CORBA, FTP), сообщения (JMS, MQ), системы анализа и принятия решений. Плюс до кучи чтобы все это мониторилось, аудировалось, и не падало. Все это можно и на Руби реализовать, не проблема, но зачем?
ps не ради holy war
Навскидку это различные распределенные транзакции, интеграции внешних систем (SOA, ESB и SOAP, XML-RPC, CORBA, FTP), сообщения (JMS, MQ), системы анализа и принятия решений. Плюс до кучи чтобы все это мониторилось, аудировалось, и не падало. Все это можно и на Руби реализовать, не проблема, но зачем?
ps не ради holy war
ээ… _годовой_ отчёт?
Скажите, а почему имея опыт php выбрали Java? Мне просто любопытно.
На мой взгляд, учиться нужно на множестве небольших примеров, осваивая каждую технологию в рамках того, что есть в ее официальной документации и пытаясь произвольно стыковать разные технологии так, как только придет вам в голову. Шанс самостоятельно подобрать правильную архитектуру для первого проекта на джаве стремится к 0, поэтому не имеет никакого смысла затевать что-то большое. Кроме того, не следует доверять курсам, мнениям старперов (моему, в частности) и вообще как-то заморачиваться. Дело в том, что в джава-мире обычно действуют большие группы, часто на технологиях, устаревших много лет назад, связанные долгосрочными отношениями с поставщиками решений. Поскольку каждый хочет казаться компетентным, существует множество людей, которых научили программировать в какой-то крупной компании, и они по инерции считают, что те или иные фреймворки — круты, несмотря на то, что архитектура была, возможно, выбрана исходя из того, поставщик какого сервера приложения откатил больше техническому решению или чему научился на курсах в предыдущей конторе ведущий разработчик. Следует избегать всего, что исходит от компаний-интеграторов — вовне их технологии неприменимы, а если уж вам доведется туда попасть, вас погрузят во все нюансы. Технологии «по документации» никогда не используются на больших проектах.
Eclipse принято советовать новичкам, поскольку он бесплатен. В нем все супер до тех пор, пока вы имеете дело с «чистым» джава-кодом, отладкой его и всем, что не выходит за рамки запуска единственного проекта с пом main(). Как только вы пытаетесь запустить произвольный сервер приложений, или хотите для фреймворка ХХХ пользоваться мастером (тем более, производить рефакторинг кода, написанного с использованием такого фреймворка), начинается геморрой, поскольку плагины либо написаны криворукими бесплатными разработчиками, либо плохо совместимы с текущей сборкой, либо не работают друг с другом и так далее и тому подобное. Мой опыт говорит, что чем потом терять в производительности, лучше сразу переучиться на IDEA. Достичь ее пределов довольно сложно, а глюки, если они и бывают, некритичны и исправляются быстро.
Не советую тратить много времени на изучение веб-фреймворков для джавы. Нужно идеально знать, как устроен сервлет-контейнер (пройтись по исходникам томкета и джетти), однако упаси вас бог по собственной воле встрять в разработку на JSF, Struts и прочем подобном. Продуктивность на таких проектах минимальна, никакие паттерны современной веб-разработки на эти фреймворки не ложатся, а получаемый результат зачастую уродлив. Для того, чтобы получить на подобных технологиях хотя бы удовлетворительный «сайт», придется вложить колоссальное количество усилий без гарантии, что код останется поддерживаемым. В то же время имеет смысл как можно больше внимания уделять технологиям интеграции — от организации веб-сервисов до серверов очередей.
Удач.
Eclipse принято советовать новичкам, поскольку он бесплатен. В нем все супер до тех пор, пока вы имеете дело с «чистым» джава-кодом, отладкой его и всем, что не выходит за рамки запуска единственного проекта с пом main(). Как только вы пытаетесь запустить произвольный сервер приложений, или хотите для фреймворка ХХХ пользоваться мастером (тем более, производить рефакторинг кода, написанного с использованием такого фреймворка), начинается геморрой, поскольку плагины либо написаны криворукими бесплатными разработчиками, либо плохо совместимы с текущей сборкой, либо не работают друг с другом и так далее и тому подобное. Мой опыт говорит, что чем потом терять в производительности, лучше сразу переучиться на IDEA. Достичь ее пределов довольно сложно, а глюки, если они и бывают, некритичны и исправляются быстро.
Не советую тратить много времени на изучение веб-фреймворков для джавы. Нужно идеально знать, как устроен сервлет-контейнер (пройтись по исходникам томкета и джетти), однако упаси вас бог по собственной воле встрять в разработку на JSF, Struts и прочем подобном. Продуктивность на таких проектах минимальна, никакие паттерны современной веб-разработки на эти фреймворки не ложатся, а получаемый результат зачастую уродлив. Для того, чтобы получить на подобных технологиях хотя бы удовлетворительный «сайт», придется вложить колоссальное количество усилий без гарантии, что код останется поддерживаемым. В то же время имеет смысл как можно больше внимания уделять технологиям интеграции — от организации веб-сервисов до серверов очередей.
Удач.
Спасибо за развернутый ответ.
Еще немного подумаю, и буду решать, что учить дальше. В вакансиях на позиции java-разработчика постоянно фигурируют требования знать эти фреймворки. Я от этого и пляшу. В период так называемого «кризиса» джуниоров стараются не брать, так что хочу подготовиться на позицию сразу разработчика (на сколько это возможно).
Я пока что не могу придумать себе задачу для использования веб-сервисов и т.п. Если подскажете — буду признателен. (:
Насчет IDEA — согласен с вами.
Еще немного подумаю, и буду решать, что учить дальше. В вакансиях на позиции java-разработчика постоянно фигурируют требования знать эти фреймворки. Я от этого и пляшу. В период так называемого «кризиса» джуниоров стараются не брать, так что хочу подготовиться на позицию сразу разработчика (на сколько это возможно).
Я пока что не могу придумать себе задачу для использования веб-сервисов и т.п. Если подскажете — буду признателен. (:
Насчет IDEA — согласен с вами.
А фиг знает, для изучения сервисов попробуйте, например, освоить стыковку визуальной части Flex-а или Ext через бекенд, предоставляющий доступ к сервисам с форматом выдачи в JSON или XML. Для этого можно, например, использовать Apache CXF. С SOAP можете не связываться, все равно не сможете применить куда-либо осмысленно. Напишите по результатам статью, переведите ее на английский язык, вставьте там скриншотики и выложите где-нибудь — этого будет вполне достаточно, вопросы большинства работодателей по поводу вашей адекватности это покрывает с лихвой.
Обычно все понимают, что серьезный разработчик может и не знать в деталях какого-то конкретного фреймворка, но зато способен разобраться в том, как его использовать за конечное время и, главное, понимает, что на нем делать можно, а чего — нельзя, и во что это выльется. К сожалению, это приходит с опытом, однако, если много всего перепробовать и быть любознательным, то появляется здравый взгляд на многие вещи, который сильно помогает. Между тем, потратить время на то, чтобы разобраться, что из себя представляют JSF и Struts — просто необходимо — всегда нужно собственное мнение. Вдруг понравится.
Проект на джаве это, чаще всего, не один человек и даже иногда не одна команда. Я всегда обращаю внимание на то, упомянуты ли в резюме «инфраструктурные» инструменты — особенно Maven (или, хуже, Ant), умеет ли товарисч писать тесты, понимает ли, как произвести нагрузочное тестирование и как сделать из него правильные выводы, знаком ли с инструментами ведения проекта, например, багтрекером JIRA, знает ли SVN (попадаются и незнающие), может ли пользоваться линуксом (хотя бы перезапустить томкет и посмотреть, не кончилось ли место на диске). Очень хорошо посвятитеть некоторое время изучению java reflection (потому что это один из ключей к пониманию того, как jvm работает). На мой взгляд, тонкости владения языком совершенно не важны, если конечный продукт не умеет собираться с консоли или вы не можете обеспечить работу среды, в которой он будет выполняться. Использование правильных инструментов — это половина успеха, другая половина — это опыт. Нюансы, касающиеся именно программирования (некритичные для работоспособности, типа, как покрасивее написать) вообще не важны.
Обычно все понимают, что серьезный разработчик может и не знать в деталях какого-то конкретного фреймворка, но зато способен разобраться в том, как его использовать за конечное время и, главное, понимает, что на нем делать можно, а чего — нельзя, и во что это выльется. К сожалению, это приходит с опытом, однако, если много всего перепробовать и быть любознательным, то появляется здравый взгляд на многие вещи, который сильно помогает. Между тем, потратить время на то, чтобы разобраться, что из себя представляют JSF и Struts — просто необходимо — всегда нужно собственное мнение. Вдруг понравится.
Проект на джаве это, чаще всего, не один человек и даже иногда не одна команда. Я всегда обращаю внимание на то, упомянуты ли в резюме «инфраструктурные» инструменты — особенно Maven (или, хуже, Ant), умеет ли товарисч писать тесты, понимает ли, как произвести нагрузочное тестирование и как сделать из него правильные выводы, знаком ли с инструментами ведения проекта, например, багтрекером JIRA, знает ли SVN (попадаются и незнающие), может ли пользоваться линуксом (хотя бы перезапустить томкет и посмотреть, не кончилось ли место на диске). Очень хорошо посвятитеть некоторое время изучению java reflection (потому что это один из ключей к пониманию того, как jvm работает). На мой взгляд, тонкости владения языком совершенно не важны, если конечный продукт не умеет собираться с консоли или вы не можете обеспечить работу среды, в которой он будет выполняться. Использование правильных инструментов — это половина успеха, другая половина — это опыт. Нюансы, касающиеся именно программирования (некритичные для работоспособности, типа, как покрасивее написать) вообще не важны.
как вариант можно сделать сильно упрощенную версию CMS, но, например, рассчитанную под определенную нагрузку ( среднюю и высокую ).
К.О. тут мне подсказывает: SUN == Stanford University Network, если кто не в курсе. Поэтому смотреть лекции Stanford по поводу Java очень неплохая идея.
Сначала благодарности :)
Автору — за толковый подход. Всех читающих прошу обратить внимание, как человек подошел к вопросу: изучает документацию, придумывает задачи, решает их, делает выводы. При всей кажущейся банальности так делают минимум (!) людей. Говорю это как человек, который помог приобщиться к Java технологиям десятку человек.
Далее хочу обратить внимание на комментраии товарищей metakey cocojumber. Очень и очень взвешенные и адекватные мысли.
И, наконец, по сути вопроса.
Совершенно не хочу повышать энтропию и писать сюда еще список технологий, которые можно учить — это вам подскажет опыт, здравый смысл и рынок. Я приведу лишь пример из жизни, иллюстрирующий важность базовых вещей над производными.
Я работаю с Java уже более 7 лет и поучаствовал в проектах различного масштаба. Одним из них был небольшой проект по созданию ряда прототипов для оценки технологий a-la in-memory storage (Terracotta, Gigaspaces, Coherence). Одно из требований к прототипу звучало как «разработка с использованием базовых библиотек Java». Так как одной из задач была грубая оценка производительности веб-приложения, которое должно было общаться с такого рода storage системами, то мы «закатав рукава» писали простые сервлеты, вспоминали как их корректно использовать в мультипоточной среде, как работают всевозможные lock и thread-safe классы из java.util.concurrent. И при этом ни Spring'ом, ни Hibernate'ом, никаким MVC фреймворком там и не пахло.
Прошло время, я уехал в Калифорнию, участвую в разработке высоконагруженного веб-ресурса и уверяю вас: количество используемых фреймворков дикутется реальным нуждами. Решение об использовании того или другого принимается на основе оценки его производительности, расширяемости и т.д. При этом достаточно много «велосопедов» изобретено заново из-за того, что существующие фреймворки не удовлетворяют требованиям производительности.
Мой посыл в том, что понимание базовых вещей (что находиться ниже Hibernate, Spring, Struts или JSF, над каким протоколом построен SOAP или как проходит общение между сервером и клиентом в GWT) — очень важно. Знание нижележащих уровней позволят вам строить предположения о принципиальном устройстве работы неизвестных вам фреймворков, задавать правильные вопросы когда очередной адепт фреймворка А утверждает, что ничего подобного вы доселе не знали, понимать что ничего волшебного в проприетарных продуктах от IBM, Oracle и иже с ними нет, а построены они на тех же базовых вещах.
В моем понимании, знание базовых вещей в Java для человека, который собирается провести некоторое время с этим языком так же необходимо, как знание базовых алгоритмов и структур для инженера, считающего себя разработчиком программного обеспечения.
В заключении отыскал старую статью A new breed: Framework Java Coder? как раз в ключе моего поста.
Желаю вам удачи, вы на верном пути.
P.S. Intellij IDEA — вещь! Использую с версии 4.0 (2003 год, если не ошибаюсь).
Автору — за толковый подход. Всех читающих прошу обратить внимание, как человек подошел к вопросу: изучает документацию, придумывает задачи, решает их, делает выводы. При всей кажущейся банальности так делают минимум (!) людей. Говорю это как человек, который помог приобщиться к Java технологиям десятку человек.
Далее хочу обратить внимание на комментраии товарищей metakey cocojumber. Очень и очень взвешенные и адекватные мысли.
И, наконец, по сути вопроса.
Совершенно не хочу повышать энтропию и писать сюда еще список технологий, которые можно учить — это вам подскажет опыт, здравый смысл и рынок. Я приведу лишь пример из жизни, иллюстрирующий важность базовых вещей над производными.
Я работаю с Java уже более 7 лет и поучаствовал в проектах различного масштаба. Одним из них был небольшой проект по созданию ряда прототипов для оценки технологий a-la in-memory storage (Terracotta, Gigaspaces, Coherence). Одно из требований к прототипу звучало как «разработка с использованием базовых библиотек Java». Так как одной из задач была грубая оценка производительности веб-приложения, которое должно было общаться с такого рода storage системами, то мы «закатав рукава» писали простые сервлеты, вспоминали как их корректно использовать в мультипоточной среде, как работают всевозможные lock и thread-safe классы из java.util.concurrent. И при этом ни Spring'ом, ни Hibernate'ом, никаким MVC фреймворком там и не пахло.
Прошло время, я уехал в Калифорнию, участвую в разработке высоконагруженного веб-ресурса и уверяю вас: количество используемых фреймворков дикутется реальным нуждами. Решение об использовании того или другого принимается на основе оценки его производительности, расширяемости и т.д. При этом достаточно много «велосопедов» изобретено заново из-за того, что существующие фреймворки не удовлетворяют требованиям производительности.
Мой посыл в том, что понимание базовых вещей (что находиться ниже Hibernate, Spring, Struts или JSF, над каким протоколом построен SOAP или как проходит общение между сервером и клиентом в GWT) — очень важно. Знание нижележащих уровней позволят вам строить предположения о принципиальном устройстве работы неизвестных вам фреймворков, задавать правильные вопросы когда очередной адепт фреймворка А утверждает, что ничего подобного вы доселе не знали, понимать что ничего волшебного в проприетарных продуктах от IBM, Oracle и иже с ними нет, а построены они на тех же базовых вещах.
В моем понимании, знание базовых вещей в Java для человека, который собирается провести некоторое время с этим языком так же необходимо, как знание базовых алгоритмов и структур для инженера, считающего себя разработчиком программного обеспечения.
В заключении отыскал старую статью A new breed: Framework Java Coder? как раз в ключе моего поста.
Желаю вам удачи, вы на верном пути.
P.S. Intellij IDEA — вещь! Использую с версии 4.0 (2003 год, если не ошибаюсь).
Тогда мне на помощь приходили замечательные видео-курсы Стэнфордского университета CS106A (видео лежит на youtube)
Еще один замечательный видеокурс: www.lektorium.tv/course/?id=22824 Новичку — самое оно.
Просмотрите на возможный следующий следующий этап: участие в проекте Java Enterprise "Наиболее востребованные технологии /инструменты / фреймворки Java Enterprise: Maven/ Spring/ Security/ JPA(Hibernate)/ REST(Jackson)/ Bootstrap(css, js)/ jQuery + plugins/ Java 8 Lambda, Stream and Time API.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой отчет по годовому изучению платформы Java EE