Новый Большой проект на FPC - стоит ли рискнуть?

[Odyssey]

Те, кто работают с ним плотно, уже пофиксили всё, что им мешало, и пишут свои приложения

[.wOvAN]

Вот свежий пример, когда даже если вы сами пофиксили или добавили какую то фунцию, которая мало того что позволит вам реализовать то что вам нужно, но и улучшит совместимость с кодом-дельфи, вы даже потратили своё время на создание патча и казалось бы все что нужно от комунити применить его. А вот ФИГ ВАМ. Тут мы всестречаемся с новым качеством "дружелюбных" сообществ, называемым "ПАЛКИ В КОЛЕСА". Ведь есть на свете люди которые думают, что вы тратите своё время на патч кода от нечего делать, и если им это НИНУЖНО то и другим от этого прока нет.

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

[Logo]

...
которая мало того что позволит вам реализовать то что вам нужно, но и улучшит совместимость с кодом-дельфи,
...

Вот именно то, чем недовольны пришедшие из Делфи. Те, кто увидели другие преимущества Lazarus/fpc, те влились в их идеологию, а те кто хочет иметь бесплатный Делфи, тот до бесконечности бутет жаловаться, что его фичи не принимают в багрепорте. Система кроссплатформенная и внесение всяких фич может отразиться на работе в других системах, поэтому и рассматривают долго.

[vada]

Доказано вами?

Нет не мной а разработчиками EJB.

В системе, которую я на данный момент поддерживаю 611 таблиц, специально даже посмотрел, не считая временных таблиц, которые создаются в схеме пользователя, вся логика целиком положена PostgreSQL и написана на PL/pgSQL и немного pl/java, там же хранятся пользовательские формы и настройки, отчеты. Так вот - при изменении каких либо бизнес процессов, я могу перестроить систему зачастую просто несколько раз кликнув мышью не перебегая к программированию вообще.
Так же занимаюсь Парус 8 - там та же история.

Да ради бога. Это просто две разные технологии. Два разных подхода. Ваша система работает, это хорошо. Теперь попробуйте перенести ее на Оракл, или BD2... или с Widows на Linux или MacOS. Рабатать не будет. EJB будет.
Дело в том что разработчики EJB не зря пошли по пути упрощения до нельзя работу с SQL серверами. Зачастую, при начале проекта тупо не хватает финансирования на покупку навороченного сервера, да и предсказать перспективы роста масштабирования системы зачастую не просто. Инвистиции могут оказаться зряшными. Потом отложенный инвистиции, как правило, эффективнее замороженных на года разработки. EJB разрабатывали не школьники а люди зубы стершие на разработках систем масштаба предприятия. Все не просто так. В систему могут быть интегрированны уже существующие базы данных на всяческих DBF или MySQL времен отсутствия тригеров и процедур. Да хоть из текстовых файлов логов *NIX системы.

В итоге получаем глючного тормоза типа Дебет Плюс. потому что то что будет работать быстро и правильно, например в Oracle не будет в PostgreSQL, а все потому, для начала нужно понимать особенности и различия разных СУБД - доведется поработать с многотерабайтной базой и с сотней - другой одновременно работающих пользователей, тогда вспомните эти слова

При чем тут Дебет Плюс? Я не понял. Это совсем не в тему.
И вовсе не потому что то что будут.... Работать будет быстро и надежно и на постгресе и на оракле и майскуле,... потому что от SQL сервера требуется только INSERT, UPDATE, SELECT. Вы просто не поняли ничего из моего поста. Бизнес-логика реализованная на JAVA не уступает по скорости работы SQL серверу. Кроме того, снимается излишняя нагрузка с SQL сервера, т.к. аппликейшн сервер может работать на другом физическом сервере, или на другом ядре процессора. Это еще один путь масштабирования.

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

Вы опять меня не поняли. Да бизнес-логика у всех разная, но прохождение документов ОДИНАКОВОЕ. Любой документ проходит по одному и тому же пути. Жизненный цикл у них у всех одинаковый. Например, в JAVA для документооборота написана специальная библиотека/технология EComerc прозывается. Охватывает ЛЮБУЮ бизнес-логику именно потому что одинаково все.

[ronin]

Теперь попробуйте перенести ее на Оракл, или BD2... или с Widows на Linux или MacOS. Рабатать не будет. EJB будет.

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

Зачастую, при начале проекта тупо не хватает финансирования на покупку навороченного сервера, да и предсказать перспективы роста масштабирования системы зачастую не просто

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

Работать будет быстро и надежно и на постгресе и на оракле и майскуле,... потому что от SQL сервера требуется только INSERT, UPDATE, SELECT

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

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

какой то извращённый способ реализации распределённых систем, ей богу

Да бизнес-логика у всех разная, но прохождение документов ОДИНАКОВОЕ. Любой документ проходит по одному и тому же пути. Жизненный цикл у них у всех одинаковый

это заявление меня вообще добило чёж мы тогда все тут пыжимся чёто разрабатываем если у всех всё одинаково и ребята из EJB уже давно всё придумали до нас... зачем кто то постоянно допиливает базовую конфигурацию 1С итд. и т.п. ? им делать нефик?

[Logo]

...
Теперь попробуйте перенести ее на Оракл, или BD2... или с Widows на Linux или MacOS. Рабатать не будет. EJB будет.
...

Вы сами то поняли, что написали???

Если построено на PostgreSQL, то зачем его переносить на Оракл, или DB2 ??? Шеф так захотел? Так пусть оплачивает конвертацию баз за свою дурь.

" ...или с Widows на Linux или MacOS..." - А вы о чем??? Вам же ясно человек написал, что вся логика написана на СЕРВЕРНОЙ СТОРОНЕ, но если даже Вы додумались на клиентской машине обрабатывать глобальные данные, то в чем проблема в отношении этих трех ОС, BSD подобных и Соляриса?

Понимаете, я не говорю, что Ява плоха, я не соглашаюсь, что FPC/Lazarus плох. На все есть своя ниша, но прежде чем убеждать других, - поработайте сначала сами на разных IDE и платформах, а по Ваших постах не видно, чтобы у Вас были серьезные реализации. Слишком уж примитивные ошибки допускаете.

В отношении Явы, то точно так же не хватает компонент, точно так же есть баги, точно так же нужно дописывать, так же долго висячка в багрепорте, но в итоге все это произведение на много тормознутее, чем реализация на FPC/Lazarus

[WAYFARER]

Да ради бога. Это просто две разные технологии. Два разных подхода. Ваша система работает, это хорошо. Теперь попробуйте перенести ее на Оракл, или BD2... или с Widows на Linux или MacOS. Рабатать не будет. EJB будет.

Зачем мне переносить её на Oracle или DB2?
А про Windows/Linux - сервер будет работать там, где работает PostgreSQL и Java. Что касается клиента, клиент написан так, что будет работать в Любой ОС, где будет работать FPC/Lazarus. Проще говоря, это всего лишь GUI для приложения, которое выполняется на стороне сервера. Причем абсолютно не требовательное к ресурсам.

При чем тут Дебет Плюс? Я не понял. Это совсем не в тему.

В тему, я назвал довольно распространенную систему уровня предприятия, написанную на Java и работающую с множеством различных СУБД, используя как вы выразились, только "SELECT, INSERT, UPDATE".

Работать будет быстро и надежно и на постгресе и на оракле и майскуле,... потому что от SQL сервера требуется только INSERT, UPDATE, SELECT.

Это справедливо, если в базе не используются индексы(которые как правило все равно будут, если есть первичные ключи), внешние ключи, ограничения, триггеры, про процедуры и функции молчу. Это справедливо лишь для простых запросов. Если у нас сложные запросы с множеством внешних объединений, то сказать, что выполняться они будут по разному в разных СУБД- ничего не сказать, хотя конечно, сервер вернет нужный нам результат. Более того, управление транзакциями в различных СУБД реализовано по разному. Обеспечение целостности данных, как правило, в таких случаях ложится на плечи разработчиков.
Более того, использование этих технологий предполагает, что программисту позволяется иметь лишь поверхностное представление о СУБД и даже не знать SQL.
Это плохо. И может принести некоторые проблемы. Например, первое что пришло в голову и достаточно распространенное, допустим, вы написали приложение, использовали скажем, тот же DB2 при разработке и отладке, внедряете заказчику у которого уже куплен Oracle(не заставлять же его покупать DB2, тем более, что наше приложение работает с любой СУБД). Вдруг в один прекрасный момент из таблицы начинает возвращаться пустой набор данных, хотя данные в ней есть. Программа посылает простейший запрос вида(запрос правильный):

Код: Выделить всё

SELECT f_id from tablename where ...

Вы в недоумении открываете SQLPlus и выполняете этот запрос - ошибок нет, возвращено 0 строк.
Вы полняете запрос вида:

Код: Выделить всё

SELECT * from tablename where ...

и о чудо - данные вернулись, а вы в еще большем удивлении.
Что будете делать? Искать специалиста по Oracle?
Ошибка весьма частая, и, собственно, простая.

Подведу итог: Использовать можно, но осторожно, и при условии что размер БД относительно небольшой.

Охватывает ЛЮБУЮ бизнес-логику именно потому что одинаково все.

Тут я промолчу. Эта тема обширна, и не относится к тематике данного топика. Хотя тема интересная, можно вынести её в отдельный топик и разобрать всем миром)))

какой то извращённый способ реализации распределённых систем, ей богу

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

Добавлено спустя 33 минуты 21 секунду:

но если даже Вы додумались на клиентской машине обрабатывать глобальные данные

у меня это при всем желании не реализуемо)) Все упрется в сеть и производительность клиента. Объемы данных большие))

[carrots]

Интересно что за всю тему никто не посмотрел в сторону c++. Я недавно разрабатывал серверную часть каталога ресурсов на c++, потом попробовал на фрипаскале (в качестве редактора использовал lazarus), понравилось, в результате все на фрипаскаль переписал, не смотря на то что для C не сравнимо больше готовых библиотек.

Конечно, что выбрать java или freepascal виднее непосредственно разработчику, хотя по моему для подобной задачи более подошел-бы python, а не java (если выбирать между python и java), там удобный подход к классам и объектам + его можно использовать совместимо с fpc.

[minoshi]

Да ради бога. Это просто две разные технологии. Два разных подхода. Ваша система работает, это хорошо. Теперь попробуйте перенести ее на Оракл, или BD2... или с Widows на Linux или MacOS. Рабатать не будет. EJB будет.

Да зачем куда-то переносить, брат?

Выбор базы для проекта - mysql, sqlite, firebird или тот же банальный BDE - это важнейший этап построения. Его нужно решать сразу и "на века". Если ошиблись - считай завалили дело, а это влекет дополнительные расходы.
И Вам уже об этом говорили.

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

[Logo]

....
Добавлено спустя 33 минуты 21 секунду:

но если даже Вы додумались на клиентской машине обрабатывать глобальные данные

у меня это при всем желании не реализуемо)) Все упрется в сеть и производительность клиента. Объемы данных большие))

Это же не к Вам, а к опоненту было адресовано.
УВас все правильно.

Добавлено спустя 2 минуты 41 секунду:

Интересно что за всю тему никто не посмотрел в сторону c++. Я недавно разрабатывал серверную часть каталога ресурсов на c++, потом попробовал на фрипаскале (в качестве редактора использовал lazarus), понравилось, в результате все на фрипаскаль переписал, не смотря на то что для C не сравнимо больше готовых библиотек.

Конечно, что выбрать java или freepascal виднее непосредственно разработчику, хотя по моему для подобной задачи более подошел-бы python, а не java (если выбирать между python и java), там удобный подход к классам и объектам + его можно использовать совместимо с fpc.

Eiffel Studio еще освой, скажешь как она, а то я ленивым стал уже

[stikriz]

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

Зачастую, при начале нового проекта - это первоочередной, первый, главный, основополагающий вопрос, без решения которого, дальнейшая разработка не имеет смысла. А чтобы вложения не были заморожены, все поставщики СУБД предоставляют бесплатные версии своих серверов. Когда-то давно, предоставляли почти бесплатные версии для разработчиков, а теперь, когда много OpenSource решений - бесплатные. Другое дело, когда проект ориентирован на мультисерверность. Но, это уже другая история, в которой издержек часто больше, чем явных преимуществ. Не одним инсертом апдейтом и делитом жив человек!

[vada]

WAYFARER писал(а):
В тему, я назвал довольно распространенную систему уровня предприятия, написанную на Java и работающую с множеством различных СУБД, используя как вы выразились, только "SELECT, INSERT, UPDATE".

Сарказм Ваш понятен. Только неувязочка получилась. Очень многие не видят разницы между JAVA и JavaScript.
Читаем на сайте Дебет Плюс

бизнес логика программы написана на языке JavaScript. За интерпритацию скрипта отвечает библиотека Rhino

Это не имеет никакого отношения к EJB и EComerc. Скорее это Ajax

Друзья мои! Я пытаюсь вам рассказать про технологии реализованные на JAVA. Всего-то. В коротких постах топика невозможно объять необъятное. Я уже где-то тут писал что книжка по EJB больше 600 страниц. И это совершенно не полное описание, так познакомиться. Есть еще несколько десятков фреймворков. Каждый - отдельный мир. И технологию придумал вовсе не я. Не понимаете почему я все время твержу про перенос на другие SQL и операционки? Так просто технология МАСШТАБА КОРПОРАЦИИ IBM. Это другой мир и законы там другие, нежели на складе ООО "Пупкин анд Ко".
Но некоторые ТОВАРИСЧИ почему-то воспринимают все как личное оскорбление. Достают из шанов свою драгоценность и начинают примерять... Да ради бога. Не хотите не надо. Мне-то пофиг.

[stikriz]

Друзья мои! Я пытаюсь вам рассказать про технологии реализованные на JAVA.

Было бы оно нам надо - были бы мы индусами, и сидели в другом форуме

Но некоторые ТОВАРИСЧИ почему-то воспринимают все как личное оскорбление.

Я уже где-то тут писал что книжка по EJB больше 600 страниц.

Это другой мир и законы там другие, нежели на складе ООО "Пупкин анд Ко".

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

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

[WAYFARER]

Сарказм Ваш понятен. Только неувязочка получилась. Очень многие не видят разницы между JAVA и JavaScript.
Читаем на сайте Дебет Плюс

Именно. Логика написана на JavaScript - ядро на Java. Eclipse RCP:)
Кстати, никакого сарказма.

Друзья мои! Я пытаюсь вам рассказать про технологии реализованные на JAVA. Всего-то. В коротких постах топика невозможно объять необъятное. Я уже где-то тут писал что книжка по EJB больше 600 страниц. И это совершенно не полное описание, так познакомиться. Есть еще несколько десятков фреймворков. Каждый - отдельный мир. И технологию придумал вовсе не я. Не понимаете почему я все время твержу про перенос на другие SQL и операционки? Так просто технология МАСШТАБА КОРПОРАЦИИ IBM. Это другой мир и законы там другие, нежели на складе ООО "Пупкин анд Ко".

Никто не говорит что EJB это плохо. Я сам, например, большой любитель EJB и JSP. Мы все с вами спорили не о инструменте, а о подходе к реализации.
Работать доводилось и в мире склада ООО "Пупкин анд Ко", и крупных предприятий с десятками филиалов, в том числе и за пределами РФ, с единой БД но разной законодательной базой. Участвовал и в маленьких, и крупных проектах, и в качестве менеджера проектов, и в качестве программиста, были проекты и удачными, и с треском и грохотом провалившимися. Сужу исходя из опыта, что успел получить за свою короткую жизнь))
Сейчас работаю в нашем оборонно-промышленном комплексе, и перед глазами у меня множество примеров того как работать нельзя(аналитические отчеты, которые формируются часами, потому, что об оптимизации никто не думает, или не думает вообще, не полное понимание целей внедрения АС, что сказывается на эффективности и тормозит взаимодействие между отделами и подразделениями, а должно быть наоборот(подход типа: "Мы делаем это не для того что бы было удобно, а что бы систематизировать и упорядочить данные")) и как работать можно.

Но некоторые ТОВАРИСЧИ почему-то воспринимают все как личное оскорбление. Достают из шанов свою драгоценность и начинают примерять... Да ради бога. Не хотите не надо. Мне-то пофиг.

Разве? В спорах рождается истина.

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

Замечу, что не просто программера, а в зависимости от отрасли, еще и технаря, экономиста, бухгалтера, кадровика, маркетолога, etc

[alexs]

МАСШТАБА КОРПОРАЦИИ IBM

Уважаемый - не надо прогибаться перед большими компаниями. В 99.99% они вам ПРОПИХИВАЮТ новые технологии, им надо на них деньги заработать.
И не факт, что эти технологии вам нужны.
Конечный софт писать нам с вами, и обычные юзеры спросят у нас - а почему софт так глючит? или почему он так медленно работае?
И что вы им ответите? - что это последнии тенденции в мировой моде написания ПО? Так вас сразу же пошлют...