Практика Java EE
Всем привет. Знает ли кто-нибудь хорошую фирму, в которой можно сделать практику и набраться немного опыта, работая с Java EE (JSF, JPA, EJB и т. д.) в NRW?
И ещё два нескромных вопроса:
1) Каковы шансы найти работу имея IHK-Anwendungsentwickler, OCA и OCP, но не имея стажа и опыта (есть лишь несколько своих домашних проектов).
2) Есть ли смысл делать дальше OCE, и если да, что будет лучше - EE6 Web Componet Developer или сразу EE6 Web Services Developer??
Огромное спасибо за полезную инфу))
Каковы шансы найти работу имея IHK-Anwendungsentwickler, OCA и OCP, но не имея стажа и опыта (есть лишь несколько своих домашних проектов).
Есть шансы быть приглашенным на собеседование. А там - как впечатление произведете. Если не секрет, на cколько процентов OCA и OCP сдали? Для 7-й или 8-й явы?
Как насчет опыта с инструментами? Git, svn? IntelliJ, Eclipse? maven, ant, gradle? JBoss (Wildfly), Websphere, Tomcat, ...? Свои проекты показать сможете? Код, работающий проект вживую?
Есть ли смысл делать дальше OCE, и если да, что будет лучше - EE6 Web Componet Developer или сразу EE6 Web Services Developer??
Помешать - не помешает. Но опыт тут уже важнее. Имхо. С опытом и OCE, конечно лучше чем с опытом но без бумажки. Но в конце концов все сведется к тому, как на вопросы на интервью ответите.
Спросят что-нибудь про управление транзакциями в JPA или почему на сервере не стоит потоками пользоваться... Знаете, сможете ответить - возьмут и с небольшим опытом и без бумажки. Поплывете - и бумажка не поможет.
Я здал OCA на 78, и OCP на 76 для 7ой явы. Из перечисленных технологий - gradle мне вообще ничего не говорит. Мои проекты, на самом деле, учебные CRUD-приложения. Эти пару проектов я делал по туториалам и с небольшой собственной доработкой, ну и с курсов ещё что-то осталось.
Из техник, я работал с JSF, немного c JPA( то есть в общих чертах понимаю, что такое ORM), GIT. О maven имею теоретическое представление. Из серверов - только Glassfish.
У меня ещё такой вопрос. Hibernate вообще стоит учить, или достаточно обычной JPA-реализации, как скажем - EclipseLink. Просто, на курсах нам говорили, что собственная ORM-реализация Hibernate якобы устарела.
gradle мне вообще ничего не говорит.
Если будете искать работу в конторах, которые что-то для андроида делают, будут спрашивать. Это... мутант maven + groovy.
О maven имею теоретическое представление.
Зря. Очень многие переползли с анта на maven. А к нему надо привыкнуть.
Из серверов - только Glassfish.
Плохо. Имхо. После того как оракл его саппортить перестал я его почти нигде не вижу. Попробуйте сделать приложение для wildfly (он же JBoss). Он бесплатный и часто используется фирмами.
У меня ещё такой вопрос. Hibernate вообще стоит учить, или достаточно обычной JPA-реализации, как скажем - EclipseLink. Просто, на курсах нам говорили, что собственная ORM-реализация Hibernate якобы устарела.
Устарел хибернейт или нет можно спорить, но используется он часто. Придете куда-то поддерживать продукт, написаный пару лет назад, натолкнетесь на хибернейт. Пока спринг от него не откажется, будет и в новых проектах. Имхо - если идете на JPA вакансию, хибернейт надо знать минимум на уровне "помню как описать one-to-many, вспомню как конфигурировать many-to-many с помощью гугла за минуту, как работает lazy-loading помню."
Лично я его не люблю, но в 3-х моих проектах он используется. И пока проекты не помрут ни на что его менять не будем - дорого.
Тут все сложно. Насколько мне не изменяет склероз, это JPA попытка натянуть сову на глобус. Т.е. сначала был hibernate потом в нем появились свои аннотации. Ага! Сказал Сан. И забабахал JPA. Которое было не совсем 1:1 копия хибернейтовских понятий и аннатоций, но близко к этому.
В 3-й по-моему версии хибернейт стал и JPA поддерживать. И долгое время был, собственно, единственной реализацией JPA, которая работала. Но эталонная... Вряд ли. С транзакциями хибернейт накрутил, имхо.
Такие ответы для меня ОЧЕНЬ важны!! Дело в том, что технологий просто МАССА, а времени учить всё это не так и много, нужно ведь и работать уже.. Поэтому мне просто нужно сделать для себя список САМЫХ важных технологий, и заняться этим пока автодидактично.
Пока что я отметил следующее: Maven, WildFly. GIT - я думаю вручную учить не нужно, т.к. можно будет воспользоваться средствами IDE. Насколько важен ЕJB - контейнер и всё что с этим связано( всякие EJB бины, ЖМСы итд. ) ???
Насчёт HIbernate, я так понял, что это как реализация JPA, так и собственная реализация ORM( со своем HQL и тд. ). Конечно я двумя руками за JPA, так как это увеличит переносимость кода, но что потребует работодатель,
никто не знает..
По моему опыту AppServer отмирает как класс, но в мире много старья.
Посмотрите еще Spring Framework - очень широко используется по поводу и без повода.
Git рекомендую изучить поглубже (см. соседнюю тему, там именно по этому много написано полезного).
И запомните одну очень важную вещь: хороший работодатель не ожидает от вас знания всего и вся, но вы должны быть в состоянии в кратчайшие сроки получить нужные знания. Так что не забивайте свой чердак всякой ерундой, лучше смотрите более абстрактные вещи типа оо-дизайна.
нп.
SOLID, DRY, KISS наше фсё.
Кстати, некоторым помогает открыть глаза на разработку качественного кода почитать про "нефункциональные требования" (nicht-funktionale Anforderungen, NFA) и "требования к качеству" (Qualitätsmerkale).
ТС, кстати, а как у вас с JUnit, EasyMock/Mockito/... и вообще с тестированием кода?
Про солид: http://www.yegor256.com/2017/03/28/solid.html
Ваще чувак жжот, я тут целый рабочий день на его блог убил :)
Прочитал про SOLID. Жжот это да. Так передергивает что на онанизм похоже. Хорошо что знает про loose coupling и cohesion. Пока что он мне нашего теоретика напоминает. Он тоже L не понимал :)
P.S. Открыл Америку.. Просто пока ты выговоришь high cohesion, loose coupling поседеешь. А тут бах - SOLID!
но что потребует работодатель, никто не знает
-----
Как никто? 
Я в точности знаю что именно нужно работодателю.
Даже где-то на сайте писал - про найм секретарши на несложную работу.
А вообще - полная задница с работничками. Чуть что-то более сложное чем верстка ХТМЛ - человека надо искать дооолго.
Я уже почти отчаялся найти людей на фрагменты проекта - ни у кого нет нужного мне опыта. Ну оно и не удивительно - реализации делались всего раз 20-30...
Удивительно то, что уже никому НЕ ИНТЕРЕСНО разобраться с вопросом на требуемом уровне... это - реально швах...
>А вообще - полная задница с работничками. Чуть что-то более сложное чем верстка ХТМЛ - человека надо искать дооолго.
Небось в требованиях стоит что-то навроде 10 лет C++, C#, RS 232, ProfiBus, SQL Server и CORBA с Javascript-ом до кучи. Зарплата 45 тыс :)
Да проще - есть задача, для реализации которой нужны либо конкретные знания, либо желание разобраться в проблеме.
За разбирание проблемы не платится, платится за фактическую реализацию.
Работа - разовая и не срочная. Т.е. можно поковырятся в свободное время для расширения кругозора.
Тематика - вполне себе интересная и весьма полезная для исследователя.
Оплата - да, не высокая. Но работа предлагается там, где эта оплата вполне существенна.
По крайней мере лет 15-ть назад Я бы взялся посмотреть на что-там-можно-сделать просто из интереса.
Но интереса - нет. Просмотры объявлений - есть. Интереса к области - пока не зарегистрировано...
В требованиях - Шарп, знание МС Студий от 2010 до 2017 как инструмента. (2002 и 2005 - не прошу - там организация другая).
Читаю https://www.amazon.de/Adrenalin-Junkies-Formular-Zombies-T..., там на эту тему тоже есть :)
Насчёт HIbernate, я так понял, что это как реализация JPA, так и собственная реализация ORM( со своем HQL и тд. ). Конечно я двумя руками за JPA, так как это увеличит переносимость кода, но что потребует работодатель, никто не знает..
Spring Data рулит, Hibernate де-факто стандарт. Отдельные фишки последнего нужны только оптимизации, почти все делается на чистом JPA. EJB уже сто лет никому не нужен, как и WildFly. В наше время делается микросервис с embedded сервером, например Tomcat, executable jar закидывается в cloud - и дело с концом. Maven само собой, но там учить особо нечего.
Каковы шансы найти работу имея IHK-Anwendungsentwickler, OCA и OCP, но не имея стажа и опыта (есть лишь несколько своих домашних проектов)
Доведи до ума проект, выложи на гитхаб и показывай. Опыт кроет сертификаты every single time.
Spring Data рулит, Hibernate де-факто стандарт. Отдельные фишки последнего нужны только оптимизации, почти все делается на чистом JPA.
О как. Конгресс, немцы какие-то. Что тут думать, взять и поделить. К сожалению, многие более-менее серьёзные продукты быстро перерастают границы "чистого JPA". И выясняется что дешевле написать две реализации ORM-а для двух БД чем пытаться добиться от хибернейта чтобы он работал то с одним то с другим диалектом хотя бы в 2 раза (а не в 10) медленнее, чем тупой JDBC с SQL-ем. Остающиеся на хибернейте потом почему-то все равно скатываются в дорогих запросах на SQL. И получается такая каша... А потом начинаешь разбираться почему хибернейт то лочит то не лочит строки... И даже приглашеный гуру хибернейта разводит ручками, любовь к этому "стандарту" становится все глубже и глубже.
EJB уже сто лет никому не нужен, как и WildFly.
Ну, это смотря кому. Если пишешь веб-формочку "введите свое имя", то конечно нет. Тут EJB и не нужен был никогда.
В наше время делается микросервис с embedded сервером, например Tomcat, executable jar закидывается в cloud - и дело с концом.
Вы забыли добавить "в наше время, там где я работал". База в облаке, приложение в облаке. Зато load balancer тремя кликами подключается. Нормальное расшаривание сессии между несколькими серверами, аутентификация, авторизация, datenschutz - а чо эта такое?
Вы пытались настроить у томкэта в амазоновском облаке аутентификацию керберосом с вашим локальном AD? Попробуйте. Очень весело.
А потом попробуйте сделать это же на локальном wildfly-е и поделитесь впечатлением.
Не забывайте, когда шашкой в следующий раз махать будете, что есть разные требования к приложениям. Что-то решается задеплоеным на встроенном томкате классом из 20 строчек, зато на 100 северах, разбросанных по всему миру, где главное скорость, а где-то лучше подождать 10 минут зато гарантировать целостность данных. Какое-то приложение разрабатывается 100 часов и живет 6 месяцев, а какое-то требует 100 часов только на прогон интеграционных тестов, и живет десять лет.
А где-то комбинируется и то и другое. Мы и в облако докеровские имижди деплоим и в своем ВЦ на вебсферы EAR-ы.
Вы забыли добавить "в наше время, там где я работал"
Я как бы фрилансер и имею новые рабочие места каждые несколько месяцев.
К сожалению, многие более-менее серьёзные продукты быстро перерастают границы "чистого JPA".
Ясен пень, что случаи бывают разные. Я было писал двухстраничные запросы в нейтивном SQL для Oracle, кои исполнялись через майбатис. Всякое бывает. Но тут речь о наиболее популярных случаях для вхождения новичка в отрасль. А EJB сегодня нигде не нужны. Изначально дебильная технология. Как и JSF
Я как бы фрилансер и имею новые рабочие места каждые несколько месяцев.
Верю. Именно поэтому вас и не допускают до чего-то серьезного. Пришел, сделал за 3 месяца, ушел. Кстати, вопрос к этой дискуссии не относящийся, как к фрилансеру - а как часто и в каком объеме вы документируете свои разработки?
Вот вы на многих фирмах работали, примерно можете оценить, вроде "на 50% фирм от меня требовали javadoc, на 10% - многостраничную документацию по их шаблонам, на остальных про документацию никто не спрашивал".
У нас просто бич какой-то нанятые экстерны сваливают не оставляя за собой ни строчки документации. Потом этот натурпродукт переваливают на нас. И я пытаюсь понять это наши HR-ы так "экономят" или у фрилансеров "так принято".
Но тут речь о наиболее популярных случаях для вхождения новичка в отрасль. А EJB сегодня нигде не нужны. Изначально дебильная технология.
Имхо - EJB, особенно с 3-й версии когда все стало более понятно, без всех эти Home-ов и тепе, намного более проще во вхождении, применении и приносит больше пользы (в сложных проектах) чем хибернейт.
Для вхождения новичка в отрасль никаких проблем не представляет. Только с транзакциями голову ломать приходится. Понял что такое statefull / stateless и вперед, на баррикады. Это вам не генерировать ИД как стринг в хибернейте...
Или что вы подразумеваете под "дебильностью" технологии?
Очень смешно. Особенно когда именно я обычно делаю мясо, то бишь костяк проекта.
Вы не обижайтесь, я со свой колокольни сужу, мы фрилансеров ни до чего серьезного не допускаем. Потому как потом никакой информации не найти. А часто проще переделать чем править.
Ну и перечисленные технологии - спринг, хибернейт, встроенный томкэт, не хватает только какой-нить NoSQL-базы или in-memory вроде H2. Из песни слов не выкинешь - "хуяк, хуяк и в продакшен" :)
А через 2 месяца как от фрилансера стул остыл, руководство понимает что ой, ашипки полезли. Ну-ка разберитесь. И ты видишь что ошибка лезет из-за бага в спринге. А зачем его использовали? А чтобы быстренько найти все классы из класспаса, из пакета a.b.c. Ну не может же быть чтобы всю сотню мегов спринга только для этого тянули? Да лехко. Потому что время на
написать свои 50 строчек или поискать более подходящую библиотеку фрилансер не потратил. Он же спринг знает и гори оно все огнем. А уж написать пару строчек вроде "здесь я использую спринг а не рефлекшенз потому что..." тем более.
Потому что время на написать свои 50 строчек или поискать более подходящую библиотеку фрилансер не потратил.
-----
А сможешь объяснить - ЕМУ-то - зачем?
Свою работу - работу на которую его наняли - он сделал. 50 строчек его написать не просили...
Кстати, у меня щас как раз такой случай. Hibernate 3.2.6, мэппинги собираются в jar и запихиваются в ejb.jar, а при инициализации хитровыеб...сто оттуда достаются через getResource. Блять, руки бы таким "программистам" отрывал на месте.
Я подумал, а че бы мне их не экспортировать в отдельный jar и не подать через addJar? А хрен там, путь к jar только через жопу.
А через 2 месяца как от фрилансера стул остыл, руководство понимает что ой, ашипки полезли. Ну-ка разберитесь. И ты видишь что ошибка лезет из-за бага в спринге. А зачем его использовали? А чтобы быстренько найти все классы из класспаса, из пакета a.b.c. Ну не может же быть чтобы всю сотню мегов спринга только для этого тянули? Да лехко. Потому что время на написать свои 50 строчек или поискать более подходящую библиотеку фрилансер не потратил. Он же спринг знает и гори оно все огнем. А уж написать пару строчек вроде "здесь я использую спринг а не рефлекшенз потому что..." тем более.
Ну давай уж быть честными :) Это не косяк фрилансера, это косяк тимлида ;)
Не спорю. Да. Но. Тимлида мы поменять не можем.
:) Ну т.е. получается, что вы не допускаете фрилансеров до чего-то серьезного из-за того, что косячит ваш тимлид :)
Получается забавная ситуация - вы за дорого покупаете эксперта, но из-за того, что тимлид косячит, эксперта этого допускаете до работы, которую мог бы делать студент :D С таким подходом надо срочно менять тимлида. Иначе он (тимлид) вас разорит :D
А вот решить какие задания давать фрилансеру - можем повлиять.
А также прописать используемые технологии, описать круг задач итд.
Меня на актуальный проект взяли на роль архитектора. Тимлид правда боится делать какие-то изменения, но иногда мне все таки удается что-то продавить. Вот юнит-тесты ввел (тимлид изначально был против), Постепенно меняю архитектуру проекта... маленькими шажками,
чтобы тимлид не особенно переживал. Тимлид при этом свячески старается меня затормозить, дает какие-то незначительные задания из тагесгешефта... мне, в принципе, похер, я могу и логи править. Но брали-то меня не логи править, а внедрить автоматическое тестирование и сделать проект тестируемым.
Ну т.е. получается, что вы не допускаете фрилансеров до чего-то серьезного из-за того, что косячит ваш тимлид :)
Еще хуже. Он не "наш". Ну, в смысле наш что на нашей фирме работает, да. Тимлид А берет фрилансера, не контролирует что он делает, потом когда фрилансер сваливает и надо править / дорабатывать что он сделал, это натурпродукт сваливают на нас (на "моих" тимлидов), мол это же утилита / веб проект а значит в вашей "зоне компетентности". А мои тимлиды - трусы. И вместо того, чтобы отказаться перенимать дерьмовый проект блеют "начальство не поймет" и перенимают его. Продавить обязательное одобрение архитектора при передаче проекта у нас пока не получается.
Влиять на тимлида А я могу только жалуясь начальству. А вот в разработке правил,
на какие проекты мы берем фрилансеров а на какие нет я участие принимаю.
Вот и получается что проще засадить их мелочь доделывать и освободить собственных экспертов, чем давать им что-то серьезное. В том числе и из-за вечной лени тимлидов. Но и из-за того что фрилансер редко заинтересован в качестве, его надо из него клещами выдирать.
Не совсем понятно, но коротко :)
Запутанно у вас :) Но в результате все равно тимлиды косячат, а фрилансер - получается хорошим спецом :)
Кстати, много зависит от постановки задачи. Мой тимлид так ставит задачу, что хрен поймешь его мысль. Потом эта задача идет на аутсорс и в результате получается говно. А все потому, что во-первых, задача была криво поставлена и во-вторых, фрилансер не попытля доказать, что тимлид неправ.
Но и из-за того что фрилансер редко заинтересован в качестве
Фрилансер заинтересован в ауфтрагах. При чем, чем больше аутраг, тем лучше. Так что тут ты не прав.
Но в результате все равно тимлиды косячат, а фрилансер - получается хорошим спецом :)
Дык. Я и с этим не спорю. Среди фрилансеров часто хорошие специалисты встречаются. Но я пока что не встречал ни одного фрилансера, который бы свое творчество документировал, если не стоять с палкой и плеткой за спиной. Даже когда в задании отдельно упомянуто что и где должно быть описано.
Если ты работал 10 лет с Java, независимо от того, как ты попал на работу в самом начале( через контакты, удача и тд.) - то да, ты вполне подготовлен. Речь идёт о новичках. Да и где не надо думать?? Industriekaufmann не должен думать?? Просто у них нет таких проблем как у прогеров-новичков. Опять таки, это моё мнение и я не хочу спорить. Я знаю, что есть талантливые ребята и всё такое, но речь идёт не об этом.
Если ты работал 10 лет с Java, независимо от того, как ты попал на работу в самом начале( через контакты, удача и тд.) - то да, ты вполне подготовлен.
-----
Бред.
Единственная не бредовая часть - в том что уровень подготовленности не зависит от способа получения работы.
Все остальное зависит от организации процесса.
Простой пример - берем Жабиста на формошлепство. Работа - разместить контролы на форме, подогнать размеры, сделать отработку ресайза и т.п. Бизнес-объекты - не его - получает готовые. Что он будет знать через 10 лет такой работы? Ни-че-го!!! Даже полный синтаксис Жабы забудет...
Просто у них нет таких проблем как у прогеров-новичков.
-----
Не у всех. И не всегда.
Я, вроде, не совсем новичек, но... вот сегодня потребовалось нарисовать текст в рамке с закругленными концами.
До сих пор не отрисовал... Драфт есть, но - с ошибками...
Да и где не надо думать?
-----
Ну у меня сейчас не надо думать.
Просто надо МНОГО делать. Стандатная, рутинная работа по вырезанию кусков кода, переводу на другой язык, разделению на объекты и т.п. Никакого творчества...
И даже это толком не получается сделать. Просто где-то в средине процесса происходит прерывание с переключением, недоработанный кусок откладывается и делается что-то другое.
В текущем приложении - уже 6 таких брошенных частей - Я его даже собрать толком не могу.
Сейчас вот была неделя по-свободнее - подчистил что помнил. Оказалось - не все помнил - теперь надо имплементить еще один класс - ордера поделены на группы и запрос по диапазону ордеров гребет много лишнего... надо делать список по группам и с конвертированием в СКЛ-фильтер...
Согласен, что 10 лет формостроя не сделают Жабиста лучше, но Жабист, уже, по крайней мере, будет работать в правильной среде, и, если есть интерес, может и дома заниматься и улучшаться. Я как раз и ищу такую работу, рутинную, типа формостроя.. Но это тоже не так легко найти. В основном пока только разные Аrbeitnehmerüberlassungsfirmen предлагают работу вроде - Support/Helpdesc.
но Жабист, уже, по крайней мере, будет работать в правильной среде
-----
??? - Точно в среду? Может четверг или вторник?
В любом случае - это то, как организован процесс.
Знаю девочку-драйверописателя, не знавшую ни одного формального языка. Совсем.
Ни-че-го. Но драйвера - писала. И не учила ничего.
может и дома заниматься и улучшаться
-----
Эээ... Гхммм... Хи-хи-кс...
Я как раз и ищу такую работу
-----
Так ее все ищут - именно - тупую, рутинную, но денежную.
Иногда - находится...
Эээ... Гхммм... Хи-хи-кс...
-----
Не совсем понял ваши аргументы. Может очередной, новый, так требуемый на рынке труда, фреймворк?.
Так ее все ищут - именно - тупую, рутинную, но денежную.
Иногда - находится...
----
Извольте, я не сказал тупую, и я не сказал денежную. Я лишь сказал - рутинную.