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

AVK>Несомненно. Для БД, если нет меппинга а работа идет напрямую то хотя бы менеджер соединений. Ну а если меппинг есть то сам бог велел закрывать БД полностью.

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

AVK>>>Это сильно зависит от платформы. К примеру в джаве и дотнете эти вопросы уже решены.

ГВ>>Хм... ИМХО, GC — это не решение, а закрывание глаз на проблему, точно также, как и Stack Trace по поводу ошибок.

AVK>По опыту использования скажу что все таки решение, причем очень неплохое. Это очень здорово — забыть про распределение памяти совсем. Столько гимора снимается. А всякие кеши объектов реализовывать вобще просто несравнимо.

Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

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

AVK>В принципе ты прав, но вот дотнет, а особенно джава стимулируют к тому чтобы большинство задач решать на ней. Т.е. скажем отдельный модуль написать на С++ лучше, но вот при интеграции его в сужествующую джава-среду ты все преимущества потеряешь. Плюс только крупные конторы могут позволить себе держать кодеров для нескольких платформ. В общем вопрос этот очень и очень сложный. Выбирая гетерогенную среду мы в чем то выигрываем, а что то проигрываем. И как всегда приходится искать золотую серидину, а она в каждом случае своя(выделено мной — ГВ.).

Согласен на все сто.

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

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

BME>>спор, на тему как дешевле: самим писать, или что готовое покупать и дорисовывать под себя, так же встречался много раз. в вашей ситуации, думаю будет не дороже(выделено мной — ГВ.). но уж точно предприятие выиграет по срокам внедрения. ну не придется ему ждать, пока Команда Разработчиков, таки проштудирует всю мыслимую литературу по средствам разработки, напишет пачку ХелоуВорлдов в серверных и клиентских вариантах , и сможет наконец снизойти до низких материй — ейной автоматизации.

ГВ>А основания для подобных утверждений каковы? Особенно — по части штудирования мыслимой литературы и ХеллоуВорлдов?
И кстати, про добавленную стоимость слышал? Как ты думаешь, в каком случае она будет больше (для предприятия-внедренца)? В случае продажи готовой системы или разработки своей? Ась? А соответственно — обеспеченная именно этими деньгами устойчивость предприятия когда будет больше? Ты не забудь, что покупая, например, решение SAP вкладывают деньги прежде всего в саму SAP AG...

штудирование... — человек черным по-русски написал более менее подробно о своем опыте работы и т.д.

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

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

да много чего еще знаю, уж поверьте...

Резюмируя, предприятие А ТЕРЯЕТ:
1. _a месяцев + сумму $Х (на з/п Команды Разработчиков (КР) + проблемы внедрения)
или
2. _b месяцев + сумму $Y при привлечения конторы (К) специализирующейся на подобных внедрениях.

Именно ТЕРЯЕТ — не надо про добаленную стоимость и т.д. взрослые люди, все понимаем..

(извиняюсь за сложение величин разной размерности

надо сравнить
[(_a месяцев + сумму $Х)+риски1] и [(_b месяцев + сумму $Y)+риски2]


как вот оцените слагаемое <риски1>, при наличие разработчиков уровня автора данной ветки? может быть одного единственного


BME>>вы также останетесь в выигрыше по крайней мере по количеству выживших нервных клеток

ГВ>Бабушка надесятеро сказала... увы...

ГВ>[...]

BME>>вы, извиняюсь, директор этого самого предприятия? если нет, то это просто ЭГОИЗМ. уж если хочется разбираться с высокими технологиями, зачем лезть в низкие материи (учетные задачи)? полно задач в науке, технике и т. д. до куда 1С и ей подобные не добрались. там и писать-то интереснее.

BME>>по-прежнему готов к потоку КОНСТРУКТИВНОЙ критики

ГВ>Сделай утверждение — будет и критика. А пока что — эмоциии...

утверждение сделано в предудыщей ветке. разумный вариант, имхо, дождаться выхода 8-ки. выходит — в марте 2003. трехзвенка, mssql и т.п.
более продуманная структура бд, в отличии от 7-ки генерит достаточно адекватный sql — сам смотрел, тестировал
при грамотно построенной конфе, на вскидку, на ней 100-200 человек будут работать вольготно.

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

ГВ>Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

Ну значит напишет на С++ внешний компонент, который будет данные буферизировать, а как сервер освободится будет буфер скидывать. Это как писалки CD — жестко реалтаймные устройства, тем не менее в Windows функционируют превосходно.

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

ГВ>>Решение, конечно, не спорю. И в своём роде очень неплохое, но для технологического ядра, ИМХО, довольно рискованное. А вдруг ему понадобится, например, биллинг или какое-нить управление станками "накрывать"? А это уже реалтайм как-никак... Да и вообще — ядро с непредсказуемыми таймингами...

AVK>Ну значит напишет на С++ внешний компонент, который будет данные буферизировать, а как сервер освободится будет буфер скидывать. Это как писалки CD — жестко реалтаймные устройства, тем не менее в Windows функционируют превосходно.

Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

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

BME>>>спор, на тему как дешевле: самим писать, или что готовое покупать и дорисовывать под себя, так же встречался много раз. в вашей ситуации, думаю будет не дороже(выделено мной — ГВ.). но уж точно предприятие выиграет по срокам внедрения. ну не придется ему ждать, пока Команда Разработчиков, таки проштудирует всю мыслимую литературу по средствам разработки, напишет пачку ХелоуВорлдов в серверных и клиентских вариантах , и сможет наконец снизойти до низких материй — ейной автоматизации.

ГВ>>А основания для подобных утверждений каковы? Особенно — по части штудирования мыслимой литературы и ХеллоуВорлдов?
ГВ>>И кстати, про добавленную стоимость слышал? Как ты думаешь, в каком случае она будет больше (для предприятия-внедренца)? В случае продажи готовой системы или разработки своей? Ась? А соответственно — обеспеченная именно этими деньгами устойчивость предприятия когда будет больше? Ты не забудь, что покупая, например, решение SAP вкладывают деньги прежде всего в саму SAP AG...

BME>штудирование... — человек черным по-русски написал более менее подробно о своем опыте работы и т.д.

Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь? Кстати, ты так и не ответил ничего по поводу "Hello, world".

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

Ну вот калий с кальцием давай не будем путать. "Серийный софт" и серйиная продукция конвейера — совсем не одно и тоже. И как это соотносится с себестоимостью серийного спецсофта?

BME>еще знаю что такое отлаживание... хотя бы бизнесс-кода...
BME>еще знаю про наше законодательство и его изменчивость....
BME>еще про изменчивость желаний пресловутых пользователей самого разного ранга....

Верю, верю.

BME>Резюмируя, предприятие А ТЕРЯЕТ:
BME>1. _a месяцев + сумму $Х (на з/п Команды Разработчиков (КР) + проблемы внедрения)
BME>или
BME>2. _b месяцев + сумму $Y при привлечения конторы (К) специализирующейся на подобных внедрениях.

BME>Именно ТЕРЯЕТ — не надо про добаленную стоимость и т.д. взрослые люди, все понимаем..

Речь шла о предприятии-разработчике (или, как я его обозначил — внедренце), это оно получает ДС. Предприятие-клиент, естественно, всегда её оплачивает.

Притом учти, что речь идёт о неизвестном количестве предприятий-клиентов. Соответственно сумма $X будет изменяться абсолютно неизвестно как.

BME>надо сравнить
BME>[(_a месяцев + сумму $Х)+риски1] и [(_b месяцев + сумму $Y)+риски2]

BME>
BME>как вот оцените слагаемое <риски1>, при наличие разработчиков уровня автора данной ветки? может быть одного единственного

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

BME>утверждение сделано в предудыщей ветке. разумный вариант, имхо, дождаться выхода 8-ки. выходит — в марте 2003. трехзвенка, mssql и т.п.
BME>более продуманная структура бд, в отличии от 7-ки генерит достаточно адекватный sql — сам смотрел, тестировал
BME>при грамотно построенной конфе, на вскидку, на ней 100-200 человек будут работать вольготно.

100-200 человек — это что, потолок? А на какой конфигурации? А кроме mssql она ещё что-нибудь поддерживает? И (самое главное) всем ли охота "укладываться" под 1С?

С другой стороны, может быть, это и разумный выход, но: а) мы не знаем причин, подвигнувших mvg_first на подобное решение, б) он прямо просил не заниматься отговорами. Этих двух причин вполне достаточно, ИМХО, чтобы отвечать по существу заданных вопросов, а не отговаривать от ошибочного по чьему-то мнению решения.

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

ГВ>Видел, впрочем ладно. Давай, закроем эту тему в таких фразеологизмах.

Давай, извини, не мог удержаться

ГВ>Понимаешь... твои выводы актуальны для тех, кто вынужден принимать условия "как есть".

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

ГВ>mvg_first всё-ж-таки начальник отдела (загляни в профайл), ему под силу, надеюсь, сформировать часть таких условий исходя из своих соображений. ИМХО, такой путь для него — более адекватный.

Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли. Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо. Да и сейчас техническая политика отдела зависит в основном от моих решений, но заниматься такой хренью как "я сказал C++, значит будет C++" я даже и не собираюсь. Более того, любые предложения обсуждаются, взвешиваются и принимается решение об их использовании или неиспользовании в конкретных задачах.

Автору топика я могу сказать, что его затея гарантированно обречена на провал, именно по причине не гибкости подхода и ориентации на древние технологии. Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов. О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

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

ГВ>Естественно не все телодвижения IT (я не тебя имею ввиду ) делаются ради моды самой по себе. У Java и у .NET есть свои вполне адекватные области применения. Держаться зубами и ногами за нечто одно-единственное, и на мой взгляд тоже — глупо. Просто не всегда уместно обобщать свой частный (а он всегда частный) опыт. Вот ты говоришь относительно своего опыта и своей конторы — и всё становится на свои места... А то бы я тут разнаезжался.

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

Мои первые проекты были очень длинные, дело было в НИИ и мы годами занимались научными, блин, исследованиями. Спутники в космос запускали, топили их сотнями в Тихом и других океанах, делали свои компиляторы и языки имитационного моделирования. Классно было, опыт как разработчика неоценимый. Только одна проблема, все 100% тех задач которые мы делали пошли в мусорку.

Дальше был период тех самых бухгалтерий. Свою с нуля, а как же иначе? 1С тогда ешё из пелёнок не вылезла, а у нас уже был рабочий комплексный прототим для целого предприятия. На доводку правда ушли годы, но зато на этой базе мы наклепали кучу других проектов. Правда не всегда удачных, часть тоже шла в мусорку или с большими задержками (!) и затратами на внедрение. Проекты эти были длинной уже не более года. Процент внедрения можно оценить примерно в 75%, что я считаю большим достижением.

Параллельно мы продолжали кое-что делать для военных, и вот интересно, что чем длиннее были этапы, тем труднее было их завершить и получить свои кровные. Последняя такая затея как мне известно так и не удалась. Процент успеха можно оценить как — 50%.

Были конечно и проекты, которые с самого начала были обречены на успех, т.к. в противном случае, нам бы просто не сносить головы. И что интересно, внедрялись они почти в срок, но в очень сыром виде и доводились потом до ума по ходу дела, чем и был обеспечен успех, хотя мы нагло требовали ещё 6 месяцев и считали, что поступаем против всех правил.

Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

Так что насчёт обобщения частного опыта ты возможно не совсем прав. Java, .NET и вообще новые технологии позволяют сократить время разработки в разы, следовательно (из моей теории ) таким проектам обеспечен успех по определению.

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

ГВ>Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

Слишком дорогим может оказаться написание ядра с заточкой под реалтайм задачи. Если это сервер для управления предприятием то такие задачи там скорее исключение чем правило.

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

ГВ>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

Вот только он об этих основаниях пока не признался.

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

ГВ>100-200 человек — это что, потолок? А на какой конфигурации? А кроме mssql она ещё что-нибудь поддерживает? И (самое главное) всем ли охота "укладываться" под 1С?

ГВ>С другой стороны, может быть, это и разумный выход, но: а) мы не знаем причин, подвигнувших mvg_first на подобное решение, б) он прямо просил не заниматься отговорами. Этих двух причин вполне достаточно, ИМХО, чтобы отвечать по существу заданных вопросов, а не отговаривать от ошибочного по чьему-то мнению решения.

уважаемый. если интересно описание 1С как платформы, расскажу. по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

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

BME>уважаемый. если интересно описание 1С как платформы, расскажу.

Интересно, расскажи. Если хочешь — приватом.

BME>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

Ну, вообще-то он немного о другом спрашивал.

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

ГВ>>Понимаешь... твои выводы актуальны для тех, кто вынужден принимать условия "как есть".

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

Не без того.

ГВ>>mvg_first всё-ж-таки начальник отдела (загляни в профайл), ему под силу, надеюсь, сформировать часть таких условий исходя из своих соображений. ИМХО, такой путь для него — более адекватный.

IT>Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли.

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

IT>Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо.

...то есть, они стояли перед твоим шефом, только и всего.

IT>Да и сейчас техническая политика отдела зависит в основном от моих решений, но заниматься такой хренью как "я сказал C++, значит будет C++" я даже и не собираюсь. Более того, любые предложения обсуждаются, взвешиваются и принимается решение об их использовании или неиспользовании в конкретных задачах.

А если конкретная задача может быть сформулирована как разработка АСУ "с нуля"? Знаешь, я не очень верю в полезность обсуждений выбора того или иного решения, особенно когда техническое решение принимается большинством голосов — большинство, как известно... 1000000 lemmings cann't be wrong. Наверное.

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

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

IT>Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов.

Ну, а мы на что? Подскажем как делать так, чтобы ликов не было. Вообще. Кроме того, он и сам сможет спецов у себя поискать.

IT>О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

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

Его затея, ИМХО, будет обречена на провал при отсутствии заказчиков, понимающих хотя бы — что им нужно. Ещё его затея гарантированно провалится, если начнутся внутрикорпоративные разборки — такие проекты "режут" обычно в первую очередь.

IT>Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

Ты наверное, не представляешь, но в СНГ ещё навалом случаев, когда на предприятиях нет вообще никакой автоматизации. Соответственно, интегрироваться там попросту не с чем. Ну, может быть, не считая 1С:Бухгалтерии.

IT>Не проблема, я могу прикинуть свой опыт с самого начала.

Если честно, то я думал, что ветка на этом и закончится. Ну ладно...

IT>Мои первые проекты были очень длинные, дело было в НИИ и мы годами занимались научными, блин, исследованиями. Спутники в космос запускали, топили их сотнями в Тихом и других океанах, делали свои компиляторы и языки имитационного моделирования. Классно было, опыт как разработчика неоценимый. Только одна проблема, все 100% тех задач которые мы делали пошли в мусорку.

Как я понимаю, они пошли в мусорку а) как и немалая часть исследовательских работ и б) вместе с космической индустрией СССР. Не так?

IT>Дальше был период тех самых бухгалтерий. Свою с нуля, а как же иначе? 1С тогда ешё из пелёнок не вылезла, а у нас уже был рабочий комплексный прототим для целого предприятия. На доводку правда ушли годы, но зато на этой базе мы наклепали кучу других проектов. Правда не всегда удачных, часть тоже шла в мусорку или с большими задержками (!) и затратами на внедрение. Процент внедрения можно оценить примерно в 75%, что я считаю большим достижением.

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

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

По-моему, основная проблема нашей индустрии связана с тем, что в ней стремительно уменьшается процент людей, способных строить индукцию. Если им сказать, что есть красный кирпич, синий камень и белый камень, то они никогда даже не подумают, что может появиться белый кирпич или, скажем, жёлтый камень... Точно также, они никогда ни на йоту не предполОжат возможных изменений продукта и требований заказчика. Вот это я и называю обычно интеллектуальной трусостью. И к сожалению, в околоакадемической среде таких — до той самой матери, а в не академической — в десять раз больше.

IT>Параллельно мы продолжали кое-что делать для военных, и вот интересно, что чем длиннее были этапы, тем труднее было их завершить и получить свои кровные. Последняя такая затея как мне известно так и не удалась. Процент успеха можно оценить как — 50%.

Ты не забудь, что всё это происходило на фоне снижения финансирования военных в целом. Да и другие факторы были, если, конечно, речь идёт об СССР-СНГ. Даты ты не проставил, место действия — тоже, ну да ладно.

IT>Были конечно и проекты, которые с самого начала были обречены на успех, т.к. в противном случае, нам бы просто не сносить головы. И что интересно, внедрялись они почти в срок, но в очень сыром виде и доводились потом до ума по ходу дела, чем и был обеспечен успех, хотя мы нагло требовали ещё 6 месяцев и считали, что поступаем против всех правил.

IT>Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

А может, всё дело в том, что класс задач изменился? Задачи стали более мелкими. Их лучше понимает и заказчик и вы. Отсюда и неизбежный в таких случаях успех внедрения. Ты ведь никак не характеризуешь сами задачи.

IT>Так что насчёт обобщения частного опыта ты возможно не совсем прав. Java, .NET и вообще новые технологии позволяют сократить время разработки в разы, следовательно (из моей теории ) таким проектам обеспечен успех по определению.

Уффф... Ужас. Ну давай по-новой — какие задачи? Как решены? Хочешь, подкину ещё несколько вопросов по которым я оцениваю качество разработки? Слепить ИС на коленке может любой, а вот, например, решить задачи ограничения доступа более детально, чем это предоставляет сервер БД или хуже того — базовая ОС, или, например, оптимизации структуры БД "на ходу" — почти никто. Точно также, как почти никто, например, не может решить задачу вывода мультиструктурных списков (это такие, где для разных записей разные наборы колонок), да элементарно зачастую не могут преположить, что дерево, к примеру, может быть совмещено со списком.

В принципе, частично с тобой согласен — долгострой по большому счёту всех участников только раздражает. А короткие сроки в основном появляются при ясности задач (они ещё могут быть при адекватной интерпретации задачи, но это сильно зависит от людей, а о людях я уже писал). Но знаешь... если продолжить твою теорию, то получится, что чинить сапоги всяко выгоднее, чем строить заводы по производству тех же сапог. Ан ведь находятся же ещё те, кто такие заводы строит. Просто это разные сегменты рынка и требуют, соответственно, разных подходов. Тебе оказался адекватен подход сапожника (не сочти это попыткой оскорбления, пожалуйста), mvg_first хочет строить завод. Чуешь разницу? Сапожник не рекомендует строить завод... звучит сильно. Ты пойми, что если ты нашёл для себя определённую нишу — то это супер, это здорово, но для другого она может быть другой. Так было есть и пребудет ныне и присно и во веки веков. Я не пытаюсь сказать, что твой опыт мелок и неприятен и прочую чушь. Наоброт, мне очень интересно было прочесть твой постинг, возможно, ты Мастер в свой области. Нет проблем. Но почему ты (кстати, не ты один) пытаешься другим запретить делать то, на что они имеют полное право и более того — то, чего они хотят?

Так что, всё, что ты сейчас доказал, так это, по крайней мере не-ложность моего утверждения о неуместности обобщения частного опыта. Увы. Кроме того — непосредственно подтвердил мои предположения о необходимости для mvg_first противостояния внешненму давлению. Вот смотри, мы с тобой потратили без малого полдня на бесплодную в сущности дискуссию. А у него таких (и ещё похлеще) споров будет вагон и мелкая телега, а ещё нужно думать. А думать-то может оказаться и некогда. И вот тогда действительно появится ещё один камешек в почву для мифов о безнадёжных проектах. Вот так-то.

Так что, извини, но:
Мораль сей басни такова — сто зайцев вместе п$#&%т льва... Только вот львами они от этого не станут...

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

ГВ>>Тоже вариант, конечно, но ИМХО, лучше всё-таки наоборот — в ядре сразу максимум критически важных функций реализовать, а что там снаружи — VB, Java, .Net — по вкусу.

AVK>Слишком дорогим может оказаться написание ядра с заточкой под реалтайм задачи. Если это сервер для управления предприятием то такие задачи там скорее исключение чем правило.

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

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

ГВ>>Но тем не менее, он сделал выбор и вобщем-то не просил от него отговаривать. Вероятно, у него тоже есть свои основания так говорить, не находишь?

AVK>Вот только он об этих основаниях пока не признался.

Ну что же... подождём. Глядишь и выяснится чего. То-то он обрабуется, завидев флейм, вызванный его вопросом.

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

IT>>Да ладно, я был начальником отдела РПО в России, и, между прочим, подобные вопросы передо мной не стояли.

ГВ>Ну, из этого ровным счётом ничего не следует, кроме того, что перед тобой такие вопросы не стояли...

Да, вот такие вопросы передо мной не стояли :

Меня интересует с чего начать изучение VC — что бы в максимально короткие сроки приступить к разработке указанной выше задачи.

IT>>Всё пробовалось, тестилось (преимущественно дома) и потом доказывалось шефу, что так надо.

ГВ>...то есть, они стояли перед твоим шефом, только и всего.

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

ГВ>А если конкретная задача может быть сформулирована как разработка АСУ "с нуля"?

Это не задача, это большой долгосрочный проект.

ГВ>Знаешь, я не очень верю в полезность обсуждений выбора того или иного решения, особенно когда техническое решение принимается большинством голосов — большинство, как известно... 1000000 lemmings cann't be wrong. Наверное.

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

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

ГВ>Да ну! Подход то максимально гибок, просто ему практически мало есть на что опереться из готовых квазитехнологий.

Перечитай его сообщение ещё раз:

Да еще одно очень важное замечание: Пожалйста не отговаривайте меня использовать VC, и не предлагайте основную разработку вести на каких либо других языках. Мне это не интересно: что лучше — что хуже я уже осознал и сделал свой выбор, в детских перебранках типа "чья песочница лучше?! "участвовать нежелаю (такого начитался уже достаточно). Т.е. мораль такова подскажите в какую сторону, рыть, где читать, смотреть пробовать. В таком духе.

P.S. Ах да, чуть не забыл, и советов что "мол сам такое не потянешь", "...пустая трата вреени и денег...", "... зачем изобретать велосипед..." пожалуйста тоже постарайтесь избежать. Колечество работы, усилий и затрат я трезво оцениваю. Знаю и в данном вопросе их попрошу не рассматривать

Максимальная гибкость так и прёт

IT>>Он просто не представляет себе с его "средним уровнем", что такое в дебагере на плюсах три дня искать мемори-лики или утечку других ресурсов.

ГВ>Ну, а мы на что? Подскажем как делать так, чтобы ликов не было. Вообще. Кроме того, он и сам сможет спецов у себя поискать.

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

IT>>О какой вообще системе предприятия с нуля идёт речь? Детский сад, ей богу. Это всё уже было пройдено 8-10 лет назад целым поколением программистов. И где все те чудо-универсальные системы? Везде, ну почти везде, стоит 1С.

ГВ>Ну во-первых, не одна только 1С, а во-вторых, сейчас всё равно пойдёт очередная волна собственных разработок. Слишком уж жирный кусок — автоматизация, чтобы на нём могла остаться только 1С.

Возможно, даже скорее всего так и будет.

ГВ>Его затея, ИМХО, будет обречена на провал при отсутствии заказчиков, понимающих хотя бы — что им нужно.

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

ГВ>Ещё его затея гарантированно провалится, если начнутся внутрикорпоративные разборки — такие проекты "режут" обычно в первую очередь.

Ну это и ёжику понятно.

IT>>Если у него и есть шанс, то только один, постепенно, без революций, заменять части системы, обеспечивая при этом интеграцию с существующим ПО. Любой другой вариант — авантюра в чистом виде.

ГВ>Ты наверное, не представляешь, но в СНГ ещё навалом случаев, когда на предприятиях нет вообще никакой автоматизации. Соответственно, интегрироваться там попросту не с чем. Ну, может быть, не считая 1С:Бухгалтерии.

Вот с ней и интегрировать, тем более что автор топика именно о ней и говорил.

ГВ>Как я понимаю, они пошли в мусорку а) как и немалая часть исследовательских работ и б) вместе с космической индустрией СССР. Не так?

В том числе. Но то, что это проекты неживые было видно ещё при их разработки.

ГВ>Да, действительно — неплохо. Хотя, сталкивался я с плодами трудов выходцев из НИИ (снова, я не тебя имею ввиду)...

У меня складывается впечатление, что имеешь.

ГВ>ну как тебе сказать... наверное, это неизлечимо. Всё что можно сказать о плохом стиле — это кним. Хотя мужики умные. Хотя и трусливые нередко.

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

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

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

ГВ>По-моему, основная проблема нашей индустрии связана с тем, что в ней стремительно уменьшается процент людей, способных строить индукцию. Если им сказать, что есть красный кирпич, синий камень и белый камень, то они никогда даже не подумают, что может появиться белый кирпич или, скажем, жёлтый камень... Точно также, они никогда ни на йоту не предполОжат возможных изменений продукта и требований заказчика. Вот это я и называю обычно интеллектуальной трусостью. И к сожалению, в околоакадемической среде таких — до той самой матери, а в не академической — в десять раз больше.

Это ты опять на меня намекаешь?

ГВ>Ты не забудь, что всё это происходило на фоне снижения финансирования военных в целом. Да и другие факторы были, если, конечно, речь идёт об СССР-СНГ. Даты ты не проставил, место действия — тоже, ну да ладно.

Военные находились (да и сейчас наверное там же) в Москве, разве в России военные где-то ещё занимаются софтом?

IT>>Сейчас (исключая конечно клинические случаи, описанные мной в предыдущем посте) процент внедрения всех задач у нас 100%. И я считаю, что это обеспечивается прежде всего коротким циклом разработки.

ГВ>А может, всё дело в том, что класс задач изменился?

Естественно изменился, действие теперь происходит на другом континенте

ГВ>Задачи стали более мелкими. Их лучше понимает и заказчик и вы. Отсюда и неизбежный в таких случаях успех внедрения. Ты ведь никак не характеризуешь сами задачи.

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

ГВ>Уффф... Ужас. Ну давай по-новой — какие задачи? Как решены?

А о чём мы вообще говорим?

ГВ>Хочешь, подкину ещё несколько вопросов по которым я оцениваю качество разработки? Слепить ИС на коленке может любой, а вот, например, решить задачи ограничения доступа более детально, чем это предоставляет сервер БД или хуже того — базовая ОС,

Естественно решено, с системой работает около 1000 employee, без разграничений прав доступа и секурити никак. Но решение не вполне устраивает, поэтому будет пересматриваться.

ГВ>или, например, оптимизации структуры БД "на ходу" — почти никто.

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

ГВ>Точно также, как почти никто, например, не может решить задачу вывода мультиструктурных списков (это такие, где для разных записей разные наборы колонок), да элементарно зачастую не могут преположить, что дерево, к примеру, может быть совмещено со списком.

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

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

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

Это зависит от задачи. Если требуется строить завод, то будем строить завод, если нужно чинить сапоги, то зачем строить завод, что бы починить один сапог.

ГВ>Ан ведь находятся же ещё те, кто такие заводы строит.

Я бы сказал пытается строить. И сколько таких недостроек валяется на многих винчестерах, просто несчесть. А ведь зачастую надо было всего-то навсего починить сапог.

ГВ>Просто это разные сегменты рынка и требуют, соответственно, разных подходов. Тебе оказался адекватен подход сапожника (не сочти это попыткой оскорбления, пожалуйста)

Счёл

ГВ>, mvg_first хочет строить завод. Чуешь разницу?

Я чую чем это попахивает, обычное шапкозакидательство.
Вот ты как почётный заводостроитель, объясни ему, да и нам сапожникам, через что ему придётся пройти без опыта, без знаний, без понимания того, что ему нужно делать. Судя по его сообщению, ему самому просто нужно поучить C++ и COM, так как он где-то услышал, что это круто. На самом же деле этот поезд уже давно ушёл и сейчас это совсем не круто. Через пол года он прочитает про .NET и захочет всё перекосить по новой. Вот это я чую.

ГВ>Сапожник не рекомендует строить завод... звучит сильно.

Да, сильно. Если бы я не был такой добрый, то я бы точно обиделся. Сапожником меня ещё никто не обзывал, ну да ладно, видимо и ты и mvg_first очень крутые заводостроители и нам деревенским ни чета

ГВ>Ты пойми, что если ты нашёл для себя определённую нишу — то это супер, это здорово, но для другого она может быть другой.

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

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

Да ладно, Ты не не пытаешься, ты это делаешь

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

Я кому-то что-то запрешал? Перечитай топик ещё раз, я, кажется, автору первым посоветовал взять ATL, COM, MFC и вперёд, если уж он так хочет позаниматься мазахизмом за денежки своей конторы.

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

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

ГВ>Мораль сей басни такова — сто зайцев вместе п$#&%т льва... Только вот львами они от этого не станут...

А это ты к чему? Извини, тупею на чужбине.

Здравствуйте, IT:

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

Относительно же шага mvg_first скажу, что это в конце концов его личное дело и не факт, что всё, что мы тут с тобой наговорили сможет ему в какой-то степени помочь. Хотя я лично постараюсь не отказывать по существу.

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

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

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

Но тем не менее, всё же благодарен тебе за дискуссию (которая, кстати, содержала не совсем приятные нотки и для меня тоже) и не откажусь от обсуждения технических и иных существенных аспектов вопроса mvg_first.

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

ГВ>Слушай, давай мы с тобой эту ветку завяжем, а то чует моё сердце — неладно это кончится. Поскольку мы уже начинаем соскальзывать на личности.

Завязываем.

ГВ>IT, насколько я заметил, ты иногда выставляешь личный опыт в публичной конференции, а потом обижаться на оценку его уместности. Не хочешь нелицеприятных оценок — деперсонифицируй свои посылки, и никто в обиде не будет. Чего же проще?

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

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

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

BME>>уважаемый. если интересно описание 1С как платформы, расскажу.

ГВ>Интересно, расскажи. Если хочешь — приватом.

да ладно уж. может кому еще будет интересно.
http://klerk.ru/soft/1c/?916 — статья старая, но информация в ней подтвержденная. все так и есть
из "революционного" :
— привели в удобоворимый вид структуру бд — отказались от общих таблиц (общий журнал, константы). теперь как проектировщик конфы пользователей по табличкам разведет, так и будет. (1-я беда 7-ки)
— генеримый sql стал куда более вразумительный и компактный (2-я беда 7-ки)
— наваяли собственный app server, который будет синглюзером работать с mssql. пока объявили только о поддержке mssql 2000. про поддержку оракла и прочих серверов я задавал вопрос на семинаре разработчикам, говорят пока не планируют, да и смысла большого не видят. без коментариев.
— наваяли собственный формат бд (файл-серверная версия). дюже шустрый. по тестам обходит современную дбф-версию 7-ки в 7-8 раз на идентичных задачах. это вариант "для бедных" — на небольшое количество пользователей.
— из разряда "вишек", но тем не менее: не используют виндовую графику — написали свое — вполне презентабельно выглядит.
— в язык ввели кучу полезных фич. вообще, даже на уровне языка оптимизировали обращение к бд (отдельные объекты на чтение, отдельные на запись и т.д.). собственный (1с) язык запросов стал максимально приближен к sql.
— поддержка unicode'а. интерфейсы можно элементарно делать на нескольких языках
— поддержка ole

имхо, на эта платформа реально сможет конкурировать со многими erp-системами (и нашими и не нашими). но, учитывая огромное количество разработчиков (по неофициальным данным в СНГ их около 100.000), простоту и мощность языка, скорость разработки, цену (ее, правда, пока не оглашали), она скорее всего станет стандартом разработки эконом. прложений в ближайшие несколько лет на рынке не очень крупных предприятий по крайней мере в РФ. громко конечно сказано , но скорее всего так и будет — люди всегда стараются экономить время и деньги, а 1с это как раз и позволяет.

BME>>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

ГВ>Ну, вообще-то он немного о другом спрашивал.

да вот не показалось что-то. конечная его цель, имхо, именно такая

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

А>да ладно уж. может кому еще будет интересно.

OK, спасибо за ссылку.

А>имхо, на эта платформа реально сможет конкурировать со многими erp-системами (и нашими и не нашими). но, учитывая огромное количество разработчиков (по неофициальным данным в СНГ их около 100.000), простоту и мощность языка, скорость разработки, цену (ее, правда, пока не оглашали), она скорее всего станет стандартом разработки эконом. прложений в ближайшие несколько лет на рынке не очень крупных предприятий по крайней мере в РФ. громко конечно сказано , но скорее всего так и будет — люди всегда стараются экономить время и деньги, а 1с это как раз и позволяет.

Всё могет быть. С некоторой вероятностью.

BME>>>по поводу просьбы автора ветки не заводить разговор в сторону так же помню. думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке. но его изначальная постановка вопроса (что почитать, чтобы по-быстрому налабать АСУ предприятия, так вроде?) вызвала у меня просто испуг

ГВ>>Ну, вообще-то он немного о другом спрашивал.

А>да вот не показалось что-то. конечная его цель, имхо, именно такая

Ну уж, что показалось — то показалось.

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

BME>думаю его проблемы, которые были на 7-ой 1С, в большинстве своем исчезнут на 8-ке.

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