Вы ещё раз очень наглядно продемонстрировали уровень ваших задач :) Не понимаю, зачем из себя изображать птицу высокого полёта?

Ну например PostgreSQL вместо Oracle.

Вы в курсе, как у PostgreSQL обстоят дела с кластеризацией? с горизонтальным партиционированием / шардингом? В курсе, когда там появилась «родная» репликация, и в каком она сейчас состоянии?

Tomcat/Jetty вместо WebSphere.

Ну это вообще!! предлагать заменить Java EE 6 контейнер на servlet engine? Хотя, дайте догадаюсь, «EJB3 ненужны», а транзакции, security и remote access - «маркетоидные баззворды», как сейчас принято говорить у молодёжи.

Делал проект на ruby с RoR... «будь проклят тот день когда я сел за баранку этого пылесоса»... Видеть после этого руби не хочу. Если для web, то php лучше.

Более того у руби страшные проблемы с совместимостью как с прямой так и с обратной. Программа написанная под одну версию руби с большой вероятностью не заработает ни на предыдущей версии(ну это ещё ладно) ни на последующих.

Да почти что угодно.

«Я не намерен строить для того, чтобы иметь клиентов. Я намерен иметь клиентов для того, чтобы строить.» (с) Говард Рорк из книги Айн Рэнд — «Источник»

предлагать заменить Java EE 6 контейнер на servlet engine?

У меня и без servlet container REST-сервисы работают. На grizzly. ЧЯДНТ?

, а транзакции, security и remote access

Все это есть в спринге. Да и не в спринге.

«EJB3 ненужны»

Так точно.

Ну это вообще!! предлагать заменить Java EE 6 контейнер на servlet engine?

А что тут такого? Кто мешает собирать EE-стек по кускам? Из-за одного ejb3 тянуть всю вебсферу — верх энтерпрайзного идиотизма.

Вы ещё раз очень наглядно продемонстрировали уровень ваших задач :)

Иди это покричи в гугле или яндексе. Они же, дурачки, MySQL используют. Так что не позорься.

Вы в курсе, как у PostgreSQL обстоят дела с кластеризацией?

Кластеризация РСУБД это такой кактус, что никакой не надо.

с горизонтальным партиционированием / шардингом?

Это вообще лучше делать application level. Прозрачно кактус получится. Угу, ксли прозрачно и на уровне БД, тут уж точно без «спеца» не обойтись.

В этом собственно проблема было-контор. Вначале себе на создают проблем излишней сложностью, а потом ноют, что опенсорс не торт и спецов нету.

В курсе, когда там появилась «родная» репликация, и в каком она сейчас состоянии?

В нормальном. Проект входит в топ 25 России по посещаемости, если че.

> Иди это покричи в гугле или яндексе. Они же, дурачки, MySQL используют. Так что не позорься.

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

UPD

http://habrahabr.ru/blogs/google/123999/

Да, и перешли на хранилище с еще более низкоуровневым API с точки зрения разработчика. Все правильно. Не на Oracle же они перешли. Таким образом просматривается тенденция: чем более дубовые разработчики, тем больше им нужно оперденей вроде оракла.

К слову, у нас Postgres, а не MySQL, тоже не от хорошей жизни. Legacy кривой код. Если бы все было грамотнее написано то, думаю, MySQL было бы за глаза достаточно.

>Есть ли что-то удобнее Ruby?

Да почти что угодно. Это ж наследник Perl'а. Write-only, хотя и не в такой запущенной форме. Даже PHP-код через год читается легче, чем Ruby.

Python и сейчас вот учу JS. Могу сказать одно - последние два - нихрена не интуитивны в сравнении с Ruby.

Вот Python, как раз, весьма неплох для написания _читабельного_ кода.

<troll mode> parser 3</troll mode>

а чем рутноп не интуитивен?

а чем рутноп не интуитивен?

Ну например оишбка при

def f(a):
    def g():
        a = a
    return g

f(1)()

Да почти что угодно. Это ж наследник Perl'а. Write-only, хотя и не в такой запущенной форме. Даже PHP-код через год читается легче, чем Ruby.

Так может дело в авторе просто, рубин, к слову, ниразу не наследник перла. А уж в сравнении с пхп, так его (пхп) даже после написания читать не хочется.

откуда в g возьмётся а?

> Да почти что угодно. Это ж наследник Perl'а. Write-only, хотя и не в такой запущенной форме. Даже PHP-код через год читается легче, чем Ruby.

Опять самовнушением занимаешься.

Вики(о перле):Повлиял на: Ruby, Python, PHP

>рубин, к слову, ниразу не наследник перла

Ну-ну: «Название навеяно языком Perl, многие особенности синтаксиса и семантики из которого заимствованы в Ruby: англ. pearl — «жемчужина», ruby — «рубин»»

А уж в сравнении с пхп, так его (пхп) даже после написания читать не хочется.

Угу. Зато PHP код _читается_ (даже когда не хочется :-p). А в Ruby его нужно _изучать_. Как и в Perl.

Как это откуда, из лексического замыкания, это как раз очевидно, смущает ошибка компилятора, нифига не интуитивная, при этом если заменить a=a на print a то все отлично работает, такая вот фича с read-only переменными из внешнего контекста меня как-то сильно напрягла, ну и фикс в виде g(a=a) тоже не ахти как интуитивно, больше похоже на хак.

>>Есть ли что-то удобнее Ruby?

Tcl

Подтверждаю

Ну-ну: «Название навеяно языком Perl, многие особенности синтаксиса и семантики из которого заимствованы в Ruby: англ. pearl — «жемчужина», ruby — «рубин»»

Уф, ну попиши на перле, руби, питоне и на си, и ты увидишь что многие особенности синтаксиса и семантики у них как у братьев близнецов, а потом посмотри на смолток и сравни с рубином.

Угу. Зато PHP код _читается_ (даже когда не хочется :-p). А в Ruby его нужно _изучать_. Как и в Perl.

Ты его читаешь, потому что пишешь на нем много, для рубиста код на руби так же будет читабелен, а от пхп будет плеваться как от write-only, к слову нормальный перловый код - тоже нормально читается, даже через год, если конечно пишешь на перле.

> Угу. Зато PHP код _читается_ (даже когда не хочется :-p). А в Ruby его нужно _изучать_. Как и в Perl.

На Ruby ты пишешь, _что_ делать, а на PHP ты пишешь, _как_ делать. Конечно PHP «читается» — примерно как ассемблерный листинг, «всё просто и понятно».

>Уф, ну попиши на перле, руби, питоне и на си

Писал. Как и ещё на десятке языков :)

и ты увидишь что многие особенности синтаксиса и семантики у них как у братьев близнецов

Отнюдь. По идеологии синтаксиса Perl тесно группируется с Ruby (или Tcl, например). Противоположности им (в этом контексте) — языки, типа Python, Basic, Pascal, Java, PHP. Си и Си++ занимают промежуточное положение.

Ты его читаешь, потому что пишешь на нем много, для рубиста код на руби так же будет читабелен

Увы, не в этом дело. Вся тонкость в насыщенности токенов языка и побочных эффектах. Многое из того, что в других языках требует явной операции, в Perl или Ruby — «подразумевается». В голове приходится держать больше сущностей. Пока пишешь код — всё прекрасно. Когда откладываешь его и возвращаешься год спустя — нужно время, чтобы его осознать. Это и назвается «write-only» синтаксис.

к слову нормальный перловый код - тоже нормально читается

Да и на Ruby _можно_ писать так, что он будет потом читаться легко. Но синтаксис языка провоцирует писать кратко и неявно. Потому что так писать много проще. Но вот читать потом, с нуля, такое много сложнее. А на том же Питоне или Java ты при всём желании в таком стиле писать не сможешь :) Нет и соблазна…

>На Ruby ты пишешь, _что_ делать, а на PHP ты пишешь, _как_ делать

В 90% случаев и там, и там пишется _что_ делать. И даже на ассемблере (при грамотном проектировании) ты тоже в 50% пишешь _что делать_ :) Так что это из другой категории.

Отнюдь. По идеологии синтаксиса Perl тесно группируется с Ruby (или Tcl, например). Противоположности им (в этом контексте) — языки, типа Python, Basic, Pascal, Java, PHP. Си и Си++ занимают промежуточное положение.

В чем например?

Увы, не в этом дело. Вся тонкость в насыщенности токенов языка и побочных эффектах. Многое из того, что в других языках требует явной операции, в Perl или Ruby — «подразумевается».

Например? Частично тут я могу согласиться насчет перла, есть у него такое свойство, но в упор не вижу где тут питон выигрывает у руби.

А на том же Питоне или Java ты при всём желании в таком стиле писать не сможешь :) Нет и соблазна…

Да ладно, можно и на питоне, сам проверял:)

Ну-ну. Когда на Ruby программмист использует, например, простые и понятные методы select, map, reduce, join и т.п., пыхер будет героически преодолевать все грабли синтаксиса, а также бороться с поистине эпичной стандартной библиотекой якобы обьектно-ориентированного языка.

Открываем пример из манула:

<?php
function odd($var)
{
    // returns whether the input integer is odd
    return($var & 1);
}

function even($var)
{
    // returns whether the input integer is even
    return(!($var & 1));
}

$array1 = array("a"=>1, "b"=>2, "c"=>3, "d"=>4, "e"=>5);
$array2 = array(6, 7, 8, 9, 10, 11, 12);

echo "Odd :\n";
print_r(array_filter($array1, "odd"));
echo "Even:\n";
print_r(array_filter($array2, "even"));
?>

лол с маленькой л.

При попытке написать что-нибудь в таком стиле, запутавшись после 4-й вложенной функции, плюём, выкидываем весь этот мусор и пишем, тупо, обычной импертивщиной при помощи foreach и while. Получаем очень читабельный код, потому что читать приходится много. Еще бы, там где в руби одна строчка, в PHP, порою, бывает и целая страница.

> Увы, не в этом дело. Вся тонкость в насыщенности токенов языка и побочных эффектах. Многое из того, что в других языках требует явной операции, в Perl или Ruby — «подразумевается».

Блесни уж. А то со времен треда про автоматически преведения int во float в PHP, ты так и не смог придумать ничего никакого компромата.

> У меня и без servlet container REST-сервисы работают. На grizzly. ЧЯДНТ?

Рассуждаете о незнакомых вещах (WebSphere, Java EE 6), на практике будучи просто клепателем веб-сервисов.

«EJB3 ненужны»

Так точно.

Вполне ожидаемый ответ. Но почему из того, что EJB не нужны (не знакомы) лично вам, вы выводите ненужность продуктов типа WebSphere?

> А что тут такого? Кто мешает собирать EE-стек по кускам?

Попробуйте прикрутите CDI к Jetty, потом поговорим.

Из-за одного ejb3 тянуть всю вебсферу — верх энтерпрайзного идиотизма.

Где я говорил про «одно EJB3»?

Вас послушать, так EJB3 не нужны, кластеризация не нужна, шардинг ненужен... боюсь даже предположить, что это у вас за такой «проект из топ 25». Наверняка какая-нибудь социальная сеточка. Не хотите поподробнее рассказать, а?

Попробуйте прикрутите CDI к Jetty, потом поговорим.

Сам догадаешься где у тебя ошибка?

Хинты: Spring 3, Guice.

Вас послушать, так EJB3 не нужны, кластеризация не нужна, шардинг ненужен... боюсь даже предположить, что это у вас за такой «проект из топ 25».

Еще раз. Чем грамотнее написан проект, тем меньше нужно тяжелой артиллерии.

Пример: если разрабы совсем дауны, то во всю используется 2PC. Если разрабы чуть умнее, то у них idempotency + undolog/backuplog.

Простота она с кровью дается. А у ленивых на ум обычно ораклы с вебсферами, проходили уже.

Попробуйте прикрутите CDI к Jetty, потом поговорим.

ЛОЛ, ты опарофинился по самое небалуйся.

> Сам догадаешься где у тебя ошибка?

Я, в отличие от вас, таки прикручивал CDI к Jetty и Tomcat.

Хинты: Spring 3, Guice.

И что? Чем они лучше стандартного CDI?

> ЛОЛ, ты опарофинился по самое небалуйся.

По теме есть что сказать? Я повторяю, лично я прикручивал CDI к Tomcat.

> Еще раз. Чем грамотнее написан проект, тем меньше нужно тяжелой артиллерии. Простота она с кровью дается.

Обычно такие поборники «простоты» заканчивают тем, что изобретают медленную, неспецифицированную, напичканную багами, костыльную имплементацию половины Java EE.

Я повторяю, лично я прикручивал CDI к Tomcat.

Я и говорю, что прописать weld в зависимости проекта — невеликое достижение. Гордится тут нечем.

Spring 3, Guice.

И что? Чем они лучше стандартного CDI?

Тем что появились намного раньше и являются стандартом де-факто?

изобретают медленную, неспецифицированную, напичканную багами, костыльную имплементацию половины Java EE.

Имплементации еешных жеэсэрок уже написаны. Мы просто берем нужные. Вот и всё. А интегрировать их намного проще самому, без ковыряний в жопе у слона.

> Я и говорю, что прописать weld в зависимости проекта — невеликое достижение. Гордится тут нечем.

Вы только что сознались в том, что сами этого не проделывали ни разу. Потому что одним «прописыванием в зависимости» там не обойдёшься. Ну, и кто тут «опарофинился», лол?

> Тем что появились намного раньше и являются стандартом де-факто?

Язык Си появился раньше Java и является стандартом де-факто. и что?

Вы только что сознались в том, что сами этого не проделывали ни разу.

Я этого и не скрывал. Зачем мне брать молодой стандарт, вместо проверенного временем спринга. Тем более последний, помимо DI, предоставляет еще кучу плюшек и интегрируется с чем угодно без головной боли?

Язык Си появился раньше Java и является стандартом де-факто. и что?

Кривая аналогия. Си тут скорее рожденный в муках JSR-299, чем приятные и современные спринг и джуйс.

бычно такие поборники «простоты» заканчивают тем, что изобретают медленную, неспецифицированную, напичканную багами, костыльную имплементацию половины Java EE.

Ты путаешь нубасов с «просвещенными». Нуб лепит кривые велосипеды по не знанию. «Просвещенный» же способен выйти за рамки установленные дядей на качественно новый уровень.

Имплементации еешных жеэсэрок уже написаны. Мы просто берем нужные. Вот и всё.

Более того можно выбирать разные имплементации. Например для JAX-RS можно Jersey взять, а можно CXF.

Идем дальше. Можно брать не только JEE компоненты а вообще любые.

И наконец, можно писать свои собственные компоненты и НЕ СЛОЖНО их интегрить. Особенно легко писать интеграции для Guice, поэтому он мой любимчик.

А готовые сборки вроде JBoss это что-то вроде Windows Super Extreme Edition Plus :)