Практика Java EE
Каковы шансы найти работу имея 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
А вот решить какие задания давать фрилансеру - можем повлиять.
А также прописать используемые технологии, описать круг задач итд.
Меня на актуальный проект взяли на роль архитектора. Тимлид правда боится делать какие-то изменения, но иногда мне все таки удается что-то продавить. Вот юнит-тесты ввел (тимлид изначально был против), Постепенно меняю архитектуру проекта... маленькими шажками,
чтобы тимлид не особенно переживал. Тимлид при этом свячески старается меня затормозить, дает какие-то незначительные задания из тагесгешефта... мне, в принципе, похер, я могу и логи править. Но брали-то меня не логи править, а внедрить автоматическое тестирование и сделать проект тестируемым.
Ну т.е. получается, что вы не допускаете фрилансеров до чего-то серьезного из-за того, что косячит ваш тимлид :)
Еще хуже. Он не "наш". Ну, в смысле наш что на нашей фирме работает, да. Тимлид А берет фрилансера, не контролирует что он делает, потом когда фрилансер сваливает и надо править / дорабатывать что он сделал, это натурпродукт сваливают на нас (на "моих" тимлидов), мол это же утилита / веб проект а значит в вашей "зоне компетентности". А мои тимлиды - трусы. И вместо того, чтобы отказаться перенимать дерьмовый проект блеют "начальство не поймет" и перенимают его. Продавить обязательное одобрение архитектора при передаче проекта у нас пока не получается.
Влиять на тимлида А я могу только жалуясь начальству. А вот в разработке правил,
на какие проекты мы берем фрилансеров а на какие нет я участие принимаю.
Вот и получается что проще засадить их мелочь доделывать и освободить собственных экспертов, чем давать им что-то серьезное. В том числе и из-за вечной лени тимлидов. Но и из-за того что фрилансер редко заинтересован в качестве, его надо из него клещами выдирать.
Не совсем понятно, но коротко :)
Запутанно у вас :) Но в результате все равно тимлиды косячат, а фрилансер - получается хорошим спецом :)
Кстати, много зависит от постановки задачи. Мой тимлид так ставит задачу, что хрен поймешь его мысль. Потом эта задача идет на аутсорс и в результате получается говно. А все потому, что во-первых, задача была криво поставлена и во-вторых, фрилансер не попытля доказать, что тимлид неправ.
Но и из-за того что фрилансер редко заинтересован в качестве
Фрилансер заинтересован в ауфтрагах. При чем, чем больше аутраг, тем лучше. Так что тут ты не прав.
Но в результате все равно тимлиды косячат, а фрилансер - получается хорошим спецом :)
Дык. Я и с этим не спорю. Среди фрилансеров часто хорошие специалисты встречаются. Но я пока что не встречал ни одного фрилансера, который бы свое творчество документировал, если не стоять с палкой и плеткой за спиной. Даже когда в задании отдельно упомянуто что и где должно быть описано.