лучше всего изучать язык не на отдельных задачках, а на одном большом проекте, который разрабатывается на протяжении всего обучения. Тогда начинаешь понимать отличие main() класса от проекта
занятия надо иметь в записи, чтобы была возможность пересматривать. Отредактированное видео гораздо чище сырого вебинара + там можно делать исправления и дописывать материал
боле-менее причесанный проект для обучения выстраивается с 3го потока. И важно постоянно его дорабатывать
чем больше людей, тем больше вопросов, активности в чате и интереснее учиться
Спасибо:) Жду продолжения. Небольшое замечание- в сервисе и контроллере мне кажется вместо get() более адекватно getAll(). Ну и картинки мне не очень..
Если коротко и мягко, то "не согласен". Будете много лет говнокодить, не догадываться об этом и считать себя асом. Как чукча — писатель. Необходим фидбэк и наставничество от опытных коллег. Варианты- обучаться либо работать в команде с ревью кода.
Я писал про стандартные API, которые входят в Java SE. Стронииих библиотек огромное количество. XStream не разу не юзал. В каких случаях им пользоваться удобнее?
Спасибо, хорошая статья.
Немного из своего опыта общения с ним 5 лет назад:
приходилось вместо специализированных плагинов использовать remote shell script (выполнение shell на удаленной машине) — получалось гораздо гибче. ssh настраивается через ключи.
для сборки разных веток на Jenkins были свои репозитории, все не перемешивалось
активно использовал комбобоксы для выбора артефакта для сборки, окружения для деплоя и пр. Если таски не делать универсальными, их количество растет пропорционально N (кол-во артефактов) M (кол-во окружений для сборки) ...
Считаю, что осваивать web, особенно новичкам, следует с сервлетов. Самое примитивное CRUD приложение на сервлетах. Разобраться не так сложно. А если таки сложно-приглашаю на свою практику по Java.
Spark, Ninja, Jooby — это все круто, модно и удобно но не для начинающих. Если вы напишите в резюме что работали с этими фреймворками и не сможете ответить на элементарный вопрос про сервлет на собеседовании шансов, что вас возьмут будет 0.
Некоторые вообще рекомендуют начинать изучение Java без IDE (я к ним не отношусь).
Для новичков самое основное- понимать, КАК внути все это работает. Я собеседовал людей, которые изучали Spring без знания основ (а сервлеты это основы). Ужастно. Николай Алименков задает новичкам на собеседовании вопросы, поверх чего реализован Hibernate. Если вы не ответите, что JBDC и не будете иметь про него представление- кому нужен такой разработчик?
Про JSP — с 2005 года я поработал более чем на 10 проектах. В 60% использовался JSP. Почему? Да потому что встроено в Tomcat (42% по статистике 2016 г) и на нем выводят что-то достаточно примитивное. Остальное делается в основном на js фреймворках. И еще потому что в основном проекты уже N-летней давности. И в 90% смысла переписывать JSP на чтото другое никакого. Далее — если вы знаете JSP, то например освоить Thymleaf или любой другой шаблонизатор будет легче. А сам JSP достаточно простой.
изучать Spring MVC можно только после того, как будете знать что такое сервлет. Тогда будет понятно что такое DispatcherServlet и паттерн Front Controller
Как можно работать со спринг не зная HttpServletRequest и прочие 5 основных классов сервлетов? Как вы будете его хотя бы дебажить?
НЕ беритесь за Spring-Boot, пока не освоили Spring. Точнее не так: все зависит от ваших задач. Если вам надо быстро написать небольшое работающее приложение- отличный выбор. Но если вы хотите стать Java разработчиком, пройти собеседование, устроится на работу и использовать Boot на больших проектах- не ваш вариант. Для вас это будет черный ящик, полный магии.
Те еще раз- джуниорам нужно учить именно основы и то, что требуется в вакансиях. Проверить легко: на hh в поиске работы по ключевым словам, ограничив область поиска разработкой ПО.
Напоследок приведу цитату
Любое знание стоит воспринимать как подобие семантического дерева: убедитесь в том, что понимаете фундаментальные принципы, то есть ствол и крупные ветки, прежде чем лезть в мелкие листья-детали. Иначе последним не на чем будет держаться.
Таки надеюсь что автор не призывает полностью отказаться от библиотек-фреймворков и писать все самому:)?
Тогда вопрос встает о том, чем его заменить.
DI из статьи не понял хотят ли выбросить… надеюсь что нет. Заменить можно Guice например..
утильных классов не очень много, их вполне перекрывают apache commons / guava. Однако тот же CharacterEncodingFilter скорее всего придется скопипастить
для spring-security-web/spring-security-config самому на основе сервлетов тоже конечно можно написать… но лучше взять готовое
webmvc. Можно JAX-RS. Можно взять другой фреймворк- playframework, vert.x. Будет он проще и свободен от того, чего автор не любит? Но в любом случае не писать самому!!
spring-test, spring-security-test — или подбирать отдельные библиотеки или опять же взять готовый другой фреймворк
spring-jdbc, spring-datajpa. Есть альтернативы: jooq, mybatic… Лучше опятьже взять уже интегрированные в фреймворк. И сравнения скатываются к достоинствам-недостаткам ORM
spring-cloud можно заменить akka, можно еще кучу библиотек
… и так далее по всем остальным модулям Spring
Что имеем в результате? Сильно сомневаюсь, что радость от программирование, скорось разработки и качество кода проекта станет выше.
spring-boot- да, за простоту запуска и все-из-коробки приходится платить тем, что его нужно поковырять, чтобы настроить. Но там все доступно, код на java и нет никакой автогенерации.
Те если надо сделать веб-приложение с авторизацией и базой данных (70% приложений) не вижу альтернативы писать все самому и набирать из разных библиотек. Только взять дургой фреймворк, который непонятно чем будет лучше для автора.
Цели создателей языков тоже на удивление разнообразны. Вот c какой целью Odersky создавал Scala? Может быть это были сугубо академические (исследовательские) цели, и ему, как исследователю, было интересно сделать что-то новое вокруг идеи связки функционального и объектно-ориентированного программирования… Понятно, что хороший язык, тем более писаный гениальными чуваками, типа Odersky, можно использовать по-разному, и он будет хорош. Но все же, максимальный эффект язык даст в том случае, когда он используется в соответствии с теми целями, ради которых язык создавался.
Для меня также основная задача языка (как и фреймворка) — упростить и ускорить разработку и поддержку
Сравнение OSGi c Jigsaw сильно напоминает рекламныю брошуру OSGi (Netcracker). Я полагаю надо все таки быть честными, раз пишете техническую статью. Jgisaw это же только механизм в Java, на основе которого можно уже строить различные фреймворки по динамической загрузке (если я это правильно понимаю). А что OSGi с 2000 года существует и далеко не майнстрим- так это плата за сложность обращения с ним. Вот если бы вы написали про его будующее, про возможности интеграции с Jigsaw- было бы интересно…
Впечатление такое, что обманули, причем непонятно где:)
Есть сервис, есть его клиентское API в виде отдельного модуля и клиентами он подтягивается.
В чем новизна и необычность? Зачем большая статья, когда это умещается в 2х строчках?
Еще мне интересно — почему сервис не должен зависеть от модуля API?
API обычно включает интерфейсы, сервис — их реализацию. Примеров таких куча:
Было бы хорошо сделать некоторую вводную: что это такое, где применяется… Полагаю (на примере себя) что не все знакомы с этим чудом.
Мои 5 копеек как ведущего Java обучение:
Рад помочь. Про резюме не подскажу, кроме google...
Спасибо:) Жду продолжения. Небольшое замечание- в сервисе и контроллере мне кажется вместо get() более адекватно getAll(). Ну и картинки мне не очень..
Если коротко и мягко, то "не согласен". Будете много лет говнокодить, не догадываться об этом и считать себя асом. Как чукча — писатель. Необходим фидбэк и наставничество от опытных коллег. Варианты- обучаться либо работать в команде с ревью кода.
Я писал про стандартные API, которые входят в Java SE. Стронииих библиотек огромное количество. XStream не разу не юзал. В каких случаях им пользоваться удобнее?
Спасибо, интересно, не знал что можно StAX скрещивать с JAXB. Нашел пример с unmarshalling:
http://blog.bdoughan.com/2012/08/handle-middle-of-xml-document-with-jaxb.html
При этом работа со StAX чтобы добраться до элемента остается актуальна.
Тоже неплохо:) Но ДУП же цитата из "Бриллиантовой руки". Не поменять.
Взможно будет интересно и поучительно почитать истории выпускников: http://javaops.ru/view/story
Достаточно много, кто идет сразу middle
Была уже информация: https://jug.ru/2017/09/java-plans/
Спасибо, хорошая статья.
Немного из своего опыта общения с ним 5 лет назад:
Не соглашусь. По опыту моего обучения:
Spark, Ninja, Jooby — это все круто, модно и удобно но не для начинающих. Если вы напишите в резюме что работали с этими фреймворками и не сможете ответить на элементарный вопрос про сервлет на собеседовании шансов, что вас возьмут будет 0.
Некоторые вообще рекомендуют начинать изучение Java без IDE (я к ним не отношусь).
Для новичков самое основное- понимать, КАК внути все это работает. Я собеседовал людей, которые изучали Spring без знания основ (а сервлеты это основы). Ужастно. Николай Алименков задает новичкам на собеседовании вопросы, поверх чего реализован Hibernate. Если вы не ответите, что JBDC и не будете иметь про него представление- кому нужен такой разработчик?
Про JSP — с 2005 года я поработал более чем на 10 проектах. В 60% использовался JSP. Почему? Да потому что встроено в Tomcat (42% по статистике 2016 г) и на нем выводят что-то достаточно примитивное. Остальное делается в основном на js фреймворках. И еще потому что в основном проекты уже N-летней давности. И в 90% смысла переписывать JSP на чтото другое никакого. Далее — если вы знаете JSP, то например освоить Thymleaf или любой другой шаблонизатор будет легче. А сам JSP достаточно простой.
изучать Spring MVC можно только после того, как будете знать что такое сервлет. Тогда будет понятно что такое
DispatcherServletи паттерн Front ControllerКак можно работать со спринг не зная
HttpServletRequestи прочие 5 основных классов сервлетов? Как вы будете его хотя бы дебажить?Те еще раз- джуниорам нужно учить именно основы и то, что требуется в вакансиях. Проверить легко: на hh в поиске работы по ключевым словам, ограничив область поиска разработкой ПО.
Напоследок приведу цитату
Илон Маск
Таки надеюсь что автор не призывает полностью отказаться от библиотек-фреймворков и писать все самому:)?
Тогда вопрос встает о том, чем его заменить.
Что имеем в результате? Сильно сомневаюсь, что радость от программирование, скорось разработки и качество кода проекта станет выше.
spring-boot- да, за простоту запуска и все-из-коробки приходится платить тем, что его нужно поковырять, чтобы настроить. Но там все доступно, код на java и нет никакой автогенерации.
Те если надо сделать веб-приложение с авторизацией и базой данных (70% приложений) не вижу альтернативы писать все самому и набирать из разных библиотек. Только взять дургой фреймворк, который непонятно чем будет лучше для автора.
Простите, из какого фреймворка из вышеперечисленных это:
@TargetFilter?И хотелось бы конечно сравнения, какие из них поддерживают эту и другие фичи..
Посмотрите Stream javadoc для
filter,map, mapToInt, flatMap,и прочих промежуточных операций:@return the new streamА также в коде:
return new StatelessOp<P_OUT, R>(this, ...Те возвращается обертка над текущим потоком
Вот хорошая статья (можно начало по диагонали прочитать): https://habrahabr.ru/post/260149/
Про скала верно написано:
Для меня также основная задача языка (как и фреймворка) — упростить и ускорить разработку и поддержку
Вот тут подробнее: Дайджест: судьба Jigsaw
Сравнение OSGi c Jigsaw сильно напоминает рекламныю брошуру OSGi (Netcracker). Я полагаю надо все таки быть честными, раз пишете техническую статью. Jgisaw это же только механизм в Java, на основе которого можно уже строить различные фреймворки по динамической загрузке (если я это правильно понимаю). А что OSGi с 2000 года существует и далеко не майнстрим- так это плата за сложность обращения с ним. Вот если бы вы написали про его будующее, про возможности интеграции с Jigsaw- было бы интересно…
Впечатление такое, что обманули, причем непонятно где:)
Есть сервис, есть его клиентское API в виде отдельного модуля и клиентами он подтягивается.
В чем новизна и необычность? Зачем большая статья, когда это умещается в 2х строчках?
Еще мне интересно — почему сервис не должен зависеть от модуля API?
API обычно включает интерфейсы, сервис — их реализацию. Примеров таких куча:
slf4j-api<-logback-classicjavax.el-api<-org.glassfish.web.javax.elhibernate-jpa-2.1-api<-hibernate-core