Софтверный проктолог ренегатНу и на кой вам там ява сдалась?

А почему бы и нет?
Чем она хуже любого другого языка/решения (которые вряд ли позволит написать всё с его помощью, включая и средство управления всем этим хозяйством — абонентами там, тарифными планами, счетами и т.д.). Мы уж не говорим о том, что это любой другое решение должно работать под Linux без каких-либо вопросов и замечаний. И под Windows тоже и так же, посколько на нем мы пока пишем :)

Я могу назвать тебе массу доводов из отряда того, что вы могли бы обойтись исключительно
Oracle (в т.ч. XE). По всем параметрам (производительность, надежность, дешевизна и скорость разработки и т.д.).

Вообще без явы. И без C/C++-а в т.ч. (ну может разве только по фронту адаптеров доступа к первичным счётчикам).

Кстати, мобильные операторы (в основном) так и делают.

Софтверный проктолог
ренегатА напрасно. Среди пластов махрового маразма там иногда мелькают (редко) ценные мыслишки.
Как-нибудь потом, когда научусь эффективно отделять зерна от плевен на основе своего опыта :) А, это да ;)

Софтверный проктолог
ренегат
По javadocs, что ли?
В мире Java принято выпускать хорошую документацию. К тому же мы пользуемся сервером приложений, в котором документация очень подробная (почти вся). Ну и плюс еще всегда можно поинтересоваться у более опытных товарищей, где стелить соломку.
У меня мнение строго обратное. Более отвратной документации (не считая примитивов) я ещё
не видел. Впрочем, отвратны там были скорее сами решения, документация - это уже вторичное.

Впрочем, всё познается в сравнении.

Софтверный проктологP.S. Кстати, javadoc тоже может быть весьма полезен — во время практического применения какого-нибудь, хм, решения. Мне очень нравится то, что такое гибкое средство документирования и комментирования легко использовать и поддерживать.
Ну ну.

Софтверный проктологНет, не смогли бы обойтись. И в скорости, скорее всего, не смогли бы превзойти. Это я тебе сообщаю как бывший разработчик Oracle с 2,5 летним стажем (небольшим, но всё-таки; представление я имею хорошее обо всей кухне).
Ниачем.

Софтверный проктолог
Мобильные операторы используют параллельно какую-нить громозиллу как CRM/Control. У нас нет ресурсов на громозиллы :)
Мы маленькая, но, сцуко, гордая компания.
На место Amdocs (которому давно пора сдохнуть, к слову) не метим.
CRM и биллинг - совершенно разные классы задач.

По поводу комплексных решений - опустим. Ибо сейчас мы плавно перейдем к тому, что
неплохо было бы на яве вона ещё и аналог 1С настрадать (не смешно, но про войну).

Софтверный проктолог ренегатНиачем.
Твое предложения все делать на Oracle — тоже не блещет конкретикой. И оно нас не устроит совершенно точно, посколько не даст решить те задачи, которые нам нужно решать :)

Ну так озвучь те задачи, которые вы там решаете. Можно не все, а только те, которые не даст вам решить связка Oracle RDBMS + APEX. И которые потребуют яву в обязательном порядке.

Итак?

Софтверный проктолог ренегат
Ну так озвучь те задачи, которые вы там решаете. Можно не все, а только те, которые не даст вам решить связка Oracle RDBMS + APEX. И которые потребуют яву в обязательном порядке.

Итак?
Часть из них нерешаема (мы, к примеру, в данный момент используем Sybase ASE; он гораздо дешевле; мы всё-таки продаем решения, а не распиливаем деньги).

Дешевле чем полная бесплатность? ;)))

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

Софтверный проктологработа отдельно от DBMS (горизонтальное масшатбирование для быстрых отдельных приложений; без разнообразных кластеров из СУБД);
Что-то явно странное. Работа информационной системы без БД? Это как? Из плоских файлов, чтоль?

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

Софтверный проктологпосмотри на сайт Тома Кайта — один из самых тормозных сайтов, что я видел);
Поклеп. Сравнивал что с чем?

Софтверный проктологвозможность отказаться от веб-интерфейса в некоторых случаях (и его усложнение с помощью Applet-ов/Flash-ем);
Апплеты идут строго на юг, по определению, в вашем классе задач. В остальном - не вижу никакой трудности.
Впрочем, можешь озвучить задачу, где без апплетов - ну никак, хоть тресни.

Софтверный проктолог
принципиальная возможность смены DBMS (если завтра Sybase поднимет цену в два раза — пойдет он лесом незамедлительно).
Детский сад. Если честно - вообще не интересно. Использовать Oracle на уровне ANSI SQL-92 - это
совсем не смешно.

Софтверный проктологВсе это можно решить и Java. Только зачем?
Вот и я о том. Нафига в биллинге ява - я не понимаю. Пытаюсь у тебя выпытать.

Софтверный проктологДля остальной части альтернатива слишком дорога.
То есть?

Софтверный проктологМне нужно ООП. Это факт. Бессмысленно рассуждать на тему зачем. Просто нужно.
Религия? Или таки мракобесие?

Софтверный проктологДумаю, уже этого достаточно.
Увы нет, ты так и не сказал, для чего тебе понадобилась Java


Софтверный проктологДа и, строго говоря, бессмысленно перечислять. До этого мы вели беседу в легком и непринужденном стиле; теперь же требуется что-то обосновывать? Зачем? Никто никого не убедит ни в чем.
В том то и дело. Я просто коллекционирую доводы от людей, которые выбирают .NET или Java для
чего-то там. Осознанно и обоснованно.

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

Софтверный проктологКак люди использовали Java, так и используют.
И я даже знаю почему ;)
Ответ - потому что ничего другого не знают и не умеют, и выбрать им не из чего (клиника начинается, впрочем и заканчивается, на утопическом тезисе кроссплатформенности от СУБД).

Софтверный проктологКак использовали СУБД в виде всего-всего-всего, так и используют (заливая туда мегатонны бессмысленного барахла, о чем ты уже говорил несколькими постами выше; куда ж им еще девать барахло, если нет ничего кроме СУБД?).
Ну и? При чём тут одно к другому?

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

Вопрос - а на кой? Усложнять то?

А?

--

Кстати, озвучил бы ты задачи поконкретнее. А то кроме адаптеров (по сути - драйверов) - ничего и
не вырисовалось.

Софтверный проктологНеужели ты думаешь, что я буду тебе потакать? :)
Мы вели непринужденную беседу? Мне действительно было интересно, узнать ход осознанной мысли о выборе тех или иных средств.
В остальном, если доводов нет - ну не приводи их, делов-то. Истина так и останется нераскрытой.

Я вот запросто могу тебе сказать классы задач (от клиента), которые не стоит решать на RDBMS или APEX, но почему ты их не можешь озвучить - вот в чём вопрос.

Впрочем, я ведь заикался больше про UI (а там больше вопрос чисто адекватного средства GUI дизайна). А ты говорил про серверные задачи.

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

Но мы говорили именно про сервер сайд.

Софтверный проктолог ренегат
Кстати, давай проведем эксперимент.
Сколько компаний и в скольких странах используют ваше решение (сделанное на базе чистого Оракла и Apex)?
Тебе действительно интересны причины (и даже следстваия) стадности? Я вполне могу их озвучить.
Но мы не про это сейчас.

А так, об упрощении в сторону ... той самой гениальности?

Софтверный проктолог И сколько оно стоит (достаточен порядок — 10k$, 100k$, миллион; вместе с оборудованием и ценой на лицензии, разумеется)?
Я могу тебе собрать кластер любой степени сложности практически с нулевыми дополнительными лицензиями.

Берем в виде стасиса - любую центральную базу данных (пусть это будет хоть Oracle EE или даже какой DB2, Sybase - не важно).

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

И никаких отличий от какого томката и подобных - я не вижу. С той только разницей, что базовые
знания и обязанности девелоперов будут ... SQL, PL/SQL и (вот тут ключевой момент - без Java/J2EE).

А результат - один в один.

ООП? Так там есть и ООП, в явном и неявном виде. Вебсервисы? Есть и они. А что ещё то?
Даже рассылка почты и СМС-ок есть ;)

Ну и? Чего там, в яве то, такого незаменимого? Вот если честно?

Софтверный проктологЭто мы всё говорим о биллинге, напоминаю.

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

Ну и какие вариации на тему отчетинга, фискалинга (счета-фактуры и иже), и что там ещё?

Софтверный проктолог ренегат
Тебе действительно интересны причины (и даже следстваия) стадности? Я вполне могу их озвучить.
Но мы не про это сейчас.
Да при чем тут стадность? Это же чистый бизнес :)
Люди умеют считать деньги (и ничего плохого в этом нет; не все же качают ништяки из нефтяной трубы).
Ну да. И тут вырисовывается Oracle Utilities или SAP IS-U. Которые покрывают биллинг медным тазом.

Софтверный проктолог
ренегат...
Берем в виде стасиса - любую центральную базу данных (пусть это будет хоть Oracle EE или даже какой DB2, Sybase - не важно).
...
А результат - один в один.

Ну и чего такого в Oracle-е незаменимого-то? Вот если честно? Накуй он нужен (кроме того, что он реально быстр) :)
Только тем, что реально быстр он и нужен. Ну и тем, что реально кроссплатформенен, реально надежен (если читать документацию) ну и много чего разного.

А главное - не надо страдать идиотские недоORM-ы, итераторы по коллекциям и прочий левый и нудный бред.


Софтверный проктолог
ренегат
ООП? Так там есть и ООП, в явном и неявном виде.
В Оракле нет ООП. В PL/SQL нет ООП.

Ну да, в 1999-м году ещё вроде не было. Потом ты что-то упустил, видимо. При том - два раза (как известно, ООП достижим даже на чистом C, и, в т.ч., даже на PL/SQL в версии Oracle7).

Рассказать, как делается наследование на голом SQL или полиморфизм/инкапсуляция на голом PL/SQL?

Софтверный проктологТы видимо забыл о том, что я говорил про 2,5 года опыта с этой платформой и решил сыграть на дурачка?
Да нет. Не ты первый плохо читаешь документацию по нему.

Софтверный проктологУправление, мой друг, управление всем своим абонентским богатством.Возможно у нас разные понимания задач управления.
Я вот первым делом подумал про стратегический менеджмент или инвестиции. А ты про что?

Про междумордия для операторов? Ну и? Покажи мне хоть одну формочку, которую нельзя сделать на APEX?

Софтверный проктологТы уверен, что понимаешь, что такое ООП и в чем его преимущество? :)
Для бизнес задач - увы, не понимаю. Только в двух местах я видел необходимость оного.
Первое - сущность Клиенты (Физики, Юрики), второе сущность Документы (и понеслась).
Первая - проста как двери и сводится к денормализованной таблице.
Вторая - ну... в общем случае - не очень то и хорошая идея, ибо нафиг рушит декларативную
целостность в БД (ну, к примеру, появляется возможность выписать авансовый СФ на какую
заявку на мощность или письмо, и т.д., и т.п., что, в общем то, полная глупость, если
не накладывать доп квалификатор на связь). Тем не менее.

В остальном я могу честно сказать - ООП для бизнес-задач - бесполезен. Как средство для
навайки UI классов - ну да, вполне. В остальном, увы, парадигма противоестественна реалиям.

Впрочем, можешь рассказать, где тебе реально нужен ООП в бизнес-задачах. Было бы интересно.
Я вот за лет уже 12-ть практики - таких задач (на явный ООП в прикладном коде) не видел вообще.

--

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

Америки тут нет никакой вообще. Это ведь бизнес такой. Большой бизнес распиливает бабло
большого бизнеса. Техническая сторона там вторична. Первичен сервис овокруг
(консалтеры-шманалтеры и прочее). Да и вообще, amdocs или is-u - это не программа, а доступ
к компетенциям и типовым бизнес-процессам (если ты не знал).