Сообщений в теме: 153

[ct.kz]

...

Сообщение отредактировал ct.kz: 05.08.2010, 15:39:29

[Big Joe]

Даже заведение карточки из десятка полей и поиск по базе, пишут под windows на Дельфи.

а на чем надо?
на клиппере под дос? или си под линух? или на ПХП сайт сделать?
имхо для таких задач дельфа как нельзя лучше годится

А если клиентов много (все области и районы), данных в базе миллионами записей, сеть медленная, компьютеры древние, обновление периодическое - как обычно в наших гос.структурах бывает.
Так еще и пишутся у нас 2х звенки, где везде ставится 200 метровый клиент оракул + организация покупает лицензию на каждое рабочее место, дистрбьютивы самой ПО тоже не малых размеров с кучей одаковских библиотек. Когда это все можно сделать под WEB, из пары страниц. А потенциал Дельфи про быструю разработку, оо это не про нас (сплошные запоздания, не сдачи в срок, штрафные санкции). Опыт работы у меня не большой, на за то время которое я поработал, насмотрелся такого.

[akh]

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

вы что же думаете если сеть медленная, то вэб интерфейс вас спасет?

[Big Joe]

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

вы что же думаете если сеть медленная, то вэб интерфейс вас спасет?

По крайней мере не нужно будет качать мегабайты обновленного ПО и библиотек.

[akh]

По крайней мере не нужно будет качать мегабайты обновленного ПО и библиотек.

А сейчас качаете? с каждого клиентского места?
Обычно патчи и апдейты скачиваются один раз и ставятся на все клиентские места сисадмином.
Если у вас не так, так это не дельфи и не 2-звенка виновата.

Впрочем, если вам нравится вэб интрефейс - валяйте, удивите всех очередным сайтегом.

[kant]

Даже заведение карточки из десятка полей и поиск по базе, пишут под windows на Дельфи.

а на чем надо?
на клиппере под дос? или си под линух? или на ПХП сайт сделать?
имхо для таких задач дельфа как нельзя лучше годится

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

Назовите для какой категории программного обеспечения Delphi лучше в долгосрочном плане?

Объем вводимой информации на одном рабочем месте:
a) 1-100 заполненных экранных форм в день
b) 100 и выше экранных форм в день

Общее количество клиентских мест/инсталляций
a) 1-10 Размер мелкой организации
b) 10-1000 Размер средней и большой органиазации
с) свыше 1000 - международные корпорации

Управляемость окружения в котором будет работать ПО
a) внутри компании и возможно небольшое количество инсталляций для внешних клиентов
b) внутри компании и среди компаний, являющихся клиентам
c) произвольное лицо, являющееся клиентом компании

Также стоит принять во внимание динамичность изменения количества клиентских мест, что может изменить текущие шаблоны применения ПО.

Также можете объяснить чем вам не нравится архитектура веб-приложений, видимо у вас есть предвзятое мнение по этому поводу

PS. В чем я с вами согласен, это в том что лучше без клиппера как нибудь )))

[akh]

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

Насчет моды согласен. С оговоркой.
Зачастую выбор тулзов и технологии делается исходя из того каких программеров организация имеет в распоряжении. Дельфистов - будет дельфи, дотнетчиков - будет дотнет.
И еще. Если основной критерий - дешевизна, то вам придется мириться с рисками. Всякими.
Как говорится из "быстро, качественно, дешево" выберите любые два.

Назовите для какой категории программного обеспечения Delphi лучше в долгосрочном плане?

...............

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

Также можете объяснить чем вам не нравится архитектура веб-приложений, видимо у вас есть предвзятое мнение по этому поводу

PS. В чем я с вами согласен, это в том что лучше без клиппера как нибудь )))

Дааа есть у меня субъективное негативное отношение. к веб интерфейсу. Работал я пару лет в команде на аутсорсе одной амеровской конторы. Поддерживали и дописывали их корпоративный сайт.
Писали на асп и VB, ну и HTML и JavaScript. Редкая гадость этот веб. . Это stateless программирование, инъекции, поддержка кросс браузерности и прочая лабуда. Особенно меня бесили кнопки back/forward в браузере. . Короче, очень много приходится делать, чтоб достичь самой элементарной функциональности и секьюрности.
Правда это было несколько лет назад. сейчас не знаю. Слава богу отошел я от этого.

зы
У Оракла есть свое решение - APEX. Может время будет - поковыряю.

[Big Joe]

По крайней мере не нужно будет качать мегабайты обновленного ПО и библиотек.

А сейчас качаете? с каждого клиентского места?
Обычно патчи и апдейты скачиваются один раз и ставятся на все клиентские места сисадмином.
Если у вас не так, так это не дельфи и не 2-звенка виновата.

Впрочем, если вам нравится вэб интрефейс - валяйте, удивите всех очередным сайтегом.

Не каждая организация может позволить себе по одному сисадмину во всех областных центрах, регионах, отделениях итп. Видел я как внедрялась такая ПО, которая один раз скачивается и все. Ведение версионности, несоответствие билдов итп. Да, возможно это все из за кривизны рук разработчиков, но с web интерфейсом этого всего небыло бы.

[kant]

Насчет моды согласен. С оговоркой.
Зачастую выбор тулзов и технологии делается исходя из того каких программеров организация имеет в распоряжении. Дельфистов - будет дельфи, дотнетчиков - будет дотнет.
И еще. Если основной критерий - дешевизна, то вам придется мириться с рисками. Всякими.
Как говорится из "быстро, качественно, дешево" выберите любые два.

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

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

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

Дааа есть у меня субъективное негативное отношение. к веб интерфейсу. Работал я пару лет в команде на аутсорсе одной амеровской конторы. Поддерживали и дописывали их корпоративный сайт.
Писали на асп и VB, ну и HTML и JavaScript. Редкая гадость этот веб. . Это stateless программирование, инъекции, поддержка кросс браузерности и прочая лабуда. Особенно меня бесили кнопки back/forward в браузере. . Короче, очень много приходится делать, чтоб достичь самой элементарной функциональности и секьюрности.
Правда это было несколько лет назад. сейчас не знаю. Слава богу отошел я от этого.

Сейчас все тоже самое, но вам скорее всего просто не повезло. ASP (чистый ASP, а не ASP.NET) это почти как клиеппер в досе, так что не удивительно что у вас болезненные воспоминания. Не так уж плох веб как его малюют. Сейчас даже намного привлекателен чем два года назад. Браузеры почти одинаково все отображают, так что это не проблема. После того как jQuery поборол большинство JS фреймворков, я уверяю вас, вы полюбите JavaScript и начнете творить с помощью него маленькие чудеса, без особых усилий.

зы
У Оракла есть свое решение - APEX. Может время будет - поковыряю.

APEX сакс, только и того что таким нубам в Oracle как я помогает, как и Oracle. Хотя у меня больше претензий не к самому серверу Oracle, а к его убогой справочной системе. Гугл ни сколько не помогает. Причем для самых банальных вещей.
В качестве примера, можете попробовать
http://www.google.co...ition by oracle, http://www.google.co...tition by mysql и http://www.google.co...rtition by tsql.
И это к сожалению не единичный случай.

[sobol]

дельфи небось?

Вот только Дельфи не трогайте... Контрпримером могу привести компанию Мединформ, которая до сих пор пишет софт на Фокспро, и вся Единая Информационная Система Здравоохранения Казахстана по сути на их продуктах и крутится...

[ndp]

Хотя у меня больше претензий не к самому серверу Oracle, а к его убогой справочной системе. Гугл ни сколько не помогает.

То, что Вы не умеете готовить кошек, не значит, что они не вкусные...
Каким боком Гугл относится к ораклу, и с каких пор он выдает достоверные ответы, соответствующие действительному поведению программного продукта? Гугл суть - агенство новостей "Одна Бабка Сказала".
На сайт вендора зайти религия не позволяет?
Oracle RDBMS. полное собрание сочинений.

И это к сожалению не единичный случай.

Вот это верно. Очень много, к сожалению, молодых "программиздов", придерживающихся точки зрения "не читал, но осуждаю".
"не писал под эту СУБД, но точно знаю что она хуже", а когда предлагаешь конкретизировать, в чем же она хуже, то получаешь ответ как в анекдоте:
- армяне хуже чем грузины!
- ну чем, чем они хуже???
- чем грузины!!!

Сообщение отредактировал ndp: 06.08.2010, 10:07:41

[xxel]

бизнес по казахстански (часть 2)

бизнес по российский
http://nnm.ru/blogs/..._biznes_delali/

Вот только Дельфи не трогайте... Контрпримером могу привести...

а что случилось то? и контрпример то зачем?
или это типа как в детстве "а у тебя еще хуже!" ?

[akh]

После того как jQuery поборол большинство JS фреймворков, я уверяю вас, вы полюбите JavaScript и начнете творить с помощью него маленькие чудеса, без особых усилий.

не полюблю, однозначно
роль дба/дбд меня вполне устраивает.

APEX сакс, только и того что таким нубам в Oracle как я помогает, как и Oracle.

я в апексе не спец, но то что мне нравится так это то что он крутится там же где бд, и оракл управляет HTTPшными сессиями, ну и то что это плскл. А не VB или Жава.

[ndp]

не полюблю, однозначно

и правильно: невозможно полюбить костыли, даже такие золотые и инкрустированные жемчугом как jQuery, но все-таки замастряченные для исправления изначальной убогости HTML-ного UI (даже в сравнении с голыми WinAPI-Control-ами).

я в апексе не спец, но то что мне нравится так это то что он крутится там же где бд, и оракл управляет HTTPшными сессиями, ну и то что это плскл. А не VB или Жава.

+100..500
Кстати, для того чтобы сделать веб-морду к ораклячей СУБД, вовсе необязательно ставить на нее апексовский фреймворк, достаточно установить опцию XMLDB и встроенный (начиная с версии 11.2) HTTP-сервер у вас уже под рукой и DBMS_EPG вам в руки для конфигурации DAD-ов...

[akh]

(HTTP REST или если ну очень надо то бинарная сериализация передаваемых данных

добавлю немного оффтопа:
У Кайта описан случай, когда команда жава-девелоперов, решили не заморачиваться с базой и сделали просто - сериализовывали все объекты и сохраняли их в BLOBе.
Прошло некоторе время и юзеры захотели строить репорты с помощью всяких тулзов типа репорт билдера, аксеса и т.д.
И теперь программеры спрашивают как можно это сделать.
Сам Кайт обозвал все это ведром с битами.

[Big Joe]

Кстати о казахстанских программистах: Почему в НИТ-е программисты ходят в белых халатах как доктора, кто ни будь знает?

[ndp]

- сериализовывали все объекты и сохраняли их в BLOBе.
...
И теперь программеры спрашивают как можно это сделать.
Сам Кайт обозвал все это ведром с битами.

я плАчу... классические разработчики классической трёхзвенки...

[kant]

не полюблю, однозначно
роль дба/дбд меня вполне устраивает.

Насильно мил не будешь

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

[ndp]

kant, Вы, как сторонник веб-технологии клиента, посоветуйте - как можно организовать локальное кеширование множества справочников, необходимых для работы клиентской стороны, чтобы не передавать их с сервера при каждом чихе UI.
А то моя основная претензия к веб-мордам состоит в бешенном network i/o overhead-е: чтобы просто отобразить юзеру 2 кб данных приходится упаковывать их в 10-20 кб тегов с атрибутами, а чтобы отобразить красиво и с клиентским интерактивом - так вообще за 100кб на страницу легко можно перевалить.
Клиент-сервер overhead-а не имеет ибо все данные передаются в виде struct и обладает гораздо более широкими возможностями кеширования справочников (согласитесь, что кол-во типовых пользовательских операций не идет ни в какое сравнение с кол-вом случаев необходимости обновления exe-файла на машине юзера).
Что посоветуете? Можно как-то побороть overhead веб-морд и отсутствие в них возможности кеширования справочников (по крайней мере штатной)?

[kant]

(HTTP REST или если ну очень надо то бинарная сериализация передаваемых данных

добавлю немного оффтопа:
У Кайта описан случай, когда команда жава-девелоперов, решили не заморачиваться с базой и сделали просто - сериализовывали все объекты и сохраняли их в BLOBе.
Прошло некоторе время и юзеры захотели строить репорты с помощью всяких тулзов типа репорт билдера, аксеса и т.д.
И теперь программеры спрашивают как можно это сделать.
Сам Кайт обозвал все это ведром с битами.

Если обмениваться оффтопом, то работал я на одном заводе, на котором почти вся информационная система была написана на фоксе, по требованию главного программиста внедрили MS SQL. Все хорошо, система частично мигрировала в MS SQL, но только некоторые запросы, которые формировали отчеты, работали по 20 минут и большинство сотрудников отдела АСУП умели написать то что надо на фоксе, но не понимали почему и что проиходит при оптимизации. Я только трудоустроился, работал с MS SQL. Работенка была не пыльная, поэтому я из любопытства подошел посмотреть что же вызывает вопли и танец с бубном одного разработчика.
Оказалось что таблицы которые содержат основных массу данных содержат МИЛЛИОНЫ записей. Поэтому все происходит так долго и вообще MS SQL какая-то непонятная и сложная штука. Пара тройка правильно расставленных индексов и запросы стали отрабатываться за секунды. Народ был поражен. Мировое признание и все такое.

PS. Так что умение решить прикладную задачу не освобождает от знания теории ). Что самое странное это то что в фоксе индексы применялись очень активно, и правильно. А вы говорите ведро с битами

У Кайта .....

Не могли бы вы дать примеры литературы/ресурсов, которые помогли бы отвечать на простые вопросы, которые специфичны именно для Oracla + хорошая справка по PL/SQL?