×Закрыть

Java Enterprise: что и как учить

Я выступал с аналогичной темой на IT fest, и, судя по реакции зала, людям было интересно. Формат доклада сжатый, многое пришлось проговаривать уже потом, отдельно от выступления. Да и качество записи вышло не очень, не всё слышно. Поэтому решил написать статью.

Сначала о себе любимом. У меня достаточно большой опыт работы java-разработчиком (с 2001 года, даже считать страшно), а программистом и того больше — с 96-го. Большую часть из этих лет я работал тимлидом в разных аутсорсинговых компаниях Киева. Кроме того, более 10 лет я преподаю в учебных центрах Luxoft, NetCracker и вот IntroPro. И даже год вёл в школе информатику. В общем, обучать умею. Ну и с другой стороны, во многих компаниях я выступал как технический специалист, проводящий собеседование. Так что я еще и тот самый человек, который знает, о чем вас будут спрашивать на будущей работе. В этом году я принял участие в создании учебной программы по java в GoIT и преподавал в одной из групп. Большинство моих студентов уже работают.

Я это всё рассказал не ради хвастовства, а для того, чтобы пояснить, на чём я основываюсь, говоря о списке технологий и порядке обучения.

Итак, начнем, и внезапно с конца — я соберу выводы, которые сделал из обучения молодых специалистов.

Первый вывод самый печальный — программистами могут стать не все. И нечего смеяться! Изначально я рассчитывал, что научиться программировать может любой. А чего там, программирование — откровенно не rocket science. Бери больше, кидай дальше. Но всё оказалось не так. Всё уперлось в мотивацию. Сейчас объясню.

Не бывает людей вообще без способностей к программированию. Но всё равно — все люди разные. Так вот, обучаясь (в том числе и программированию), вы тратите мотивацию. Достигая чего-то в процессе обучения — вы мотивацию восполняете. И чем меньше у вас способностей, тем тяжелее вам продвигаться до очередного достижения. Если у вас было не так уж много мотивации, вы рискуете просто до следующего достижения не доучиться. А другой человек, возможно с меньшей мотивацией, чем у вас, но с большими способностями просто будет щелкать задачи как орехи и доучится. Се ля ви.

Второй вывод. Учиться java-разработчику без ментора, работающего в этой сфере — невозможно. Наша индустрия полна огромным количеством невнятных и даже контр-интуитивных знаний о том, как надо поступать и как не надо. Сами вы в этом не разберетесь. Гарантированно.

После конференции меня спрашивали — так что же делать, если наставника нет? Отвечаю: найдите себе ментора. Понимаете, программистам тоже надо расти, из миддлов становиться сеньорами, из сеньоров — тимлидами и так далее. И для всего этого надо получить опыт руководства, общения с подчиненными. И где его взять? Тут проблема та же самая, что и у джунов — нужен опыт, чтобы получить определенную работу. А получить его можно только на этой работе. Так что помогите друг другу.

Где найти такого ментора? Потусуйтесь на форумах программистов (на том же DOU) — постучитесь к людям в личку с вопросом: «Простите, а можно я буду вам время от времени вопросы задавать?» Большинство согласится. Полазьте на линкедин, в конце концов.

Третье. Самое важное, что делает java-разработчика java-разработчиком — привычка и способность быстро находить знания и впитывание их с необходимой скоростью. Именно на это должен быть нацелен процесс обучения джавистов. Учить их по классической университетской схеме (лекции, семинары) — бессмысленно. Только по жестокой схеме: раскачали и кинули в омут. Кто сможет — выплывет. Ну а если человек не может совладать с тем, что кроме него никто задачу не решит («есть ты и есть задача, все остальное зависит от тебя»), то ему программистом не стать. Другой разговор, что задачи должны быть подобраны с правильной сложностью — чтобы их можно было решить, но для этого требовалось напрячь все возможности.

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

Что же должен знать java разработчик

Здесь я просто приведу список, а потом раскрою все пункты отдельно:
— Core Java;
— ООП;
— JDBC;
— Servers + Servlets +JSP;
— Spring;
— ORM;
— Web-frameworks;
— Web-services (SOAP, REST);
— SQL, HTML, JavaScript;
— Специфичные требования.

Core Java и ООП

Меня постоянно спрашивают, что я имею в виду под знанием ООП. Рассказываю. Прежде всего, это означает свободно ориентироваться в трёх принципах ООП. Понимать, как работает наследование и полиморфизм. То есть если один класс наследуется от другого, кого и к чему надо приводить, а что автоматически является экземпляром чего. Если у базового класса и у дочернего есть метод с одинаковой сигнатурой, то какие именно ограничения накладываются на типы принимаемых и возвращаемых значений, а также бросаемых исключений. Что будет в compilation time, а что в run time. Ну и так далее. Человек, который этого не понимает, нормальный код не напишет — это уже проверено. Лично мы таких просто не берем, даже если у человека хорошие знания фреймворков. Себе дороже будет потом его код поддерживать.

Из Core java нужно знать методы объекта Object и Collection Framework. Enterprise java — это на 90% ковыряние в разных коллекциях. От них никуда не уйдешь.

Так же часто спрашивают про concurrency. Отвечу несколько спорно, но по моему опыту так. Есть проекты, которые жестоко завязаны на многопоточность. Для найма в эти проекты вас буду жестоко гонять по concurrency. В других проектах многопоточности особо нет, и вас там про нее ничего не спросят. Думаю, общее представление иметь необходимо всем, учить ли глубже — сами решайте. Другой разговор, что есть множество собеседователей, которые страшно любят эту тему и будут вас по ней спрашивать, даже если для проекта это все нафиг не надо. Почему именно многопоточность пользуется у них такой большой любовью — тут я только руками развожу.

JDBC (Java Database Connectivity)

Зачем учить то, чем никто уже в чистом виде не пользуется? По двум причинам.

Во-первых, новичков любят нанимать на проекты поддержки (support). А это в большинстве своем весьма древний софт, написанный кем-то левой задней. И вероятность того, что там используется plain JDBC — не нулевая.

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

Servers

Тут все просто. Любой java разработчик должен знать Tomcat. Он самый простой, самый легкий и пожалуй, имеющий наибольшую knowledge base. Спрашивать на собеседовании о нем вас никто не будет — предполагается, что вы его и так знаете. Не знать томкет — это стыд и позор. Имейте в виду.

Дальше стоит изучать уже JBoss/WildFly — всё-таки многие J2EE технологии на томкете не работают (те же EJB или кластерное решение, хотя, может, я отстал от жизни). А вот JBoss/WildFly — как раз оптимален. Он бесплатен и вполне функционален. Никто не ожидает от новичка, что он взял и скачал где-то WebLogic и фигачит код под него. А вот знание JBoss/WildFly — самое оно. Более того, он частенько используется даже у серьезных заказчиков

Unix-like

Про знания юникса вас могут максимум спросить — владеете ли и на каком уровне. Сразу отвечаю — достаточно владеть на уровне пользователя. Запустить, остановить, воспользоваться SSH и SCP. Ну в общем-то и все.

Servlets + JSP

Этот пункт аналогичен пункту про JDBC. И встречаются они всё-таки иногда, и знание того, что под капотом более современных web фреймворков — очень полезно. Как минимум, сокращает время нахождения ошибки в разы. Лишним не будет. Да и спросить на собеседовании об этом вполне могут.

Spring

Знание спринга — ультимативно. Как минимум, потому что спринг — отраслевой стандарт. И не важно, нравится вам спринг или нет. Главное, чтобы вы его знали. С вероятностью 80% вы будете с ним работать уже на одном первых трёх проектов. Да и вообще, энтерпрайз разработчик не должен перебирать — это хочу, это не хочу. Взялись и работаем. Вот это как раз тот случай.

Есть ещё CDI, стандарт от Оракла. Я провел опрос среди своих друзей, спрашивая, кто им пользуется. 80% ответили: «А что это такое?. Остальные 20% сказали: «Нет, не пользуемся». Так что можете смело на него забить.

ORM

Промышленным стандартом является Hibernate. Опять же, нравится он вам или нет, знать вы его обязаны. Использовать должны через JPA.

Объем знаний: уметь замепить отношения один-к-одному, один-ко-многим и многие-ко-многим. Написать HQL запрос и настроить лейзи загрузку.

Web-framework

В этом пункте всё-таки вкусовщина, но знание какого-либо веб-фреймоврка необходимо. JSF, так JSF. SpringMVC, так SpringMVC. Всё будет хорошо. Главное, чтобы вы могли хоть каким-то образом отрисовать UI. Все веб-фреймворки сходны в принципах работы, так что учите то, что покажется наиболее востребованным.

Web-services (SOAP, REST)

Ну, с REST вообще всё просто. От джавера там нужно только аннотацию повесить. И в принципе представлять, как оно работает.

С SOAP сложнее — надо знать несколько ключевых слов, описать, для чего служит WSDL, ну и представлять общие основы протокола.

SQL, HTML, JavaScript

Знание SQL — ультимативно. Вы должны его знать на уровне джавы. Сейчас даже на проекты, использующие NoSQL базы, не берут без хорошего знания SQL. Что уж говорить об остальных. Почему он так нужен — объяснять не буду, но если вкратце — на SQL вы будете писать часто и много. Естественно, не хранимые процедуры (хотя это тоже не исключено, но это всё-таки экзотика), но запросы на вставку и проверку тестовых данных — очень часто.

Я не беру людей на должность в двух случаях. Если они заваливаются на первом пункте (Core Java и ООП) и на этом. Делайте выводы.

Насчет знания HTML я даже говорить не буду. Чего там знать? Прочитал статью — ты уже его знаешь.Естественно, все хитрости и заморочки современных CSS — это хлеб Front End. Вот пусть они там и пасутся. Мы же должны хорошо знать HTML и немного JavaScript. Причем, знание JavaScript — отличный бонус для новичка. Знаете почему? Потому что новичков любят брать на саппортовый проект, в котором давно уже не работают дизайнеры. Java-скриптик подправить иногда надо, а джаверы его не любят. И если вы, в отличии от остальной команды, готовы им заниматься — все будут вас любить. И вы с бОльшими шансами попадете на работу, чем чистоплюи, которые не хотят ковыряться в этом вашем фронт-энде. Так что любите JavaScript, и будет вам счастье.

По объёмам знаний. Надо знать сам JavaScript. Хорошо также уметь читать JQuery. А ещё лучше — уметь его писать. Если вы обладаете соответствующим опытом — не стесняйтесь указать их в резюме. Это смежные с нами знания. Это вам не PHP какой-нибудь, про который джаверы говорят: «У тебя до сих пор есть в резюме PHP, тебе не стыдно?»

Знания скриптовых языков (sh, bash, perl &etc) — штука полезная. Как минимум, вы увеличиваете свои возможности по затыканию дыр — а это и есть основная суть работы на саппортовом проекте. Другой разговор, спрашивать вас об этом на собеседовании не будут, а выучить основы такого языка — дело пары дней. Так что я бы не советовал в это упираться.

Специфичные требования

Вы должны быть готовы, что при приеме на работу вас первым делом спросят: «А знаете ли вы фреймворк бла-бла-бла 4.2?» Нормальный ответ — нет, не знаю. В любом проекте есть какие-то странные вещи, которые только там и используются. Все знать вы не можете и не должны даже пытаться.

Как выбрать специализацию

Очень советую всем начинающим программистам выбрать себе специализацию. Сейчас объясню, что я имею в виду. Мы все — java-разработчики. Ок, все знают джаву, все знают более менее полный стек наших фреймворков. Но, в любом проекте будет цениться человек, который реально хорошо знает один из нужных фреймворков. Например — гуру по Hibernate. Или гуру по какому-нибудь PrimeFaces. Или — мощный знаток Oracle DB.

Вы поняли, к чему я. Да, знать нужно все, но что-то одно — выучить досконально. И поразить своими глубокими знаниями об устройстве вашего любимого фреймворка собеседователя. Да, естественно не в каждой команде нужен специалист именно по вашему любимому фреймворку. Там вы просто будете обычным джавером. Но в какой-то команде ваше появление будет встречено аплодисментами — «О! именно ты и был нам нужен, тебя нам послало небо!» Короче, вы поняли. Будьте как все, но немножко лучше :)

В каком порядке всё это изучать

Значит так, сначала ставим цели. Мы должны добиться того, чтобы новичок не боялся чудовищного массива знаний и привык к тому, что всё он не будет знать никогда. И научился работать в ситуации неполного знания.

Пока методика выглядит следующей:

1. Погрузиться в сложные алгоритмические задачи. Главное, чтобы эти задачи еще не были реализованными в готовых библиотеках, и человек понимал, что задача относительно реальная. Например — вывести что-то отформатированное. Смысл: вызывать у человека понимание, что любая задача решаема. Просто нужно несколько дней подумать, покрутить задачу, и вот тогда все выйдет.

2. Нарисовать к этим задачам Unit tests. Юнит тесты легко покажут все ошибки вашего проектирования и заставят переписать код в гораздо более приличном формате. Как бонус — студент привыкает не бояться править код снова и снова. Это умение абсолютно необходимо для профессионального программиста

3. Научиться декомпозиции. Выбрать несколько предметных областей и порисовать по ним UML диаграммы. Это необходимо, чтобы просто понять — это и будет самым сложным в нашей работе. Единственное замечание — диаграммы должны проверяться опытным и толковым ментором. На этом этапе ментор просто необходим. Настроить свой мозг на вырезание скоупа проекта, на декомпозицию объектов и их взаимосвязей — это то, что само не придет, сколько не программируй.

4. Сделать код на основе результатов одной из декомпозиций. Этот код будет впоследствии нашим слоем бизнес-логики.

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

6. Выучить основы веба и томкет. Надо сделать к вашей бизнес-логике и DAO layer последнюю оставшуюся часть — UI. Пока на сервлетах и JSP. Нужно сделать так, чтобы JSP обращались к бизнес-логике за ее данными. Та запрашивала данные из базы и возвращала их на View (JSP). По нажатию на кнопки в JSP управление передавалось в сервлеты, которые отправляли команды бизнес-логике на изменение состояния. А та, в свою очередь, меняла данные в базе с помощью DAO layer. И затем сервлеты отправляли управление обратно на JSP (например — редиректом), и затем все повторялось. Тут надо внимательно следить, чтобы никакие запросы от JSP не лезли в DAO layer.

7. Изучить возможности томкета. Создаем Data Source и работаем уже не с физическим коннектом, а с логическим, получая его через JNDI.

8. Освоить Spring. Все, что нужно сделать — проинжектить DataSource в нужные классы DAO Layer. Сначала — через XML конфигурацию, а потом — через аннотации. Этих знаний будет достаточно

9. Теперь можно вводить Hibernate через JPA аннотации. Смысла изучать меппинг-файлы я не вижу. Они уже почти нигде не используются. Заменяем весь код в DAO на HQL или Criteria. Что лучше пойдет.

10. Ну и наконец, самое веселое — выбираем фреймворк для морды. Я бы порекомендовал какой-то JSF или SpringMVC.

Дальше, когда ключевые вещи освоили, изучать можно уже что угодно. Я бы рекомендовал погрузиться в SQL, WebServices и JavaScript

Обращаю внимание: перескакивать этапы крайне не советую.

Если у вас получится следовать этому плану, и ваш ментор окажется достаточно квалифицирован, всё будет отлично. И скоро на одного Java разработчика станет больше. Удачи вам!

  • Популярное

Лучшие комментарии пропустить

Не статья, а сокровище для каждого кто хочет изучить технологию!

Гуй полностью на ангуляре и про джаву на сервере ничего не знает (сепарейшн оф респонсибилитиз). Я считаю это красивая архитектура. Можно отдельно тестировать фичи гуя не имея коннекта к серверу через моки. А если на сервере надо какой-то хтмл сгенерить для спам-рассылки то фримаркер

ваше мнение очень ценно для нас. Пишите еще!

Как это похоже на наше образование — а давайте дадим студенту богом забытые технологии, авось пригодятся, и все равно, что новые проекты на них уже не пишут.
Наверно поэтому в западных передовых конторах на собеседованиях проверяют умение программировать, а в бодишопах — тупо знание какого то framework-а.

Прошу понять меня правильно, я не имею ввиду что вы не правы, просто грустно это все.

136 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Класна стаття! Зі свого досвіду можу додати, що якщо людина має класну освітню базу: вивчала дискретнку математику, булеву алгебру, робила олімпіадні задачки, то зрозуміти багато речей в ентерпрайзі для неї простіше. Якщо набити трохи шишок на голові, то можна це освоїти навіть і без ментора. Інша справа людина без бази, якщо візьметься сама, то будь-яка книжка по спрінгу швидше за все її просто вб’є :)

Да. Уж. Если прибавить к этому всему еще и английский язык, то получается очень сложная задача.

ага. Я об этом давно говорю — если есть другой выбор, то лучше он

А лучше в дворники сразу?

Никто не может сделать тебя избранным, Нео. только ты сам можешь это понять :)

«Да и вообще, энтерпрайз разработчик не должен перебирать — это хочу, это не хочу.» — вот из=за такого подхода технологии и не развиваются. Давно пора на Scala перейти, а все с джавой сидят.

Ви тільки не сказали що на вивчння всього цього піде мінімум рік, і це на досить базовому рівні.

все зависит от стартового уровня. Моя группа училась четыре месяца. Через три с половиной один из студентов уже работал программистом

На Глобаловский курсах трейни это где-то за три месяца было. 8 часов 5 дней в неделю.

Прежде всего, это означает свободно ориентироваться в трёх принципах ООП.
Можете кто-то подсказать ресурс/ссылку на статью/книгу, где углубленно рассматриваются принципы ООП? Ресурсы, которые я нахожу там шаблонно «B extends A — мы веселая семя».

Их много. Есть даже книжка серии ХедФёст — ООП — 700 стр. с картинками:)

Такої книжки немає в серії Head First, можливо ви переплутали з Head First Object-Oriented Analysis and Design? :)

Я всегда советую Эккеля Thinking in Java

Очень интересная статья, как раз изучаю. Да ментора пока что не нашел, но я буду дальше стремится к цели освоить язык Джава) Да сейчас очень трудно уже все пошло. Но блин, а что учится легко бывает?

ждем тему: «Общая тема для менторов, которые набирают junior-ов»)))

Вы имеете в виду — написать статью с советами для менторов? Интересная идея.

Да, чтобы в ней менторы, которые хотят обучать начинающих оставляли свои требования.
Например:
— набираю java junior EE, требования: 40 свободных часов в неделю, английский Intermediate+, отличные знания java core, jsp, servlets. Немного о себе. Какая оплата.
или
— набираю javascript junior. Текст тестового задания и мыло куда его присылать. Обучение групповое, прием заявок до ...

Идея в том чтобы поставить обучение программированию на поток, как английский азык. Есть тема(вопрос, задание) от ученика, есть цена от преподавателя и hangouts.

От себя добавлю, автору респект, сам в свое время шел таким путем. Но... как человек который 10 лет тому назад с дельфи пересел на java утверждаю что обойтись без ментора ВОЗМОЖНО !!! (но сложно :) ). Кроме того хочу заметить о необходимости изучать шаблоны проэктирования и SOLID принципы, без них Ваш проэкт (кроме калькулятора) будет со временем похож на клубок запутаных ниток.

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

А вот изучение паттернов — это не ранее года работы. Иначе просто в одно ухо влетит, из другого вылетит

да все что вы описали старье, в общем. и ничего особо сложного для изучения там нету.

Отлично!
я бы еще добавил базовые знания в системах контроля версий и системах сборки проекта. Это очень сильно используется на всех реальных проектах.

Ну, знания по Git и так идут. Я просто забыл их указать — они показались естественными. Добавлю в следующую статью. И по системе сборки — считаю что надо учить мейвен

Список немалый. Интересна глубина — это надо изучить и поддерживать постоянно на каком то уровне в голове? Или достаточно пройти разок, а после вспоминать по мере необходимости?

Ну, тут сложно. ООП надо выучить и поддерживать. Collections — аналогично. Остальное — по мере необходимости обновлять

Вот она, эта статья. С пятницы ждал ее. К стати, Сергей, я таки остался последним после трансляции как и говорил. ;)


JDBC (Java Database Connectivity)
...никто уже в чистом виде не пользуется...
А як ви виконуєте запити на стрічок 30 після того як скурпульозно вилизали всі індекси і чудом добилися нормальної швидкодії?
Tomcat ... Servlets + JSP ... Spring ...ORM ... Web-framework
Може в мене дуже специфічний досвід роботи з java ....
але навіщо взагалі писати web-сайти на Java?
Як на мене, це складно, дорого, потребує жирного сервера, і в 99% випадків непотрібно.

Вы небось в банке работаете? Очень похоже по большим SQL запросам.
1. ну как что делать со сложным запросом? Если это апдейт -в хранимую процедуру и фиг с ним. Если селект — во вьюшку. Или в ту же процедуру. Вы же этот запрос не на findById используете ? :)
2. А кто говорил про веб-сайты? На джаве пишутся не веб-сайты, а веб-приложения. Обычно — интранетовские

Не банк, але дикі запити в основному попадаються у всякого роду звітах.
В банках їх більше, напевно :)
Хранимі процедури та в’юшки це добре, звичайно.... але якось з ними не зрослося ....
забагато недоліків, в основному в обслуговуванні (бекапи, контроль версій і т.д.).

На джаве пишутся не веб-сайты, а веб-приложения.
Тоді для чого приплітати сюди всякі web-фреймворки, а тим більше JSP?
Щось REST-like, або не дай бог SOAP — достатньо, наче.

1. ну не знаю. В чем проблема-то? В любом случае какие-то изменения в базе будут в некоторых версиях. Ну и процедуры с вьюшками там же. Какие проблемы хранить версии — не понимаю
2. веб-приложения с веб-интрфейсом. Чтобы сотрудники бек-офиса могли делать какие-то изменения в своих данных через броузер. Через интранет. Так вообще-то весь энтепрайз работает. Или что — девочкам из бек-офиса какого-нибудь банка РЕСТ интерфейс предоставить? ;)

1. Та як на мене, простіше запит зробити прямим SQL-ем витягнувши connection з пула і зберігати це все просто в git, чим ганяти зміни в процедурах через якийсь liquibase (як ви ще версійність в БД зробите?).

2. Ем... схоже я вас не вірно зрозумів. Я, просто, не бачу причини бекофіс з CRUD-ом, репортами та статистикою не називати web-сайтом. Термінологія дуже суб’єктивна ( stackoverflow.com/...ite-and-a-web-application ). Питання кінець-то кінцем те ж саме.... навіщо це писати на Java? Є ж купа більш адаптованих для цього технологій (PHP, Ruby,...) і виходить простіше, дешевше і легше.

1. очень просто скрипт изменения базы кладете в ваш гит/свн или что там у вас. Ну и скрипт отката изменений. У меня уже на десятках проектов работает эта технология. Поддержка получается очень простая
2. Ну отличие веб-приложения от веб-сайта, естественнно умозрительные. В большинстве случаев я лично для себя определяю веб-сайт — когда интерфейс основное,а веб-приложени, тем более энтепрайз — когда ОЧЕНЬ много бизнеес-логики и очень много сопряжения с другими системами и базами. А мордочка — только небольшой управляющий пульт на этом. Если в моем текущем приложении 500 Мб исходников с бизнес-логикой и 10 веб-страничек, то извините я бы это на РНР писать бы не стал. поддерживать такое — умереть можно

Какой-то большой монолит на 500Мб

Большой? Ну, смотря с чем сравнивать. У нас есть проекты и побольше.

500Мб это примерно 90тыс файлов сорсов если брать в среднем. Или что входит в эти 500Мб?

там дофигище огромных по несколько тысяч строк классов. Индусы писали же

1. Я ж приблизно це і написав .... ми для цих цілей використовуємо liquibase.
2. У вашому випадку це може і має місце, коли веб там займає менше 1% коду, а зв’язків має багато. Але 500Мб монолітного коду ... ну так важко сказати, але можливо є сенс пробувати його декомпонувати? і можливо є сенс почати саме з веб-адмінки?

Ну, с версионностью разобрались :) Отлично
Насчет 500 Мб — это не монолит. Это примерно 10-15 приложений, каждое из которых имеет дополнительные связи с приложениями, не входящими в проект

Скажите, для Вас LinkedIn, Amazon, eBay, Paypal являются веб-сайтами? =)

1. Так. Чому б ні?
2. Ви часто пишете проект такого масштабу і такого навантаження?
3. 99.9% проектів ніколи не доживуть до таких розмірів ... тим більше enterprise.
4. Так навіщо платити більше?

а для вас это — приложения?

Для меня это и сайты в том числе. И, естественно, с JVM под капотом.

Не статья, а сокровище для каждого кто хочет изучить технологию!

спасибо, мне очень приятно :)

Хорошая статья. От себя добавлю, что всё меньше и меньше (лично я) встречаю проектов на JSP, JSF, теперь как-то принято писать чистый фронт на ангулярах, и чистые бекенд контроллеры.

аналогично. Но новичкам я бы не советовал рассчитывать пройти мимо старых проектов. Их как раз любят на такие проекты брать

«Ангуляр» не для Java разработчиков, а для JavaScript’еров. Да и если брать из коробки Java EE (GlassFish например), там все оптимизировано именно под JSF. А JSP действительно устарел и советуется в утилизацию.

Лично мне это даже нравится, что можно быть просто back-end разработчиком.
При этом я считаю, что важно знать тренды front-end’a, как он собирается, какие технологии популярны, чтобы друг-друга понимать при общении с коллегами.

Очень важно не отвлекаться при изучении на другие технологии. А так новички почитают комментарии и начнут паралельно «JavaScript» подтягивать. Пусть освоят хотя бы Java.

Ну вообще-то стоит и javaScript знать. Я про это в статье писал как раз :) Естественно, это идет вторым номером после Java+SQL

Зачем человеку, который «кодит с 96-го» идти в преподаватели?

Надоело кодить за 20 лет? -)

Ну как сказать... Призвание? :) Очень люблю преподавать. была бы сопоставимая ЗП — давно бы бросил программирвоать

Пардон. Из текста я понял, что вы как раз поменяли кодинг на преподавание.
п.с. Как совмещаете? Что-то страдает или «я всё могу, всё успеваю, таймменеджмент и.т.п» ?

Менторинг это неотъемлемая часть тимлидерства.

Менторинг во время работы и образование, как отдельная работы — разные вещи, не находите?

Есть люди которые являются собственниками софтверной компании(больше 30 разрабов), и кодинг не забрасывают, и параллельно с этим ведут еще преподавательскую деятельность в университете

Я знаю многих разрабов, которые от 8 до 5 отработали и после этого за программинг даже слышать не хотят

Хотелось бы внести разъяснения в мою позицию, потому что, судя по комментариям, я не очень ясно выразился. 1) Одновременно кодить и преподавать можно. 2) Кодить в основное время и давать редко краткие лекции — скорее всего можно, но будут моменты, когда придётся жертвовать качеством либо того, либо другого, либо и того и другого. 3) Преподавать в основное время и кодить мелкие задачки — наверное можно, но надо понимать, что это задачки, насколько регулярна эта «мелочность» и не бывает ли ситуаций, когда вместо «мелкой» возникает задача «покрупнее», а на носу большая лекция. Опять выбор и расстановка приоритетов.

Идеальный вариант: я преподаю, потому что это моя страсть, а когда я уверен, что всё готово, я могу позволить себе «Hello, world!» (крайний пример) в удовольствие.

Моё мнение, это абсолютно субъективная вещь, основанная на наблюдении и опыте.

Ну скажем так. Я специально сейчас сижу тим-лидом на саппортовом проекте. У нас как у админов — хороший админ — спящий админ. Система работает как часы, все исправления вносятся легко и относительно безболезненно. поэтому у меня много свободного времени на преподавание.

По тому, что вы описали, ближе всего 3-й вариант из моего поста.

п.с. Я надеюсь, чтобы вы не подумали, что я в чём-то пытаюсь вас уличить :)

нет, конечно. Вы очень правильные вопросы задаете. Я сам над ними думаю.

а я из тайтла человека понял что он дев лид.

Мешает. Довести до совершенства можно одно дело, всё остальное будет развиваться второстепенно. Вопрос только в том, что стоит на первом месте.

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

Именно это я имел ввиду.

Перфекционизм, это миф для неокрепших умов :) Имхо.

Спасибо, посмеялся.

ваше мнение очень ценно для нас. Пишите еще!

Не знаю jsp,jsf,webmvc,struts как я живу?

А что вместо jsp используете?

Ничего. Или ангуляр

А если нужно хтмл рендерить?

Гуй полностью на ангуляре и про джаву на сервере ничего не знает (сепарейшн оф респонсибилитиз). Я считаю это красивая архитектура. Можно отдельно тестировать фичи гуя не имея коннекта к серверу через моки. А если на сервере надо какой-то хтмл сгенерить для спам-рассылки то фримаркер

а что вы показываете поисковым ботам?

это ж энтерпрайз, ботам доступа туда нет :)

Ну, с Google так точно можно подружится, на счёт других поисковиков не знаю.

ангуляр для админок и кабинетов а не для сайтов
ангуляр = почти бан в поисковике

опять же, в контексте энтерпрайза вы не учавствуете в сео.

єто получается всю жизнь на одном проекте?

Если глянуть сколько требуется разработчиков на проекты в Нью Йорке, которые используют JDK EE — можно хоть каждый день менять проект.

ну плохо. Что я могу сказать? Да, безусловно, за решениями типа Аглуара — будущее. Но будучи джуном лучше ориентироваться на устаревшие технологии, чем на относительно новые

Самый лучший скилл девелопера это умение самообучаться ,а технологии часто меняются и нет смысла учить все-все-все в надежде что когда-то понадобится. Я готов взять джуном человека с отличным знанием java core но без знания фреймворков — до остального он сам дойдет помощью примеров уже написанного кода и интернета

я тоже готов. но пока — прецедентов не видел. Всегда таких людей зарубали ПМы

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

Любой java разработчик должен знать Tomcat

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

Он самый простой, самый легкий

Самый простой и легкий это com.sun.net.httpserver.HttpServer.
В 90% случаев, где я видел томкат — его выбор не оправдан. И именно из-за апологетов энтепрайза.

Здесь нужно учесть, что статья ориентирована на будущих джунов. Вряд ли у них хватит сил заранее изучить ещё и JEE на JBoss’е. А так — познакомятся с такими вещами, как deployment, например.

Только если у Вас энтерпрайз коры головного мозга
У меня профессия — энтерпрайз разработчик. И я учу внезапно начинающих энтепрайз разработчиков. И статья именно для них.
Называется
Java Enterprise: что и как учить
Если вас эта специализация не интересует. зачем вы читали эту статью?
В 90% случаев, где я видел томкат — его выбор не оправдан. И именно из-за апологетов энтепрайза.
Разговор про энтепрайз. И про энтепрайз задачи. Если у вас задачи под андроид или маленькие сайтики, то вам все это, естественно не к чему.

У меня сложилось впечетление что вы не в курсе что такое Enterprise Soft. Почитайте что ли на вики. Я тоже разрабатывал энтерпайз софт и все что вы перечислили совершенно не обязательно для его разработки, а скорее дань моде.

А, ясно. значит я 15 лет занимался незнамо чем. Ну извините :) Видать мы в разных мирах живем. В моем мире именно это и есть Java entrprise

Так я вот к чему и веду. Энтрепрайз софт это всего лишь софт для обслуживания нужд компании. А на чем его пишут не принципиально. Для веб-серверов там можно использовать HttpServer или Jersey или Grizzly — они проще и эффективней. То что за энтерпрайзом закрепилась репутация тяжелого, медленного и тормозного софта как раз заслуга инертности мышления многих разработчиков.

Простите. Это справочная статья, а не обзорная по энтерпрайз техологиям. В эту маленькую статья я положил только выводы без объяснений. Адресаты этой статьи те, кому она понравилась — люди, которые хотят учиться именно энтепрайзу, те у кого «энтерпайз головного мозга» как вы мило выразились. Судя по вашему профилю, вы занимаетесь андроидом. Возможно это статья просто не для вас? Я же не прихожу к вам в статьи рассказывать о том, как надо учить андроид и на чем надо фокусироваться. Я честно этого не знаю, это не моя специализация. Тут я полностью доверяю мнению профессионалов. Например — вашему. Очень бы хотел и с вашей стороны аналогичного отношения. Заранее спасибо

С «энтерпайз головного мозга» я немного переборщил, бывает. Извиняюсь, если Вас это обидело.
Андроидом я не занимаюсь. Где Вы это нашли?

в описании компании,в которой вы указаны основателем: Small IoT startup company developing platform with iOs and Android apps to control Arduino, Raspberry Pi and similar microcontroller boards over Internet.

Ну “platform” это не только “Android” =).

а как там с EJB на томкате?

Надеюсь, вы со своими подчиненными/коллегами более корректны в общении, чем с Сергеем, чтоли.

<disrespect> чтоли </disrespect>
На грамматику можно плевать, но вот на человеческое отношение — нет.

Где в моем сообщении не корректность?

Дмитрий, lmgtfy. Сравните термины «enterprise software» и «enterprise java». Вы зацепились только за первое слово. В статье — своя, особая атмосфера JEE.

ентерпрайз = внутренняя автоматизация
там может быть и андроид (мобильные клиенты), и «маленькие сайтики» и вообще все что угодно

Дмитрий, JEE — это, по большей части, про серверы. Нам, как начинающему обучаться, необходимо познакомиться с понятием сервлета, контейнера сервлетов, сервера приложений и т.п.
Вам не понравился именно Tomcat? Тренируйтесь на Jetty, Wildfly.
Пан має час та натхнення? Купите WebSphere и кластер Weblogic’ов, не забудьте запилить Soa Suite и AIA, BPEL и OSB, JMS и SAF.
Учебные 3-tier приложения сразу засверкают тысячей огней!

Если у кого желание еще не отбилось вот на DOU еще материальчик dou.ua/...ers/staslozenko/articles и по стеку технологий есть dou.ua/...es/java-beginner-guide-5

Да, Стас отлично пишет

Если переходишь с другого языка есть несколько проблем:
— В инете полно устаревших библиотек, мануалов, решений и мусора. Зачастую просто не знаешь оно актуально еще или уже нет
— Везде выбор: maven/gradle/ivy, EE/Spring, Tomcat/Jetty/JBoss, JSP/Freemarker/Thymeleaf, Hibernate 3/4 и тд

Если на том же пхп как-то строже и выбирать не нужно: composer, symfony2, php-fpm, twig, doctrine, а всякое гавно видно невооруженным глазом даже для новичков

Symfony2 никак не стандарт для php, т.к. Symfony2 != Spring, скорее Zend Framework 2 == Spring по своей архитектуре.
twig не нужен, т.к. php сам себе шаблонизатор.
вообще выбирают ZF2 для Enterprise или SF2 если ориентация больше на фронт, если же полегче, то Laravel/Yii.
Doctrine2 только для enterprise, часто выбирают ORM фреймворка (active record), бывает что пишут на простых query builder или pdo.

Вы видимо человек из мира Java и поверхностно знаете в PHP. Я так же, но наоборот, однако я не пишу о том, о чем не знаю хорошо.

Если Doctrine2 это AR то о чем тут еще говорить?

в этом плане дотнет проще для начинающего. ничего выбирать не надо — все выбрано за вас Майкрософтом Ж-)))

согласен. Я всегда советую выбирать что-то попроще

Когда два года назад пытался изучать Java Enterprise, местные гуру все как один очень не рекомендовали JSF, думаю сейчас новичкам учить его смысла большого нет.

Я не местный гуру. Я рекомендую :) Ну, на основе того, что реально новички встретят на своей первой работе. А это с большой вероятностью будет какой-то саппортовый проект.

Как это похоже на наше образование — а давайте дадим студенту богом забытые технологии, авось пригодятся, и все равно, что новые проекты на них уже не пишут.
Наверно поэтому в западных передовых конторах на собеседованиях проверяют умение программировать, а в бодишопах — тупо знание какого то framework-а.

Прошу понять меня правильно, я не имею ввиду что вы не правы, просто грустно это все.

Ну, я с вами согласен. однако. Аутсорс — это аутсорс. Выше головы не прыгнешь. На аутсорс практически всегда отдают те проекты, которые как чемодан без ручки — тащить лень, но бросить нельзя. Будут у нас в промышленном масштабе продуктовые компании — будут и каттинг эйдж технологии. пока що маемо то, що маемо

Я не местный гуру. Я рекомендую :) Ну, на основе того, что реально новички встретят на своей первой работе. А это с большой вероятностью будет какой-то саппортовый проект.
Тут надо понимать цель. Если задача «пролезть в ИТ» любой ценой, то знания JSF могут быть таки плюсом для новичка.
Если задача розвиваться в ИТ, стать хорошим программистом и тд, то в настолько специализированные/высокоуровневые вещи как то JSF, JAX-WS, JAX-RS, GWT и даже некоторой мерой SpringMVC углублятся не стоит. Надо хорошо понимать основы, а кокретный стек лучше изучать уже на самом месте работы. Если тот же JSF требуют уже знать от джуна, то в такой конторе будет сложно развиваться.

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

Человек хочет научить «Enterprice», а многие не вникая просто показывают свое «неумение читать заголовок статьи», что приводит к таким комментариям. Из коробки (скачав JDK EE с оф сайта) сразу есть почти все, что перечислил автор статьи и этого достаточно, чтобы писать хорошие высоко-нагруженные «Enterprice» веб приложения. JSF например — основа основ такого приложения. Если я не прав — почитайте документацию!

скачав JDK EE с оф сайта
высоко-нагруженные «Enterprice» веб приложения. JSF например — основа основ такого приложения
Спасибо, повеселили :)
Человек хочет научить «Enterprice», а многие не вникая просто показывают свое «неумение читать заголовок статьи», что приводит к таким комментариям.
Угу, а некоторые демонстрируют продвинутый уровень: «неумение читать текст статьи» :)
.
Хотя если цель была научить именно «EnterpriCe», то да, надо качать JDK EE с оф сайта и учить JSF.

Ну ошибка и что? ) Бывает. Смысл же донес? )

Войти в IT через Enterprise очень нелегкий путь.

нужно было написать капслоком и с болдом типа ОЧЕНЬ НЕЛЕГКИЙ

видимо в java enterprise это единственный путь )

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

Если нелегкий, то сложнее каких способов? QA и Frontend?

Я после курсов по джаве пол года работу искал и так и не нашел(именно по джаве).

сложнее любых других. Так будет точнее. Самый сложный

А если мотивации вагон?

Ну, от этого путь не становится легче. От этого он становится проходимее :)

Если выбирать путь по его «легкости» велики шансы не дойти. При любом варианте нужно готовиться к тому, что будет сложно, везде по своему. Лучше выбирать то, что ближе по духу.
Сергей писал про мотивацию, её нужно запастись в достатке. И вот тут как раз мотивация «мне нравится то, чем я занимаюсь», работает лучше чем «я занимаюсь этим, потому что так легче».
ИМХО

Илья, ты безусловно прав

Интересно, а пробовал ли сам пройти хоть разок гайд по JDK EE? Ничего сложного я не заметил. И как результат — чтение такого гайда со всеми примерами сразу дает хороший результат при устройстве на работу именно на такие проекты, которые используют JDK EE.

Подписаться на комментарии