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 разработчика станет больше. Удачи вам!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному9
LinkedIn



Найкращі коментарі пропустити

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

143 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
программистам тоже надо расти, из миддлов становиться сеньорами, из сеньоров — тимлидами и так далее.

Не согласен! Карьерный рост != росту профессиональному.

Согласен с большей частью описанного, кроме HTML и Javascript. Более того, мой всем совет — если видите в вакансии java-backend разраба HTML и JS — БЕГИТЕ.

Так нравилась Java, пока не обросла вот этим вот всем...

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

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

Я думаю це тому що математика навчила думати

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

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

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

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

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

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

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

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

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

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

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

Ларман Крэг. Применение UML 2.0 и шаблонов проектирования — одна з кращих книг, що ви можете знайти по ООП. Глибше, буде хіба Грейді Буч, але його варто вже читати як маєш досвід.

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

ждем тему: «Общая тема для менторов, которые набирают 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 как я живу?

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

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

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

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

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

Ну, с 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” =).

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

<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.

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