Услышал тут от технического руководителя одной немецкой программерской конторы, что абсолютное большинство систем с web-интерфейсом делаются в Германии на java.
Его субъективная оценка, порядка 70-80% на java, остальное это либо какая-нить на данный момент ещё относительная экзотика, вроде функциональных языков, либо что-то устаревшее вроде PHP (особенно PHP 4), либо что-то, что ещё не стало пока MainStream, но имеет к этому предпосылки, вроде Node.js или Angular.js.
Я не в курсе именно немецкого рынка, но в России я думаю соотношение технологий в web другое. И PHP там используется по полной программе.
Кто сталкивался с немецким рынком, какая ваша оценка?

Корпоративный на джаве и дотнете, пых тоже имеется.

что в вашем понимании web? если обычные сайтики то скорее всего вообще ничего не пишется, берется любая готовая cms (php как правило) и при надобности даводится
а java оно для чего-то более серьезного чем просто сайтик

Осталось догадаться что понимается под "системой с веб-интерефейсом".
Пыхыпы у немцев тоже в почете. Всякие джумлы (лютый пыхыпизм :)) и тайпо3. Но как только система должна выдерживать больше одного хита в секунду, не отваливаться каждые 12 часов или работать с большой и сложной БД - ява.

ах бедный фейсбук, хабр и прочие ))

Ты забыл упомянуть, что у ФБ пхп компилируется в плюсы ;)

да какая разница? У хабра тоже наверняка apc или ещё что-то. сути то не меняет.
в высоконагруженных проектах намного важнее архитектура: как реализовано кеширование, масштабирование, балансировка нугрузки, а не какой язык используется в бэкенде для формирования html.

Right. На жабе горизонтальное масштабирование делается очень просто, про пых не скажу, не в курсе.

как вообще язык используемый в бэкенде для формирования разметки, может влиять на горизонтальное масштабирование?)))

Не язык, а технологии, с ним связанные.

В итоге всё равно всё упрётся в базу, разве не так?)) А читать/писать из/в базу какая разница чем?

Можно взять nosql ;)

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

Нет, там не упирается в базу в итоге, потому что база скалируется лучше, чем реляционная :)

подпишусь под каждым словом. И?))) Оратор выше вроде утверждает, что пых будет бутылочным местом при построении хайлоада. Что к реальности не имеет никакого отношения вообще.))
п.с. хотя стоп, какой ещё хайлоад с двумя хитами в секунду?)

Да фиг с ним со всем. Снег идет :)

флуд во время урагана - святое дело)

нипонял... а что делать с попкорном? :о)

:-D

Вот, человек понимает :)

Ога. В 99% случаев. Уж так исторически сложилось почему-то. Но "оратор" не утверждал что на пыхыпы в принципе невозможно написать что-то стоящее. Но вот как-то все время то тайпо3 получается то еще что пострашнее.
Году так в... 2008 наверное, мигрировали мы как-то с джумлы сайтик. Так как клиент был жадный, база не переделывалась, дописывались модули к одной простенькой явовской CMS (грубо говоря запросы в PreparedStatement, результаты в бины), темплейты переделывали на jsp, никаких дополнительных оптимизаций, никаких изменений в хардваре. Разница была (при выключенном кешировании) очень ощутимая. На той же хардвари, с той же мусклевской бд. Чисел точных не скажу, что-то вроде джумловская версия дохла при 5-и потоках долбящих ее запросами каждую секунду, явовская выдерживала около 200.
Я думаю можно утверждать следующее - дле среднезагруженных систем проще и дешевле найти программистов, которые напишут бэкенд на яве, чем на пыхыпы. И будет этот бэкенд в большинстве случаев лучше задокументирован и намного легче расширяем. Да и границы того же MVC будут скорее всего заметны.
Для простеньких сайтов ищется пыхыпист работающий за еду. Для высокозагруженных систем - все равно на чем писать, все одно затраты будут 7-и значные.
Да, фейсбук лично для меня не показатель. Потому как уродство + никакой информации о том, например, сколько пройдет времени от момента когда ваш френд напишет что-то на свою стену до того момента, когда у вас об этом появится уведомление.
troll on
а вечные дыры в мордокниге только подтверждают, ессесно, что он написан на пыхыпы :)
troll off

1) зато точные числа есть у меня. загляни в ветку "веб". я долбил джумлу на впс(за 8 евро в месяц) и у меня успешно отрабатывались десятки тысяч запросов, при количестве параллельных запросов в единицу времени = 20. и это на апаче с mod_php. Двухядерник с nginx + php-fpm устойчиво обрабатывал сотни тысяч отправленных запросов, при общем кол-ве оправленных параллельных = 200
2) количество и сами sql запросы к бд в обоих реализайциях были одинаковы при долблении идентичных страниц? ставлю бутыль хорошего коньяку (ты вроде бы тоже из Ганновера?), что запросы и их кол-во было разным. что и сыграло основную свою роль.
давай сделаем замеры, если хочешь. железку я настрою. ок?

Да что фейсбук, я лично оптимизировал корпоративные веб-сайты и интерфейсы на PHP до времени ответа в 5-10мс без учета БД и прочих бекэндов.

В основном Java и PHP, дотнета меньше. Питона мало, остального почти нет.

Java как язык на два порядка быстрее пыха. Правда без мозгов элементарно убить перформанс что там, что здесь.

<имхо>
серверная часть 75-ти% не ентерпрайз веб проектов, в которых в прошлом году удалось поучаствовать делали следующие вещи:
-серверная валидация переданных данных
-ковыряемся в кэше / формирование запросов к БД
-обработка результатов пред. шага. и формирование ответа(json или разметка)
и это ВСЁ.
доменная модель: анемичная.
профайлер показывает, что 95% времени уходит на работу с БД. Тут без разницы: жаба или пых.
для ентерпрайза же практически всегда - ASP.NET MVC, WCF, WFF и WPF(для десктопов).
всё зависит от задач: у тебя они одни, а у меня - другие. конечно глупо брать пых и пытаться строить на нём рич доменную модель или тяжёлые мат модели. А вот для "проверь ввод---> cформируй SQL --> отдай результат" подходит не хуже любого другого языка.
</имхо>

Для формирования SQL PHP как раз не идеален - что-нибудь вроде Spring Data делает это на порядки элегантнее и с меньшими затратами времени. Пых лучше там, где можно организовать REST-интерфейс к бэкэнду.

Да-да, именно апач и именно с мод_пхп. Но. Про джумлу с 10.000 запросов в минуту (без кэша, само собой) - пока не увижу, не поверю. Если только половину этого угробища переписать.
Хотя... Может ту джумлу и того, переписали уже :) Я последний раз что-либо на пыхыпы в 2010 видел.

угу

Запросы я не менял. Только часто используемые или с параметрами перегнал в PreparedStatement. Так как клиент платил мало, ничего не улучшали. Если стояло select id from clients а потом для каждого id-а select * from purchases where client_id = ?, то я ничего не переделывал, ибо нефик. Но сильно тупого sql не было, скорее структура таблиц была... пугающей. В результате часто выполняемые запросы делали по 3-4 join-а, там где можно было обойтись foreign key-ем дополнительным.
Про количество... Тут я не могу сказать что ничего не изменилось. Темплейты переделывал фронтенд, я туда заглядывал только подсказать какие свойства у моих бинов им нужны. Может что и изменилось. Но если пыхыпист был настолько туп что по 2 раза на одной странице выполнял запрос, то это в копилку "пыхыпы очень часто бутылочное горлышко".
Так что согласен на половину бутылки. SQL-то не менялся :) Предпочитаю Camus. Или Aberlour из хересовой бочки, да.

Если честно, то просто лень. Разве что без сроков, как делать дома будет нечего, можно будет наваять сервлетик. Без какого-либо кеша, просто отвечающий на гет с параметром хтмл-ем с данными из бд? И на апаче с томкатом через коннектор. Даже читить не буду - коннекшен буду каждый раз новый открывать а не в статику засовывать.
В общем, если не торопишься, можно помериться :)

Ого, нас уже трое! Пора собраться и обсудить :))

Spring Data для более быстрого создания слоя репозиториев базируемых на jpa? для пхп полно такого добра, разве нет?
мне вполне хватает ORM в yii, а сложные запросы или оптимизация всё равно делается руками.

Я бы даже сказал "сообразить"!
Поспорь с Posmotrim на что-нибудь и пусть проставляется :)

Да может они и в пыхыпы были подготовленны, это я уже не помню. Я про PreparedStatement-то упомянул потому что это было единственное похожее на оптимизацию. А, не, пул коннекшенов предоставлял CMS. Но джумла же тоже их менеджит, нет? Или это тайпо3 делал...

Конечно! Oставшуюця половину - тебе. :)

Даже близко ничего похожего нет.

Видел предложение в Вупертале. Народ делал автоматизацию магазина на пхп.
И выбор между пхп и ява выбирается совсем не так, многие тут расписали. Это зависит от лицензии - может контора себе позволить купить лицензию явы или дешевле на пхп. Нужно ли интеграцию под Виндовс или геммороиться с Линуксом. Например наша контора бы использовала какой-нибудь линукс, но лицензия на софт для контроллеров Бекхоф идет только под Виндовс.
Так что на чем и как определяется лицензированем. И если для себя лично какая-то контора может позволить и яву или даже SAP, то при реализации клиентам требуется решение подешевле, иначе конкуренты задушат.

Что за лицензия на джаву? :О Там все свободное.

неужели? и под ЕЕ тоже?

Если имеется ввиду Aplication Server то например:
Glassfish http://glassfish.java.net/de/
JBOSS http://www.jboss.org/overview/
находяться под лицензией Open Source

Ты меня запутал слегка. Пусть выскажутся более продвинутые товарищи.

можно пруф? интересно просто.

давайте обсудим втроём, тольк не на этой неделе. в субботу Hannover Cup im Sambo - режим :)

Удачи!
В какой категории выступаешь?

ветеран до 90 =)

Взвешивание у вас в день боев или за день, как в профбоксе?

класс! Желаю удачи

Удачи!

ОпеннСоурс совсем не означает, что не нужно деньги платить:

А дома можете тренироваться сколько влезет до тех пор, пока "влезет" не станет приносить деньги.

Да пожалуйста. вопрос звучит так: What is the difference between being a Java EE licensee and being Java EE compat...

Здорово. А вы текст по ссылке (и выше процитированный) как понимаете?
Подсказка: для того, чтобы РАСПРОСТРАНЯТЬ яву надо просить у оракла разрешение. Если програмный продукт распространяется (продается) БЕЗ явы - никаких лицензий не надо.

В указанном мной тексте ничего нет прораспространение. Сказано только, что лицензия прошла тест на совместимость и это не значит, что лицензируемые продукты совместимы. Но самой первой строчкой стоит : Лицензия JavaEE означает коммерческую дистрибуцию(то бишь распространение) для JavaEE. И это означает, что если ты устанавливаешь JavaEE в коммерческих целях - должен платить.

Текст вы поняли неправильно. Ну, давайте тогда потихоньку разгребать.
Текст:

Примерный (не дословный) перевод (мой :)) :

Теперь ваши комментарии:

Есть. "A Java EE licensee has signed a commercial distribution license for Java EE."

А вот этого в тексте нет. Лицензия никаких тестов не проходит. Лицензиат имеет доступ к тестам и (скорее всего по условиям лицензионного соглашения) должен стремиться к совместимости своих продуктов.

Неправильный перевод первой строчки. Правильный (надеюсь) - мой.

И вывод неправильный. Распространение (distribution) не то же самое что использование или установка. Вы можете приехать к клиенту и установить ему Java EE. Никаких денег за это вы платить никому не должны. Вы не имеет права распространять Java EE на коммерческой основе без лицензии. Т.е. продавать диски, на которых ваз продукт и Java EE, или давать скачивать со своей страницы Java EE. Вот jre (емнип) можно распространять.
Итого: использование Java EE бесплатно (ну чесслово, поверьте). Для распространения - нужна лицензия.

Вы будете смеяться, но я впервые с вебом столкнулся с такой экзотикой, как Джанго и Рельсы. Почти все шопы - это ПХП. Еще лично знаком с программистами ASP.NET - она очень быстро прикручивается к корпоративному ПО.
Что такое Java в веб?

зачем тебе нужен хайлоад, если твой очередной стартап загнется по финансовым причинам на 10 посетителях в день?

я не участвовал ни в одном стартапе, который бы загнулся. ты меня с кем-то перепутал.

это то, откуда инженеры из ASP.NET идеями вдохновляются. Никогра не задумывался почему браузерные скрипты называются "JavaScrip", а не "ASP " (про "VB " гусары, молчать! это маркетинговый выкидыш)? Но это побочно-отдельный продукт. Еще помоему до эпохи ПХП Ява со своими сервлетами использовалась для построения корпоративного Вэб-окружения. Высокая скорость обработки и платформонезависимость. Плюс работа внутри баз (оракл и дб2). Тогда еще ява н епринадлежала Ораклу (фирме).