Здравствуйте, ambel-vlad, Вы писали:
AV>А как оценить квалификацию программеров из Microsoft и других? Полагаться только на имя? А в данном случае заказчик имел возможность контролировать программеров и их код. И тестеры сидять у заказчика. Так что тут еще бабушка надвое сказала.
Квалификацию программеров из MS оценивать не надо — не они пишут модули для вашего сервера. Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
А у вас как-то странно — разработчиков вы контролируете, а платформу, на которой они пишут — нет. Даже ОС заранее неизвестна.
AV>Из кода, написанного на одном языке, дернуть код, написанный на другом языке.
"дернуть" — вообще можно чем угодно. Передача данных пользовательских типов, я так понимаю, не входит в понятие "дернуть"?
AV>Ты читать умеешь? Говорилось про Python, а не про IronPython.
И в чем разница? Ваши питоновские исходники не работают под IronPython?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>А одного процесса? G>>>>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
AV>>>Почему? Если уверен к качесте unmanaged кода? G>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль.
Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>>>И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе? G>>Тогда не совсем понял как реализован интероп, если так просто вынести в отдельный процесс.
AV>Ничего сложного в этом нет. Если невдаваться в подробности, то в момент создания компонента определяется где он должен располагаться и далее от этого пляшем.
AV>>>А если есть два куска managed кода, но на разных языках? G>>SOA и пайпы\TCP\HTTP как транспорт.
AV>Не все ложится на SOA. Далеко не все.
Как раз на SOA ложится гораздо больше, чем вы можете себе представить.
AV>Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы?
Абстракция однако.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Sinclair, Вы писали:
S>>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
H>Синклер, не смеши общественность Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений.
Это как раз отсуствие контроля.
H>Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
В первую очередь работодатель не больной на голову чтобы набирать людей с абсолютно разными пристрастиями. Я вообще не видел ни одной конторы, где писали бы более чем на трех языках, причем решения по интеропу между языками заранее продуманы и не допускают произвольного дергания кода на одном языке и кода на другом языке.
Hi gandjustas
G>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства.
AV>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>Ну оно всегда так и начинается.
Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было.
Hi Sinclair
AV>>А как оценить квалификацию программеров из Microsoft и других? Полагаться только на имя? А в данном случае заказчик имел возможность контролировать программеров и их код. И тестеры сидять у заказчика. Так что тут еще бабушка надвое сказала. S>Квалификацию программеров из MS оценивать не надо — не они пишут модули для вашего сервера.
Ааа, в этом отношении. Так никто из внешних программистов не пишет модули для сервера. Они пишут только куски программ, которые крутятся под аппсервером. Даже если ляжет какой-то модуль, то он утянет за собой только одно приложение. Которое использует этот модуль. Если разработчик программы так сомневается в качестве используемого компонента, то он может первоначально создавать за пределами основного процесса. Да, при этом упадет производительность. И лишь потом, когда сможет убедиться, что он нормально функционирует, может использовать как inproc. При этом пересобирать остальной код не надо будет. Так что не так все страшно.
S>Если есть возможность контролировать программистов, тогда совершенно незачем поддерживать зоопарк языков программирования. Обычно, требование поддержки "произвольного языка" происходит именно из неконтролируемости внешнего разработчика.
Да нет, не всегда. Например, может оказаться, что разные части задачи выгоднее решать на разных языках.
S>А у вас как-то странно — разработчиков вы контролируете, а платформу, на которой они пишут — нет. Даже ОС заранее неизвестна.
Ну, набор ОСей известен. Просто он не ограничивается одной. Зачем абсолютно точное знание информации под какой ОС.
Заказчик контролирует код самого сервера, а не приложений работающих под ним.
AV>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. S>"дернуть" — вообще можно чем угодно. Передача данных пользовательских типов, я так понимаю, не входит в понятие "дернуть"?
Не правильно понимаешь, входит. Потому что в в противном случае толку было бы немного.
AV>>Ты читать умеешь? Говорилось про Python, а не про IronPython. S>И в чем разница? Ваши питоновские исходники не работают под IronPython?
Начнем с того, что толку с IronPython не под виндой мало. На чем мне его пускать? Опять вспоминаем Mono?
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Я выше в этой теме на данный вопрос ответил.
AF>Где? Тема большая.
Hi gandjustas
G>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы.
G>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов.
AV>>>>А если есть два куска managed кода, но на разных языках? G>>>SOA и пайпы\TCP\HTTP как транспорт.
AV>>Не все ложится на SOA. Далеко не все. G>Как раз на SOA ложится гораздо больше, чем вы можете себе представить.
Знаю, но все таки далеко не все.
AV>>Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы? G>Абстракция однако.
За которую приходится платить. Что не всегда может оказаться возможным.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
AV>И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства.
IIS, только произвольно звать один код и другого никто не даст.
Да и вообще это плохая идея, как уже обяснили многократно.
AV>>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>>Ну оно всегда так и начинается.
AV>Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было.
Это не является достоинством продукта.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
G>>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
AV>А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы.
Самое интересно что любую задачу можно решить просто.
G>>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов.
Ну в нормальном случае такое даже не потребовалось бы.
Hi gandjustas
G>>>>>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
AV>>>>Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль. G>>>Да ну. Далеко не для всех языков интероп с другими делается легко. Например с C++ итеропать на бинарном уровне не очень умеет даже сам C++.
AV>>А никто и не обещал, что будет все просто. Иначе мы и не нужны были бы. G>Самое интересно что любую задачу можно решить просто.
Ага, для любой задачи есть простое, лежащее на поверхности решение. И при этом неверное.
G>>>Использование кучи языков и выливается в создание нереальной инфраструктуры, вместо решения задачи.
AV>>Нормальная там инфраструктура. Не так уж оно и страшно. Когда мы думали браться или нет, то тоже казалось, что все страшно сложно делать. А потом, по мере въезжания в задачу все становилось понятно. А заказчик спокойно решает свою задачу, без каких-то напрягов. G>Ну в нормальном случае такое даже не потребовалось бы.
Ага, вот так не зная задачи ты сразу установил, что надо, а что не надо. Могёшь.
Hi gandjustas
G>>>>>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
AV>>>>Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово. G>>>Большой объем интеропа уже ненормально. Существуюищие аппсерверы обычно не допускают такого.
AV>>И много ты знаешь серверов на которых я могу использовать разные языки? Причем не из одного семейства. G>IIS, только произвольно звать один код и другого никто не даст.
Еще раз, IIS для первоначальной задачи не подходил. Кстати, как запустить IIS под HP-UX не подскажешь?
G>Да и вообще это плохая идея, как уже обяснили многократно.
Ага, объяснение типа мы так не делаем. Или я бы так не делал. Сильно.
AV>>>>И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер. G>>>Ну оно всегда так и начинается.
AV>>Да не сказал бы. Апп сервер сейчас отдельный продук, который используется не только на первоначальном проекте. И который заказчик уже сумел даже продать, несмотря на то, что на тот момент даже альфа-версии не было. G>Это не является достоинством продукта.
Полагаю, если бы это не нужно было бы, то вряд ли бы получилось продать кому-то. При этом показывая лишь рабочую версию.
AV>>Заказчик контролирует код самого сервера, а не приложений работающих под ним.
G>Так всетаки unmanaged код может завалить весь процесс, даже с managed модулями?
Одного приложения или всего сервера? Если только одного приложения, то да, может. Если будет выполняться в одном процессе. Если сервер завалить, то нет. Даже теоретически такой возможности нет.
Здравствуйте, March_rabbit, Вы писали:
CC>>Нет, все таки почему нельзя сделать и выложить отдельно DotNET_Runtime_XP32_Eng.msi? CC>>В чем непреодолимая трудность то? M_>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой?
Мне всё равно что там в линухе.
Я спрашиваю конкретно под винду: что именно мешает создать отдельные маленькие .NET Runtime дистрибутивы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Какая у тебя интересная классификация...
CC>>безопасник kochetkov.vladimir KV>Наверное все-таки дотнетчик в данном контексте. +можно и питонистом назвать, наверное.
Ну, как скажешь
CC>>линухоид Sheridan KV>считающий себя плюсником...
Шеридан это вообще отдельная категория, за пределами зла и добра.
KV>еще тут отмечался в создании тем Роман Одайский (плюсник, питонист) и куча другого народа, о чьих специализациях мне ничего неизвестно.
Я смотрел в первых нескольких темах в янусе.
Да в общем то в КСВ не столько важно кто тему создал, сколько к чему она в итоге приходит. Сцепились двое фанатов — и всё, подветку смело можно помечать как "ответы по теме прочитаны" чтоб больше этого срача не видеть.
KV>Отрицание фактов, как правило, является признаком того, что человек руководствуется верой, а не здравым смыслом. Он это имел ввиду, IMHO
Голые факты еще и трактовку могут иметь через призму мировосприятия трактующего. Потому и выходит, что факт то один, а понимают стороны его по-разному. Для кого-то может это и не факт вовсе.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
m> M_>гм.... а ничего, в линуксе это такая работа "маленький инсталлятор для дистра + закачка из инета остального" считается нормой? Сможете найти дистр, к которому не нужен будет инет для любого применения (Не берем ДВД поставку)?
m> Посмеялся, спасибо . Есть куча дистров, которым не нужен инет, это раз. А во вторых, где связь между дистрами Линуха и их установкой, и тем, что МС не выложила Фреймоворк разбитым на разные платформы?
Яркий пример странной двусторонней логики линуксоидов
Здравствуйте, CreatorCray, Вы писали:
KV>>еще тут отмечался в создании тем Роман Одайский (плюсник, питонист) и куча другого народа, о чьих специализациях мне ничего неизвестно. CC>Я смотрел в первых нескольких темах в янусе. CC>Да в общем то в КСВ не столько важно кто тему создал, сколько к чему она в итоге приходит. Сцепились двое фанатов — и всё, подветку смело можно помечать как "ответы по теме прочитаны" чтоб больше этого срача не видеть.
Тогда уж проще от КСВ отписаться, тут везде срач фанатов
C> M>Нет. Истинная кроссплатформенность — это "write once, run everywhere" (написал однажды, запустил везде) C> M>C++ с боооольшим натягом изредка предлагает "write once, compile everywhere" (написал однажды, скомпилировал везде)
C> Тут не согласен. Бинарная портируемость не особо-то нужна. Нормальной source code portability достаточно, тем более, что часто для каждой системы по мелочи надо затачивать определённые вещи.
А то
C> M>Действительно серьезного большого кросплатформенного софта (и чтобы еще на слузу) на Qt я особо не видел. Ну, кроме Qoogle Earth и Skyope (который, несмотря на всю кросплатформенность Qt, для Линукса развивается с большим опозданием)
C> На Windows он просто Skype не использует, вроде.
Знаешь, как оно бывает в больших конторах? А бывает так, что над проектом работают люди из совершенно разных поколений. Стоит ли говорить о том, что пристрастия, которые таки являются определяющими, у всех разные, а работодатель не больной на голову, чтоб инвестировать в переучивание всей толпы на новые фишки "современных технологий".
Посмеялся, спасибо 
