Re[3]: Апплет - за и против - Java

Здравствуйте, vladserge, Вы писали:

B>>Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.

V>Мы такие разные....

V>По мне так все определяется инструментом. Рефакторинг .
V>Куда как проще сопровождать, отслеживать и обновлять когда все сделанно в одной идеологиии на одной языковой платформе.

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

Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?

Здравствуйте, Blazkowicz, Вы писали:

B>Как часто приходится на вэб страничке динамически отображать контент клиентского DXF?

Возможности аплета покрывают всю функциональность доступную DHTML.
Тут я привел пример где на DHTML(в отличии от JAVA) просто вообще никогда решения небудет.

V>>Где взять такой редактор кода и столько готового кода на ActionScript(Flash) какой есть у JAVA.
B>IDE — не аргумент. Не много java программистов которые способны в короткие сроки создать симпатичную визуализацию.

V>>Небывает "песочниц" для ActiveX.
B>И?

незнаю как кто, а я ActiveX из интернета (кроме от MS) никогда не ставлю.

B>>> но при этом не требуют загрузки JRE.
V>>для Flash поддержки нужен тоже свой runtime.
B>Flash runtime уже имеется у подавляющего большинства пользователей.

те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash.
ну так ничто не мешает скачать поддержку JAVA. это так же просто

(Я правильно понял тему. Мы говорим о +/- решении на Applet вообще, а не конкретно по тому с чего начался топик.)

Здравствуйте, vladserge, Вы писали:

V>те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash.

как-то в моем IE она сама собой появилась, а вот в mozilla наоборот после какого-то апдейта слетела и больше не поднимается
так что я с Flash уже примерно как с месяц не особо дружу

V>ну так ничто не мешает скачать поддержку JAVA. это так же просто

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

впрочем, в контексте вопроса автора и то и это одинаково — раз клиенты суть члены организации, то могут поставить то, что им скажут "сверху" (или, админы могут им поставить)

Здравствуйте, Blazkowicz, Вы писали:

B>Сергей, ты всегда судишь с позиции себя — любимого разработчика. И никогда с позиции эффективности денежных ресурсов. И при это при том что мы уже давно живем в капитализме.

Я в двух позициях одновременно. Стандартная ситуация прибегает заказчик — мне тут побыстрому, пару кнопочек, пару полей ...
В итоге выростает в нечто совсем непохожее на то, чего он хотел когда пришел. Поэтому пердпочитаю "приподнять" его на мой уровнь, а если не получается тогда да, он не мой клиент.

B>Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?

Тут спору нет

1с рулит

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, vladserge, Вы писали:

B>>>Но если предполагается XP/Agile программинг, или, например формы будут менятся так же часто как отечественные законы, то тут ты на 100% прав. Регулярный апдейт апплета проигрывает простоте модификации HTML based решений.

V>>Мы такие разные....

V>>По мне так все определяется инструментом. Рефакторинг .
V>>Куда как проще сопровождать, отслеживать и обновлять когда все сделанно в одной идеологиии на одной языковой платформе.

B>Сергей, ты всегда судишь с позиции себя — любимого разработчика. И никогда с позиции эффективности денежных ресурсов. И при это при том что мы уже давно живем в капитализме.

B>Если что случится с java девелопером, который разработал супер мощный апплет. То во что выльется модификация решения заказчику? Купить студента на месяц, который тебе подкрутит HTML. Или нанять крутого спеца, который стоит раз в 5 — 10 дороже. Который разберется в существующем клиент-серверном взаимодействии и сможет эффективно модифицировать существующее решение?

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

Здравствуйте, C0s, Вы писали:

C0s>как-то в моем IE она сама собой появилась,

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

C0s>а вот в mozilla наоборот после какого-то апдейта слетела и больше не поднимается
C0s>так что я с Flash уже примерно как с месяц не особо дружу

V>>ну так ничто не мешает скачать поддержку JAVA. это так же просто

C0s>думается, модемные пользователи в качестве контраргумента скажут, что инсталляшка JRE больше, чем Flash

поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98

А если из MS VM повыкидывать WFC классы, то останется всего лишь 3мb из 5 — совсем немного.

Здравствуйте, MT, Вы писали:

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

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

редкая забота о заказчике

тронут

Здравствуйте, vladserge, Вы писали:

B>>Как часто приходится на вэб страничке динамически отображать контент клиентского DXF?
V>Возможности аплета покрывают всю функциональность доступную DHTML.
V>Тут я привел пример где на DHTML(в отличии от JAVA) просто вообще никогда решения небудет.
Тоже могу привести как минимум 2 примера где апплеты очень эффективно работают. Никто не говорит что таких ниш нет. Они есть. Но их на столько мало, что приходится серьёзно анализировать область прежде чем решится на использование в ней апплета.

V>>>Небывает "песочниц" для ActiveX.
B>>И?
V>незнаю как кто, а я ActiveX из интернета (кроме от MS) никогда не ставлю.
Ты авторитетно заявляешь что 90% пользователей вэб делают точно так же? Для них все равно разрешить ли установится ActiveX или дать пермишены апплету. Они понятия не имеют к чему это приведет. От них требуется только да/нет, и исходят они из того нужно или нет им предлагаемое решение. И вопросы безопастности тут встают, к сожалению, в последнюю очередь.

B>>Flash runtime уже имеется у подавляющего большинства пользователей.
V>те читать нужно так. Большинство пользователей скачало и поставило поддержку Flash.
V>ну так ничто не мешает скачать поддержку JAVA. это так же просто
Такое очучение, что тебе просто хочется поспорить. Приблизительная математика:
90% — уже имеют Flash.
10% — уже имеют JRE.
Мы предлагаем скачать пользователю JRE. Мы не знаем на сколько эффективное наше решение поэтому считаем пользователь скачает его с вероятностью 50%.
С flash мы имеем 90% + 5% запустивших нашу программу. C апплетом мы имеем 10% + 45%.
Итого 95% vs 55%.
То есть с учетом того что рапространение flash среди пользователей больше решение на нем будет более эффективным (если отбросиь все другие параметры).

V>(Я правильно понял тему. Мы говорим о +/- решении на Applet вообще, а не конкретно по тому с чего начался топик.)
И да и нет. Все выше написаное относится к апплетам вообще. Но анализ с учетом исходного поста будет как минимум интересен его автору. Так что можно и нужно их обсуждать с соответствующей оговоркой.

Здравствуйте, MT, Вы писали:

MT>Поделитесь мнением и опытом изпользования апплетов на клиентской части.

Апплеты традиционно используются в качестве клиентов в приложениях, отображающих в реальном времени результаты биржевых торгов. Клиент — многопоточное приложение, общающееся с сервером через сокеты. Частичная обработка данных на клиенте, кэш и собственный протокол позволяют уменьшить трафик. Апплет позволяет трейдеру подсоединиться к системе из любого места (теоретически, так как теперь уже необходимо наличие java плагина), где есть интернет.
А если нужны только формочки и кнопочки, то наверное DHTML удобнее.

Здравствуйте, Blazkowicz, Вы писали:

В принципе, все верно, только маленькое замечение.

B>1) Апплеты на MS JVM. Это там где только AWT. И то что будет работать скорее всего только в IE. Который вскоре может и не будет поддерживать Java. Вобщем безперспективняк.

Неверно, апплет, написанный под MS JVM будет работать везде, где есть хоть какая-то ява-машина (кроме старой макоси, где я видел машину 1.0, работающую в старом нетскейпе). По крайней мере пока не отменят обратную совместимость.

Здравствуйте, MT, Вы писали:

MT>Здравствуйте, nant, Вы писали:

N>>Здравствуйте, MT, Вы писали:

MT>>>Поделитесь мнением и опытом изпользования апплетов на клиентской части.
MT>>>Есть приложение (обработка форм — ввод данных) основанное на апплетах — нужно убедить заказчика что это не есть хорошо, и лучше переделать чем поддерживать то что уже написано.
MT>>>Спасибо.

N>>Приложение используется работниками организации заказчика, или его клиентами?
N>>Каково количество пользователей (единицы, десятки, сотни, тысячи, больше)?

N>>Вопросы имеют принципиальное значение.

MT>Сотрудниками предприятия (офисы удаленные в том числе)

Так я и думал.

Я смотрю там выше по ветке методом последовательных приходят к правильному решению с правильной мотивацией. Мотивация для заказчика — финансовая целесообразность.

Решение вопросов:
1) Стоимости поддержки и наличия deprecation — рефакторинг.
2) Скорости работы — рефакторинг + оптимизация, если таковая понадобится после рефакторинга.
3) Проблем с версией Java — переход на JDK 1.5. Лучше после рефакторинга, так как в общем случае — дешевле.
4) Проблем с установкой Java — сборка инсталляционного пакета, который установит нужную версию Javа или, если таковая уже установлена, сконфигурирует Java Plugin отдельного браузера
Deployment такого пакета — через механизмы ОС ( profile, group policy, etc), либо предложением пользователю: у вас не та версия, поставьте заботливо подготовленный пакет.

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

Я виду не все, поэтому может быть и другой вариант развития событий — вы доказываете почему плохо _существующее_решение_, а тезнология на котором оно сделано — это второй план. Даете оценку на создание нового решения и на приведение того, что есть в нужный заказчику вид (что именно этот вид нужен заказчику — нужно доказать). И тогда уже разговор приобретает предметный для закахчика вид. X1 против X2 с возможностями F1 против F2

Мало того, во вормя сбора этой информации вы найдете еще некоторое количество проблем в том, как существующая система поддерживает бизнес заказчика.
Тут тоже будет определенный пласт работы, которую можно предлагать сделать.

<advise nooffence="on">
Cоздавать себе объем работы манипулированием тем, на какой технологии сделана система — не есть профессиональный подход. Хороший игрок — это тот, кто не проигрывает с плохими картами, а не тот, что выигрывает с хорошими.
</advise>

Здравствуйте, Cider, Вы писали:

C>Неверно, апплет, написанный под MS JVM будет работать везде, где есть хоть какая-то ява-машина (кроме старой макоси, где я видел машину 1.0, работающую в старом нетскейпе). По крайней мере пока не отменят обратную совместимость.

К сожалению подобной информацией в полном объёме не владею. Но сотня ворнингов в проекте настораживает. По крайней мере каждый из них нужно будет проверить на современных JRE

Здравствуйте, Blazkowicz, Вы писали:

B>90% — уже имеют Flash.
B>10% — уже имеют JRE.

Все проскипано... Ну не люблю я голые среднепотолочные цифры

На вскидку...

http://globalstats.hotlog.ru/#JAVAENABLED

http://gs.spylog.ru/r/?dayFrom=9&monthFrom=8&yearFrom=2005&dayFor=9&monthFor=10&yearFor=2005&ltType=4&visitors=on&x=24&y=23&order=visitors&desc=1&inner=0&reportId=14&categoryId=1&representationType=table

Тем не менее имхо юзать аплеты последнее решение. Когда других вариантов просто нет. И согласен что таких ситуаций практически не бывает.

Здравствуйте, Infernal, Вы писали:

I>Все проскипано... Ну не люблю я голые среднепотолочные цифры

I>На вскидку...

I>http://globalstats.hotlog.ru/#JAVAENABLED

I>http://gs.spylog.ru/r/?dayFrom=9&monthFrom=8&yearFrom=2005&dayFor=9&monthFor=10&yearFor=2005&ltType=4&visitors=on&x=24&y=23&order=visitors&desc=1&inner=0&reportId=14&categoryId=1&representationType=table

I>Тем не менее имхо юзать аплеты последнее решение. Когда других вариантов просто нет. И согласен что таких ситуаций практически не бывает.

Имел ввиду Java 1.4 и выше. Приведенная статистика учитывает MS JVM. И так понятно что она предустановлена и о ней речь не идет. Так что не надо тут "цифрами" раскидываться.

Здравствуйте, Blazkowicz, Вы писали:

I>>http://gs.spylog.ru/r/?dayFrom=9&monthFrom=8&yearFrom=2005&dayFor=9&monthFor=10&yearFor=2005&ltType=4&visitors=on&x=24&y=23&order=visitors&desc=1&inner=0&reportId=14&categoryId=1&representationType=table

B>Имел ввиду Java 1.4 и выше. Приведенная статистика учитывает MS JVM. И так понятно что она предустановлена и о ней речь не идет.

почему

, говорили о JAVA вообще.

B>Так что не надо тут "цифрами" раскидываться.

как меня эти цифры порадовали Ё!!!!!!

не знал. эх пойду щас кой кого носом натыкаю.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, AVM, Вы писали:

C0s>>><SKIP> я-то тоже не уверен, что апплеты — это хорошо <SKIP>
AVM>>Почему?

B>Рискну ответить, хотя вопрос адресован и не мне.
B>IMHO, апплеты способны решать эффективно только узкий круг задач. Такие задачи находятся довольно не часто. ActiveX, Flash, DHTML составляют очень серьёзную конкуренцию апплетам, потому что так же эффективно решают эти задачи, но при этом не требуют загрузки JRE.

Позволю с тобой не согласиться. Аплеты это обычное десктопное java приложение (с некоторыми ограничениями по security) + удобный механизм доставки приложения на клиент.
Самый серьезный и принципиальный минус у аплетов — необходимо наличие JVM на клиенте. К сожалению Sun &MS сделали все от них зависящее, чтобы JVM by default отсутствовала на большинстве десктопов.

IMHO аплеты ничем не хуже обычной java application. Правда с появлением Java Web Start они начали смахивать на неуловимого Джо, за исключением некоторых случаев. Похоже один из этих случаев мы сейчас рассматриваем — есть legacy system кторую надо промантейнить, и есть мы — пра-пра-пра-правнуки интернационала "весь мир насилья мы разрушим до основания " и все перепишем нафик заново на технологии T

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

Здравствуйте, vladserge, Вы писали:

V>поэтому я и стараюсь писать не вылезая за jdk 1.1.8 она предустановленна в Win 95, но лучше её проапгрейдить до той что в win 98
MS JVM, пусть покоиться она с миром, и будем вспоминать в суе войну на которой она погибла.

Здравствуйте, AVM, Вы писали:

AVM>Позволю с тобой не согласиться.
AVM>Самый серьезный и принципиальный минус у аплетов — необходимо наличие JVM на клиенте.

Это такой приём полемики? Выразить несогласие и повторить слова собеседника?

Здравствуйте, C0s, Вы писали:

C0s>допустим, есть набор требований, который реализуется без апплетов, только на html. без нужды лепить апплеты? — ни в коем случае.
почти согласен

C0s>предположим, возникает требование, которое дает фантазии разгуляться — прежде всего, фантазии заказчика, который хочет фишечки и еще бантички сбоку впридачу. тут уже надо смотреть — готов ли заказчик спонсировать свои аппетиты. обычно в такой ситуации апплеты рассматриваются как скачкообразное усложнение архитектуры, что влечет за собой массу подготовительных действий. при правильном финансовом и временном обосновании заказчик смягчает требования.
Поясни плиз, почему аплеты должны усложнить архитектуру, да еще скачкообразно?
Какое они вообще влияние на архитектуру могут оказать? В простейшем случае это presentation (причем может быть очень навороченный presentation, с графиками, картами, VoIP, etc), если архитектор вставил в аплет business logic это не проблема с аплетами, это проблема с архитектором.

C0s>но у вас — другой случай, в котором апплеты _уже_ есть. наверное, надо отталкиваться от того, насколько легко удается нести бремя поддержки, и адекватны ли финансы заказчика это добра
IMHO написать тонкого клиента на Swing-е (считай applet), будет менее трудоемко, чем тоже самое изобразить например на Struts-е.

	От:	cafebabe
	Дата:	07.11.05 16:46
	Оценка:

	От:	Blazkowicz
	Дата:	07.11.05 16:50
	Оценка:	1 (1)

	От:	vladserge
	Дата:	07.11.05 16:55
	Оценка:

	От:	C0s
	Дата:	07.11.05 17:03
	Оценка:

	От:	vladserge
	Дата:	07.11.05 17:05
	Оценка:

	От:	AVM
	Дата:	08.11.05 09:07
	Оценка:

	От:	AVM
	Дата:	08.11.05 09:12
	Оценка:

	От:	AVM
	Дата:	08.11.05 09:26
	Оценка: