А вот антихоливар

[metaclass]

ру-жаба:
В рамках проекта по сбору информации с метеорологических сенсоров, пишу софт. Каждую из метеорологических станций планируется оснастить локальным сервером, который будет прослушивать COMы и считывать то, что есть сказать тому или иному прибору. Локальный сервер будет накапливать наблюдение и пересылать его центральному серверу. Центральный сервер - JBoss, локальные - самописные


чудаки додумались реализовать сетевой стэк сервера на жабе, за что и отгребают уже который месяц :)


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

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

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

Comments

[medvedd.livejournal.com]

Ну неужели нельзя проще,а ? :(

[metaclass.livejournal.com]

Если бы был выбор - я бы все делал как можно проще.
Но простые разработки давно закончились.
Сейчас нормальный проект - гуй, БД, сервер, сервис сбора данных, веб-морда и еще с десяток вспомогательных утилит. И вспомогательные системы - автообновление, бэкапы, проверка кошерности сети.
И это еще простой проект. В сложном еще три разных веб-сервиса, две сторонних проги, прикрученные через COM и веб-сервисы, каждая тоже с БД и веб-сервисами, три вида гуев, взаимодействие с HID-устройствами и доступ по GPRS с j2me-проги на сотовом телефоне :)

[volodymir-k.livejournal.com]

А что сложно?

[volodymir-k.livejournal.com]

> а не сломалось ли чего в настройках JRE

А что за настройки, которые могут сломаться?

Единственные, что я знаю -- в реестре "актуальная" версия. Помнится, поставил я себе 4 JDK/JRE одновременно и пытался колупать -- тогда да, сломалось. Само собой ничего не случалось нигде.

[metaclass.livejournal.com]

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

[theiced.livejournal.com]

Ребе, это неправильная паранойя. Моя, правильная, паранойя велит как раз собирать данные на чём нить managed.

[volodymir-k.livejournal.com]

Наоборот, в Яву можно через JMX посветить, чего и как. Это очень качественный код.

Хотя если иметь в виду вредителей -- то да.

[raydac.livejournal.com]

если некоторые гос учреждения на полном серьезе пропихивают Java+JBoss в системы боевого управления, то уж опросить метеооборудование это цветочки

[metaclass.livejournal.com]

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

[theiced.livejournal.com]

В таком случае мона жре с собой носить. Оно таки автономно совсем будет. А вот томкаты и прочая жабская ересь - оно _ЗЛО_.

[thedeemon.livejournal.com]

>я лучше независимую ни от чего прогу сделаю.

Это тоже не всегда просто. Т.е. в винде еще довольно просто, а вот в юниксах - то ядро не то, то libc не тот, то еще куча пакетов не той версии. С Java может быть даже проще обеспечить запускабельность.

[metaclass.livejournal.com]

Да, это тоже печаль известная.

[gds.livejournal.com]

насчёт венды имею что сказать из сегодняшних открытий.
Имеем на клиентах nt4. Хотим заменить гнидогондоидный ichat на что-нибудь работающее и надёжное. Что? -- очевидно, жаббер. Сисадмин заебался вусмерть, пока нашёл неглючный и понятный юзерам клиент, умеющий nt4. Это оказался какой-то древний билд миранды, следующие работать не хотят или недостаточно публично выложены.
И буквально сегодня наблюдал, как наш сисадмин ебётся вовсю: если на nt4 не поставить office xp, то не будет правильно работать локаль в миранде (будет слать сообщения не в той кодировке), а если вместо ie5 стоит ie6, то смайлики становятся не анимированными.
Хуй его знает, как в юниксах, но тут диагностировать такое _конструктивными_ средствами -- ну практически нереально. В юниксах с открытым ядром, дебажными версиями библиотек и каким-нибудь strace/ltrace/gdb -- можно подойти к вопросу конструктивно. (предполагаю, что неконструктивные меры вида "потрясти бубном" одинаковы как под юниксами, так и под виндой, и предполагаю, что при сравнимой сложности конструктивные меры лучше неконструктивных)

[metaclass.livejournal.com]

Ну, поддерживать nt4 и обходные маневры для таких вещей делать - да не в жизнь.
Я даже за деньги это делать не стану, зачем мне тратить недели на сидение в windbg и вылавливание зависимостей от баговых версий comctl32 какого-нибудь, если за это время я сделаю 10 фич для клиентов с нормальными ОС и получу гораздо больше результата.
И под юниксом то же самое никто делать не станет на самом деле - скажут "у вас ядро устарело, идите нахер".
Но при надобности и под виндой дебаг доступен.

[volodymir-k.livejournal.com]

> Имеем на клиентах nt4.

Это примерно как линукс ядро 2.0.14.

> В юниксах с открытым ядром, дебажными версиями библиотек

Как правило, открыто ядро не в юниксах, а в линуксах. Юниксы наоборот, после 1990 сорцы не дают.

И не вижу разницы между дебажными версиями от MSDN и Ubuntu.

[gds.livejournal.com]

линукс -- подмножество юниксов. бсд -- один из юниксов с открытым ядром.

дебажная версия от msdn не включает в себя исходники ядра/библиотек.

[1ceheart.livejournal.com]

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

Да иногда банально зависит от компилятора, не то что от языка. Я однажды был немало удивлен, сменив в одном проекте компилятор - платформа причем клон x86, все на plain C, никаких SSE и прочей экзотики - и получив разницу в производительности на четыре порядка. Причем это была чистая случайность - ну вот, просто на определенном куске кода у gcc рвало крышу и он генерил бред. Так что никогда не угадаешь - можно сделать все правильно и наступить на какие-нибудь идиотские грабли, а можно написать TCP/IP на питоне и он будет даже приемлемо работать. Just because. Это, конечно, не повод писать TCP/IP на питоне :)

[lupus-lupusum.livejournal.com]

а на что ты сменил gcc?

[1ceheart.livejournal.com]

OpenWatcom :)