Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий. S>Возникает вопрос, какие средства разработки использовать?
Сейчас я выскажу крамольную мысль и мне понаставят кучу минусов.
Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность.
Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......
Приобретая систему вы получаете минимальную гарантию, что ее уже оттестировали на других предприятиях и фирмах, что она уже прошла хоть какую-то обкатку. Кроме того, вы получаете гарантию, что эту систему будут сопровождать, поддерживать и расширять...
И не считайте сразу, что это дорого. А лучше прикиньте, сколько вам будет стоить собственноручная разработка, плюс тестирование, плюс потери в бизнесе за то время, пока вы пишете эту систему. Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства...
Опыт подсказывает, что после таких подсчетов корпорации приходят к выводу, что купить готовое дешевле, чем разработать что-то свое.
Здравствуйте, DemAS, Вы писали:
DAS>Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......
Прикол в том что ни одна из перечисленных тобой систем, ничем не управляет
это просто пассивные отчеты. Так что эти система туфта, и по функционанальности(основной)
такие же как и 1С, за исключением разных архитектур, реализаций и фич, которые
в общем то бизнесу кардинально ну никак не помогут. А бизнесу поможет только УПРАВЛЕНИЕ
так вот не одна из систем не дает этого, только данные для этого
а что толку их внедрять на предприятиях когда там сидят тупые управленцы, ничего не изменится,
ну разве что какой отчет покрасивше.
Так что даже написанная на фокспро простая управляющая система,
сделает для предприятия гораздо больше, чем разпиаренная аксапта и ко.
Здравствуйте, Slick, Вы писали:
S>Но вместе с тем это более гибкое
Гибкость гибкости рознь. Кое в чем менеджед платформы куда гибче плюсов.
S>и более скоростное решение. Так что такой аргумент меня не убеждает.
Да ради бога. Я уже давно убедился что определенным людям доказать что в этом мире есть что то помимо С++ практически невозможно.
S> Фактически вы утверждаете что С++ не годится потому, что он сложен.
Ну такого я пока не утверждал, но впрочем это тоже причина не использовать С++.
S>Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка.
Не соглашусь. Если что то можно сделать автоматически с приемлемыми потерями то это нужно делать автоматически. Это, так сказать, азы дизайна сложных систем. Иначе с определенного момента ты просто утонешь в деталях и заморочках.
S>Давайте исходить из того, что над системой работают высокоуровневые программисты S>и сложность языка не имеет значения.
Высокоуровневые в плане профессионализма? Как правило реальная ситуация прямо противоположная.
S>Вообще надо сказать, что начиная с определенного уровня сложности задач, такой критерий как сложность языка совершенно теряется перед сложностью алгоритма и структур данных.
Я бы так не сказал. Тем более что сложность ERP систем как правило не в алгоритмах, а в структуре и количестве.
S> Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%.
Аргументы?
S>А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.
Это часто встречающаяся ошибка. Во первых — говорить о языках в случае джавы и особенно дотнета не имеет смысла, надо говорить о платформах. Во вторых — мощность и гибкость средства разработки должна быть ровно такой какая нужна для конкретного применения. И кроме этого фактора существует масса других — например очень часто во главу угла при создании ERP ставят скорость разработки и надежность полученного кода, а мощность языка обычно этому помеха.
Здравствуйте, DemAS, Вы писали:
DAS> Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность. DAS> Систем сейчас куча и есть из чего выбрать, например — Axapta, Attain, SAP, Baan, Oracle Application, MFG, Галактика, Парус......
Обычно редко какая-либо из них сможет удовлетворить все потребности предприятия, особенно с динамично развивающимся бизнесом. К тому же такие системы тоже требуют настройки и сопровождения, и очень часто не меньшей. Отдел IT в 50 человек на предприятиях где используется, наприр, R3, обычное дело. Моё ИМХО — готовые системы использовать надо, но только как часть системы предприятия. Такие системы не должны быть основой системы предприятия и должны в неё легко интегрироваться. В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Slick, Вы писали:
S>> Но это уже конкретика. А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.
K>Мощью языка, красотой кода, невероятной оптимизацией и прочей распальцовкой можно заниматься дома, лабая из интереса, любопытства, комплексов. K>А в реальной работе в условиях ограниченных ресурсов надо выбрать наилучшее соотношение затрат (ИМХО, выбор языков и технологий на них сильно влияет) к качеству результата. А то ведь можно и в лужу на глазах изумленной публики
Мощность языка, крастота кода, оптимизация и прочая распальцовка — это факторы непосредственно определяющие качество результата. Эти факторы не являются романтикой, они определяют стиль программирования подход к решению задач в целом. Самоутвеждение здесь не причем, поверь.
Конечно, пока ты лабаешь порносайты из шести статических страниц и одного голосования, тебе этого не осознать. Твой стиль — дешево и сердито, и в этом нет ничего плохого. Просто сложность реализации должна быть адекватна ценности решенной задачи.
Но когда(если) ты выберешься из таких задач, если эффективность и надежность а не скорость разработки, будут основными требованиями к твоим продуктам, ты поймешь, что это не понты и не пустой звук. Тогда ты сам будешь выбирать то что качественее а не то что легче и быстрее. Иначе, не будешь успевать просыхать от падений в лужу на глазах изумленной публики.
Indeed, the study showed that a well-written Java program could equal or exceed the efficiency of an average-quality C/C++ program.
... << RSDN@Home 1.1 beta 1 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Dym On, Вы писали:
DO>R3 — в российских условиях внедрить в полном объеме нельзя, насколько я знаю, она нигде полностью не внедрена.
ОК. Еще раз — что такое успешное и полное внедрение ERP системы.
Могу предложить два подхода (хотя на самом деле их бесконечное множество).
Первый — все акты закрыты и подписаны. Все модули системы установлены и пользователи аккуратно вводят в систему всю необходимую информацию. Как внедренец, так и заказчик дружно кричат, что мы закончили успешно это внедрение. Это успешное внедрение ? На первый взгляд вроде как да — но, а что если попробовать прикинуть, какую прибыль дало это внедрение ? Насколько повысилась управляемость предпрития ? Насколько прозрачны стали бизнес-процессы ? В проинципе, может оказаться, что внедрение оказалось даже убыточным, так как зарплата персоналу, который забивает туда данные превышает прибыль от этой системы....
Вторая точка зрения. Компания начала внедрять систему. Пусть у нее пошло не все гладко, пусть она внедила только один модуль из 100, но что если этот один модуль позволил этой компании так оптимизировать часть своих бизнес-процессов, что ее доход увеличился вдвое ? Это успешное внедрение... ?
Перед началом каждого проекта, компания должна решить, что является ЦЕЛЬЮ этого проекта. Целью проектов никогда не является внедрение системы — это не самоцель, а всего лишь средство. Целью может быть увеличение прибыльности, привлекательности для инвесторов и т.д. И по окончании проекта надо смотреть была ли достигнута поставленная цель или нет и уже поэтому судить об успехе проекта.
И напоследок небольшая реальная история. Одна производственная фирма решила внедрять у себя ERP, выбрала продукт, наняла консалтеров..... ...в общем через полтора года работы консалтеров не был внедрен не дин модуль , но консалтеры внедряя систему вскрыли столько проблем в управлении предприятием, что директор был вынужден сменить половину руководителей средего звена, которых больше интересовали собственные интересы, кол-во позиций производства сократилось вдвое, за счет исключения убыточных продуктов, было полностью модернизированно проив. оборудование, а следовательно и увеличена произв. мощность завода... и т.д. Генеральный счастлив — наконец-то он стал понимать, что происходит у него на заводе, наконец то он получил контроль над процессами... ..а то что закупленный софт пылится — так он всего лишь средство.
Здравствуйте, Аноним, Вы писали:
ГВ>>Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше. А>Просветите пожалуйста, что входит в понятие "системного ядра ERP". И чем ядро отличается от бизнесс-логики. И что на чем пишется.
Само по себе это понятие определяется в зависимости от того кому как приспичит и кто что продвигает. Вот моё мнение, исходя из предпочитаемой мной "сервероцентрической" архитектуры:
Ядро Поддержка ЖЦ "прикладных" объектов;
Поддержка взаимодействия с пользователем (трансформация отображения — в том числе);
Объектно-реляционное отображение (как минимум — CRUD + транзакции + кеширование);
Поддержка работы в кластере;
Управление доступом;
Управление памятью;
Управление локализацией;
Контроль версий прикладного софта;
Управление deployment-ом.
Как дополнение — административные "фенечки" и контрольные механизмы: всякие счётчики, сбор статистики, run-time оптимизация и т.п.
Драйверы, подключаемые к ядру Адаптеры компонентных инфраструктур (более низкий уровень — сетевые драйверы);
Драйверы хранилищ данных;
Драйверы тонких клиентов (Web-servers-API, собственный клиент);
Драйверы генерации отчётов (не забываем, что отчёты — частный случай отображения).
Дополнительно — адаптеры взаимодействия с другими программами.
Прикладная логика — пишется на том же языке, что и ядро по некоторым соглашениям (наследование от... и т.п.) + библиотеки связи с ядром. Как вариант — использование чего-то вроде VBS для прикладной логики.
В идеале — код прикладной логики полностью освобождается от "системных" аспектов — только собственно прикланая логика + декларативные элементы описания особенностей ЖЦ, persistability, отображения пользователю и т.п. (2AVK: да-да, а-ля атрибуты .Net )
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, alexm1202, Вы писали:
A>Если не секрет, то почему Sybase, а не DB2, которая в сочетании с AIX и WebSphere выглядела бы логично?
Я тоже это спросил
Оказалось, что это политический вопрос. Предприятие, для которого мы пишем, также имеет договора с IBM и Sybase, так что они там что-то делят (деньги наверно )
Здравствуйте, DemAS, Вы писали:
DAS> Опыт подсказывает, что после таких подсчетов корпорации приходят к выводу, что купить готовое дешевле, чем разработать что-то свое.
Так-то оно так, только ситуации разные бывают и пожелания заказчиков — тоже.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Slick, Вы писали: S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
Уже ведется аналогичный похожий проектhttp://www.vtools.ru/2c.htm, http://www.vtools.ru/2c_faq.htm), одной из целей которого является создание подобной системы.
Концепция проекта:
Разработка делится на уровни:
Уровень 0 — ядро системы, которое включает в себя очень быстрое ядро исполняемой системы (компилятор + интерпретатор байт-кода), примитивные объекты ("Массив", "Таблица", "Список значений" и пр.), редактор модулей и диалогов. Ядро уровня 0 пишется с использованием языка "C++".
Уровень 1 — микрообъекты для работы с БД, например: константы, справочники, документы и пр. Такие объекты, в отличие от 1С, изначально в системе не определены. Их логика должна задаваться на внутреннем языке, на котором пишется две части: поведение объекта в конфигураторе и объектная модель в режиме Предприятия (в т.ч. взаимодействие с БД через системный объект "ЗапросSQL"):
· Состав и поведения микрообъектов в Конфигураторе в дереве метаданных задается в "Модуле среды конфигурирования" на встроенном языке.
· Объектная модель (набор атрибутов и методов) задается в "Модуле среды исполнения" также на встроенном языке.
Уровень 2 — создание прикладных объектов (таких как виды документов, например, "Приходная накладная", "Расходная накладная" и пр.) и описание бизнес — логики. Т.е. обычное конфигурирование в понятии 1С программиста. После окончания выполнения работ уровня 1, будет создан конвертор конфигураций из 1С
Проект открытый и на текущий момент уже есть первые пробные версии программы (поддержка project@vtools.ru)
Здравствуйте, Slick, Вы писали:
Как раз занимаюсь разработкой ERP.
Хочу указать некие точки, чтобы вам не наступить на мои грабли.
На чем будет написана система не столь важно Java или .NET. мы пишем под .NET.
У вас сразу образуется ряд задач требующих динамики, как при формировании классов, так и при создании метоописаний/ну и интерфейсов.
Поэтому в качестве 2ого уровня приложения: советую взять любой из существующих интерпретаторов — Perl/Python/Smalltalk.
Дальше обратитесь либо к RPC и т.д. или к SOAP — как мы
На чем вы будете писать клиентскую часть не важно. На чем удобнее.
Конечно, вы можете написать и свой интерпретатор... и встроить его не только в промежуточный слой — но и клиентскую часть. Мы выбрали Scripting Host + VBA от MS. т.е. велосипедов изобретать не стали.
Все что я написал, было рождено в муках и довольно хорошо обоснованно.
Хотя не зная вашей предметной области мне трудно что либо советовать. Наверное наше решение не слишком "быстрое".. даже при медленном/Application Server — слое, ERP способна решать реалтаймовые задачи. Все зависит от оборудования.
В любом случае удачи вам!
Если возникнут вопросы — готов сотрудничать
... << RSDN@Home 1.1 beta 1 >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, Slick, Вы писали:
AVK>>Идеальных программ не бывает. Как не бывает идеальных разработчков.
S>Вот, о профессиональном уровне программистов я и говорил. Нечего на язык пенять, коли руки кривы.
Батенька, программисты есть именно такие какие они есть. Если для разработки системы нужна команда состоящая целиком из очень квалифицированных профессионалов, то стоимость такой системы возрастет в разы, вероятность успешного завершения снизиться и вобще непонятно откуда брать такую команду. Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.
AVK>>Да оне и без сборщиков мусора ленятся следить за памятью.
S>Во всяком случае в плюсы не ограничивают возможности программиста в этом направлении.
Ну да, вот только GC там реализовать нормальный так и не удалось.
S>Утечки в Java приложениях можно только глубокомысленно созерцать, размышляя о бренности бытия.
Ни разу с таким не сталкивался. Течь могут только неуправляемые ресурсы.
S>А в плюсах у тебя полная свобода действий. Твои утечки это твои проблемы и ты можешь их ликвидировать.
Ага, при помощи пары месяцев траха.
AVK>>Какие утечки? И почему они неприемлемы?
S>Те утечки кторые имеют место из-за некорректной работы сборщика мусора.
Мда, ни разу о таком не слышал и сам не сталкивался. Вон уже 1.4 вышел, а уж багфиксов было несчетно и что то последнеи лет пять не помню чтобы исправляли ошибки в GC приводящие к утечкам. Видимо никто кроме тебя об этих утечках не знает.
AVK>>Зачем говорить о каких то гипотетическизх ситуациях, если скорость разработки была и будет одним из самых важных факторов?
S>Ну далеко не всегда.
Так практически всегда.
S>Думаю что при разработке внутренних систем автоматизации для NASA и нью-йорркской фондовой биржи,
Здравствуйте, kavlad, Вы писали:
IT>>Типа того. Стингреевскую библиотеку совсем сгноили, на .NET забили, разработчики разбегаются, менеджмент докладывает инвесторам о новых победах.
K>А откуда такая информация? Релизы новые аккуратно появляются
А в релизах что-нибудь новое появляется?
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, S-SH, Вы писали:
SS>Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней SS>фирмы есть не самая удачная строка бюджета.
Тут приходится выбирать между преимуществами, если они есть , самопальной системы и "стандартной".
А зависимость будет в обоих случаях, и неизвестно, где она будет сильнее.
Здравствуйте, AndrewVK, Вы писали:
S>>Чем обосновывается решение применять .NET или Java в ядре системы?
AVK>Надежнее код, нет утечек памяти, невозможна случайная порча памяти.
Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java.
Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка. Давайте исходить из того, что над системой работают высокоуровневые программисты и сложность языка не имеет значения.
В такой ситуации какие преимущества у Java и С# перед С++?
Вообще надо сказать, что начиная с определенного уровня сложности задач, такой критерий как сложность языка совершенно теряется перед сложностью алгоритма и структур данных. И в такой ситуации необходимо делать выбор, основываясь на том, какие сопутствующие технологии существуют для того или иного языка. Например, совершенно логичен ваш пример относительно джаваы и сопутствующей ей технологиии EJB. Вот это я принимаю, и это действительно серьезный аргумент. Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%. Остальное маркетинговые фишки, типа того, как круты и безальтернативны наши Entity Beans, и у MS ничего подобного нет. Но это уже конкретика. А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.
Здравствуйте, Slick, Вы писали:
S> Но это уже конкретика. А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.
Мощью языка, красотой кода, невероятной оптимизацией и прочей распальцовкой можно заниматься дома, лабая из интереса, любопытства, комплексов.
А в реальной работе в условиях ограниченных ресурсов надо выбрать наилучшее соотношение затрат (ИМХО, выбор языков и технологий на них сильно влияет) к качеству результата. А то ведь можно и в лужу на глазах изумленной публики
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Slick, Вы писали:
S>>Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.
G>Так это они и есть — "тяжеловесные и медлительные контейнеры Java", "отсутствие контроля памяти разработчиком"...
1. java.collection проигрывает STL по скорости, гибкости и предоставляемым возможностям.
2. Отсутствие контроля памяти в Java тем не менее приводит к написанию "текущих" приложений, порою изрядно текущих. Причина — качество сборщика мусора. Если тебе нужно идеальное в смысле утечек приложение, иного способа кроме самоконтроля — не найдешь.
Здравствуйте, Slick, Вы писали: S>Ну далеко не всегда. Думаю что при разработке внутренних систем автоматизации для NASA и нью-йорркской фондовой биржи, все же отказоустойчивость, скорость работы и надеженость будут поважнее времени разработки.
По случайности видел я системы в NASA. Ну это даже обсуждать не серьезно!
50% кода на ASM и зашита в ПЗУ — системы рельного времени. Встречаются также модули высокого уровня на Java.
Только пример выбран не верно! Разработка такой системы стоит милиарды. Ты в жизни потом ее не окупишь — это очень специфичные предметные области.
... << RSDN@Home 1.1 beta 1 >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.
ГВ>>Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.
AVK>Но что же получается — программисты на той же джаве в массе своей менее криворуки? Как еще можно объяснить к примеру тот факт что качество джавовских библиотек в среднем заметно выше тех же Дельфовых компонент или плюсовых либ?
Ну так тем же самым — массовостью, "массой", которая... stl, например, очень неплохая библиотека. А про Java где-то бегало исследование из серии "Java vs C++", так там пришли к выводу, что Java обеспечивает меньший разброс качества, чем C++, т.е., у неё "нижняя планка" выше, чем у C++, но и "верхняя" — ниже. Сейчас быстро не найду, но если будешь настаивать, то раскопаю вечером.
AVK>Я все таки считаю себя специалистом и тем не менее пользоваться GC мне удобнее, и не потому что я без него лики пложу, а потому что во многих случаях это позволяет писать более красивые и простые алгоритмы. Я могу выделить кусок памяти внутри какой то функции и не заботиться больше о том кому этот кусок грохать, даже если его использует кто то из другого процесса.
Ну, хозяин — барин.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, alexm1202, Вы писали:
A>Здравствуйте, Геннадий Васильев, Вы писали:
A>>>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.
ГВ>>Ключ — "необязательный".
A>Так в C++ много необязательных фич. Однако каждая из них была добавлена, исходя из тех соображений, что она существенно облегчит жизнь разработчикам в том или ином классе задач (не обязательно всем, кому-то например RTTI не нужен, а большинство прекрасно обходятся без МН). И, похоже, Страуструп считает что GC тоже облегчил бы жизнь достаточно большому числу пользователей С++, чтобы его добавить в язык. Это я к тому что со словами "не нужен (почти)" ты, имхо, погорячился
Здравствуйте, Mishka, Вы писали:
M>А теперь раскажу о том что планируем делать на будущее, поскольку понадобилось произвести действительно большую систему для нескольких тысяч пользователей. Всё дело будет бегать под IBM AIX и WebSphere. Будем пользовать Java, IE6, Kodo JDO, Tangosol (для распеределённых кэшей) и Sybase как БД.
Если не секрет, то почему Sybase, а не DB2, которая в сочетании с AIX и WebSphere выглядела бы логично?
Здравствуйте, vtools, V>Проект открытый и на текущий момент уже есть первые пробные версии программы (поддержка project@vtools.ru)
http://sourceforge.net/projects/myenterprise/
Ссылка не на ваш проект случайно? Что-то там нет ни активности ни пробных версий программы.
Заявление о намерениях (которые на http://www.vtools.ru/2c.htm почемуто называются — Концепция!?)
очень неплохи.
Однако вызывает сомнение что данное начинание вообще сможет дойти хотя бы до релиза.
|К проекту предъявляются следующие требования:
|· Совместимость с 1С.
Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
Возникает вопрос, какие средства разработки использовать?
Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.
Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.
— Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
— Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
— Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
— Вопрос шифрования данных циркулирующих в системе.
Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
ERP? Значит много формочек, окошек и т.д. и т.п.. Лучшие варианты для клиента, по моему, Builder и Delphi.
S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
Вообще, лучше писать на том, что привычнее для программистов. Но если до этого Java не сильно использовалась, то лучше сразу переходить на .NET, по крайней мере, для Винды он роднее будет. С#, C++, managed С++, большой разницы в производительности, как показывают тесты, нет. Опять же, что роднее.
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
Тоже большой разницы нет, но если идти по пути Microsof, то надо выбирать MS SQL Server.
S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
Web — это очень хорошо и очень удобно, но если нужен действительно очень мощный пользовательский интерфейс, то реализовать его для Web будет гораздо сложнее. И опять же, ориентация на Web означает, что на сервер ляжет очень большая нагрузка, так как те функции, которые могло выполнить GUI-приложение, придётся перенести на сервер, кроме простенькой валидации данных.
S>- Вопрос шифрования данных циркулирующих в системе.
Существует очень много готовых систем шифрования, причём, для каждой платформы, это не самая большая проблема.
DAS> Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства...
Не в первый раз слышу и никак не могу допереть — зачем в системе планирования ресурсов предприятияотслеживать изменениия закнодательства? Для бухгалтерии понятно, но для ERP или CRM зачем?
Здравствуйте, PeterZT, Вы писали:
DAS>> Учтите также, что вам придется самим сопровождать систему и отслеживать все изменения законодательства... PZT>Не в первый раз слышу и никак не могу допереть — зачем в системе планирования ресурсов предприятияотслеживать изменениия закнодательства? Для бухгалтерии понятно, но для ERP или CRM зачем?
ERP как правило включает в себя и бухгалтерию и оперативный учет, кои от законодательства зависят. А вот CRM кстати обычно не включают в понятие ERP, хотя тесно с ней интегрируют, поскольку это внешний мир, а не ресурсы предприятия.
Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
Мммм... хотя бы порядковые количества узлов?
S>Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
А конкретнее можно? То, что такие системы, как правило, 24x7 — понятно.
S>Возникает вопрос, какие средства разработки использовать?
S>Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.
S>Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.
Сервере или серверах?
S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
Я сам бы предпочёл DB2. Но здесь зависит от требований к системе и бюджета. Хотя, ИМХО, самое лучшее решение — отвязаться от конкретной БД.
S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
На самом деле нет противоречия между клиентом с GUI и Web-клиентом, поскольку и тот и другой могут загружать конфигурацию интерфейса пользователя и осуществлять взаимодействие с сервером, просто отображать UI они будут по-разному. Иными словами — закладывайся на то, что клиент: а) не определён , б) не содержит прикладной логики — вся логика приходит с сервера.
S>- Вопрос шифрования данных циркулирующих в системе.
Внутренний трафик шифруется?
S>Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.
Сроки? Сколько народу задействовано? Какова их квалификация? Хорошо ли представляете, что хотите получить в итоге?
Ну, пока что вот так вот.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
Копают давно, но похоже не долго им осталось.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PeterZT, Вы писали:
AVK>>ERP как правило включает в себя и бухгалтерию и оперативный учет, кои от законодательства зависят. PZT>Оперативный учет как зависит ?
Здравствуйте, AndrewVK, Вы писали: PZT>>Оперативный учет как зависит ? AVK>Ну например НСП.
Понятно. Но все же не так сильно, как бухгалтерия, т.е. оперативный учет можно держать в соответствии с законом намного меньшими усилиями, чем бухгалтерию.
Здравствуйте, IT, Вы писали:
ГВ>>Посмотри, что-то есть у RogueWave. Они давно в этом направлении копают. Как раз — для поддержки скоростных Enterprise Applications. В России, вроде бы, АйТи у них генеральный дистрибутор или типа того (не сочтите за рекламу).
IT>Копают давно, но похоже не долго им осталось.
С чего ты так решил?
На NASDAQ они сейчас растут существенно быстрее, чем Microsoft. (RWAV, MSFT)
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
AVK>>Чего, докопались до трупа?
IT>Типа того. Стингреевскую библиотеку совсем сгноили, на .NET забили, разработчики разбегаются, менеджмент докладывает инвесторам о новых победах.
А откуда такая информация? Релизы новые аккуратно появляются
Здравствуйте, DemAS, Вы писали:
DAS> Я считаю, что если вы действительно разрабатываете крупную систему предназначенную для больших объемов данныых и т.д. и т.п., то не стоит ее разрабатывать. Надо выбрать и купить что-то готовое максимально приближенное к вам, к вашим бизнес процессам. А потом доработать выбранное с учетом вашей конкретной специфики, тем более, что все современные ERP системы оставляют такую возможность.
Вообще-то когда речь идет о действительно крупной системе управления большим предприятием такой подход неприемлем.
Уже не раз в этом убеждался.
Все эти готовые усредненыые решения подходят для не очень больших предриятий с типичными бизнес-процессами. В крупных предприятиях, в промышленности внутренние процессы настолько сложны и специфичны что адаптировать под них что-то существующее — себе дороже.
А если говорить про конкретный случай, тот здесь это даже не обсуждается. Решение о собственной разработке уже принято и варианты с использованием существующих ERP не рассматриваются. Решаются вопросы планирования, проектирования временной оценки и необходимых средств разработки.
Буду благодарен за помощь в решении именно этих вопросов.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Копают давно, но похоже не долго им осталось.
ГВ>С чего ты так решил?
ГВ>На NASDAQ они сейчас растут существенно быстрее, чем Microsoft. (RWAV, MSFT)
Если у тебя есть их акции, то срочно беги продавай
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
S>Вообще-то когда речь идет о действительно крупной системе управления большим предприятием такой подход неприемлем. S>Уже не раз в этом убеждался.
S>Все эти готовые усредненыые решения подходят для не очень больших предриятий с типичными бизнес-процессами. В крупных предприятиях, в промышленности внутренние процессы настолько сложны и специфичны что адаптировать под них что-то существующее — себе дороже.
Да, а такие компании как РосТлеком, Ленсвязь, Toyota, Энергомаш, Перекресток, Исток, Волгоградский Аллюминий, MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей, Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный комбинат, Первоуральский новотрубный завод, РУССО, Ригла, Техносила, Тинькофф — это я говорю про тех людей, которые выбрали Axapt'у. Про другие системы не буду рассказывать, так как не очень с ними знаком. Это по твоему мелкие компании ?
S>А если говорить про конкретный случай, тот здесь это даже не обсуждается. Решение о собственной разработке уже принято и варианты с использованием существующих ERP не рассматриваются. Решаются вопросы планирования, проектирования временной оценки и необходимых средств разработки. S>Буду благодарен за помощь в решении именно этих вопросов.
А вот тут как раз обсуждать то и нечего . Либо ты можешь это делать, либо нет — обсуждениями здесь дело не поправишь.
IT> В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.
Как правило все современные ERP имеют средства разработки, позволяющие модифицировать их под себя. А отстегивать консам и программерам на разработку или обучить своих людей — здесь каждый решает для себя сам...
> Да, а такие компании как РосТлеком, Ленсвязь, Toyota, > Энергомаш, Перекресток, Исток, Волгоградский Аллюминий, > MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей, > Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный > комбинат, Первоуральский новотрубный завод, РУССО, Ригла, > Техносила, Тинькофф — это я говорю про тех людей, которые > выбрали Axapt'у. Про другие системы не буду рассказывать, > так как не очень с ними знаком. Это по твоему мелкие компании ?
Ростелеком будет работать на том, что для него выберет Связьинвест Или
выбрал.
Такие конторы, как Перекресток, Исток, ДельтаСпорт, Техносила и подобные — суть
торговые фирмы, с известными бизнес-процессами. На Энергомаше уже давно
внедряется R/3. Toyota — это где? В Москве?
Но любое количество подобных примеров не доказывает правильности выбора. Оно
лишь доказывает правильность маркетинга конкретной системы.
SS>Ростелеком будет работать на том, что для него выберет Связьинвест Или SS>выбрал.
Ростелеком будет работать на Axapta. Он уже на нем работает, и будет на нем работать, так как софт уже куплен, работает и люди довольно. И нокто не пойдет на то, чтобы выбросить деньги потраченные на внедрение.
Да Связьинвест выбрал Oracle Application (если это конечно можно так назвать ). Но если ты внимательно следил за их пресс-релизами, то ты знаешь, что они будут внедрять его только там, где еще не внедрены другие системы.
Более того, Связьинвест не будет работать на том, что выберет.. ..потому, что выбора там, как такового не было. Не буду выносить эту историю в открытый форум, но те кто следили за этими событиями сами все понимают — информации наружу вышло достаточно, для того чтобы каждый смог сделать соответствующие выводы...
SS>Такие конторы, как Перекресток, Исток, ДельтаСпорт, Техносила и подобные — суть SS>торговые фирмы, с известными бизнес-процессами.
Хм.. А ты хочешь писать не зная бизнес-процессов...
SS> На Энергомаше уже давно SS>внедряется R/3.
Лично я могу назвать три Энергомаша. Ты про какой говоришь ?
SS>Toyota — это где? В Москве?
Да.
SS>Но любое количество подобных примеров не доказывает правильности выбора. Оно SS>лишь доказывает правильность маркетинга конкретной системы.
Просто у меня есть опят, что такая-то такая-то компания колбасилась пять лет пытаясь разработать что-то свое,но поняла, что лучше довериться профессионалам ..... Блин, да что я буду рассказывать — прочитай любой пресс релиз о внедрении....
p.s. На самом деле это философский вопрос и каждый его решает сам. Что бы не выбрали — внедрять готовое или писать свое — все равно, опыт подсказывает, что поставленные цели редко становятся достигнутыми — речь идет лишь о приближении к мечте...
> SS>Ростелеком будет работать на том, что для него выберет Связьинвест > SS>Или выбрал. > > Ростелеком будет работать на Axapta. Он уже на нем работает, > и будет на нем работать, так как софт уже куплен, работает > и люди довольно. И нокто не пойдет на то, чтобы выбросить > деньги потраченные на внедрение.
К примеру, ежели я доволен своим Delphi 3, и деньги на софт потрачены, а
начальник мне говорит, что надо переходить на VS.Net, мне его не слушаться? Так
что это все неоднозначно.
> SS>Такие конторы, как Перекресток, Исток, ДельтаСпорт, > SS>Техносила и подобные — суть торговые фирмы, > SS>с известными бизнес-процессами. > Хм.. А ты хочешь писать не зная бизнес-процессов...
Я?!! Они фирме-разработчику известны. А автор ветки имеет в виду нетиповые
бизнес-процессы, о которых разработчик и не догадывался.
> SS> На Энергомаше уже давно > SS>внедряется R/3. > > Лично я могу назвать три Энергомаша. Ты про какой говоришь ?
Так, начинается... Есть разница? Ты назвал фирму Энергомаш. Я тоже. Пусть это
будут две разные фирмы с похожим названием. И что это меняет? Вроде речь не о
том, какую систему покупать, а о том стоит ли покупать.
> SS>Toyota — это где? В Москве? > Да.
Вроде речь про крупные фирмы была. А не про их региональные представительства.
> Блин, да что я буду рассказывать — прочитай любой пресс релиз > о внедрении....
Примерно так — "мы внедряли, мы внедряли, наши пальчики устали"
К сожалению, "ошибкой было бы думать", что внедрение является одноразовой
задачей.
Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней
фирмы есть не самая удачная строка бюджета.
Здравствуйте, S-SH, Вы писали:
SS>Это — длительный, бесконечный процесс. Зависимость в этом процессе от сторонней SS>фирмы есть не самая удачная строка бюджета.
Я раньше работал со стороны заказчика. То есть на предприятии, которая приобрела Axapt'у. Предприятие называется Карачаровский Механический Завод (тут скрывать нечего). Уже в самом начале проекта было ясно, что на пользоваться услугами консалтеров и сотронних программистов мы позволить себе не можем. Было принято решение все изучать самим. Ну не было у нас в бюджете такой строки
На самом деле я не говорю, что не нужно разрабатывать — я лишь говорю, что разрабатывать следует не с нуля, а взяв за основу какой-то Framework.
Несколько далекий пример — разработка на чистом WinAPI или MFC(VCL). Решая писать на MFC ты не говоришь, что теперь у тебя лишняя строка в бюджете — ты говоришь, что надо просто изучить MFC — в результате я смогу вести разработку более быстро, а следовательно дешево.
Примерно такая же ситуация и здесь — я говорю — не надо писать с нуля, возьми готовую библиотеку классов, алгоритмов и т.д. , все то, что присутствует в готовой ERP системе. Если тебя не устраивает какой-то алгоритм — ты его можешь переписать. Если чего-то нет, то ты сможешь это дописать.. причем эта доработка будет вестись значительно быстрее, чем если бы ты писал с 0.
... << RSDN@Home 1.1 alpha 1 >>
Re: Все известные промышленные ERP писаны на С++
От:
Аноним
Дата:
28.07.03 14:06
Оценка:
Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
S>Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
S>Возникает вопрос, какие средства разработки использовать?
S>Естественно, кое-каие соображения есть, но хочется услышать мнения общественности.
S>Кроссплатформенность не требуется. Все должно работать на NT-сервере. Клиенты — тоже под Windows.
S> — Имеет ли смысл в таких условиях использовать Java для серверной части? Насколько мне известно на западе Java используют в ERP системах среднего масштаба и ниже. Крупный enterprise — область применеия С++. Так ли это? Так же в пользу С++ — требование высокой скорости серверных вычислений.
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
S>- Клиентские приложения. Ситема закрытая, т.е. количество клиентских мест ограничено. Нет требования возможности доступа к системе с любого компьютера. Это наводит на мысли что клиент может быть построен на GUI. С другой стороны web-клиент упростит ситуацию с модификацией клиентской части.
S>- Вопрос шифрования данных циркулирующих в системе.
S>Вобщем вот такие вопросы. Благодарен за любые ответы, мысли, мнения.
Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики.
И вряд ли ситуация изменится.
Re[2]: Все известные промышленные ERP писаны на С++
Здравствуйте, Аноним, Вы писали:
А>Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики.
А>И вряд ли ситуация изменится.
Да, похоже на то.
Это очень консервативная область IT.
Внедрение на большом предприятии занимает месяцы — годы, цена систем — порядок миллионов и десятков миллионов, поэтому там, исповедуемый в Java принцип — дешево и сердито — не катит
Какую-то мелочевку может на Java и лабают, но это все крохи с ERP-шоного стола
Re[2]: Все известные промышленные ERP писаны на С++
А>Все известные промышленные ERP писаны на С++, сейчас J2EE проталкивают туда, но лидерство по-прежнему у классики. А>И вряд ли ситуация изменится.
Как правило написание ERP системы начинается с написания своего метаязыка, на котором уже и разрабатывается функционал. Примеры ? Axapta, SAP, Галактика ... тот же 1С.
Сам метаязык как правило пишется на 1С.
P.S. М2 — написан на Дельфи (хотя я не скажу, что это удачная система); Platinum — сишное ядро, интерфейс и отчеты на Дельфи. Парус сейчас кажется на .Net переписывается.
... << RSDN@Home 1.1 alpha 1 >>
Re[3]: Все известные промышленные ERP писаны на С++
Здравствуйте, DemAS, Вы писали:
DAS> P.S. М2 — написан на Дельфи (хотя я не скажу, что это удачная система); Platinum — сишное ядро, интерфейс и отчеты на Дельфи. Парус сейчас кажется на .Net переписывается.
Здравствуйте, DemAS, Вы писали:
IT>> В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.
DAS> Как правило все современные ERP имеют средства разработки, позволяющие модифицировать их под себя.
Это как раз понятно, иначе бы их никто не пользовал бы, а если бы и пользовал, то разработчики тратили бы больше на сапорт, чем получали бы денег... хотя если всё правильно обставить, то можно сделать неплохой бизнес на лохах. И между прочим некоторые делали, была (может и сейчас есть) конторка, которая в своё время окучила центробанк, так там
Но речь не об этом. Речь о том, что другой софт должен не строится вокруг подобной системы, а она должна быть плавно включена в существующую. Т.е. вопрос всего лишь о том где яйцо, а кто курица.
DAS>А отстегивать консам и программерам на разработку или обучить своих людей — здесь каждый решает для себя сам...
Точно. Только обычно это решение принимается уже после покупки системы, когда заказчик, потративший туеву хучу бабок, просто ставится перед фактом, а позади Москва и отступать некуда. К сожалению, это обычная практика тех кто пробивает внедрение таких систем.
... << RSDN@Home 1.1 beta 1 >>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Все известные промышленные ERP писаны на С++
Здравствуйте, NetStyler, Вы писали:
NS>Как раз занимаюсь разработкой ERP. NS>Хочу указать некие точки, чтобы вам не наступить на мои грабли. NS>На чем будет написана система не столь важно Java или .NET. мы пишем под .NET.
Большое спасибо за советы.
И все же я хочу уточнить один, ключевой с моей точки зрения моомент.
Чем обосновывается решение применять .NET или Java в ядре системы? Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++? Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java
Здравствуйте, Slick, Вы писали:
S>Чем обосновывается решение применять .NET или Java в ядре системы?
Надежнее код, нет утечек памяти, невозможна случайная порча памяти.
S> Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++?
Больше работы, особенно по отладке.
S> Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java
Между .NET и Java за и против простые. Плюсы нета
1) Поддрежка МСовских enterprise технологий — serviced components, MSMQ и т.п.
2) Простота взаимодействия с legacy-кодом
Плюс джавы — больше количество родных решений — EJB, JDO и т.п.
Здравствуйте, Slick, Вы писали: S>Большое спасибо за советы. S>И все же я хочу уточнить один, ключевой с моей точки зрения моомент. S>Чем обосновывается решение применять .NET или Java в ядре системы? Почему не следовать традиционной практике разработки подобных систем, предполагающей применерие С++? Действительно хочу разабраться. Какие за и против по всем трем кандидатам: С++, .NET, Java
1. С++ Выигрываем в быстродействии. Проигрываем в "стоимости разработки". Под стоимостью я подразоумеваю не только затраты на программистов, но и высокие временные затраты на разработку и отладку. У С# и Java эти пороги гараздо скромнее.
2. С# и Java — платформы похожие. Но если вы используете линейки продукции Microsoft/MS SQL и т.д. — выбор очивидет. Здесь самое главное не устроить войну идеологий, а выбирать основываясь на принципе наименьшего сопротивления.
Задайтесь вопросом кто ваши клиенты — какое ПО они используют — какое ПО им проще поддерживать. Ответ придет к вам сам
... << RSDN@Home 1.1 beta 1 >>
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, Slick, Вы писали:
S>Мощность языка, крастота кода, оптимизация и прочая распальцовка — это факторы непосредственно определяющие качество результата. Эти факторы не являются романтикой, они определяют стиль программирования подход к решению задач в целом. Самоутвеждение здесь не причем, поверь.
S>Конечно, пока ты лабаешь порносайты из шести статических страниц и одного голосования, тебе этого не осознать. Твой стиль — дешево и сердито, и в этом нет ничего плохого. S>Просто сложность реализации должна быть адекватна ценности решенной задачи.
Так и я о том же.
S>Но когда(если) ты выберешься из таких задач, если эффективность и надежность а не скорость разработки, будут основными требованиями к твоим продуктам, ты поймешь, что это не понты и не пустой звук. Тогда ты сам будешь выбирать то что качественее а не то что легче и быстрее. Иначе, не будешь успевать просыхать от падений в лужу на глазах изумленной публики.
Упс! Пора бежать в прачечную
Не хотел обидеть. Ключевая фраза "в условиях ограниченных ресурсов", ИХМО, надо смотреть на конкретую задачу.
Здравствуйте, Slick, Вы писали:
S>>>Чем обосновывается решение применять .NET или Java в ядре системы? AVK>>Надежнее код, нет утечек памяти, невозможна случайная порча памяти.
S>Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java. S>Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка. Давайте исходить из того, что над системой работают высокоуровневые программисты и сложность языка не имеет значения.
Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++).
S>В такой ситуации какие преимущества у Java и С# перед С++?
С учётом нижеизложенного требования надёжности и эффективности напоминаю: и Java и .Net используют garbage collector.
PS. Я для таких приложений альтернативы собственному ядру на С++ пока что не вижу. Особенно, если хочется иметь возможность контролировать почти всё, что происходит в системе.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++).
Это чистой воды маркетинг. Что занчит усовершенствование? Отсутствие множественного наследования, шаблонов и контроля памяти разработчиком — это что усовершенствование? Тяжеловесные и медлительные контейнеры Java по сравнению с мощнейшим и гибким STL — это тоже усовершенствование?
Облегчение синтаксиса — да, но усовершенствования я здесь не вижу.
Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.
AVK>Гибкость гибкости рознь. Кое в чем менеджед платформы куда гибче плюсов.
Ну кое в чем возможно да. Упаси меня бог отрицать необходимость и мощь Java и C#. Моя задача — взвесить аргументы за и против и принять решение. Так что я очень ценю ваше мнение.
AVK>Да ради бога. Я уже давно убедился что определенным людям доказать что в этом мире есть что то помимо С++ практически невозможно.
Это не про меня. Я готов изменить свою точку зрения. Да согласен, мой основной опыт и знания лежат в плоскости С++. Тем не менее не могу сказать что я полный профан в J2EE. Я занимался этой технологией полтора года, занимался серьезно. Так что имею возможность сравнить. И на основание имеющегося у меня опыта и впечатлений, а также опыта ведущих разработчиков ERP (авторитет SAP я думаю вы не будете отрицать) я склоняюсь к С++.
Готов выслушать здравые аргументы против, дать себя переубедить и сожрать свою шляпу если вам все-таки удастся это сделать. Форум для того и существует.
S>>Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка.
AVK>Не соглашусь.
Ну это же просто глупо. Вы что хотите сказать что программа на С++ идеально написанная господом богом, все равно будет течь только из-за того что это С++? Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью. А между тем имено такой контроль как показывает практика — самый эффективный.
AVK>Если что то можно сделать автоматически с приемлемыми потерями то это нужно делать автоматически. Это, так сказать, азы дизайна сложных систем. Иначе с определенного момента ты просто утонешь в деталях и заморочках.
Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.
S>>Давайте исходить из того, что над системой работают высокоуровневые программисты S>>и сложность языка не имеет значения.
S>> Другое дело что качество реализации этой технологии — паршивое, и полезных вещей 40%.
AVK>Аргументы?
Вообще-то я немного сказал об этом. Entity Beans — это действительно необходимые сущности или чистый маркетинг? Можно говорить дальше, можно говорить о качестве серверов приложений, но это уже философский спор.
Хотя это интнресно и я готов обсудить.
S>>А общая идея в том, что давайте при принятии решений об использовании того или иного языка в ядре ERP будем руководствоваться мощьностью этого языка и близлежащих технологий.
AVK>Это часто встречающаяся ошибка. Во первых — говорить о языках в случае джавы и особенно дотнета не имеет смысла, надо говорить о платформах. Во вторых — мощность и гибкость средства разработки должна быть ровно такой какая нужна для конкретного применения.
Тут — полностью согласен. Действительно, мощность и гибкость средства разработки должна быть ровно такой какая нужна для конкретного применения. Я и пытаюсь выяснить, мощность какого средства меня устроит.
AVK>И кроме этого фактора существует масса других — например очень часто во главу угла при создании ERP ставят скорость разработки и надежность полученного кода, а мощность языка обычно этому помеха.
Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы. Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.
Здравствуйте, Slick, Вы писали:
S>а также опыта ведущих разработчиков ERP (авторитет SAP я думаю вы не будете отрицать)
А что SAP? Понятно что они конкурентов хвалить не будут.
S>>>Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка.
AVK>>Не соглашусь.
S>Ну это же просто глупо. Вы что хотите сказать что программа на С++ идеально написанная господом богом, все равно будет течь только из-за того что это С++?
Идеальных программ не бывает. Как не бывает идеальных разработчков.
S>Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью.
Да оне и без сборщиков мусора ленятся следить за памятью.
S>Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.
Какие утечки? И почему они неприемлемы?
S>Вообще-то я немного сказал об этом. Entity Beans — это действительно необходимые сущности или чистый маркетинг?
Необходимые сущности, бо в современных решениях в этой области часто реализуют что то похожее. И никто не заставляет использовать все возможности EJB. Понятно что в каких то случаях неприемлемы CMP, в каких то неприемлемы вобще entity beans, но это никоим образом не отменяет остальных возможностей EJB-серверов.
S>Тут — полностью согласен. Действительно, мощность и гибкость средства разработки должна быть ровно такой какая нужна для конкретного применения. Я и пытаюсь выяснить, мощность какого средства меня устроит.
Боюсь что для ERP систем (не для их ядра, а для того самого бизнес-кода) особой мощности и гибкости не нужно. Тот же упомянутый тобой SAP вобще считает что настройки должны быть декларативными.
S>Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы. S>Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.
Зачем говорить о каких то гипотетическизх ситуациях, если скорость разработки была и будет одним из самых важных факторов?
Здравствуйте, AndrewVK, Вы писали:
AVK>Идеальных программ не бывает. Как не бывает идеальных разработчков.
Вот, о профессиональном уровне программистов я и говорил. Нечего на язык пенять, коли руки кривы.
S>>Другое дело, что многие разработчики, развращеные хреново работающими сборщиками мусора, просто ленятся следить за памятью.
AVK>Да оне и без сборщиков мусора ленятся следить за памятью.
Во всяком случае в плюсы не ограничивают возможности программиста в этом направлении. Утечки в Java приложениях можно только глубокомысленно созерцать, размышляя о бренности бытия. А в плюсах у тебя полная свобода действий. Твои утечки это твои проблемы и ты можешь их ликвидировать.
S>>Вот именно — с премлемыми потерями. Утечки, которые дает Java не приемлемы в сверхкрупных приложениях.
AVK>Какие утечки? И почему они неприемлемы?
Те утечки кторые имеют место из-за некорректной работы сборщика мусора. Не спорю, в большинстве случаев они незначительны, и на них можно закрыть глаза. Но если объем памяти — критический параметр?
S>>Давайте еще раз обрисуем приоритеты. Пусть основными требованиями для разрабатываемой ERP считаются отказоустойчивость и скорость работы. S>>Время разработки — тоже достаточно важный, но все же второстепенный фактор по сравнению первыми двумя требованиями.
AVK>Зачем говорить о каких то гипотетическизх ситуациях, если скорость разработки была и будет одним из самых важных факторов?
Ну далеко не всегда. Думаю что при разработке внутренних систем автоматизации для NASA и нью-йорркской фондовой биржи, все же отказоустойчивость, скорость работы и надеженость будут поважнее времени разработки.
Здравствуйте, Slick, Вы писали:
ГВ>>Напоминаю: Java подавалась как "усовершенствование C++", C# рекламируется примерно также (на фоне кастрированного Managed C++). S>Это чистой воды маркетинг. Что занчит усовершенствование? Отсутствие множественного наследования, шаблонов и контроля памяти разработчиком — это что усовершенствование? S>Тяжеловесные и медлительные контейнеры Java по сравнению с мощнейшим и гибким STL — это тоже усовершенствование?
Нет, разумеется.
S>Облегчение синтаксиса — да, но усовершенствования я здесь не вижу.
Я тоже.
S>Вот если бы вы назвали некие преимущества, вернее возможности Java и C# не доступные C++, то я бы согласислся что это усовершенствование.
Хех, я вижу у них обоих одну большую возможность, условно недоступную C++ — garbage collector => непредсказуемость задержек (об этом на RSDN, кстати, неоднократо упоминалось).
Ну а кроме шуток, Java и C# (вернее — .Net) — платформы, притом жёстко конкурирующие между собой, а С++ — язык, на котором они, кстати, написаны. Вернее — Sun/Java написана вообще на C. ИМХО, .Net — не плохая платформа, только она не для "ядерных" приложений, да и кроме неё, скорее всего и другие появятся. Где появились двое — там появилась возможность выбора => кто-то почти наверняка захочет расширить этот выбор.
Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше.
А потом, в принципе, никто не помешает тебе интегрироваться практически с любой из существующих платформ/инфраструктур, поскольку интерфейс для C по-любому у всех будет ещё ну очень долго.
Так что, я не вижу серьёзных преимуществ Java/.Net перед ядром на C++.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: средство разработки для крупной ERP
От:
Аноним
Дата:
30.07.03 10:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ещё учти, что на разработку "системного ядра" ERP при квалифицированных проектировщиках/С++-никах потребуется где-то 0,8-2 ч/года в зависимости от требований (ну это я по опыту), а на анализ и разработку предметных областей всё равно улетит в разы больше.
Просветите пожалуйста, что входит в понятие "системного ядра ERP". И чем ядро отличается от бизнесс-логики. И что на чем пишется.
Здравствуйте, Slick, Вы писали:
S>2. Отсутствие контроля памяти в Java тем не менее приводит к написанию "текущих" приложений, порою изрядно текущих. Причина — качество сборщика мусора. Если тебе нужно идеальное в смысле утечек приложение, иного способа кроме самоконтроля — не найдешь.
Я вообще-то про дотнет это упомянул. А можно ссылку куда-нибудь, где такое говорится про java GC? я лично такое слышу в первый раз
Здравствуйте, AndrewVK, Вы писали:
S>>Вот, о профессиональном уровне программистов я и говорил. Нечего на язык пенять, коли руки кривы. AVK>Батенька, программисты есть именно такие какие они есть.
Честно, Andrew, не все программисты криворуки. Далеко не все.
AVK>Если для разработки системы нужна команда состоящая целиком из очень квалифицированных профессионалов, то стоимость такой системы возрастет в разы, вероятность успешного завершения снизиться и вобще непонятно откуда брать такую команду.
Интересно, а что если она уже есть?
AVK>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.
А не находишь, что дороговизна оправдывается потребительскими качествами продукта? Тихо, тихо, я знаю, что нередко это повышение оказывается потенциальным, но всё-таки?
[offtopic on]
Знаешь, что забавно: где-то год или около того назад я как раз говорил о снижении стоимости работы программиста при переходе на более простой и эффективный [ нужное вписать ]. Хех, похоже, что я был прав. Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости. И ещё забавно то, с каким упорством это самое снижение добавленной стоимости отстаивается, в частности, тобой (не сочти за личный наезд, плиз). Или я чего-то не понимаю? Или просто "одеяло" этой самой добавленной стоимости перетаскивается со специалистов на менеджеров, а специалисты заменяются просто "вменяемыми и хорошими людьми"? Я несколько утрирую, но, ИМХО, очень похоже на истину и если так, то that's a largest trouble в недалёком будущем.
[offtopic off]
AVK>>>Да оне и без сборщиков мусора ленятся следить за памятью. S>>Во всяком случае в плюсы не ограничивают возможности программиста в этом направлении. AVK>Ну да, вот только GC там реализовать нормальный так и не удалось.
Мда. Спецам он не нужен (почти), а для ммм... их противоположностей и язык BAT-файлов — магия.
AVK>>>Зачем говорить о каких то гипотетическизх ситуациях, если скорость разработки была и будет одним из самых важных факторов? S>>Ну далеко не всегда. AVK>Так практически всегда.
У всех свои ситуации. ИМХО, не стоит здесь обобщать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Батенька, программисты есть именно такие какие они есть.
ГВ>Честно, Andrew, не все программисты криворуки. Далеко не все.
Но к сожалению значительная их часть.
ГВ>Интересно, а что если она уже есть?
Я такого еще не видел. Во всех командах которые видел всегда есть часть менее профессиональных программеров, которые занимаются менее сложной работой.
AVK>>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка.
ГВ>А не находишь, что дороговизна оправдывается потребительскими качествами продукта?
Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.
ГВ>Знаешь, что забавно: где-то год или около того назад я как раз говорил о снижении стоимости работы программиста при переходе на более простой и эффективный [ нужное вписать ]. Хех, похоже, что я был прав.
Да это собственно не было новостью даже 10 лет назад, иначе чем оправдано существование скриптовых примитивныхх языков?
ГВ> Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости.
Ну если считать за добавленную стоимость количество ручного труда то да. А если полезный функционал то нет.
AVK>>Ну да, вот только GC там реализовать нормальный так и не удалось.
ГВ>Мда. Спецам он не нужен (почти),
Ну да, а я наверное не спец, поскольку мне он нужен.
S>>>Ну далеко не всегда. AVK>>Так практически всегда.
ГВ>У всех свои ситуации. ИМХО, не стоит здесь обобщать.
Хорошо, приведи пример когда при разработке классической ERP сроки внедрения не играли важной роли.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Интересно, а что если она уже есть? AVK>Я такого еще не видел. Во всех командах которые видел всегда есть часть менее профессиональных программеров, которые занимаются менее сложной работой.
AVK>>>Если с языком способны работать только очень дорогие специалисты, то это проблема именно языка. ГВ>>А не находишь, что дороговизна оправдывается потребительскими качествами продукта? AVK>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.
Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.
ГВ>> Притом огорчает, что это снижение есть следствие объективно меньшей добавленной им стоимости. AVK>Ну если считать за добавленную стоимость количество ручного труда то да. А если полезный функционал то нет.
Мне бы твою уверенность...
AVK>>>Ну да, вот только GC там реализовать нормальный так и не удалось. ГВ>>Мда. Спецам он не нужен (почти), AVK>Ну да, а я наверное не спец, поскольку мне он нужен.
Это мне не известно. Блин, прекрати наконец сводить беседу к личным наездам.
S>>>>Ну далеко не всегда. AVK>>>Так практически всегда. ГВ>>У всех свои ситуации. ИМХО, не стоит здесь обобщать. AVK>Хорошо, приведи пример когда при разработке классической ERP сроки внедрения не играли важной роли.
Сроки играют важную роль до принятия решения о выборе как критерий сравнения а после того как решение принято (скажем, в пользу разработки), то они просто не должны срываться. Если пользователя заявленные сроки устраивают, то, ИМХО, можно хоть свою ОС написать, если есть желание.
А кроме того, сами по себе сроки можно несколько двигать, если разработкой/внедрением занимается, например, IT-отдел. Ну это я отчасти по своему опыту, который вполне вероятно, не может быть обобщён.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Не нахожу. В массе своей потребительские качества проектов на нативных компиляторах хуже из-за большего количества багов, особенно приводящих к краху программы.
ГВ>Ну, я думаю, что дело здесь ещё и в том, что в массе своей проекты написаны "массовыми" программистами, которые, как ты уже заметил — криворуки.
Но что же получается — программисты на той же джаве в массе своей менее криворуки? Как еще можно объяснить к примеру тот факт что качество джавовских библиотек в среднем заметно выше тех же Дельфовых компонент или плюсовых либ?
AVK>>Ну да, а я наверное не спец, поскольку мне он нужен.
ГВ>Это мне не известно. Блин, прекрати наконец сводить беседу к личным наездам.
Ну а как можно на такой аргумент отвечать? Я все таки считаю себя специалистом и тем не менее пользоваться GC мне удобнее, и не потому что я без него лики пложу, а потому что во многих случаях это позволяет писать более красивые и простые алгоритмы. Я могу выделить кусок памяти внутри какой то функции и не заботиться больше о том кому этот кусок грохать, даже если его использует кто то из другого процесса.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну так тем же самым — массовостью, "массой", которая... stl, например, очень неплохая библиотека. А про Java где-то бегало исследование из серии "Java vs C++", так там пришли к выводу, что Java обеспечивает меньший разброс качества, чем C++, т.е., у неё "нижняя планка" выше, чем у C++, но и "верхняя" — ниже. Сейчас быстро не найду, но если будешь настаивать, то раскопаю вечером.
Что-то вроде этого?
But programming in VB is like riding a kiddy bike, while programming in C++ is like driving a Formula 1 racing car — be prepared for accidents.
(с) Frequently Asked Questions (aka the MFC FAQ) by Scot Wingo
Геннадий, если не затруднит, не мог бы ты дать ссылку на эту статейку/исследование — было бы очень занятно почитать.
... Roxette (Run To You) ...
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Мда. Спецам он не нужен (почти), а для ммм... их противоположностей и язык BAT-файлов — магия.
"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.
Здравствуйте, alexm1202, Вы писали:
A>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.
Ключ — "необязательный".
... << RSDN@Home 1.1 beta 1 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DAS> Да, а такие компании как РосТлеком, Ленсвязь, Toyota, Энергомаш, Перекресток, Исток, Волгоградский Аллюминий, MTV, Marvel, Osko, Алтайагропромснаб, Гипермаркет О"Кей, Группа компаний DIXIS, ДелтаСпорт, Останкинский молочный комбинат, Первоуральский новотрубный завод, РУССО, Ригла, Техносила, Тинькофф — это я говорю про тех людей, которые выбрали Axapt'у.
Раз уж зашла речь про Аксапту. У меня есть знакомый, который работает внедренцем Аксапты. По его словам, процент успешных внедрений крайне низок. То есть народ это покупает, тратит деньги на внедрение, но реально не работает.
Не знаю, насколько это соответствует истине — за что купил, за то и продаю.
Прокомментируйте, пожалуйста.
Здравствуйте, Roman Avramov, Вы писали:
RA>Раз уж зашла речь про Аксапту. У меня есть знакомый, который работает внедренцем Аксапты. По его словам, процент успешных внедрений крайне низок.
Смотря что понимать под успешным внедрением. Внедрении ERP, как и ремонт — процес бесконечный. Он никогда не заканчивается, он лишь на время приостанавливается .
Предприятие могло не внедрить все запланированные модули, но даже то, что внедрено может поднять уровень управления на совершенно иной уровень. Предприятие может гордо заявлять, что оно внедрило ERP, но при этом это может оказаться все лишь маркетинговой уловкой.
Процент внедрения не высок. Но как правило это связано с тем,что часто внедрением занимаются те, кто не умеет это делать. Дальше эту тему разивать я не буду...
Однозначно могу сказать, что процент внедрения Axapta выше, чем например SAP, и даже я думаю выше, чем у самописных систем. Но ниже чем у 1С . Чем сложнее систему — тем больше рисков, а следовательно выше шанс ее не внедрить.
Здравствуйте, Геннадий Васильев, Вы писали:
A>>"В C++ нужно добавить необязательный сборщик мусора." Б. Страуструп "Дизайн и эволюция С++". Я не думаю что Страус стал бы так писать о средстве, которое не нужно (почти) пользователям языка.
ГВ>Ключ — "необязательный".
Так в C++ много необязательных фич. Однако каждая из них была добавлена, исходя из тех соображений, что она существенно облегчит жизнь разработчикам в том или ином классе задач (не обязательно всем, кому-то например RTTI не нужен, а большинство прекрасно обходятся без МН). И, похоже, Страуструп считает что GC тоже облегчил бы жизнь достаточно большому числу пользователей С++, чтобы его добавить в язык. Это я к тому что со словами "не нужен (почти)" ты, имхо, погорячился
... << RSDN@Home 1.1 beta 1 >>
BR, Alex.
Re[2]: Все известные промышленные ERP писаны на С++
S>Здесь вы приводите тезисы, традиционно упоминаемые при сравнении С++ и более высокоуровневых языков типа C# и Java. S>Да, согласен, С++ более требователен к разработчику чем Java и C#, это хорошо известно. Но вместе с тем это более гибкое и более скоростное решение. Так что такой аргумент меня не убеждает. Фактически вы утверждаете что С++ не годится потому, что он сложен. Ведь согласитесь, утечки и порча памяти — это проблемы кривого кода а не плохого языка.
Ну я конечно не знаю, может у тебя сплошь одни монстры работают, но что-то не очень верится.
S>Вообще надо сказать, что начиная с определенного уровня сложности задач, такой критерий как сложность языка совершенно теряется перед сложностью алгоритма и структур данных. И в такой ситуации необходимо делать выбор, основываясь на том, какие сопутствующие технологии существуют для того или иного языка.
C++ действительно очень сложен.
Хотите того или нет, ошибок наделаете море.
Потом их придется исправлять, а это скорее всего полностью сведет на нет все благие намерения насчет оптимальности и быстродействия.
В итоге получите то же самое, но с бОльшими трудозатратами и менее управляемое (C++ — код сопровождать куда труднее, чем ту же Java или VB).
Re[3]: Все известные промышленные ERP писаны на С++
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Блин, как назло сама ссылка затерялась.
Если вдруг попадется на глаза, то кинь, пожалуйста.
... Metallica — The Unforgiven II ...
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction. -- Albert Einstein
Расскажу как сделано у нас (было ).
Набор технологий следующий: С#, ASP.NET, IE6, SQL Server. Для шифрования (зачем оно нужно в закрытой среде — это я не понимаю), можете использовать HTTPS. COM+ можно и не использовать, пока уж очень сильно не понадобится, web farm должно хватить. IE6 мы выбрали, потому что там всяких рюшичек хватает, и потому хороший GUI можно создать. Работать это дело будет достаточно быстро, поскольку всё родное от Microsoft.
А теперь раскажу о том что планируем делать на будущее, поскольку понадобилось произвести действительно большую систему для нескольких тысяч пользователей. Всё дело будет бегать под IBM AIX и WebSphere. Будем пользовать Java, IE6, Kodo JDO, Tangosol (для распеределённых кэшей) и Sybase как БД. Ожидаемая нагрузка пара тысяч одновременно работающих пользователей, отклик системы — максимум 3 секунды. Вообщем, как построим, так расскажу справились или нет
Здравствуйте, PeterZT, Вы писали:
PZT>Понятно. Но все же не так сильно, как бухгалтерия, т.е. оперативный учет можно держать в соответствии с законом намного меньшими усилиями, чем бухгалтерию.
А акцизы на нефть и нефтепродукты...
Да вообще налоговый блок оказывает очень сильное влияние даже на краткосрочное планирование в крупных холдингах (типа нефтяных комапний), осебенно если дочки расположены в регинах с разными налоговыми системами.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, DemAS, Вы писали:
IT>>> В таком случае, если такая штука чего-то не умеет, то всегда можно будет это что-то дописать. А вот если это вещь в себе, то отстёгивать консультантам за настройку или разработчикам за дороботки придётся не мало.
DAS>> Как правило все современные ERP имеют средства разработки, позволяющие модифицировать их под себя.
Своими глазами наблюдал внедрение R3. Насчет модификации под себя — это сильно сказано, ее нельзя даже (или ее просто не смогли) привести в соответсвие с российским законодательством, и вот в этой конторе стали прогибать систему учета под R3, т.е. не R3 настраивать, а наоботот. То ли спецы у них были не грамотные, то ли R3 такая — я не знаю, но в конечном итоге там ничего не внедрили, R3 задвинули, а стали заниматься так называемой лоскутной автоматизацией.
Здравствуйте, DemAS, Вы писали:
DAS>Здравствуйте, Roman Avramov, Вы писали:
RA>>Раз уж зашла речь про Аксапту. У меня есть знакомый, который работает внедренцем Аксапты. По его словам, процент успешных внедрений крайне низок.
DAS> Однозначно могу сказать, что процент внедрения Axapta выше, чем например SAP, и даже я думаю выше, чем у самописных систем. Но ниже чем у 1С . Чем сложнее систему — тем больше рисков, а следовательно выше шанс ее не внедрить.
R3 — в российских условиях внедрить в полном объеме нельзя, насколько я знаю, она нигде полностью не внедрена.
Здравствуйте, S-SH, Вы писали:
>> а то что закупленный софт пылится >> — так он всего лишь средство.
SS>Как и консалтеры Консалтерам-то хоть заплатили?
Здравствуйте, Slick, Вы писали:
S>Планируется разрабока крупной распределенной системы по управлению сетью производственных предприятий.
S>Предполагается сложная бизнес-логика, очень большие объемы данных, высокие требования к скорости серверных вычислений и к надежности.
S>Возникает вопрос, какие средства разработки использовать?
Извени, если что не так, но твоя постоновка вопроса напоминает мне кадр из одного старого фильма — Поляки готовятся к войне. Решив что воевать всё же придётся решают вопрос о форме. Одни говорят синие штаны и красный китель, другие — китель синий, штаны красные, третьим по барабану, но эполеты должны быть!
Я дико извеняюсь конечно, но подожди годиков несколько, потом и спрашивать не придётся — будеш готов к созданию ERP, тем более крупной. ИМХО конечно.
S>- Какую использовать базу? Предполагается рапределенное хранилище. Очевидно следует делать выбор между Oracle, DB2 и может быть MS SQL Server
Я бы рекомендовал Oracle, лучше 9.2.
S>- Вопрос шифрования данных циркулирующих в системе.
Кстати, в Oracle это легко настраивается, а также можно включить подпись блоков данных, чтобы напрямую никто на диске не подменил.
Здравствуйте, Framer, Вы писали:
F>Здравствуйте, vtools, V>>Проект открытый и на текущий момент уже есть первые пробные версии программы (поддержка project@vtools.ru)
F>http://sourceforge.net/projects/myenterprise/ F>Ссылка не на ваш проект случайно? Что-то там нет ни активности ни пробных версий программы. F>Заявление о намерениях (которые на http://www.vtools.ru/2c.htm почемуто называются — Концепция!?) F>очень неплохи. F>Однако вызывает сомнение что данное начинание вообще сможет дойти хотя бы до релиза.
F>|К проекту предъявляются следующие требования: F>|· Совместимость с 1С.
F>На этом можно заканчивать....
Если нам не помогут, то мы тоже никого не пощадим.
)
