Здравствуйте, <Аноним>, Вы писали:
А>Я знал, что это была большая чушь. Просто офигивал от промывки мозгов (когда со всех сторон, во всех статьях rich client MUST DIE!!!! ), а вот теперь обратное действо. sic.
А ты не видел рекламной компании ДиджиталВошБорд?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 быстрее По затратам получается намного быстрее и дешевле написать объектный диспетчер и повесить его над существующей системой protected storage: SQL, Oracle, MySQL (если хотите конечно А>Да, я уже то же склоняюсь к этой мысли.
BG>>Вы наверняка собираетесь двигаться в направлении клиент-сервер. дотНет в этом смысле позволяет сделать распределенную аппликуху при минимальных затратах — будь это веб клиент или десктоп клиент. Дальше если сервер, делающий основную работу начинает часто засыпать — можно поставить второй такой серевер и третий. А>Продукт для всего рынка, это не "контрактный" продукт под определенную фирму (где можно прогнуть модернизацию PC). Тут такие финты ушами, как "для нашей erp нужны самые передовые компьютеры и гигабитные сети" не прокатят (мыж не ms)
BG>>Опять же, нам будет гораздо легче Вам помочь, если Вы расскажете немного о специфике задачи — объемы данных, к-рые необходимо передавать с сервера на клиенты (только недавно читал о проблематичности загрузки длинного 300 000+ списка товаров на вебклиента), род этих данных и т.д. А>Мы стараемся как можно сильнее минимизировать пересылки между клиентом и сервером, при этом не потерять безопасность и валидность данных. Данные варьируются от простых данных, до документов.
Здравствуйте, Voblin, Вы писали:
V>3. Что-то среднее между 1 и 2. Тогда сказать трудно. Пока ясно одно: Visual Studio для разработки бизнес-софта не подходит. Это всё равно, что лобзиком сосны пилить или зубной счёткой унитаз чистить.
Может, стоит повременить?
Технология, насколько я понимаю, на больших проектах еще не опробирована...
Вот лет через 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 >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, 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 >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, cvoronin, Вы писали:
C>Может, стоит повременить?
Эта мысль у меня пробегала.
C>Технология, насколько я понимаю, на больших проектах еще не опробирована... C>Вот лет через 5... Когда в магазинах появятся книги типа "Горький вкус Java" или "Типичные ошибки проектирования", но только по .net — вот тогда, пожалуй, и можно будет начинать... C>Слишком большой пока технологический риск... C>И, зная любовь Microsoft к новизне и нелюбовь поддерживать старое, я бы очень хорошо и сильно подумал, а стоит ли выбирать .Net в качестве инструментальной платформы для приложения такого масштаба... Посмотрел бы на историю COM, MTS, COM+, VB и прочего, во что народ вкладывал деньги и время...
Это я тоже учитываю.
C>Из этого не стоит делать вывод, что .Net для больших проектов не подходит... пока не доказано обратное
... << RSDN@Home 1.1.3 stable >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, 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. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм.
Здравствуйте, 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 >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Shady, Вы писали:
GZ>>5. Вы поставили интересный вопрос, сравнение RAID программирование с C++. Ответ я думаю, вполне понятен. S>Лично мне еще не очень
Как было вами замечено до этого, в скорости написания, багоустойчивости, и проблемами программистов, как этот стандартный код обойти, чтобы вся эта конструкция не развалилась.
GZ>>PS. Очень рад за вас, что у вас все продумано и никаких сюрпризов не предвидится. КРУТО! Мне бы такой оптимизм. S>Оптимизм не на пустом месте, мы очень тщательно подходили к этапу планирования и написания архитектуры (я лично основы почти целый год придумывал, во как). Незнаю, к счастью или к сожалению, я (а я был и есть главный архитектор) не "экстримальный" программист, я не кидаюсь за клаву, как только в голове что-либо мутно обрисуется, а фигли, в процессе додумаю (слишком горький опыт был), так что я настаивал, можно сказать с криками "уйду нафиг", на том, чтоб у нас была глубоко продуманая архитектура, где почти всё (так как всё невозможно) определено и решено. Получилось давольно весело
Все невозможно, ключевое слово. Да и в процессе реализации всегда найдутся несоответсвия и переработки (даже в рамках первой итерации), задача та новая. По крайней мере, обратных прецедентов я не встречал (тогда и жить неинтересно). Иначе можно было бы свободно работать по модели водопада.
Хотел бы выразить свое восхищение правильной постановкой процесса разработки. К сожалению, до сих пор, встречается метод шапками закидаем, а потом посмотрим что получится.
Надеюсь, что у данного проекта большое коммерческое будуйщее.
Здравствуйте, 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С. Притом не теперешних, а тех, какими они будут через пару лет.
В любом случае, сильно отговаривать не буду. Не догоните, так согреетесь . Но входить в финансовые обязательства под это дело я бы не посоветовал.
Здравствуйте, 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 >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, 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 >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
), а вот теперь обратное действо. sic.
. Но входить в финансовые обязательства под это дело я бы не посоветовал.
)