Вот-вот.
Я админю, так сказать, большую фирму. У нас есть своя программа с базой. Когда-то я для них писал это всё на дельфи с огнептичкой. А 2,5 года назад учредитель захотел переехать в веб. Выбирал я между дотнетом и пхп. В итоге пришел к пхп из-за сравнительной дешевизны. Хотелось кроссбраузерности и кроссплатформенности. Но не тут-то было! Оказалось, что даже кроссбраузерность не всегда легко дается.  Так и порешили, и перешли полностью в веб: пхп + мускуль. И всё это было из-за того, что канал связи в центральном офисе и на филиалах был не ахти какой. Да, с функциональностью и дизайном проиграли. Ужасно проиграли. Может потому что разработчики оказались не очень компетентные, может потому что инструменты программирования были хуже. Не знаю. Но теперь я жалею и думаю, что можно было избежать этого, оставить приложение как есть и продолжать его использолвать и дописывать. Просто базу перенести на хостинг с firebird. Пользователям новое веб-приложение оказалось сильно непривычное, неудобное, они потеряли много удобства в своей работе, сильно плевались и фукали на новую программу. Мало того, мы нормально можем использовать только Firefox, т.к. код (JavaScript) нормально работает только в Firefox, а потом уже, если есть время, то может быть допиливают для остальных браузеров, хотя сильно этим не занимаются. Как всегда нет времни и особого желания.

И я вот свою программу тоже хочу перекинуть в веб. Вернее только базу в веб, жаль что хостингов с firebird можно по пальцам пересчитать.

Так что можно сейчас смело писать веб-приложения на дельфи, а лучше на firemonkey, т.к. firemonkey предоставляет кроссплатформенность. Но, почему-то много примеров для 3D программирования и графики, и очень мало для LiveBindings и баз данных. Нет документации, особенно на русском :(

Я прошу не путать веб-приложения и веб-сайты.

Фиг его знает, товарищ майор. :unnw
Если говорить об ISS, там сам бох велел ASP зюзать. Преимуществ у делфи тут не вижу.
Если говорить об апаче, апач кроссплатформенен, здесь бы жава была бы очень уместа.

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


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


Ваш же проект был на жаве - так? И без этих кастылей вам было плохо - так?
А нам без этих кастылей прекрасно живется. Мы даже слова такие из википедии вычитываем, на столько нас не парят те проблемы, которые вы имеете на своей платформе.  

Это сообщение отредактировал(а) Zloxa - 15.3.2012, 12:10

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




Повторяю еще раз: это элемент культуры разработки.
Вот у вас счастливых дельфистов, сколько разработчиков и сколько тестировщиков? Что будет в случае 10 минутного простоя системы?




Это потому, что тебе не приходилось обновлять клиента для сотни тысяч внешних клиентов. 

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

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


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

Сотен тыщ клиентов у нас нет. У нас есть триста магазинов в Москве и области. В каждом магазине ведется учет делфевой самопиской. Одна инсталляция на магазин, около десятка рабочих мест. Где-то больше - где-то меньше. Поддержкой трехсот инсталляций этой софтины занимаются 2,5 человека. Они отвечают в том числе и за расстановку версий. Расстановка производится вручную. Но не сказал бы я, что расстановка это основное их занятие. Как процесс организован в других наших подразделениях, в других регионах, на других учетных системах - не уверен, но кажется дела обстоят схожим образом. Разработка этой самописки ведется на стороне, но, думаю, не ошибусь, если скажу что разработчиков 1,5-2 человека. Тестированием занимаются и они на своей стороне своими двумя человеками и мы на своей - своими двумя с половиной. Выбор правильного инструментария качественно снижает количество задействованного ресурса    (Тут троллю, конечно. У нас сейчас на жаве новую нескучную POS пишут. Не знаю сколько у них разарботчиков. Я общаюсь только с одним. Но подручные у него помоему есть, так что можно считать что те же 1,5 - 2 человека)

В течении достаточно длительного времени у нас муссировалась тема "облегченной" POS. POS которая не ведет учет, регистриует лишь факты продаж, а приходно/расходные операции оформляются через веб. От идеи пришлось в конце концов отказаться. Мы достаточно жестко ограничены законодательством в ценообразовании, нам нужен строгий партионный учет, который вписать в эту концепцию нам не удалось.

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

Это сообщение отредактировал(а) Zloxa - 15.3.2012, 17:09

Ну во первых надо заметить что хром для гугла это приложение №1 (как минимум на десктопах). Так что труда туда вбухивается ого-го сколько. А вот та же Пикасса например не обновляется с такой же легкостью как это делает хром, как думаешь почему?
Во вторых идея хранить код в профиле пользователя явно противоречит тому для чего эта папка создавалась.




А кто говорил, что веб интерфейс это серебрянная пуля? Достаточно очевидно, что плохие каналы связи, это первый признак того, что веб гуй тут не подходит.
Что касается обработки больших объемов данных, у нас в соседнем проекте ребята делали систему для аналитики на Flex+Java Server. И ничего система нормально работала, на тормоза никто не жаловался. Справедливости ради надо отметить, что она использовалась только в интранете, так что сетевые задержки были минимальны. Вообще говоря: пользователь больше пары тысяч строк глазами все равно не просмотрит, если данных больше значит нужна фильтрация, группировка или еще как реорганизовывать отображение.

На остальное отвечу позже.

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

И, если уж на то пошло, не плохо бы вспомнить, что изначально вся эта веб байда гордо именовалась "тонкий клиент" и предназначалась для использования как раз таки на малостабильных каналах связи    Сейчас иной толстый клиент куда тоньший канал требует ;))

Это сообщение отредактировал(а) Zloxa - 15.3.2012, 19:54

Delphi мне понравился... Я балдел от него... Пока не пришлось переставлять софт на машине.
Потом каждый раз при необходимости установки и настройки делфей, меня от них тошнило всё больше и больше...
Ну и ещё, было дело, уже когда я сильно их не любил, надо было разобраться с delphi кодом. Очень понравилось выяснять, какие свойства в каком компоненте описаны, как установлены и откуда в коде берётся определённое поведение (а это ок-ся компонент в форму закинут и там установлены определённые свойства). Кстати, с net щас похожие проблемы (недавно надо было разобраться с кодом). Да и много где начинают похожее городить.. Ладно хоть описание форм теперь в xml - для контроля версий лучше.

А сам язык нормальный - есть конечно загибоны (var... interface), но они терпимы...

зы

Веб сложен, потому что каждому охота вы*** со своим дизайном... Были тут умники - приходили пытались научить, как сэкономить на вёрстке... ;)
Ну а формочки в вебе уже давно неплохо так клепаются, в том же grails.

Это не заслуга Дельфи и не ваша. Просто таков ваш бизнес, что отдельные элементы могут достаточно долго работать в автономном режиме. А есть бизнес где это не возможно. Я не представляю как организовать тот же трейдинг без централизации, так чтобы каждый трейдер торговал сам по себе.





Веб гуй может быть очень отзывчивым особенно если использовать RIA. Могут ли отделения банка работать в автономном режиме, я не очень в курсе. Банковский день надо закрывать централизованно, так что связь должна быть, но вот допустимо ли ее пропадание в середине для - не знаю.




Есть куча библиотек которые облегчают эту задачу. Тот же грид на ExtJS реализуется достаточно просто, и при этом он весьма отзывчив. Посмотри их демки. При использовании Flex можно вообще использовать мышкокликательное программирование так любимое Дельфистами. Хотя по мере набора опыта, все Flex программисты которых я знаю, перешли на написание гуя руками. Думаю это все от недостатка опыта в разработке веб приложений.

Его я в том числе и имел в виду, когда говорил о недовылупленности. Да - тема офигенна. Но фора традиционного гуя пока еще далеко не покрыта. Делфевые, доднетные гриды и умеет больше и допиливаются проще.


У RIA, если я правильно понял о чем речь, - я вижу основное преимущество не столько в отзывчивости, сколько в возможности иметь собственную сессию c сервером приложений, принцип работы которой отличается от HTTP сессии и ближе к классической клиент-серверной сессии. Это позволяет реализовать пессимистическую стратегию блокирования, которую не возможно реализовать в класическим веб приложении, и которая очень востребована в корпоративном секторе. Например накладную куда проще заблокировать на время ее модификации пользователем, нежели свести воедино результат параллельной работы над ней двух разных пользователей. Если же попытаться заблокировать ресурс в http сессии, возникает непонятка, когда его освобождать, пользователь может закрыть окно редактирования, не завершая сессии и сервер приложения не будет оповещен об этом факте. Да, существуют разнородые кастыли, которые применить для получения желаемого, но даже до статуса органических протезов им весьма далеко.

Я так понимаю Oracle Forms можно отнести к этим самым RIA. Его концепция, в этом отношении, мне очень нравится. Принцип построения вебового приложения не отличается от классического клиент-сервера. Но во всем же остальном, увы, это буквально чудовище.

Flex - не ковырял, но в виду его иметь, наверное стоит. Ораклиный металинк на флексе врой как переписан. Но кто его знает, не ждет ли этот флекс участь жава апплетов, которые казались столь же перспективными еще так недавно. Не будет ли для флекса HTML5 тем же самым, чем стал для апплетов флэш?

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



Есть веб сокеты. Правда они появились недавно, потому не очень распространены пока.

Добавлено через 1 минуту и 8 секунд
Ах да, главная претензия к Дельфям, они наш null обозвали nil! И вы еще спрашиваете за что их не любят?!  

Вам с вашим null и обращаться то достойно не дозволено

А что не так?

Трехзначная логика - где?
Ваш null - значение, характеризующее неопределенное значение.   
Т.е. значение определено, но оно не определено - подвоха не чуствуешь? Принюхался?

Вот оно - достойное поведение:


Это сообщение отредактировал(а) Zloxa - 21.3.2012, 17:10

Где-где -- в су-бэ-де  




Это ваш null - значение характеризующее, а наш это значение указателя не указывающего ни на какой объект и все. Никакой другой смысловой нагрузки он не несет.



У тебя опечатка  
Что будет в результате?

  

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


А ваш это недонаш null