Перейти к содержимому


Фотография
- - - - -

Java в саранске, есть ли?

есть ли конторы

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 36

#21 BaRoN

BaRoN

    Ламо

  • Почетный житель
  • PipPipPipPip
  • 2 035 сообщений

Отправлено 24.12.2014, 14:31

Повторюсь, в Химки, к торговцу деревянными членами!.. Вероятно, автор мнения работает в корпоративной среде, на вышеозначенные ГАЗПРОМ, Боинг и т.п.

Применение J2EE в новых некорпоративных проектах — неоправданный оверхед, ни одна здравомыслящая компания в наши дни НОВЫХ решений на этой технологии не создаёт и не будет создавать.
И если ты придёшь в какую-нибудь компанию и будешь нести эту чушь, и внедрять при разработке НОВОЙ СИСТЕМЫ, то руководство компании Химкинское изделие ещё и в тебя воодрузит, и три раза провернёт. Но, как и всякие фортраны-коболы-смоллтолки, JEE жила, живёт и будет жить ещё долго, потому что системы УЖЕ написаны и их надо поддерживать.

JEE стало "проще и удобнее", потому что его пытаются сделать совместимым. С тем же Hibernate (ту же JPA писали, когда Hibernate уже был; JPA сделан по сути на основе Hibernate), соответственно перевод существующего приложения на JPA was a breeze. В том числе, для того, чтобы существующие EJB можно было использовать в новых системах на основе Spring (и да, это работает, реально можно). Так же возможна интеграция и в обратном направлении.

Сейчас практически всё в ecommerce, и уж тем более всё не относящееся к e-commerce, пишут с Hibernate/Spring/Wicket. Не потому, что это костыли и подпорки, а потому, что это удобный конструктор. Например, когда впридачу к бинам не идут пулы для потокобезопасной обработки (знаю-знаю, можно отключить с JEE6), а наоборот - когда какая-то фича потребуется, добавляют соответствующий компонент. В повседневной жизни JEE приложение - это электронный микроскоп для забивания гвоздей. Громоздко, дорого и неудобно. Проекты Spring + Hibernate - это как собрать молоток из ручки и головки. Под одно решение нужен молоток с гвоздодёром, под другое - киянка, под третье - лёгкий молоток со стеклопластиковой рукоятью (или хз из чего там её делают). Вполне возможно, со временем, небольшая контора на 1000 человек вырастет до гигантской корпорации с сотнями тысяч сотрудников, к молотку прикрутят и весь электронный микроскоп, то бишь прикрутят все "фишки" JEE поверх обычного каркаса Spring (опять же, почему нет?).

В отличие от JEE, этих ребят никуда не тянет груз старой архитектуры и совместимости с ней. Они не учат, как программировать и какие технологии использовать. За счёт этого, к ним можно прицепить ВООБЩЕ всё. Можно прицепить stateful EJB, например, а можно и Hibernate. То, что почти все отдают предпочтение Hibernate, у меня не вызывает никаких вопросов. Это свободный осознанный выбор. И по моему мнению, для повседневных задач - выбор верный smile.png. Возможно, когда-нибудь передо мной будут стоять какие-нибудь задачи вселенского масштаба и возможно, для них осознанным верным выбором будем EJB, не знаю.

Сообщение отредактировал BaRoN: 24.12.2014, 14:39

Искренне свой, Я! =) [Старый блог] [ Место работы ] [ Jabber: ruslanbalkin@gmail.com ] [ Telegram ] [baron.su] [ Twitter ].


#22 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 641 сообщений

Отправлено 24.12.2014, 23:54

Sring сейчас — это как раз унаследованное решение, которое заменяло ранние разработки J2EE. Если точнее — в эпоху ухода Java 2.0 и появления Java 5.0, когда не было альтернатив EJB 2.0, а переписать всё или написать заново на лёгком фреймворке хотелось. Ведь Spring+Hibernate развился на фоне господства Java 2.0 (v.1.4), в качестве легковесной замены неуклюжим EJB из J2EE.

Аннотации, появившиеся в Java 5.0, наметили тенденцию к уходу от монструозных XML-конфигов. Наконец, в Java EE 6 XML-конфиги для бинов практически не нужны, появилась и эволюционировала новая модель персистентности (JPA) заместо старой (EJB 2.0), что привело к тому, что надобность в связке Jetty+Spring+Hibernate, как лёгкой альтернативы, отпала сама-собой, так как все функции по интеграции, кластеризации и взаимодействию бинов, фронтенда (JSF) и бэкэнда (JPA) на себя берёт один сервер приложений, обеспечивающий к тому же интерактивную отладку в связке со средой программирования.

К примеру, Oracle GlassFish недавно выбросили из продакшена, так как он медленный на холодном старте, хотя деплой/отладка/останов приложений на нём быстрые (около 4 секунд). Для сравнения: JBoss (свободная реализация — WildFly), они стартуют с нуля и разворачивают приложение в течение нескольких секунд (порядка 8-10 секунд на всё с холодного старта).

Spring+Hibernate — это нестандартность решений. Куда повернут разработчики со своим Spring в будущих весиях — загадка. А решать задачи нужно уже сейчас и желательно использовать утверждёные JSR'ы, а не то, что придумали когда-то ребята на коленке.

Сообщение отредактировал Novikov: 24.12.2014, 23:57

Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#23 BaRoN

BaRoN

    Ламо

  • Почетный житель
  • PipPipPipPip
  • 2 035 сообщений

Отправлено 25.12.2014, 12:57

Sring сейчас — это как раз унаследованное решение, которое заменяло ранние разработки J2EE. Если точнее — в эпоху ухода Java 2.0 и появления Java 5.0, когда не было альтернатив EJB 2.0, а переписать всё или написать заново на лёгком фреймворке хотелось. Ведь Spring+Hibernate развился на фоне господства Java 2.0 (v.1.4), в качестве легковесной замены неуклюжим EJB из J2EE.

Совершенно не так. Это не "унаследованное решение", это новое решение, которое создавалось БЕЗ ОГЛЯДКИ на J2EE, им не требовалась совместимость.
Это JEE пыталось догнать паровоз, по принципу "не можешь победить - возглавь". JEE пыталось "прекратить господство" не EJB, а Hibernate. Не получилось. Зато получилось другое: скопировав интерфейсы Hibernate в JEE, они фактически сделали специалистов по Хибернейту автоматически специалистами по JPA в Энтерпрайзжаве. Это очень даже здорово. Рынок отвоевать, правда, не получилось. В моде модульные системы.

Наконец, в Java EE 6 XML-конфиги для бинов практически не нужны, появилась и эволюционировала новая модель персистентности (JPA) заместо старой (EJB 2.0), что привело к тому, что надобность в связке Jetty+Spring+Hibernate, как лёгкой альтернативы, отпала сама-собой, так как все функции по интеграции, кластеризации и взаимодействию бинов, фронтенда (JSF) и бэкэнда (JPA) на себя берёт один сервер приложений, обеспечивающий к тому же интерактивную отладку в связке со средой программирования.

Пока эти тиранозавры выпускали "шестёрку", свою долю рынка они потеряли.
О боже мой! Правда что ли, можно отлаживать приложения?!?! Вот это конкурентное преимущество biggrin.pngbiggrin.pngbiggrin.png

К примеру, Oracle GlassFish недавно выбросили из продакшена, так как он медленный на холодном старте, хотя деплой/отладка/останов приложений на нём быстрые (около 4 секунд). Для сравнения: JBoss (свободная реализация — WildFly), они стартуют с нуля и разворачивают приложение в течение нескольких секунд (порядка 8-10 секунд на всё с холодного старта).

Родной, пацак пацака не обманывает! У меня хелловорлд 10 секунд на гласфиш деплоится smile.png))
Ну и на всякий случай, посмотри spring-boot, от скорости старта вообще обалдеешь smile.png http://spring.io/gui...gs/spring-boot/ вот пример. Всячески рекомендую ставить gradle и spring-boot через gvm (gvmtool.net).

Spring+Hibernate — это нестандартность решений. Куда повернут разработчики со своим Spring в будущих весиях — загадка. А решать задачи нужно уже сейчас и желательно использовать утверждёные JSR'ы, а не то, что придумали когда-то ребята на коленке.

Никуда не повернут. Spring не учит, как жить. Он учит создавать модульные приложения, как в принципе и JEE. Только модульности ЕЩЁ больше.

Spring-core это просто инструмент, контейнер для IOC. Не нравится Spring? Взял Guice. Присаживаешь на этот "клей" что угодно, хоть EJB, хоть спринг бины, хоть контроллеры, что угодно.
Хочешь сохранять данные? ОК, берём Spring-data. Не нравится Spring-data? Берём Hibernate. Не нравится Hibernate? Берём другой ORM, забыл как звать уже, только разок щупал в личном проекте.
Нужна кластеризация? Взял glassfish, web profile. Слишком непроизводительно? Окей, запилил привязку к одному серверу по IP или кукису (через ip_hash или sticky в nginx, например). Всё-таки кластеризация нужна? Окей, реализовал репликацию сессий через redis / mongodb / реляционную БД (jdbc).

P.S. А лет через 10, наверное, в JEE добавят даже аналог Spring-Hadoop.
Ну, к тому моменту, как для спринг выпустят какой-нибудь телепатический интерфейс smile.png
P.P.S. Решать задачи надо с использованием здравого смысла, а не утверждённых JSR'ов.

Искренне свой, Я! =) [Старый блог] [ Место работы ] [ Jabber: ruslanbalkin@gmail.com ] [ Telegram ] [baron.su] [ Twitter ].


#24 majesty

majesty

    хммм..

  • Почетный житель
  • 1 439 сообщений

Отправлено 27.12.2014, 19:09

все же поднять сервер приложений и пользовать сразу ejb, jpa, jsf, jaas мне видится проще.
плюс спецификаций еще и в избытке документации.


кстати по поводу wildfly, быстрее glassfish'a по моим наблюдением раза в 2. деплой на моем железе 15 секунд против 30. и по ощущениям отзывчивее все работает.

#25 BaRoN

BaRoN

    Ламо

  • Почетный житель
  • PipPipPipPip
  • 2 035 сообщений

Отправлено 31.12.2014, 20:50

все же поднять сервер приложений и пользовать сразу ejb, jpa, jsf, jaas мне видится проще.

Проще чем что? Если ты долгое время изучал J2EE, но не изучал ничего другого, то наверное так оно и есть.
Я впервые EJB писал, вроде, в 2002 или в 2003, на компе, разрывающемся от нагрузки, но платили уж больно хорошо - альтернатив особо не было smile.png Заодно на комп заработал :-D.
Сейчас - есть достойные альтернативы, а у меня - опыт применения того и другого. Правда, с JEE - с 2008 года больше не работал, только релиз ноутс читал, но да не суть.

Прежде чем выбрать технологию, неплохо понимать плюсы и минусы этого выбора. Привязываться к JEE - значит, по большому счёту, ограничить себя рамками; получить снижение производительности (хотя, если знать про всякие тонкости вроде @Singleton, не очень значительное). Одной из особенностей будет являться железобетонная совместимость (одновременно плюс и минус). К тому же, решения, которые "советует" Sun/Oracle - они хорошие. Многоуровневая архитектура, вот это всё. И да, Sun/Oracle говорит, ЧТО ИМЕННО следует учить разработчику. Дальше можно всю жизнь вариться в этом Ынтерпрайзе, с одними и теми же технологиями, решать одни и те же задачи smile.png.

С другой стороны, можно построить архитектуру системы самостоятельно. Там, где нужна огромная масштабируемость и/или высокая производительность, J2EE скорее не место. Там вообще часто упираться будет не в количество машин в кластере, а в грамотную асинхронную архитектуру (ActiveMQ какой-нибудь, или даже инородный RabbitMQ, который я предпочитаю) smile.png. Или есть, например, Hadoop. Который кстати тоже медленный как хз что, но со своей нишей применения. Или шикарный, но непонятый и неосвоенный мной Spark. Или есть, например, JPA. И можно выбрать своего провайдера, Spring-Data, Eclipse Link или Hibernate. Да, если выбрать неправильно - можно всё испортить smile.png. Или можно остаться без работы, и на новой работе сменить инструментарий наполовину, потому что там архитектору нравятся другие технологии :-D В общем, тут уже всё зависит от архитектора - если он возьмёт например Хадуп там, где он не нужен - всё закончится трагично smile.png И как я уже писал, никто не запрещает использовать любые технологии. Нравятся Faces - пользуйся Faces! В мире JEE использование какого-то другого шаблонизатора бы выглядело как минимум странно, не правда ли - зачем держать сразу 2 шаблонизатора? smile.png

Но всё-таки, если брать сферическую задачу в вакууме, что-то небольшое, что надо запустить в сжатые сроки и не будучи миллиардером, я бы выбрал spring-core в качестве "клея", spring boot для быстрого запуска (сервер приложений вообще не нужен при отладке), ну и Hibernate как мне кажется, генерирует более предсказуемый SQL для PostgreSQL (да, ОБЫЧНО разницы никакой, но в сети можно найти примеры идиотских SQL для каждой реализации JPA). Для CRUD-админки больше, чем Spring Roo, мне нравится Grails. И лишь подтверждает актуальность выбора Hibernate вместо Spring-Data (хибернейтовский GORM отличная надстройка над Hibernate). А ещё Grails это примерно так же круто, как RoR, но во вселенной Java smile.png

Отдельное преимущество отказа от JEE - это деньги. Реально что-то простое уместить на типичной 256-Мбайтной VPS (burst 512) на OpenVZ, реально найти shared-хостинг на Tomcat. Само собой, я не говорю про проекты масштаба тех, в которых оправданно использовать Ынтерпрайз яву (газпром, боинг, …). В любом случае, инфраструктура может стоить дешевле.

Про Wildfly - может быть, JBoss всегда был довольно легковесным smile.png. Да в конце концов, ту же репликацию сессий (кластеризацию он вроде и не умеет, всё равно nginx брать) делать там примерно через такую же задницу, что и в легчайшем jetty smile.png

Искренне свой, Я! =) [Старый блог] [ Место работы ] [ Jabber: ruslanbalkin@gmail.com ] [ Telegram ] [baron.su] [ Twitter ].


#26 lysart

lysart

    Ёгало

  • Почетный житель
  • PipPipPipPip
  • 1 692 сообщений

Отправлено 31.12.2014, 20:51

Барон, купи бутылку водки, Христа ради!


ndl, типа...


#27 BaRoN

BaRoN

    Ламо

  • Почетный житель
  • PipPipPipPip
  • 2 035 сообщений

Отправлено 31.12.2014, 20:56


Но в принципе, если веровать в Спринг, можно абстрактное приложение в вакууме слепить полностью на спринг-технологиях. Spring-boot, spring-core, spring-data, spring-security, spring roo. Будет очень последовательно и всякое такое. Но если нам лучше подойдёт hibernate, чем spring data; или лучше подойдёт grails (тоже кстати spring foundation), чем spring roo - то почему не заменить? smile.png Конструктор - это не плохо, это хорошо.

Барон, купи бутылку водки, Христа ради!

Бог подаст!

Искренне свой, Я! =) [Старый блог] [ Место работы ] [ Jabber: ruslanbalkin@gmail.com ] [ Telegram ] [baron.su] [ Twitter ].


#28 lysart

lysart

    Ёгало

  • Почетный житель
  • PipPipPipPip
  • 1 692 сообщений

Отправлено 31.12.2014, 20:59

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


Сообщение отредактировал lysart: 31.12.2014, 20:59

ndl, типа...


#29 BaRoN

BaRoN

    Ламо

  • Почетный житель
  • PipPipPipPip
  • 2 035 сообщений

Отправлено 31.12.2014, 21:01

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

Так обращай хоть к психиатру, хоть к пожарному, - я не против smile.png
Хотя если тебе не хватает на бутылку водки, это наверное, к наркологу.

Искренне свой, Я! =) [Старый блог] [ Место работы ] [ Jabber: ruslanbalkin@gmail.com ] [ Telegram ] [baron.su] [ Twitter ].


#30 S.A.M.

S.A.M.

    Почетный житель

  • Почетный житель
  • 565 сообщений

Отправлено 02.01.2015, 12:38

Отвечу на первоначальный вопрос.
Есть в саранске филиал нижегородской компании Теком. На одном проекте spring+hibernate+gwt (ну и много прочего, rabbitMQ, rrd), на другом (легаси, к которому допиливают плагины) swing, osgi и как раз возможно в какой-то степени jee.

Всегда пассивно ищут "интернов" (part time, неск.месяцев до полноценного трудоустройства). Сейчас еще на hh нескоголько вакансий для людей с опытом.
public static void

#31 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 641 сообщений

Отправлено 12.01.2015, 21:44

Но всё-таки, если брать сферическую задачу в вакууме, что-то небольшое, что надо запустить в сжатые сроки и не будучи миллиардером, я бы выбрал spring-core в качестве "клея", spring boot для быстрого запуска (сервер приложений вообще не нужен при отладке), ну и Hibernate как мне кажется, генерирует более предсказуемый SQL для PostgreSQL (да, ОБЫЧНО разницы никакой, но в сети можно найти примеры идиотских SQL для каждой реализации JPA). Для CRUD-админки больше, чем Spring Roo, мне нравится Grails. И лишь подтверждает актуальность выбора Hibernate вместо Spring-Data (хибернейтовский GORM отличная надстройка над Hibernate). А ещё Grails это примерно так же круто, как RoR, но во вселенной Java smile.png

Разбор полётов: Episode 75 - Java вся такая белая и пушистая и в контейнере


Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#32 majesty

majesty

    хммм..

  • Почетный житель
  • 1 439 сообщений

Отправлено 16.01.2015, 20:34

Отвечу на первоначальный вопрос.
Есть в саранске филиал нижегородской компании Теком. На одном проекте spring+hibernate+gwt (ну и много прочего, rabbitMQ, rrd), на другом (легаси, к которому допиливают плагины) swing, osgi и как раз возможно в какой-то степени jee.

Всегда пассивно ищут "интернов" (part time, неск.месяцев до полноценного трудоустройства). Сейчас еще на hh нескоголько вакансий для людей с опытом.

знаю паренька оттуда, но когда последний раз видел , джуниоры не треба, ищут с опытом кого-то действительно. думал еще есть конторы может.



#33 majesty

majesty

    хммм..

  • Почетный житель
  • 1 439 сообщений

Отправлено 16.01.2015, 21:15

в принципе в москву может быть рвану летом, так то запас есть, даже больше чем джуниорский. JSF(Primefaces), EJB, JPA, JAX-RS , ну и Apache POI (надо было экспорт в эксель таблиц некоторых сделать smile.png. а так еще Maven для деплоя на openshift, Git  на уровне add/commit/push/pull . в общем всего не полностью, но по мере необходимости. но в принципе все работает, что не знаю - читаю, понимаю, исправляю.  сейчас CRM делаю типа регистрации корреспонденции в организации как веб приложение (первоначальный вариант на swing меня не впечатлил(долго, муторно писать и с дизайном особенная беда), так стал копать в сторону веба , почти доделал кстати (с автокоммитами и lazy таблицами , по Rest у меня работает экспорт в ворд пользователю(чисто для изучения делал), в общем всего понемногу). дело несрочное, так как работа у меня сисадминская, начальник сказал неплохо бы сделать, вот и ковыряю). а вообще интересная она Java . я стал фанат).  

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

 

а до джавы я написал пару мелких сетевых приложений на С + WinApi smile.png , но после джавы возвращаться не хочется)  (предполагаю что поэтому так джава и понравился, что сильно все упростил и оставил наиприятнейшие впечатленияsmile.png

 

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


Сообщение отредактировал majesty: 16.01.2015, 21:24


#34 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 641 сообщений

Отправлено 26.01.2015, 23:52

Вот ещё в объект темы

Разбор Полетов: Episode 76 — OSGi великий и ужасный

Пункты подкаста:OSGi or NOSGiКнигиПолезняшкиГости и участники:
twitter:
Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#35 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 641 сообщений

Отправлено 28.01.2015, 15:33

Вот ещё в объект темы

Разбор Полетов: Episode 76 — OSGi великий и ужасный

Ну что, кто-нить дослушал до конца этих "космонавтов"? Как будто они в другой реальности живут и работают, но слушать их болтовню занятно. Они же про OSGi нихрена ничего не знают, а взялись рассуждать. Только один из болтунов - Павел Самолысов, samolisov, "Суровый челябинский программист" плотно работал с этой технологией, но как-то ничего о ней существенного не сказал (или я пропустил - поправьте).
Кто что думает?

Сообщение отредактировал Novikov: 28.01.2015, 15:33

Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#36 Novikov

Novikov

    Саксаул

  • Почетный житель
  • 4 641 сообщений

Отправлено 30.12.2015, 20:58

Очередной разбор полётов: Episode 99 — Бенчмарки пишешь, небось?
 
Тема из него: JMH benchmark for JavaEE: EJB vs Spring vs CDI

Комментарий автора: http://samolisov.blo...vs-cdi-jmh.html

вторник, 29 декабря 2015 г.
Spring Framework vs EJB vs CDI. Небольшой бенчмарк с использованием JMH
На днях Суровый выложил на GitHub исходники и некоторые результаты небольшого бенчмарка, проверяющего гипотезу о том, что Spring Framework быстрее этих ваших EJB.

Как оказалось - нет, не быстрее.


Пройдя огонь, воду и медные трубы, становится как-то всё ни жарко, ни холодно и по барабану.

#37 Crocus

Crocus

    Небожитель

  • Забанен
  • PipPipPipPipPip
  • 7 024 сообщений

Отправлено 30.12.2015, 20:59

Налей лучше коньячку ))
насрать-посрать




Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 скрытых пользователей