Текущий архив: 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