Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2008.05.11;
Скачать: CL | DM;

Вниз

Надежность JAVA-приложения   Найти похожие ветки 

 
Alex Konshin ©   (2008-03-24 11:36) [40]


> Игорь Шевченко ©   (24.03.08 11:10) [39]
> Alex Konshin ©   (24.03.08 11:00) [38] Когда все упирается
> в квалификацию программиста, тем более, задающего вопрос
> на форуме - "а что бы мне такое выбрать для написания сервера
> 24/7", то ответ вообще очевиден.

Для серверов ответ, на мой взгляд, действительно очевиден. Я правда не совсем уверен, что мы очевидим одно и то же.

А в конкретном случае нужно смотреть более детально на саму задачу. Очень маловероятно, что C/C++ будет предпочтителен, но всё же случаи разные бывают.

Кстати, опять-таки по работе в фирме... У нас практически все приложения многоплатформенные, но это не значит, что везде используется Java. Есть много продуктов, написанных C/C++. Так что я непонаслышке знаком с вопросом выбора инструмента. Я специализируюсь на Java, хотя и умею C/C++ (как и многое другое). Но я рекомендую Java вовсе не поэтому, а потому, что хорошо знаком с достоинствами и недостатками обоих подходов.

В качестве ещё одного довода приведу ещё один: отладку и тестирование. На Java это будет намного проще и дешевле хотя бы потому, что зависимость от платформы меньше. Просто представьте себе объёмы тестирования сразу на многих платформах. Не забывайте ещё о 32-bit и 64-bit (на C/C++ это будет ещё одна тема для развлечений). В случае Java можно уменьшить количество платформ без существенного ухудшения качества тестирования. Обычно это сводится к паре-тройке платформ типа Windows 2003/XP (32/64 bit) и какой-нибудь юних типа Linux x86 64-bit, AIX, HPUX или Sun Solaris. Естественно, перед релизом нужно будет всё-равно тестировать все платформы, но хоть не нужно это делать с каждым билдом.


 
Alex Konshin ©   (2008-03-24 12:08) [41]

Ещё один довод: компиляция и сборка под все поддерживаемые платформы. Вы представьте, какую ферму серверов вам придётся иметь в хозяйстве только для того, чтобы строить приложение под все платформы. Может вы надеетесь на кросскомпиляцию в GCC? Я бы не стал на неё забиваться в таком серьёзном проекте, как вы его описываете. Лишние проблемы. Опять-таки я об этом знаю по реальному опыту работы в фирме. Один из проектов моей группы как раз на C/C++ и для него сборка довольно нетривиальна из-за необходимости компилиции на нескольких компьютерах под разными платформами. Конечно, у нас это автоматизировано, но повозиться пришлось немало. Кстати, а инсталятор для этого продукта всё равно на Java :).


 
Игорь Шевченко ©   (2008-03-24 12:31) [42]

Alex Konshin ©   (24.03.08 12:08) [41]

Я на Java так активно, как ты не работаю, более того, не работаю совсем, потому привел пример того, чего знаю. Исходя из того, что в Oracle тоже не очень дураки работают :)


 
31512   (2008-03-24 12:51) [43]


> Alex Konshin ©


> Игорь Шевченко ©

Господа. Внимательно наблюдая за дискуссией, возникшей тут, у меня назрел вопрос: исходя из требования надёжности системы класса 24/7 (в том числе, учитывая что убытки в результате сбоя могут быть ощутимыми),   вы предпочли бы нативное решение, указав заказчику "используй эту систему" (разумеется предварительно убедившись в надёжности самой системы) или же применили бы кроссплатформенное (тут ваш выбор) решение? И почему?


 
Alex Konshin ©   (2008-03-24 12:55) [44]

Зависит от требований заказчика. Под заказчика типа Boeing можно сделать всё, что пожелают.


 
Alex Konshin ©   (2008-03-24 12:57) [45]


> Игорь Шевченко ©   (24.03.08 12:31) [42]
> Alex Konshin ©   (24.03.08 12:08) [41] Я на Java так активно,
>  как ты не работаю, более того, не работаю совсем, потому
> привел пример того, чего знаю. Исходя из того, что в Oracle
> тоже не очень дураки работают :)

Откуда такое убеждение? Дураки работают везде!
И у нас тоже работают.


 
@!!ex ©   (2008-03-24 12:57) [46]

> [43] 31512   (24.03.08 12:51)

Я вообще не в теме, но насколько мне известное, софт под платформу(дело не только в ОС, но и в самом оборудовании) покупают, а не наоборот.


 
31512   (2008-03-24 13:00) [47]


> Alex Konshin ©   (24.03.08 12:55) [44]

Иногда заказчик говорит: "Что вы можете нам предложить?". Т.е. я хотел бы узнать ответ в случае, если бы выбор прогаммно-аппаратной части зависел от вас.


 
31512   (2008-03-24 13:08) [48]


> @!!ex ©   (24.03.08 12:57) [46]

Покупают - да. А вот разрабатывают? Т.е. я хочу сказать, что в большинстве случаев заказчик предподчёт съэкономить.
Вариант первый: мы хотим такой-то софт под платформу Грюндик.
Вариант второй: мы хотим такой-то софт но с платформой не определились может вы подскажете?


 
Игорь Шевченко ©   (2008-03-24 13:10) [49]


> Откуда такое убеждение?


"По плодам их узнаете их" (Матф., VII, 20)


 
Alex Konshin ©   (2008-03-24 13:12) [50]

Вариант третий и правильный: маркетолог изучает рынок и даёт список платформ и количество потенциальных клиентов. Продакт менеджер принимает решение, какие платформы нужно поддерживать.


 
Alex Konshin ©   (2008-03-24 13:15) [51]

> Игорь Шевченко ©   (24.03.08 13:10) [49]
> > Откуда такое убеждение?"По плодам их узнаете их" (Матф.
> , VII, 20)

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


 
Игорь Шевченко ©   (2008-03-24 13:17) [52]

Alex Konshin ©   (24.03.08 13:15) [51]

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


 
Alex Konshin ©   (2008-03-24 13:21) [53]

> Игорь Шевченко ©   (24.03.08 13:17) [52]
> Alex Konshin ©   (24.03.08 13:15) [51] Не знаю, дизайн как
> дизайн, бывает лучше (у MS например), бывает хуже. А продукты
> работают и пользуются массовым спросом, наверное это дает
> основание для выводов.

Миллион леммингов не может ошибаться?
Это маркетинг. Это не значит, что нет более правильных продуктов. Качество продукта и спрос не связаны напрямую. И помимо качества спрос учитывает множество других факторов, например, поддержку и брендовость продукта.


 
31512   (2008-03-24 13:22) [54]


> Alex Konshin ©   (24.03.08 13:12) [50]

Если так, то я начинаю понимать откуда в IT появляются продукты и платформы качества "фу!".


 
iZEN   (2008-03-24 14:45) [55]


> Игорь Шевченко ©   (24.03.08 10:34) [35]
>
> Alex Konshin ©   (24.03.08 10:32) [34]
>
> Отсюда вывод - не стоит применять Java для таких приложений
> (24/7) :)
>

Отсюда вывод: писать на C++ тем более нельзя. :)


 
Jeer ©   (2008-03-24 14:53) [56]

Если кто видел SPSS (софт типа "Statistika") ранних версий и последнюю версию 16 сделанную на Java, тот определенно скажет, имея в виду быстродействие: "Все, что угодно, но только не на Java"
Я - видел. Поэтому пользуюсь v.12

Мы, конечно, можем подумать, что в SPSS работают неумехи, но только ли дело в этом ?


 
iZEN   (2008-03-24 14:56) [57]


> Jeer ©   (24.03.08 14:53) [56]
<..>
> Мы, конечно, можем подумать, что в SPSS работают неумехи,
>  но только ли дело в этом ?

А в чём?

Java предполагает определённую (уж точно не низкую) квалификацию проектировщика и кодера. Математеки же могут написать программу на Фортране на любом языке программирования. :)


 
iZEN   (2008-03-24 14:59) [58]


> Reindeer Moss Eater ©   (24.03.08 10:42) [36]
>
> Важно: я точно сказать не могу, не я решаю, но по опыту
> могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч
> $.
>
> Ну за такие-то бабки можно не лениться и отдельные релизы
> под все платформы наваять.


К сожалению цена надёжности не измеряется в деньгах. ;)


 
Reindeer Moss Eater ©   (2008-03-24 14:59) [59]

а в чем?
в попугаях?


 
Jeer ©   (2008-03-24 15:01) [60]


> iZEN   (24.03.08 14:56) [57]


> А в чём?


А не знаю, причем расчетная часть еще ничего, а вот интерфейсная просто выводит из себя своей медлительностью.


 
iZEN   (2008-03-24 15:12) [61]


> Jeer ©   (24.03.08 15:01) [60]
>
> > iZEN   (24.03.08 14:56) [57]
>
> > А в чём?
> А не знаю, причем расчетная часть еще ничего, а вот интерфейсная
> просто выводит из себя своей медлительностью.


Вы давно JVM и JRE обновляли? Поставьте лучше эту: http://download.java.net/jdk6/
(там для своей платформы выберете нужную JRE или JDK).

Кстати, на Swing-интерфейсе сделано куча продуктов:
http://java.sun.com/products/jfc/tsc/sightings/index.html
и тут немножко:
http://www.netbeans.org/features/platform/screenshots.html (это на NetBeans Rich Client Platform).
Ну раз делают, значит это кому-нибудь нужно.

Прошу прощения за оффтопик в теме.


 
iZEN   (2008-03-24 15:21) [62]

По теме

Рекомендую почитать статьи: http://www-128.ibm.com/developerworks/ru/java/


 
Mystic ©   (2008-03-24 17:28) [63]

> Java предполагает определённую (уж точно не низкую) квалификацию
> проектировщика и кодера. Математеки же могут написать программу
> на Фортране на любом языке программирования. :)


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

Во-вторых, программируя на C/C++ я знаю, что мне придется следить за всеми ресурсами самому. И это не сложно. Я не виду трудности ни в написании крассплатформенного кода, ни в реализации многопоточности на C++, ни в том, чтобы избежать memory leaks, а также в других пунктах, которые перечислены уважаемым Alex Konshin. Как говорится, все в моих руках, все под моим контролем, ошибки проявляются быстро, если есть ошибка, то она в моем коде. Что касаемо Java, часть этих проблем Java берет на себя. Но при написании приложений 24/7 надо очень точно представлять, что происходит на всех уровнях системы. Получается, что я должен четко представлять, как именно JVM выполняет то, что написано мною (знать особенности реализации GC, и многое другое). Получается как бы дополнительный уровень, и ошибки могут быть связаны не только с ошибками в программе, но и в том, что я неправильно понял какую-то строку документации. И такие ошибки могут проявляться далеко не сразу...

В-третьих, для вычислений я бы рекомендовал Фортран:
 1) его просто изучить;
 2) сообщество программистов Фортран ограничено, но очень квалифицировано (если вы видите библиотеку на Фортран, то очень вероятно, что это код высочайшего качества);
 3) встроенный тип матриц позволяет компилятору действительно оптимизировать код;
 4) огромный выбор библиотек, многие из которых вылизывались десятилетиями.


 
Игорь Шевченко ©   (2008-03-24 17:38) [64]

У Java есть одна особенность, уж не знаю, плюс это или минус - разработчики на Java дороже других стоят.


 
31512   (2008-03-24 20:40) [65]


> Игорь Шевченко ©   (24.03.08 17:38) [64]

Ээээээ. А почему? Рискуя сделать неверное предположение: не потому ли, что они знают (или должны знать) многообразие бубнов под разные системы?
И вопрос: откуда такая уверенность? Собственный опыт? Статистические наблюдения? И могу ли я услышать ответ на ской пост [43]? Очень интересно.


 
Anatoly Podgoretsky ©   (2008-03-24 21:08) [66]


> Reindeer Moss Eater ©   (24.03.08 14:59) [59]
> а в чем?

В дураках.


 
Mystic ©   (2008-03-24 21:10) [67]

> И могу ли я услышать ответ на ской пост [43]? Очень интересно.

(1) Такая ситуация возникает достаточно редко. Обычно заказчик выбирает среди нескольких предложений, и необходимо под него подстраиваться. Если у заказчика активно используется Windows, то зачем ему головная боль с *nix-сервером?

(2) Все зависит от того, насколько будет трудоемким кроссплатформенное решение. Если это игровой сервер для какой-нить online-игры, то я не вижу никаких принципиальных проблем, связанных с реализацией кроссплатформенного решения. А вот если говорить о каком-нить решении, которое не зависит от выбора SQL-сервера, то тут в большинстве случаев против. Или это real-time система, как тут не быть завязанным на определенную real-time OS (например, QNX)?


 
Anatoly Podgoretsky ©   (2008-03-24 21:28) [68]

> Alex Konshin  (24.03.2008 13:15:51)  [51]

Чем крупнее контора, тем больше дураков в абсолютном измерение.


 
Юрий ©   (2008-03-24 21:34) [69]

> [68] Anatoly Podgoretsky ©   (24.03.08 21:28)

Как тогда феномен Google объяснить? :)


 
Anatoly Podgoretsky ©   (2008-03-24 21:40) [70]

А что с Google не так?
Ты там работаешь, владеешь инсайдерской информацией по дуракам?


 
Юрий ©   (2008-03-24 21:41) [71]

> [70] Anatoly Podgoretsky ©   (24.03.08 21:40)

Конечными продуктами имею возможность пользоваться, а Вы о чём?


 
Ramakrishna   (2008-03-24 21:42) [72]

Юрий ©   (24.03.08 21:41) [71]

http://lordmaze.livejournal.com/101501.html


 
Юрий ©   (2008-03-24 22:01) [73]

> [72] Ramakrishna   (24.03.08 21:42)

Интересно, что отсюда нужно понять? Может они в Google полы мыли.


 
31512   (2008-03-24 23:06) [74]


> Юрий ©   (24.03.08 22:01) [73]

См.

> Mystic ©   (24.03.08 17:28) [63]


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

Вот вопрос который меня давно интерисует: а что такое квалификация разработчика и как её измерить? Как можно определить что мистер А квалифицированный разработчик, а мистер Б неквалифицированный?


 
Reindeer Moss Eater ©   (2008-03-24 23:09) [75]

Понеслась душа в рай.....


 
31512   (2008-03-24 23:11) [76]


> Mystic ©   (24.03.08 17:28) [63]

Тогда может Visual Basic? Как думаешь, система разработанная будет на нём надёжнее, чем на Java?


 
Alex Konshin ©   (2008-03-25 04:47) [77]


> Юрий ©   (24.03.08 21:34) [69]
>
> > [68] Anatoly Podgoretsky ©   (24.03.08 21:28)
>
> Как тогда феномен Google объяснить? :)

Очень просто: они не жадничают, когда набирают программистов.
Но у них высокие критерии при наборе программистов.
Собственно, это одна из причин их успеха.

При таком подходе можно получить команду с низким количеством дураков.
Но в подавлющем большинстве софтверных фирм (особенно если они публичные - акционированы и их акции на бирже) подход к набору программистов и к определению уровня их зарплаты совсем иной. Они экономят на зарплате. Стремятся набрать людей по-больше, но по-дешевле. Отсюда, кстати и тенденция к аутсорсингу в Индию - там программисты дешевые (а вот качество - слабое), примерно в 6 раз дешевле программиста в Америке.

И я уже понимаю почему это так. Суть проблемы в том, что топ менеджеры фирмы не заинтересованы напрямую в качестве продуктов. Они заинтересованы в росте цены акций фирмы (причём лично и кровно заинтересованы). А на неё гораздо большее влияют такие факторы, как размер расходов (и как одна из существенных частей - затраты на рабочую силу), размер доходов (а тут важны контракты, где гораздо важнее личные связи, чем какой-то там продукт). Вот и получается, что по-большому счёту качество продукта - дело десятое. Достаточно просто регулярно выпускать новые версии (чтобы качать деньги из существующих клиентов), обеспечить поддержку (с той же целью), ну и всеми правдами и неправдами добиваться новых контрактов.

Я, конечно, упрощаю, но корень зла - именно тут.


 
Alex Konshin ©   (2008-03-25 05:07) [78]

> Mystic ©   (24.03.08 17:28) [63]
> Во-вторых, программируя на C/C++ я знаю, что мне придется
> следить за всеми ресурсами самому. И это не сложно. Я не
> виду трудности ни в написании крассплатформенного кода,
> ни в реализации многопоточности на C++, ни в том, чтобы
> избежать memory leaks, а также в других пунктах, которые
> перечислены уважаемым Alex Konshin. Как говорится, все в
> моих руках, все под моим контролем, ошибки проявляются быстро,
>  если есть ошибка, то она в моем коде.

Если проект большой и дорогой, то и разработчиков обычно бывает больше одного. Добиться такой же аккуратности от других разработчиков будет нелегко.
И как ты себе представляешь разработку и поддержку к примеру десятка платформ? Я, например, это очень хорошо представляю, я просто это вижу каждый день на работе. Ведь даже Windows несколько платформ, причём с точки зрения C/C++ 64-bit платформы очень существенно отличны от 32-bit платформ.

Вот и получается, что перед тем как начать разработку собственно приложения, придётся сначала разработать библиотеку под *все* поддерживаемые платформы, наладить сборку и тестирование на всех платформах. Это всё - время, а время - деньги. В случае Java начальные издержки значительно ниже, издержки на тестирование тоже, а сборка так вообще проще в разы (обычно достаточно собирать на одной платформе).

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


 
alxt   (2008-03-25 07:52) [79]

Забавный тред.
Уточню.
Были поставлены эксперементы по скорости- при чтении/записи БД (где проигрышь java велик хотя бы из-за большей возни с памятью и теми самыми строками, которые в ней динамические) проигрышь был 5-10%. Промасштабировали в 10 раз - то же самое. В общем- не критично.

Про утечки памяти- пока я занят другой работой, и больше, чем на ночь не запускал тесты. А за ночь потребление ОЗУ выросло на 5% (ровно как на Сишном коде). При том, что постоянно идёт выделение и выбрасывание памяти. jvm 1.6 естественно- известные прошлые грешки сборщика мусора мне не нужны.

Вро машинки у заказчиков. Уважаемый "Автор темы" забыл, что под этот софт будут покупаться отдельные машинки (иначе вся затея теряет смысл), а там уж можно и сказать, мол не надо, например, hp/ux. Да и 32бита вряд ли у кого встретится. А sun и ibm на своих ОС обеспечивают поддержку jvm (у IBM"а, кстати, есть своя версия, которая жестко привязана к их железу). Про Windows не серверах, слава богу, никто не слышал (моя утилитка, напрочь не переваривающий виндовые сервера, не вызвал ни у кого возражений).

А проблемы С++ возникнут не сейчас, в тестовых приложениях, а при работе с сетью и многопоточностью (и количество траха тут, насколько я понимаю, несравнимо).

PS: насколько я понял, только Alex Konshin сравнивает java и C++ на собственном опыте, а не "Абрам напел".

PPS: что "все программисты за java" это я не заметил. Собственно, спор пока ведется вдвоём :)


 
Игорь Шевченко ©   (2008-03-25 09:39) [80]

31512   (24.03.08 20:40) [65]


> Ээээээ. А почему?


Эээээ. А по объявлениям.


>  И могу ли я услышать ответ на ской пост [43]?


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



Страницы: 1 2 3 вся ветка

Текущий архив: 2008.05.11;
Скачать: CL | DM;

Наверх




Память: 0.66 MB
Время: 0.02 c
2-1208165182
pathfinder
2008-04-14 13:26
2008.05.11
Уничтожение объекта.


15-1206172958
@!!ex
2008-03-22 11:02
2008.05.11
Двойная буфферизация(выдернуто из "Вакансия Delphi программист")


3-1196934351
MZ
2007-12-06 12:45
2008.05.11
Узнать права роли на объект


8-1179149657
Elliner
2007-05-14 17:34
2008.05.11
Взаимодействие с программой через веб интерфейс


2-1207725582
Footballer
2008-04-09 11:19
2008.05.11
UDP