Стоит ли делать на .net erp систему? - Философия программирования

Здравствуйте, BlackTigerAP, Вы писали:

BTA>В ОБЩЕМ — НАС РАТЬ, И НАМ НАСРАТЬ НА ВАС, ДОРОГИЕ РАЗРАБОТЧИКИ WINGUI-ПРИЛОЖЕНИЙ (с) Microsoft
Ты чего разбушевался? Слава Microsoft спать мешает? Или тебя кто-то насильно заставляет на WinForms программировать?
Не нравится WinForms — не пиши на нем. Пиши на Delphi, WTL, MFC, голом WinAPI наконец. Каждому не угодишь... Не спорю, ляпы есть, но очень много сделано для того, чтобы у тебя голова не болела на тему того, как запихать иконку в кнопку.

А на тему того, кому на что наплевать, так ты бы показал свой продукт такого порядка, как System.Windows.Forms и миллионы (?) пользователей его использующих — посмотрел бы я, сколько у тебя было бы недовольных.

... << RSDN@Home 1.1.4 beta 2 >>

Позволю себе высказать несколько мыслей относительно ваших опасений.
(Не в качестве саморекламы, а просто чтобы оценить опыт — последний год работаю на c#. Проект весьма тяжел и охоч до памяти. До этого больше 10 лет писал на плюсах)

1) "GC тормозит". Это миф. Он не тормозит. По крайней мере чтобы это стало заметно. Система поколений в GC работает просто "на ура". Более того, поскольку пямять теперь — managed, то возможно использование инструментария для конторля за использованием памяти (например, .NET memory profiler). С использованием этого инструментария можно поймать перерасход памяти и улучшить критические алгоритмы. С++ такие возможности анализа и не снились. Общий результат — только выигрыш.

2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO). Машины класса PIII-500 128mb потянут только очень легкие .NET приложения.

3) Если систему планируется поддерживать хоть сколько-нибудь лет, а не "написал, получил денег и забылкак кошмарный сон" — то .NET подходит сейчас лучше всего. Во-первых, под .NET писать и сопровождать проще и легче. Что на проектах размером "средний или чуть больше" в сумме будет уже IMHO экономически выгоднее (учитывая изучение новой технологии, инструментария, etc.) Во-вторых, ставка MS сейсчас идет на .НЕТ. Все остальное объявлено "deprecated"

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.

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

BTA>Проблема, как правило, в архитектуре и возможностях ADO.NET. Оно хорошо (по словам майкрософта) для веба, хорошо (по словам майкрософта) для серверных компонентов, но это АД для WinGUI-приложений.

Я бы так не скзал. Есть куча готовых решений.

BTA>Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).

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

BTA>Разработать-то ЕРП можно, только вот не надо удивляться потом диким тормозам именно клиентской части и постоянной необходимости наращивать железо, но не на серверной части, как было раньше, а уже на клиентской.

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

BTA>Опять же, сами майкрософтовцы еще не смогли реализовать ничего толкового, в плане ЕРП, используя дотнеть.

Я бы скалаз и не брались. Для этого они прикупили несколько компаний и в ближайшие годы мы явно увидим подобные продукты.

... << RSDN@Home 1.1.4 beta 2 >>

>1) Проект stand alone — всё в себе, в том числе и база. То есть >заказчик не будет платить за продукт + еще базу
>(причем база может дороже продукта), а сразу получить всё готовое >(mysql, или другие бесплатные базы не
>подходят), хотя клиент может выбрать и готовую через драйвер >базы.

Интересный момент. Вы хотите сказать, что создать свою промышленную СУБД будет дешевле готовых, таких, как Oracle, MS SQL etc.? Стоимость их покупки и линензий — это несколько тысяч долларов, в большинстве случаев всего примерно до двух десятков ли меньше. А это, с другой стороны, зарплата команды двух-трех профессиональных разработчиков максимум на 2-3 месяца. Плюс время обкатки своей СУБД на реальных объемах, которые даст только запуск проекта промышленного масштаба, т.е. эксперимент над заказчиком, а он чаще всего не любит отрицательных результатов

Создание объектной СУБД поверх SQL для обработки больших объемов данных задача также нетривиальная. Есть мысль, что выбор серверных технологий и технологий обработки данных (сервер приложений, web сервисы etc.) окажет решающее влияние на производительность системы.
Я бы не стал рисковать и делать всё своё одним проектом, их нужно делать и проверять как отдельные этапы.

Sincerely yours,
Valery Chesnokov
<A href=http://chv.tele-kom.ru>http://chv.tele-kom.ru</A>

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Shhady, Вы писали:

S>1) Проект stand alone — всё в себе, в том числе и база. То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят), хотя клиент может выбрать и готовую через драйвер базы.

Есть совершенно бесплатный MSSQL Express (теперича, ранее Desctkp Edition). Нистоит ничего. При этом дает возможность если что легко перепрыгнуть на полноценный MSSQL в плодь до энтерпразной версии. Почему не рассмотреть его?

Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.

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

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, PPA, Вы писали:
PPA>>В чем будет секс?
VD>Ну, если писать на Плюсах, то секс гарантирован. Заклчюаться он будет в том, что после сдачи ваши
VD> программисты будут ловить разные утечки памяти и проходы по памяти.

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

Как я понял основной плюс для тебя в нете это GC?
Программеры как всегда ищут легкие пути не заботясь о конечном пользователе

RSDN@Home у меня жрет 50-60 мегов!
Сколько попросит "самодельный" SQL сервер с 1000-коннектами?
Не будет он течь, но не по причине того что у .Net есть сборка мусора,
...а потому, что на машине от такой нагрузки ресурсы кончатся

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: HIM — The Sacrament ]>>

Здравствуйте, <Аноним>, Вы писали:

А>Мы бы рады, но такая конфигурация вылезла из анализа наших гипотетических клиентов. Потом у нас идея фикс: erp со скоростью света.
А>Еще раз повторюсь, если есть какое то недопонимание, наша erp не "заказная", она для всего рынка. Мы не можем себе позволить, если клиент покупает нашу erp, чтоб он заменял все свои компьютеры.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, Shhady, Вы писали:

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.

Принципиально реализовать-то можно. Но в разработке любого продукта (в том числе и ЕПР системы) главенствует гораздо более интересный момент, чем сокрость выполнения программы — конечная стоимость.
И самым принципиальным вопросом для стороны-разработчика является ее МАХ, а для стороны-клиента ее MIN. Из текущего вопроса не очевидно на каком фланге находится Shhady. Если ближе к MAX — однозначно native, если к MIN — однозначно managed (и совершенно не обязательно .NET — это может быть Java, SmallTalk, etc)
Хотя, конечно, это- экстремумы. Можно (даже нужно) смешивать разнообразные подходы.

Но совет, который я хотел бы озвучить, звучит так: Модули/части, требующие усиленного мейнтененса -> managed (ибо гораздо!!! дешевле: ибо CPP обезъянки есть редкий и исчезающий вид, требующий хорошего обращения и дорогих витаминов), маломеняющиеся, но имеющие ограничения по ресурсам (скорости, памяти, выч. мощи) -> unmanaged.

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

Дело в том, что может оказаться так, что по конечной стоимости было бы проще заменить эти P3 на P333 и писать managed код, чем пытаться сотворить все на managed.
К тому же стоимость бутерброда с колбасой + время, натраченное на его хавание, есть величина гораздо меньшая, чем стоимость нормального "unmanaged" программера + два бутерброда с черной икрой, необходимых ему для "норамьной" работы

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
Можно, но, думаю, не стОит. База данных — нет тот продукт, который часто изменять и поддерживать приходится (я имею ввиду код, а не саму базу)

S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

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

S>p.s. если это баян, жестоко извиняюсь.
Этому баяну уже n лет, но пока никто на нем нормально не сыграл

... << J Mopc — Монтевидео >>

Здравствуйте, Shhady, Вы писали:

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.
S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

S>p.s. если это баян, жестоко извиняюсь.

Я бы начал прежде всего с вопросов сколько у Вас есть ресурсов под этот проект?
Временных, денежных, человеческих?

Объектные базы писать — задача довольно тяжелая и трудоемкая, как тут уже упоминалось, к тому времени как Вы ее допишете — стандартные клиентские машины будут раза в 2 быстрее

По затратам получается намного быстрее и дешевле написать объектный диспетчер и повесить его над существующей системой protected storage: SQL, Oracle, MySQL (если хотите конечно

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

Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д.

ERP очень красивый термин, конечно даа, только к сожалению черезчур всеобъемлющий

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

Лично я привык смотреть на вещи с трех сторон, а не с одной. Никогда не понимал огалтелого оптимизма и фанатизма.

—
ЗЫ: теперь прекрасно понимаю, почему на западе учат не ДУМАТЬ, а следовать инструкциям.
—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Я ща глянул http://www.devexpress.com/?section=/home/Customers у них там Raytheon в списке, меня не удивляет почему американские ракеты мимо цели попадают, пока там красная кнопа прорисуется, цель-то уже и сместилась (дом например

)

Звиняйте за стёб, пивцо хорошее, и нам тут совсем не скучно

.NetCoder

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Владимир, Вы писали:

А>Создал многопользовательскую систему для работы с удалёнными данными. Её архитектура и основные функции описаны в статье "К вопросу построения прототипа защищённых информационных систем". Проверить работу с 1000 клиентами нет возможности. Хотя можно убрать шифрование и оценить производительность. Работаю с двумя версиями — через .Net Remoting сервис поверх IIS и через .Net Remoting сервис поверх .Net Remoting Server. Большой разницы в производительности не наблюдаю. Но факт — через IIS работают тысячи клиентов. В вашей ситуации видимо надо переложить основные операции по работе с данными на уровень бизнес-логики (по возможности), клиентской части оставить отображение. Крайне важно не передавать на клиентский компьтер не нужную информацию. Детализация данных (по возможности) должна передаваться по дополнительному запросу. Например — выбрать покупателей Ивановых (SELECT на уровене бизнес логики и закачка результирующего набора данных в локальный DataSet) и показать в гриде. Выбор Иванова Петра Егоровича (например правой клавишей мышки) вызовет показ в другом гриде его заказов.
А>Могу утверждать, что клиентский компьютер с таким камнем будет работать, может придется увеличить память до 256.
Дело в том, что у нас "аморфный" клиент, у нас существует уникальная технология (патентуется), которая позволяет не теряя валидность, проводить операции бизнес логики на клиенте, когда он отправляет результаты своей работы, то все данные (обновление, или создание) перепроверяются на сервере. Тем самым клиент не сможет саботировать бизнес логику или проварачивать левые операции (чего не скажешь о axapte, 1c и т.д. (если не использовать их app server'ы) ).

А>Относительно создания собственной базы данных — это горячка. Крепко подумайте, особенно о том, как будете её сопровождать.
Наверное вы правы.

А>Успехов Вам.
Большое спасибо.

Shady

VD>>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
А>Для некомерческих проектов.

Это не так.

Здравствуйте, <Аноним>, Вы писали:

VD>>Есть совершенно бесплатный MSSQL Express (теперича, ранее Desctkp Edition). Нистоит ничего. При этом дает возможность если что легко перепрыгнуть на полноценный MSSQL в плодь до энтерпразной версии. Почему не рассмотреть его?
А>Для некомерческих проектов и для баз с < 4 гигами

Почему для некомерческих? Это не так. Ну, на на чет 4 гиг... Если компания работает с таими объемами, то или она занимается фигней, или ей просто таки прямая дорога к полноценному коммерческому серверу БД.

А>Спасибо за совет. Вроде желанее писать ВСУБД отпало

Мы просто оставим место для оной, что впоследствии можно было прикрутить, а пока сделаем персистные компоненты под MS SQL, ORACLE, MYSQL.

Это намного более разумно. Но я бы посоветовал остановиться на одном сервере. Или хотя бы выбрасить MYSQL. Дело в том, что создать полноценное высокопроизводительное решение для серверов с таким разным АПИ и возможностями тоже очень не просто. А MYSQL вообще слишком убог и не имеет ни одного приемущества перед MSSQL Express.

А>Я сейчас всё больше и больше склоняюсь к c#.

Ну, c# для безнес — софта, на мой взгляд — это лучший выбор.

... << RSDN@Home 1.1.4 beta 2 >>

>>Кстати тут на форуме был человек, кот. утверждал что Navision был написан чуть ли не на Delphi. Он-таки непрв?

Нет, он не прав. Хотя откуда ноги растут у такого "утверждения", знаю. Дело все в том, что в качестве внутренного языка разработки Navision (нормального, а не Аксапты) был выбран Паскаль. А вот все остальные идеи — элементы Access-а. Ну плюс еще ОЧЕНЬ недурственный сервер, и несколько гениальных решений в плане архитектуры. Майкрософт, кстати, замалчивает эти идеи. То ли из-за того, что перестанет нужен OLAP, то ли при покупке, патент на эти технологии к ним не перешел. Поинтересуйся технологией "SIFT".

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Приветствую,
вы знаете, приведу еще пару доводов по данному вопросу.

Во-первых, для тех, кто еще помнит, как создавалось ПО на Visual Studio 6.0, сколько там было разных сущностей для работы, например, со строками.
Давайте посчитаем: char *, basic_string template из STL, CString, BSTR, CComBSTR из ATL, класс _bstr_t, всякие макросы типа OLESTR, L"", _T() и т.д. Затем, String из Visual Basic 6, на котором писались ActiveX визуальные компоненты. Наверняка я не все вспомнил. И сколько памяти, утечек и времени уходило в результате таких преобразований?
Неужели наличие одного типа System.String в .NET Framework не убеждает в большей производительности создания и готового кода?

И второе.
>MS SQL или ORACLE, ВСУБД можно назвать объектной >надстройкой над другими СУБД, но с большой натяжкой.
Есть такой опыт. Что называется, не оглашая имен, скажу, что одна московская фирма, между прочим, как считается, российский лидер автоматизации одной из отраслей промышленности, два года делала проект, включающий в себя объектную СУБД поверх SQL, как минимум Oracle и MS SQL Server. Так вот, как раз это ядро весьма далеко от совершенства, и ему предстоит серьезная переделка после эксплуатации в реальных условиях. А время и деньги затрачены.
Вот такие бывают истории.
Желаю вам удачи в выборе технологий.

Sincerely yours,
Valery Chesnokov
<A href=http://chv.tele-kom.ru>http://chv.tele-kom.ru</A>

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Ха, прикольный топик. Сам уже около полугода бъюсь над этим "филосовским" проектом.

BTA>Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.
Анологично

BTA>Проблема, как правило, в архитектуре и возможностях ADO.NET. Оно хорошо (по словам майкрософта) для веба, хорошо (по словам майкрософта) для серверных компонентов, но это АД для WinGUI-приложений.
Ты не поверишь, я долго ржал (чуть не плача), я ругался матом во всё горло, когда увидел smart клиенты, которые теперь продвигает ms (раньше были thin). Ну такого лецимерия, такого ... (незнаю как выразиться) я не ждал. MS лет пять, опять повторюсь, ms лет пять всех трахала идеей о thin (то есть браузерном) софте, что все корпаративные системы должны быть на браузерах (да и SAP туда же). Долой отдельные проги. Они это пропихивали во все щели, и что? Обратно к rich клиентам! Обратно к той идеи, которые они САМИ обсирали грязью (я всегда думал, что thin клиент — чушь), и теперь они такие спасители всего бизнес софта, сволачи. У меня есть книжка "архитектура корпоративных систем" (написана мелкомягким год назад), где черным по белому пишется, что надо делать упор на thin клиентов, настольные клиенты — в попу их. А теперь они говорят совершенно противоположное.

BTA>Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).
Да да, убивали они её долго, щас же они её воскрешают, и типа это их заслуга.

... << RSDN@Home 1.1.3 stable >>

А как же меня БЕСИТ "модель событий", реализованная в дотнетовских компонентах!!! Полнейший дебилизм и беспредел! Чего только стоит засовывание события "ColumnChanging" в Binding!

Зато мусора, вроде "TextChanging" у формы — горы! Да нафига мне ловить событие изменения заголовка формы?!?!?!? Типа, крутА!?!?

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

PPA>Есть же сторонние разработки http://www.devexpress.com/
PPA>судя по демкам, их C# решение тормознее родного делфевого (иногда раза в 2),
PPA>но они наверное пока не занимались оптимизацией.

Больше чем в два раза, на глаз, и оптимизировать там уже нечего — потому что тормозит софтовый GDI+.

Здравствуйте, Shhady, Вы писали:

S>Ты не поверишь, я долго ржал (чуть не плача), я ругался матом во всё горло, когда увидел smart клиенты, которые теперь продвигает ms (раньше были thin). Ну такого лецимерия, такого ... (незнаю как выразиться) я не ждал. MS лет пять, опять повторюсь, ms лет пять всех трахала идеей о thin (то есть браузерном) софте, что все корпаративные системы должны быть на браузерах (да и SAP туда же). Долой отдельные проги. Они это пропихивали во все щели, и что? Обратно к rich клиентам! Обратно к той идеи, которые они САМИ обсирали грязью (я всегда думал, что thin клиент — чушь), и теперь они такие спасители всего бизнес софта, сволачи. У меня есть книжка "архитектура корпоративных систем" (написана мелкомягким год назад), где черным по белому пишется, что надо делать упор на thin клиентов, настольные клиенты — в попу их. А теперь они говорят совершенно противоположное.

Ты про развитие по спирали слышал? Вот это оно тебя задело лично.

Ну, а что касается до рекламных криков, то их нужно уметь слушать с здравой долей скепсиса. Иначе уши до пола оттянутся от лапши.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Вот беру ILDASM и натравливаю его не exe-шник Navision 3.7. Результат не удивляет — "error: '...\fin.exe' has no valid CLR header and cannot be disassembled." То есть исполняемый файл не дотнетовский (как вариант — может быть запакован какой-нить гадостью). Берем все основные длл-ки — тот же результат. Вопрос — а что в нем дотнетовского-то?

Тоже самое ILDASM говорит на MSCOREE.DLL.

И на devenv.exe из поставки Visual Studio.Net 2003. И на VCSExpress.exe из Visual C# Express. И еще на многие другие "совершенно не-дотнетовские программы".

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, B0rG, Вы писали:

BG>Я бы начал прежде всего с вопросов сколько у Вас есть ресурсов под этот проект?
BG>Временных, денежных, человеческих?
Ресурсы, так сказать, неограничены. Но все же не хочеться, чтоб разработка была вечно.

BG>Объектные базы писать — задача довольно тяжелая и трудоемкая, как тут уже упоминалось, к тому времени как Вы ее допишете — стандартные клиентские машины будут раза в 2 быстрее

Да, я уже то же склоняюсь к этой мысли.

BG>Вы наверняка собираетесь двигаться в направлении клиент-сервер. дотНет в этом смысле позволяет сделать распределенную аппликуху при минимальных затратах — будь это веб клиент или десктоп клиент. Дальше если сервер, делающий основную работу начинает часто засыпать — можно поставить второй такой серевер и третий.
Продукт для всего рынка, это не "контрактный" продукт под определенную фирму (где можно прогнуть модернизацию PC). Тут такие финты ушами, как "для нашей erp нужны самые передовые компьютеры и гигабитные сети" не прокатят (мыж не ms)

BG>Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д.
Мы стараемся как можно сильнее минимизировать пересылки между клиентом и сервером, при этом не потерять безопасность и валидность данных. Данные варьируются от простых данных, до документов.

BG>ERP очень красивый термин, конечно даа, только к сожалению черезчур всеобъемлющий

У нас так же всеобъемлющая erp, которая "может всё (с)"

Shady

Здравствуйте, PPA, Вы писали:

PPA>Здравствуйте, Shhady, Вы писали:

PPA>>>p.s.
PPA>>> А чем Вам готовые СУБД не подошли?
S>>1) Проект stand alone — всё в себе, в том числе и база.

PPA>Это условие клиента?
У нас нет клиента, мы делаем продукт для рынка.

S>>То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят),

PPA>Написать свою субд, способную держать одновременно 1000 активных коннектов...
PPA>Вы случаем не камикадзе?

Мы вообще сумасшедние люди

S>> хотя клиент может выбрать и готовую через драйвер базы.

PPA>Тут я не понял, что еще за драйвер?
PPA>т.е. пользователь может выбрать любую субд?
PPA>тогда что будет делать ваша самодельная БД?
У нас идея: с erp по дефолту поставляется наша база (уменьшает стоимоть), если клиент хочет использовать что-то от грандов, то пожалуйста. Эта идея (с нашей БД) частично отпала. Мы может быть сделаем нашу БД в будущем, взамен в дефолтной поставке будут драйвера для бесплатных баз.

PPA>Имхо если не завязываться под конктретный сервер — тормоза на уровне
PPA>БД гарантированны.
У нас "хитрые" дравера. Описать я их не могу (то же вроде патентуется). Прошли испытания, никаких тормазов

Причем можно очень легко писать новый драйвер под новую БД.

PPA>Создание ERP, (а особенно ее внедерение) сложная задача, а Вы еще
PPA>беретесь за создание своей субд...
Сейчас браться не будет (создавать БД), в будущем... А про сложность erp: "волков бояться, в лес не ходить"

PPA>Рисковано... Что хоть Вам сделают если не получится?

Как говоил Ильич: "РАССТРЕЛЯТЬ!". Мне лично ничего не сделают (уж слишком я уникальный)

Рисковано да, потом в нашей erp реализовано очень много уникальных фич, коотрые у sap и ms могут появиться только в будущем. Потом наша erp сама по себе уникальна, она позволяет построить на своей основе от CRM до документооборота, причем без последствий для производительности и удобства использования. Она "мега расширяема" (так в драфтах проекта

) без потери целостности и безопастности

Здравствуйте, <Аноним>, Вы писали:

А>Я знал, что это была большая чушь. Просто офигивал от промывки мозгов (когда со всех сторон, во всех статьях rich client MUST DIE!!!!

), а вот теперь обратное действо. sic.

А ты не видел рекламной компании ДиджиталВошБорд?

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, Voblin, Вы писали:

V>3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.

Вы просто не умеете ее готовить

... << RSDN@Home 1.1.4 beta 3 rev. 190>>

Здравствуйте, Shady, Вы писали:

V>>2. Полная автоматизация планирования производства, бухгалтерии, CRM, SCM, ABC- и XYZ-анализ, хз что ещё. В этом случае забудь про C#, C++, .NET, Java и прочие прелести. Поднять такое — нереально. Говорю как оптимист со стажем.
S>Вот это в самый раз. Мы именно это и хотим сделать. Вот только не понятно, почему поднять такое — нереально. Axapta, Sap, PeopleSoft, 1C — подняли, а мы не сможем?
S>Говорю как оптимист со стажем.
Они все (может быть, за исключением PeopleSoft, о котором ничего сказать не могу) сначала сделали свою среду разработки, и уже на ней поехали в ERP.

S>У меня есть тоже некий опыт, и распространенное мнение, что ERP/CRM/HRM — дело непосильное, пропагондируют SAP, MS, PeopleSoft

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

V>>3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.
S>А вот это вообще непонятно, при чем сдесь VS, это ж только IDE, или я не уловил глобальный смысл? Но сравнения мне понравились

Если на VS сляпать средство разработки, а потом на нём сляпать ERP, то я согласен. Так делать можно.
Только нужна твёрдая уверенность в том, что получившееся средство будет РАДИКАЛЬНО лучше аксапты или 1С. Притом не теперешних, а тех, какими они будут через пару лет.
В любом случае, сильно отговаривать не буду. Не догоните, так согреетесь

. Но входить в финансовые обязательства под это дело я бы не посоветовал.

Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.
Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

Тут я сумбур написал, вот выдержки:
1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

p.s. если это баян, жестоко извиняюсь.

... << RSDN@Home 1.1.3 stable >>

27.09.04 11:10: Перенесено модератором из '.NET' — TK

06.10.04 15:26: Оставлено модератором в 'Философия программирования' — AndrewVK

Здравствуйте, Shhady, Вы писали:

S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged

Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.

S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

Можно. Вот только на счет летало — это больше от алгоритмов зависит.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, VladD2, Вы писали:

VD>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная. Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается объект -> читает свои данные с диска -> посылается клиенту (это я утрировано, чисто пример). Вот тут всплывает GC, если выборка пришла на 1000 объектов, то они же будут весеть какое-то время в памяти сервера (хотя на c++ это можно мигом оптимизировать) после обработки, и память кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

VD>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
Это ладно. Я впринципе понял, что можно. Но вот база...

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Shhady, Вы писали:

S>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++),

Если выбор между C++ и C#, то даже думать не нежно. Однозначно выбирайте Шарп. Писать серверы на плюсах — это одно мучение. Основное время будете тратить на вылов багов. Причем вылезуть они когда система уже будет работать. Все эти утички памяти и т.п.

С производительснотью в худшем случае вы проиграете 20-30 проценов. Но в надежности выиграете намного больше.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, Shhady, Вы писали:
VD>>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
S>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная.

Вы и СУБД хотите сами написать на С#?
или всеж только клиентов?

S> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

А не боязно без практики браться за такой большой проект?

VD>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>Это ладно. Я впринципе понял, что можно. Но вот база...

что база то?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: Moonspell — Awake ]>>

Здравствуйте, xvost, Вы писали:
X>2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO).

В чем будет секс?
И не совсем понятно как сервер связан с клиентами?
Зачем им обоим нет?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: Moonspell — For a taste of eternity ]>>

Здравствуйте, PPA, Вы писали:

PPA>Здравствуйте, Shhady, Вы писали:
VD>>>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
S>>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная.

PPA>Вы и СУБД хотите сами написать на С#?
PPA>или всеж только клиентов?
Почему сам? Я что где то такое написал?

Я только архитектор

S>> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

PPA>А не боязно без практики браться за такой большой проект?
Писать буду не я, но надо определиться инструментами.

VD>>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>>Это ладно. Я впринципе понял, что можно. Но вот база...

PPA>что база то?

Можно ли писать на c# то

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Shhady, Вы писали:

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

.NET Framework требует как минимум Win98, неужели даже Win95 еще работает?

Здравствуйте, xvost, Вы писали:

X>Машины класса PIII-500 128mb потянут только очень легкие .NET приложения.
печально, но реалия такова

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, henson, Вы писали:

H>.NET Framework требует как минимум Win98, неужели даже Win95 еще работает?
А мне казалось и на w95 есть дистрибутив. W95 имею право на жизнь как и p3-533

... << RSDN@Home 1.1.3 stable >>

Доброго времени суток!

Здравствуйте, Shhady, Вы писали:

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.

В данный момент тоже работем над подобным проектом!
Щас работает проект написанный на VB 6.0, база Access. База как как центральная, так и клиентские, очень сильно растут (обороты растут). Самая большая проблема щас это вывод в грид (тяжело конечно!!!)!
В перспективе клиентов на порядок больше, а с центральной базой будет работать примерно 300 человек!

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

С требованиями у нас конечно получше будет! Celeron 1.8, 512 ram. В переспуктивах конечно будет лучше.

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

S>p.s. если это баян, жестоко извиняюсь.

В ценлом могу сказать что потянет! Правда со временем, конечно, технику стоило б заменить, но вот как уговорить клиента на это (

правда???).

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, PPA, Вы писали:

X>>2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO).

PPA>В чем будет секс?
Одна из проблем будет в том, что потеряется возможность просто (не вообще, а именно без особых трудозатрат) проводить рефакторинг. Изменение протокола связи, формата данных, перенос части логики на клиент и обратно — если обе стороны на дотнет все это сильно проще и дешевле.

... << RSDN@Home 1.1.4 beta 2 >>

Ха, прикольный топик. Сам уже около полугода бъюсь над этим "филосовским" проектом.

Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.

Проблема, как правило, в архитектуре и возможностях ADO.NET. Оно хорошо (по словам майкрософта) для веба, хорошо (по словам майкрософта) для серверных компонентов, но это АД для WinGUI-приложений.

Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).

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

Опять же, сами майкрософтовцы еще не смогли реализовать ничего толкового, в плане ЕРП, используя дотнеть.

ЗЫ: Не сервером и вебом едиными...

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Вот одно мое личное наблюдение: в таких топиках, как этот, НИКОГДА НЕ УЧАВСТВУЮТ ЛЮДИ ИЗ МАЙКРОСОФТ, а они ведь тута имеются!!! Даже приближенных к майкрософту не бывает. Все подобные вопросы остаются вегда либо без конкретного ответа, либо все ответы — домыслы отдельных людей.

Хотя может они никогда и не читают тут ничего? У них же есть архитекторы, нафига всяких "левых" девелоперов слушать?

АУ! ЛЮДИ ИЗ МАЙКРОСОФТА! СПУСТИТЕСЬ НЕНАДОЛГО НА НАШУ ГРЕШНУЮ ЗЕМЛЮ, ХВАТИТ ТАМ В ВЫСШИХ МАТЕРИЯХ ТУСОВАТЬСЯ! ЭТОТ ТОПИК — ВАМ!

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, BlackTigerAP, Вы писали:
BTA>Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).

Есть же сторонние разработки http://www.devexpress.com/
судя по демкам, их C# решение тормознее родного делфевого (иногда раза в 2),
но они наверное пока не занимались оптимизацией.

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: Metallica — Astronomy ]>>

Здравствуйте, Shhady, Вы писали:
PPA>>Вы и СУБД хотите сами написать на С#?
PPA>>или всеж только клиентов?
S>Почему сам? Я что где то такое написал?

Я только архитектор

Вы у своих девелоперов спрашивали что им предстоит сделать?
Что говорят?

S>>> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

PPA>>А не боязно без практики браться за такой большой проект?
S>Писать буду не я, но надо определиться инструментами.

С этим должны определяться разработчики, архитекторов производительность и сборка мусора не должна имхо волновать.
Если разработчики нули в шарпе, то браться за такой проект — самоубиство

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

VD>>>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>>>Это ладно. Я впринципе понял, что можно. Но вот база...

PPA>>что база то?

S>Можно ли писать на c# то

Клиентов можно — 100%.
СУБД на шарпе — имхо работать будет только теоретически

p.s.
А чем Вам готовые СУБД не подошли?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: Metallica — THE UNFORGIVEN II ]>>

Инфа, действительно, ОЧЕНЬ непроверенная. Никакой дотнети нету там и в помине. Как было ЦПП, так и осталось.

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Инфа, действительно, ОЧЕНЬ непроверенная. Никакой дотнети нету там и в помине. Как было ЦПП, так и осталось.

Речь именно о 3.7?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Инфа, действительно, ОЧЕНЬ непроверенная. Никакой дотнети нету там и в помине. Как было ЦПП, так и осталось.

Кстати тут на форуме был человек, кот. утверждал что Navision был написан чуть ли не на Delphi. Он-таки непрв?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

DevExpress...

Да если бы не было их компонентов, давно бы послал уже дотнеть куда-подальше, на уровень ПХП, не больше! Кстати, не тормозят они. Тормозит дотнеть — ее не сильно пооптимизируешь. DevExpress-овцы выжали МАКСИМУМ, неплохо причесали события. Ляпы, конечно тоже имеются.

В ОБЩЕМ — НАС РАТЬ, И НАМ НАСРАТЬ НА ВАС, ДОРОГИЕ РАЗРАБОТЧИКИ WINGUI-ПРИЛОЖЕНИЙ (с) Microsoft

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Миллионы?!?!? Приведите мне TOP 1000 пожалуйста, РЕАЛЬНО использующих! И я расслаблюсь.

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, PPA, Вы писали:

PPA>Вы у своих девелоперов спрашивали что им предстоит сделать?
PPA>Что говорят?
Девелоперов никто не спрашивает

(шутка).
Девелоперы будут наняты под проект, или переброшены с других (шарповцов в нашей конторе хватает)

PPA>С этим должны определяться разработчики, архитекторов производительность и сборка мусора не должна имхо волновать.
PPA>Если разработчики нули в шарпе, то браться за такой проект — самоубиство

PPA>Конечный пользователь не оценит, то что все сделано на модном нете-е, им нужно чтоб работала система в целом, и работала быстро.
Просто есть некие архитектурные решение, зависящие от реализации, вот мне и надо определиться.

PPA>СУБД на шарпе — имхо работать будет только теоретически

PPA>p.s.
PPA> А чем Вам готовые СУБД не подошли?
1) Проект stand alone — всё в себе, в том числе и база. То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят), хотя клиент может выбрать и готовую через драйвер базы.

Здравствуйте, Аноним, Вы писали:

А>Нет, он не прав. Хотя откуда ноги растут у такого "утверждения", знаю. Дело все в том, что в качестве внутренного языка разработки Navision (нормального, а не Аксапты) был выбран Паскаль. А вот все остальные идеи — элементы Access-а. Ну плюс еще ОЧЕНЬ недурственный сервер, и несколько гениальных решений в плане архитектуры. Майкрософт, кстати, замалчивает эти идеи. То ли из-за того, что перестанет нужен OLAP, то ли при покупке, патент на эти технологии к ним не перешел. Поинтересуйся технологией "SIFT".

несколько гениальных решений в плане архитектуры

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

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Миллионы?!?!? Приведите мне TOP 1000 пожалуйста, РЕАЛЬНО использующих! И я расслаблюсь.
Ты, видимо, недооцениваешь масштабы разработки с использованием Windows.Forms.
Берем одну компоненту и видим, что стянули ее 1358 раз с одного только сайта. Если хотя бы 1% из стянувших использовал ее в реальном проекте, получаем уже 13 проектов с одной только компоненты. Из них, предположим, 2 пользуются относительной популярностью, т.е. имеют как минимум 50 пользователей. Дальше надо считать?

Как пример, вот игрушка на дотнете. Правда, на DirectX

Но это значит, что мелких полезных программок на дотнете уже много. И будет еще больше.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, BlackTigerAP, Вы писали:

BTA>И ничего я не разбушевался. Просто я хочу услышать от людей из майкрософта более-менее вразумительные мысли по данному поводу. Пусть они мне докажут, что я не прав. Если доводы будут вразумительные, то почему бы мне и не пересмотреть кое-какие мои взгляды на жизнь? Пока их "доводы" — "а вот!", а это, согласитесь, не довод.

Так спроси нормально, аргументируй. "Мне не нравится" — не аргумент. Аргумент, например может быть такой:

Почему в OnGotFocus и OnLostFocus не приходит Control, который потерял или получил фокус соответственно? Т.е. невозможно узнать от кого пришел фокус ко мне, и куда он от меня ушел.

BTA>Лично я привык смотреть на вещи с трех сторон, а не с одной. Никогда не понимал огалтелого оптимизма и фанатизма.
Никакого фанатизма. Реалии жизни. Большие проекты, сложные интерфейсы пользователя — все это делается на Windows.Forms. Да, иногда надо взять бубен в руки, иногда рефлектор, иногда изматериться и сделать через рефлекшн. Но — можно.

BTA>ЗЫ: теперь прекрасно понимаю, почему на западе учат не ДУМАТЬ, а следовать инструкциям.
Это к чему?

... << RSDN@Home 1.1.4 beta 2 >>

Привет Всем!

Я тут перекинул вопрос в чаты с экспертами Microsoft, ссылка:
http://www.gotdotnet.ru/Forums/Chats/67827.aspx.

Ну очень хочется услышать их мнение.

С уважением, Дмитрий Воронин!

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Кстати, есть такой адрес: http://www.neowin.net/forum/index.php?showtopic=205561&st=30. Неизвестно, насколько там верна информация, но есть среди нее такие строки:
Applications built on the .NET Framework
• Microsoft Business Solutions—Navision 3.7
• Microsoft Class Server 2.0–3.0
• Microsoft Commerce Server 2002 SP1
• Microsoft Content Management Server 2002 SP1
• Microsoft Exchange Server 2003
• Microsoft Office SharePoint™ Portal Server 2003
• Microsoft SharePoint Team Services 1.0 SP2
• Microsoft Windows SharePoint Services
ну и плюс через google находятся такие примеры, как http://www.astrosoft.ru/proposal/products_corsair_specification.asp

Sincerely yours,
Valery Chesnokov
<A href=http://chv.tele-kom.ru>http://chv.tele-kom.ru</A>

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Shhady, Вы писали:

PPA>>p.s.
PPA>> А чем Вам готовые СУБД не подошли?
S>1) Проект stand alone — всё в себе, в том числе и база.

Это условие клиента?

S>То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят),

Написать свою субд, способную держать одновременно 1000 активных коннектов...
Вы случаем не камикадзе?

S> хотя клиент может выбрать и готовую через драйвер базы.

Тут я не понял, что еще за драйвер?
т.е. пользователь может выбрать любую субд?
тогда что будет делать ваша самодельная БД?
Имхо если не завязываться под конктретный сервер — тормоза на уровне
БД гарантированны.
Создание ERP, (а особенно ее внедерение) сложная задача, а Вы еще
беретесь за создание своей субд...
Рисковано... Что хоть Вам сделают если не получится?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: silent ]>>

Враньё и дезинформация! Некоторые продукты ОБЕЩАЛОСЬ сделать на дотнети, но сделано этого не было. Какие-то элементы — не более.

Вот беру ILDASM и натравливаю его не exe-шник Navision 3.7. Результат не удивляет — "error: '...\fin.exe' has no valid CLR header and cannot be disassembled." То есть исполняемый файл не дотнетовский (как вариант — может быть запакован какой-нить гадостью). Берем все основные длл-ки — тот же результат. Вопрос — а что в нем дотнетовского-то?

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

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

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Вот беру ILDASM и натравливаю его не exe-шник Navision 3.7. Результат не удивляет — "error: '...\fin.exe' has no valid CLR header and cannot be disassembled." То есть исполняемый файл не дотнетовский (как вариант — может быть запакован какой-нить гадостью). Берем все основные длл-ки — тот же результат. Вопрос — а что в нем дотнетовского-то?

На axforum'е проскакивала информация, что таки трабуется фреймворк при установке Navision 3.7.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, PPA, Вы писали:

PPA>Клиентов можно — 100%.
PPA>СУБД на шарпе — имхо работать будет только теоретически

Да без проблем она будет работать. Они вон и да Яве неплохо работают. Во только проект может вылиться в поект одного сервера БД.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, PPA, Вы писали:

PPA>В чем будет секс?

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

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Вот одно мое личное наблюдение: в таких топиках, как этот, НИКОГДА НЕ УЧАВСТВУЮТ ЛЮДИ ИЗ МАЙКРОСОФТ, а они ведь тута имеются!!! Даже приближенных к майкрософту не бывает. Все подобные вопросы остаются вегда либо без конкретного ответа, либо все ответы — домыслы отдельных людей.

BTA>Хотя может они никогда и не читают тут ничего? У них же есть архитекторы, нафига всяких "левых" девелоперов слушать?

BTA>АУ! ЛЮДИ ИЗ МАЙКРОСОФТА! СПУСТИТЕСЬ НЕНАДОЛГО НА НАШУ ГРЕШНУЮ ЗЕМЛЮ, ХВАТИТ ТАМ В ВЫСШИХ МАТЕРИЯХ ТУСОВАТЬСЯ! ЭТОТ ТОПИК — ВАМ!

Дык, ты форумом ошибся http://gzip.rsdn.ru/Forum/Message.aspx?mid=805643&only=1

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, Lloyd, Вы писали:

L>Речь именно о 3.7?

Судя по гуглю там сделали веб-часть на АСП.НЭТ и какие-то там тулзы.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, henson, Вы писали:

H>.NET Framework требует как минимум Win98, неужели даже Win95 еще работает?

Прекрасно работают. Только IE нужно обновить и еще пару вещей. Просто они официально не поддреживаются.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, VladD2, Вы писали:
PPA>>СУБД на шарпе — имхо работать будет только теоретически

VD>Да без проблем она будет работать. Они вон и да Яве неплохо работают. Во только проект может вылиться в поект одного сервера БД.

Как зовется SQL сервер на яве?
И каковы его характеристики?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: silent ]>>

Здравствуйте, Igor Trofimov, Вы писали:

iT>Больше чем в два раза, на глаз,
iT>и оптимизировать там уже нечего — потому что тормозит софтовый GDI+.

Что значит софтовый GDI+?
Оптимизацией видюха разве не занимается?

... << RSDN@Home 1.1.4 beta 3 rev. 190 [Winamp: Moonspell — Perverse... almost religious ]>>

Здравствуйте, PPA, Вы писали:

PPA>Как зовется SQL сервер на яве?

Гугль тебе в руки: http://www.google.ru/search?hl=ru&ie=UTF-8&q=%D0%A1%D0%A3%D0%91%D0%94+%D0%BD%D0%B0+Java&lr=

PPA>И каковы его характеристики?

Это не мои заботы. Говорят вполне сносно...

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, PPA, Вы писали:

PPA>Лик детектируется очень просто.

Агащасблин. Бывают такие ситуации, что офигешь.

PPA>А если использвать врапперы, то он не будет вобще возникать.

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

PPA>с закусью памяти сложнее, но тоже решается...

Все решаемо. Вопрос во времени и силах.

PPA>Как я понял основной плюс для тебя в нете это GC?

Для меня плюсов настолько много, что я готов расстаться с теми плюсами которые есть у анменеджед кода (а именно, меньшие затраты памяти, и больший простор для низкоуровневых оптимизаций). Причем дело не только в дотенет. Дело и в более удобном и безопасном языке (Шарпе), и в библиотеках, и в защите, и много еще в чем.

PPA>Программеры как всегда ищут легкие пути не заботясь о конечном пользователе

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

PPA>RSDN@Home у меня жрет 50-60 мегов!

А у меня IE с одной стрничкой rsdn.ru занимает 20 меторов, ну, и? Пойти Оперу поставить и мучиться на половине сайтов? А студия 2005-ая вообще 120 метров жрет, а ведь в общем-то анменеджед-продукт.

PPA>Сколько попросит "самодельный" SQL сервер с 1000-коннектами?

Зависит от того как написать. В Хоуме тоже основную память Эксес отедает. Да и сколько эта память стоит?

PPA>Не будет он течь, но не по причине того что у .Net есть сборка мусора,
PPA>...а потому, что на машине от такой нагрузки ресурсы кончатся

Ну, как видишь на дотнете он есть. А вот нэйтивного нет. А ведь сайтов то на свете море.

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

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, PPA, Вы писали:

PPA>Что значит софтовый GDI+?
PPA>Оптимизацией видюха разве не занимается?

Ты возможности GDI+ изучал? Они почти все программно реализованы. Думали выпустить GDI+2, но видимо решили все отложить до Авалона в Лонгхорне.

... << RSDN@Home 1.1.4 beta 2 >>

>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.

Создал многопользовательскую систему для работы с удалёнными данными. Её архитектура и основные функции описаны в статье "К вопросу построения прототипа защищённых информационных систем". Проверить работу с 1000 клиентами нет возможности. Хотя можно убрать шифрование и оценить производительность. Работаю с двумя версиями — через .Net Remoting сервис поверх IIS и через .Net Remoting сервис поверх .Net Remoting Server. Большой разницы в производительности не наблюдаю. Но факт — через IIS работают тысячи клиентов. В вашей ситуации видимо надо переложить основные операции по работе с данными на уровень бизнес-логики (по возможности), клиентской части оставить отображение. Крайне важно не передавать на клиентский компьтер не нужную информацию. Детализация данных (по возможности) должна передаваться по дополнительному запросу. Например — выбрать покупателей Ивановых (SELECT на уровене бизнес логики и закачка результирующего набора данных в локальный DataSet) и показать в гриде. Выбор Иванова Петра Егоровича (например правой клавишей мышки) вызовет показ в другом гриде его заказов.
Могу утверждать, что клиентский компьютер с таким камнем будет работать, может придется увеличить память до 256.

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

Успехов Вам.

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Shhady, Вы писали:

S>2. ... И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

Не надо издеваться над несчастными компьютерами со 128 ram. Операционная система столько сьедает, и на таких компьютерах желательно больше вобще ничего не запускать (в том числе и .NET приложения). А что дороже стоит дополнительные +128 ram каждому клиенту или цена вашей системы?
Дык эти дополнительные +128 они ж не только для запуска вашей системы могут использоваться...

2Владимир: Крайне важно не передавать на клиентский компьтер не нужную информацию.

Вот тут я с тобой полность согласен.

Детализация данных (по возможности) должна передаваться по дополнительному запросу

Совсем не обязательно, например вызов "тяжёлого" вебметода дорогое удовольствие.

В данном случае есть экономичное решение, отказаться от ADO.NET для передачи данных на клиента и от клиента, всё идет через бизнес объекты, но сразу скажу что это не для ленивых

У меня бизнесобъекты сериализируются в XML. На клиенте могут десириализироваться в объекты обратно или же можно колбасится напрямую в XML (это для случая java client).

.NetCoder

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Shhady, Вы писали:

S>Не будет ли грохать производительность/память GC?

Работа с базой это не тот случай когда работа джита или GC на что либо повлияет.

... << RSDN@Home 1.1.4 beta 3 rev. 190>>

Здравствуйте, VladD2, Вы писали:

BTA>>Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.

VD>А сколько по твоему такая система пишется? И когда появился дотнет? Вычти из второго первого, прибавь время на раскачку контор и поймешь почему это так. К тому же ты не прав. Я точно знаю, что во многих московских конторах делаются подобные проекты и они очень близки к сдаче. Ну, а на западе таких проектов просто море.

Из российских могу назвать Компас.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, valeri, Вы писали:

V>Интересный момент. Вы хотите сказать, что создать свою промышленную СУБД будет дешевле готовых, таких, как Oracle, MS SQL etc.? Стоимость их покупки и линензий — это несколько тысяч долларов, в большинстве случаев всего примерно до двух десятков ли меньше. А это, с другой стороны, зарплата команды двух-трех профессиональных разработчиков максимум на 2-3 месяца. Плюс время обкатки своей СУБД на реальных объемах, которые даст только запуск проекта промышленного масштаба, т.е. эксперимент над заказчиком, а он чаще всего не любит отрицательных результатов

Мы не создаем "промышленную СУБД", мы создаем, если можно так выразиться, объектный персистентный компонент erp системы, который используют другие подсистемы для хранения информации. Но так как функциональность в принципе схожа с СУБД, то мы называем этот компонент СУБД. Но еще раз отмечаю, что это не "промышленное" СУБД (которое может быть использовано другими разработчиками или продоваться отдельно), функциональность пересикается (обрабоктка sql (скорее oql) ), но всё же это не то. Потом наше ВСУБД (внутренее СУБД) использует расширяемые компоненты для хранения, то есть в готовом решении заказчик получает ВСУБД с нашим компонентом сохранения, если он нам не доверяет, может либо заказать компонент под конкретное СУБД, либо использовать уже написанные компоненты для хранения в MS SQL или ORACLE, ВСУБД можно назвать объектной надстройкой над другими СУБД, но с большой натяжкой.
V>Создание объектной СУБД поверх SQL для обработки больших объемов данных задача также нетривиальная. Есть мысль, что выбор серверных технологий и технологий обработки данных (сервер приложений, web сервисы etc.) окажет решающее влияние на производительность системы.
Да, задача не из простых, поэтому наше ВСУБД имеет свой компонент сохранения, чтоб минимизировать лишние операции мапинга таблиц и объектов (лишнее запросы sql к внешним базам), но если заказчик хочет использовать sql базу, он просто пишет свой компонент расширения (соответственно с ручным мапингом, хотя есть идеи упростить этот этап в разы).
Web сервисы нам не подходят по одной простой причине: невозможность легко организовать работу клиента в оффлайне. Хотя есть идеи, что можно тащить web сервисы к клиенту, но получается осложнения для сторонних разработчиков компонент (наши девелоперы всё стерпят). Поэтому у нас есть свои "web сервисы", называемые компонентами, но с функциональностью, которая нам нужна (работа в оффлайне, простота в разработке). Если заказчику нужны будут веб сервисы, он их с легкостью прикрутит, но мы на них ставку не делаем. Сервер приложений имеется. У нас 3 тирная (или 2 тирная, если нет внешних субд) среда.
V>Я бы не стал рисковать и делать всё своё одним проектом, их нужно делать и проверять как отдельные этапы.
Мы так и делаем

Из за неких проблем, мне придется писать из под анонима.
Shady

Здравствуйте, Silver_s, Вы писали:

S_>Не надо издеваться над несчастными компьютерами со 128 ram. Операционная система столько сьедает, и на таких компьютерах желательно больше вобще ничего не запускать (в том числе и .NET приложения). А что дороже стоит дополнительные +128 ram каждому клиенту или цена вашей системы?
S_> Дык эти дополнительные +128 они ж не только для запуска вашей системы могут использоваться...
Мы бы рады, но такая конфигурация вылезла из анализа наших гипотетических клиентов. Потом у нас идея фикс: erp со скоростью света.
Еще раз повторюсь, если есть какое то недопонимание, наша erp не "заказная", она для всего рынка. Мы не можем себе позволить, если клиент покупает нашу erp, чтоб он заменял все свои компьютеры.

Shady

Здравствуйте, PPA, Вы писали:

PPA>Сколько попросит "самодельный" SQL сервер с 1000-коннектами?
PPA>Не будет он течь, но не по причине того что у .Net есть сборка мусора,
PPA>...а потому, что на машине от такой нагрузки ресурсы кончатся

Shady

Здравствуйте, VladD2, Вы писали:

VD>Ты про развитие по спирали слышал? Вот это оно тебя задело лично.

Ну, а что касается до рекламных криков, то их нужно уметь слушать с здравой долей скепсиса. Иначе уши до пола оттянутся от лапши.
Я знал, что это была большая чушь. Просто офигивал от промывки мозгов (когда со всех сторон, во всех статьях rich client MUST DIE!!!!

), а вот теперь обратное действо. sic.

Shady

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Shhady, Вы писали:

S>>1) Проект stand alone — всё в себе, в том числе и база. То есть заказчик не будет платить за продукт + еще базу (причем база может дороже продукта), а сразу получить всё готовое (mysql, или другие бесплатные базы не подходят), хотя клиент может выбрать и готовую через драйвер базы.

VD>Есть совершенно бесплатный MSSQL Express (теперича, ранее Desctkp Edition). Нистоит ничего. При этом дает возможность если что легко перепрыгнуть на полноценный MSSQL в плодь до энтерпразной версии. Почему не рассмотреть его?
Для некомерческих проектов и для баз с < 4 гигами

VD>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
Для некомерческих проектов.

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

Мы просто оставим место для оной, что впоследствии можно было прикрутить, а пока сделаем персистные компоненты под MS SQL, ORACLE, MYSQL.

Я сейчас всё больше и больше склоняюсь к c#.

Shady

>>Тоже самое ILDASM говорит на MSCOREE.DLL.

>>И на devenv.exe из поставки Visual Studio.Net 2003. И на VCSExpress.exe из Visual C# Express. И еще на многие другие "совершенно не-дотнетовские программы".

Хочешь гадость скажу? А кто тебе сказал, что ЭТИ exe-шники на дотнети написаны? Написаны они на C++, не более того!

—

"Real programmers don't comment their code.
If it was hard to write, it should be hard to understand."

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, valeri, Вы писали:

А>Приветствую,
А>вы знаете, приведу еще пару доводов по данному вопросу.

А>Во-первых, для тех, кто еще помнит, как создавалось ПО на Visual Studio 6.0, сколько там было разных сущностей для работы, например, со строками.
А>Давайте посчитаем: char *, basic_string template из STL, CString, BSTR, CComBSTR из ATL, класс _bstr_t, всякие макросы типа OLESTR, L"", _T() и т.д. Затем, String из Visual Basic 6, на котором писались ActiveX визуальные компоненты. Наверняка я не все вспомнил. И сколько памяти, утечек и времени уходило в результате таких преобразований?
Да почему, в VS 7.1 ничего не изменилось. Еще Variant — чума com.

А>Неужели наличие одного типа System.String в .NET Framework не убеждает в большей производительности создания и готового кода?
Где то я слышал, что стринги нета быстрее stl.

А>И второе.
>>MS SQL или ORACLE, ВСУБД можно назвать объектной >надстройкой над другими СУБД, но с большой натяжкой.
А>Есть такой опыт. Что называется, не оглашая имен, скажу, что одна московская фирма, между прочим, как считается, российский лидер автоматизации одной из отраслей промышленности, два года делала проект, включающий в себя объектную СУБД поверх SQL, как минимум Oracle и MS SQL Server. Так вот, как раз это ядро весьма далеко от совершенства, и ему предстоит серьезная переделка после эксплуатации в реальных условиях. А время и деньги затрачены.
А>Вот такие бывают истории.
А>Желаю вам удачи в выборе технологий.
Спасибо за пример.

Shady

Кстати, стоит ли забивать на unix? Я понимаю, что тема не раз вроде всплывала, и всё таки?
Маркетологи где то нашли цифры в 10-15% клиентов, пожелавших чтоб сервер работал на unix, и что это одна из фич, на которую смотрят клиенты. Когда там .net перекатит на unix, и будет ли это бесплатным

(хотя проект mono заслуживает внимания, только я там не понял, бесплатный ли он будет).
Да и снежение стоимости опять. Так как мне принимать решение (маркетологи и так мозги все прожужали), это теперь главный вопрос в выборе платформы для меня.

Shady

Здравствуйте, Igor Trofimov, Вы писали:

VD>>>Так же есть InterBase в бесплатном варианте. Да и вообще много чего есть.
А>>Для некомерческих проектов.

iT>Это не так.

Да действительно, извините, если кого ввел в заблуждение.

Shady

Shhady -> "Стоит ли делать на .net erp систему?" :

S> Хотел поинтересоваться, можно ли реализовать erp систему на c#,
S> которая может обслуживать до 1000 юзеров одновременно, да еще и
S> распределенно (юзеры частично выполняют бизнес логику), да еще со
S> своей объектной базой данных (то же на .net)? Клиенты smart'ы.
S> Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)?
S> Да еще в наших суровых условиях (когда компы у юзеров ну
S> максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и
S> бутерброды с колбасой хавали, пока клиентское приложение удасужит
S> загрузиться?

Я так думаю, что к тому времени как все это допишется — у пользователей
будут стоять нормальные машины с виндой 2010

Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас

Posted via RSDN NNTP Server 1.9 gamma

Здравствуйте, Shhady, Вы писали:

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#......

Что подразумевается под понятием ERP-система? Варианты:
1. "Манагеры хотят знать, сколько товара на складах лежит". Такую систему хоть на бэйсике пиши, разницы никакой.
2. Полная автоматизация планирования производства, бухгалтерии, CRM, SCM, ABC- и XYZ-анализ, хз что ещё. В этом случае забудь про C#, C++, .NET, Java и прочие прелести. Поднять такое — нереально. Говорю как оптимист со стажем.
3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.

Неограниченных ресурсов не бывает

Например, Вы уже признались в том, что, по крайней мере, Ваши ресурсы будут ограниченными пользовательской компьютерной базой. Не хочу гнуть пальцы, но мне кажется, что переоценка ресурсов (и их ограниченности в том числе) — одна из самых распространненых ошибок в проектировании софта (да и не только софта).

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

Опять же не стоит секретничать по поводу характера передаваемых данных, потому как работа с вордовыми документами трансакционна — скачал документ (пускай подождал немного), поправил, закачал обратно. Другое дело warehousing — огромные списки товаров, длинные накладные etc — совсем другая специфика.

Я тут пару лет назад для одного астрономического проекта делал домашнюю работу по XML объектным базам данных, результатов вышло немного, да и проект загнулся по причине своей астрономичности, но может быть эта ссылка съекономит Вам несколько минут, часов, дней:
http://www.livejournal.com/users/b0rg/63266.html

Cheers
Pete

BG>>Я бы начал прежде всего с вопросов сколько у Вас есть ресурсов под этот проект?
BG>>Временных, денежных, человеческих?
А>Ресурсы, так сказать, неограничены. Но все же не хочеться, чтоб разработка была вечно.

BG>>Объектные базы писать — задача довольно тяжелая и трудоемкая, как тут уже упоминалось, к тому времени как Вы ее допишете — стандартные клиентские машины будут раза в 2 быстрее

А>Да, я уже то же склоняюсь к этой мысли.

BG>>Вы наверняка собираетесь двигаться в направлении клиент-сервер. дотНет в этом смысле позволяет сделать распределенную аппликуху при минимальных затратах — будь это веб клиент или десктоп клиент. Дальше если сервер, делающий основную работу начинает часто засыпать — можно поставить второй такой серевер и третий.
А>Продукт для всего рынка, это не "контрактный" продукт под определенную фирму (где можно прогнуть модернизацию PC). Тут такие финты ушами, как "для нашей erp нужны самые передовые компьютеры и гигабитные сети" не прокатят (мыж не ms)

BG>>Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д.
А>Мы стараемся как можно сильнее минимизировать пересылки между клиентом и сервером, при этом не потерять безопасность и валидность данных. Данные варьируются от простых данных, до документов.

Здравствуйте, VladD2, Вы писали:

L>>Речь именно о 3.7?

VD>Судя по гуглю там сделали веб-часть на АСП.НЭТ и какие-то там тулзы.

В Парус 8.5.2 аналогично.

... << RSDN@Home 1.1.4 beta 3 rev. 190>>

Здравствуйте, AndrewVK, Вы писали:

VD>>Судя по гуглю там сделали веб-часть на АСП.НЭТ и какие-то там тулзы.

AVK>В Парус 8.5.2 аналогично.

Как я понял в Парусе ведь делается отдельный проект с ОО-моделью на дотнете. Верно?

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, VladD2, Вы писали:

AVK>>В Парус 8.5.2 аналогично.

VD>Как я понял в Парусе ведь делается отдельный проект с ОО-моделью на дотнете. Верно?

Отдельный тоже, но он пока не готов.

... << RSDN@Home 1.1.4 beta 3 rev. 190>>

Может, стоит повременить?
Технология, насколько я понимаю, на больших проектах еще не опробирована...
Вот лет через 5... Когда в магазинах появятся книги типа "Горький вкус Java" или "Типичные ошибки проектирования", но только по .net — вот тогда, пожалуй, и можно будет начинать...
Слишком большой пока технологический риск...
И, зная любовь Microsoft к новизне и нелюбовь поддерживать старое, я бы очень хорошо и сильно подумал, а стоит ли выбирать .Net в качестве инструментальной платформы для приложения такого масштаба... Посмотрел бы на историю COM, MTS, COM+, VB и прочего, во что народ вкладывал деньги и время...

Из этого не стоит делать вывод, что .Net для больших проектов не подходит... пока не доказано обратное

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Shhady, Вы писали:

S>>Хотел поинтересоваться, можно ли реализовать erp систему на c#......

V>Что подразумевается под понятием ERP-система? Варианты:
...
V>2. Полная автоматизация планирования производства, бухгалтерии, CRM, SCM, ABC- и XYZ-анализ, хз что ещё. В этом случае забудь про C#, C++, .NET, Java и прочие прелести. Поднять такое — нереально. Говорю как оптимист со стажем.
Вот это в самый раз. Мы именно это и хотим сделать. Вот только не понятно, почему поднять такое — нереально. Axapta, Sap, PeopleSoft, 1C — подняли, а мы не сможем?
Говорю как оптимист со стажем.
У меня есть тоже некий опыт, и распространенное мнение, что ERP/CRM/HRM — дело непосильное, пропагондируют SAP, MS, PeopleSoft

V>3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.
А вот это вообще непонятно, при чем сдесь VS, это ж только IDE, или я не уловил глобальный смысл? Но сравнения мне понравились

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, B0rG, Вы писали:

BG>Неограниченных ресурсов не бывает

BG>Например, Вы уже признались в том, что, по крайней мере, Ваши ресурсы будут ограниченными пользовательской компьютерной базой. Не хочу гнуть пальцы, но мне кажется, что переоценка ресурсов (и их ограниченности в том числе) — одна из самых распространненых ошибок в проектировании софта (да и не только софта).
Полностью с вами согласен.

BG>Я бы посоветовал добиться от начальства примерных сроков и примерных денег на этот проект, а пока начальство думает-решает, сесть самому (или посадить кого-нибудь из команды) за написание прототипа, но при этом дать ему ограниченное количество времени и ограниченный набор задач — скажем, забросить безопасность и сконцентрироваться только на приеме, доставке и обработки данных. Даже если проект загнется, по крайней мере один человек в команде будет знаком с технологией. Основываясь на своем опыте разработки — чем дальше в лес, тем толще партизаны: у каждой системы, платформы, языка есть ограничения которые проявляются только тогда, когда начинаешь разрабатывать задачу более конкретно.
У нас есть задокументированная архитектура (вплоть до мелочей), изначально проект планировалось делать на c++, это было отражено в разделе "реализация", где всё подробно описано. Прототип на c++ так же уже имеется (так как в "реализации" всё было подробно описано, программеры написали прототип без gui за 1 месяц). Сейчас делают прототип на .net (я настоял), после сравнения скорости разработки/производительности, будет выбрано направление. К сожалению, .net проигрывает (неделя, уже 50% сделано, но производительность падает на 30%) в скорости, и так как у нас всё продумано, и никаких сюрпризов не предвидется, проект, как не прискорбно, будет на c++ (наверное). Так что ограничения (парк компьютеров), мы словили на начальном этапе планирования.

BG>Опять же не стоит секретничать по поводу характера передаваемых данных, потому как работа с вордовыми документами трансакционна — скачал документ (пускай подождал немного), поправил, закачал обратно. Другое дело warehousing — огромные списки товаров, длинные накладные etc — совсем другая специфика.
Так как у нас система "для всего", то мы и документы пересылаем, так и работает со списками товаров и т.д. Наша система изначально ориентирована на обработку множества мелких запросов, а прикрутить обработку документов, очень просто (вот обратное, очень сложно).

BG>Я тут пару лет назад для одного астрономического проекта делал домашнюю работу по XML объектным базам данных, результатов вышло немного, да и проект загнулся по причине своей астрономичности, но может быть эта ссылка съекономит Вам несколько минут, часов, дней:
BG>http://www.livejournal.com/users/b0rg/63266.html
Спасибо за ссылку, обязательно посмотрю.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, cvoronin, Вы писали:

C>Может, стоит повременить?
Эта мысль у меня пробегала.

C>Технология, насколько я понимаю, на больших проектах еще не опробирована...
C>Вот лет через 5... Когда в магазинах появятся книги типа "Горький вкус Java" или "Типичные ошибки проектирования", но только по .net — вот тогда, пожалуй, и можно будет начинать...
C>Слишком большой пока технологический риск...
C>И, зная любовь Microsoft к новизне и нелюбовь поддерживать старое, я бы очень хорошо и сильно подумал, а стоит ли выбирать .Net в качестве инструментальной платформы для приложения такого масштаба... Посмотрел бы на историю COM, MTS, COM+, VB и прочего, во что народ вкладывал деньги и время...
Это я тоже учитываю.

C>Из этого не стоит делать вывод, что .Net для больших проектов не подходит... пока не доказано обратное

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Shady, Вы писали:

S>У нас есть задокументированная архитектура (вплоть до мелочей), изначально проект планировалось делать на c++, это было отражено в разделе "реализация", где всё подробно описано. Прототип на c++ так же уже имеется (так как в "реализации" всё было подробно описано, программеры написали прототип без gui за 1 месяц). Сейчас делают прототип на .net (я настоял), после сравнения скорости разработки/производительности, будет выбрано направление. К сожалению, .net проигрывает (неделя, уже 50% сделано, но производительность падает на 30%) в скорости, и так как у нас всё продумано, и никаких сюрпризов не предвидется, проект, как не прискорбно, будет на c++ (наверное). Так что ограничения (парк компьютеров), мы словили на начальном этапе планирования.

1. Зря тесты проходили без GUI. На это уходит большинство времени разработки, несмотря на сложность остальной архитектуры.
2. Следует добавить в план, что для С++ тестирование обходится в несколько раз дороже (постоянные access violation с проблеми определения причины, а если это COM то туши свет (то что wrapper'ы полностью спасают от проблем, не более чем сказка)).
3. Учет только времени кодирования, мне не кажется правильным (тестирование будет отнимать несколько больше ресурсов и времени).
4. Достаточно важный вопрос в данном случае библиотека контролов.
5. Вы поставили интересный вопрос, сравнение RAID программирование с C++. Ответ я думаю, вполне понятен.

С данным отношением к ресурсам, я бы выбрал вариант C++. Фиг его знает, что архитекторы Microsoft придумают, а в данном случае все рычаги остаются у вас в руках (правда проблемы тоже). С С++ проблем больше, но все они решаемы. Requariments только один из недостатков Net. Существуют ограничения архитектуры, архитекторы от Microsoft думают о нас.

PS. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>1. Зря тесты проходили без GUI. На это уходит большинство времени разработки, несмотря на сложность остальной архитектуры.
В нашей ситуации gui наоборот очень быстро делается (я просто это еще не упоминал).

GZ>2. Следует добавить в план, что для С++ тестирование обходится в несколько раз дороже (постоянные access violation с проблеми определения причины, а если это COM то туши свет (то что wrapper'ы полностью спасают от проблем, не более чем сказка)).
access violation вроде еще НЕ РАЗУ не выскакивало (у нас очень жесткие стандарты, кругом смарт поинтеры

, супервайзер если видит голый new или delete, берсеркером становиться ) верьте мне или нет. Это в нашем случаи, а в общем, конечно, если есть gc то и мучений вообще как таковых нет

GZ>3. Учет только времени кодирования, мне не кажется правильным (тестирование будет отнимать несколько больше ресурсов и времени).
Дык .net побеждает только в скорости написания

ну может еще "багоустойчивости"

GZ>4. Достаточно важный вопрос в данном случае библиотека контролов.
Это да, но у нас есть опять таки прототипы всяких гридов, кнопочек (с параллельного проекта). Так что куда копать знаем.

GZ>5. Вы поставили интересный вопрос, сравнение RAID программирование с C++. Ответ я думаю, вполне понятен.
Лично мне еще не очень

GZ>С данным отношением к ресурсам, я бы выбрал вариант C++. Фиг его знает, что архитекторы Microsoft придумают, а в данном случае все рычаги остаются у вас в руках (правда проблемы тоже). С С++ проблем больше, но все они решаемы. Requariments только один из недостатков Net. Существуют ограничения архитектуры, архитекторы от Microsoft думают о нас.
Согласен.

GZ>PS. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм.
Оптимизм не на пустом месте, мы очень тщательно подходили к этапу планирования и написания архитектуры (я лично основы почти целый год придумывал, во как). Незнаю, к счастью или к сожалению, я (а я был и есть главный архитектор) не "экстримальный" программист, я не кидаюсь за клаву, как только в голове что-либо мутно обрисуется, а фигли, в процессе додумаю (слишком горький опыт был), так что я настаивал, можно сказать с криками "уйду нафиг", на том, чтоб у нас была глубоко продуманая архитектура, где почти всё (так как всё невозможно) определено и решено. Получилось давольно весело

GZ>С уважением, Gleb.
Спасибо за комментарии.

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, Shady, Вы писали:

GZ>>5. Вы поставили интересный вопрос, сравнение RAID программирование с C++. Ответ я думаю, вполне понятен.
S>Лично мне еще не очень

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

GZ>>PS. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм.
S>Оптимизм не на пустом месте, мы очень тщательно подходили к этапу планирования и написания архитектуры (я лично основы почти целый год придумывал, во как). Незнаю, к счастью или к сожалению, я (а я был и есть главный архитектор) не "экстримальный" программист, я не кидаюсь за клаву, как только в голове что-либо мутно обрисуется, а фигли, в процессе додумаю (слишком горький опыт был), так что я настаивал, можно сказать с криками "уйду нафиг", на том, чтоб у нас была глубоко продуманая архитектура, где почти всё (так как всё невозможно) определено и решено. Получилось давольно весело

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

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

Надеюсь, что у данного проекта большое коммерческое будуйщее.

С уважением, GlebZ.

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Shady, Вы писали:

V>>>2. Полная автоматизация планирования производства, бухгалтерии, CRM, SCM, ABC- и XYZ-анализ, хз что ещё. В этом случае забудь про C#, C++, .NET, Java и прочие прелести. Поднять такое — нереально. Говорю как оптимист со стажем.
S>>Вот это в самый раз. Мы именно это и хотим сделать. Вот только не понятно, почему поднять такое — нереально. Axapta, Sap, PeopleSoft, 1C — подняли, а мы не сможем?
S>>Говорю как оптимист со стажем.
V>Они все (может быть, за исключением PeopleSoft, о котором ничего сказать не могу) сначала сделали свою среду разработки, и уже на ней поехали в ERP.
Делаем то же самое. Только у нас своя среда исполнения (не надо кричать, а зачем?

), и средства для RAD (в проекте

)

S>>У меня есть тоже некий опыт, и распространенное мнение, что ERP/CRM/HRM — дело непосильное, пропагондируют SAP, MS, PeopleSoft

V>Они просто в это дело вгрохали человеко-тысячелетия. Это медицинский факт. Можно, конечно, самонадеянно объявить их недоумками. Но всё равно больше чем на порядок трудозатраты не сократишь. А это всё равно человеко-века.
Дело в том, что они вбухали человоке-тысячелетия на то, чтоб исследовать рынок, сделать "конфигурации" для супер корпораций. У нас другой подход, мы делаем технлогическую основу, конфигурации/настройки должны делать сторонние разработчики (прием 1с), только в отличии от 1с у нас все более расширяемо и "интеллектуально"

. Конечно мы не конкуренты SAP, ORACLE на уровне гос. структур (связи и "взяточная" ресурсоемкость не та) или нефтяных компаний, но вот какие-нибудь средние компании, где правит "бухгалтерская" 1с:предприятие, мы вроде как подвинуть сможем

Тем более у нас более бизнес-ориентированный процесс, чем бухгалтерский в 1с (во всяком случае у нас возможны сценарии транзакций, так и модели предметной области изначально), да и есть "уникальные" фичи, до которых sap, peoplesoft'у и т.д. нет дела (они во всяком случаи посчитали это слишком трудным для реализации).

V>>>3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.
S>>А вот это вообще непонятно, при чем сдесь VS, это ж только IDE, или я не уловил глобальный смысл? Но сравнения мне понравились

V>Если на VS сляпать средство разработки, а потом на нём сляпать ERP, то я согласен. Так делать можно.
V>Только нужна твёрдая уверенность в том, что получившееся средство будет РАДИКАЛЬНО лучше аксапты или 1С. Притом не теперешних, а тех, какими они будут через пару лет.
V>В любом случае, сильно отговаривать не буду. Не догоните, так согреетесь

. Но входить в финансовые обязательства под это дело я бы не посоветовал.
Через пару лет они мало изменяться, так пробивать радикальные перемены сложнее, да и куча X++ и 1с программистов есть, а радикально переделывать без переделки внутреннего языка невозможно, лучше просто делать чуть улучшенные версии и вбухивать их

... << RSDN@Home 1.1.3 stable >>

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Shady, Вы писали:

GZ>>>5. Вы поставили интересный вопрос, сравнение RAID программирование с C++. Ответ я думаю, вполне понятен.
S>>Лично мне еще не очень

GZ>Как было вами замечено до этого, в скорости написания, багоустойчивости, и проблемами программистов, как этот стандартный код обойти, чтобы вся эта конструкция не развалилась.
Если честно, я подумал, что вы отдали предпочтение c++

Типа ну что такое c# против "великого и могучего" с++. Спасибо что прояснили

GZ>>>PS. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм.
S>>Оптимизм не на пустом месте, мы очень тщательно подходили к этапу планирования и написания архитектуры (я лично основы почти целый год придумывал, во как). Незнаю, к счастью или к сожалению, я (а я был и есть главный архитектор) не "экстримальный" программист, я не кидаюсь за клаву, как только в голове что-либо мутно обрисуется, а фигли, в процессе додумаю (слишком горький опыт был), так что я настаивал, можно сказать с криками "уйду нафиг", на том, чтоб у нас была глубоко продуманая архитектура, где почти всё (так как всё невозможно) определено и решено. Получилось давольно весело

GZ>Все невозможно, ключевое слово. Да и в процессе реализации всегда найдутся несоответсвия и переработки (даже в рамках первой итерации), задача та новая. По крайней мере, обратных прецедентов я не встречал (тогда и жить неинтересно). Иначе можно было бы свободно работать по модели водопада.
Я же написал, что мы не всё продумали. Так что понятно, что мы еще шышек наделаем.

GZ>Хотел бы выразить свое восхищение правильной постановкой процесса разработки. К сожалению, до сих пор, встречается метод шапками закидаем, а потом посмотрим что получится.
СПАСИБО!

GZ>Надеюсь, что у данного проекта большое коммерческое будуйщее.
СПАСИБО!

GZ>С уважением, GlebZ.

... << RSDN@Home 1.1.3 stable >>

	От:	V.Petrovski
	Дата:	26.09.04 18:28
	Оценка:

От:	orangy	http://twitter.com/orangy
Дата:	25.09.04 12:01
Оценка:	1 (1) +5

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	24.09.04 19:56
Оценка:	29 (3) +2

От:	VladD2	www.nemerle.org
Дата:	25.09.04 21:23
Оценка:	+4

	От:	Аноним
	Дата:	25.09.04 19:35
	Оценка:	1 (1) +2

От:	PPA	http://flylinkdc.blogspot.com/
Дата:	25.09.04 22:47
Оценка:	1 (1) +1

	От:	Igor Trofimov
	Дата:	26.09.04 15:57
	Оценка:	+2

	От:	Алексей Владимирович Миронов
	Дата:	26.09.04 13:58
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	27.09.04 20:57
Оценка:	+1

От:	Voblin	http://maslyaew.narod.ru/
Дата:	05.10.04 15:46
Оценка:	+1

От:	henson	http://www.njt-rails.com
Дата:	25.09.04 05:44
Оценка: