Вышел MonoDevelop 1.0 Beta 3 (0.18)

> Откровенно говоря, я не прогер, я System Architect и ведущий проекта в одном лице :)

Ах извините, вы. оказывается, из высшей расы.

> Рекламу тоже, да :)

Кроме ЛОР, негде тренировать этот скилл?

>Не стройте иллюзий. Python/Ruby - лабораторные крысы исследователей из MS Research. http://www.python.org/psf/members/

сам по-grep'аешь???

>(Голосом дотнетофила) Поищи на MSDN-е, ага :)

Помнится искал я там нужную в свое время информацию. Проклял все и зарекся ходить на эту помойку

> Кроме ЛОР, негде тренировать этот скилл?

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

P.S. Ну и кто порезал флейм?

>IIS аналогичен Tomcat. ASP.NET аналогична JSP/Servlets. ADO.NET (COM+) аналогична Stateless Session Bean's. Ну есть ещё система очередей сообщений MSMQ аналогична JMS. Есть монитор распределённых транзакций (COM+) как в J2EE. Средства кластеризации системы как в Tomcat.

Заметьте, что в случае с M$ идут конкретные продукт не имеющие эквивалентной замены, а в случае жабы тоже конкретные продукты, только реализующие стандартные спецификации, поэтому без проблем возможно следующая замена Tomcat<->Jetty JBoss<->Glassfish<->WebSphere<->.......<->Geronimo Хотя средаства кластеризации по-моему не стандартизированы.

Проблема Mono и dotGNU, которую в упор не хотят видеть поклонники этих быдлоподелок, в том что в мире .Net есть только один источник выработки стандартов - это M$. Поэтому стандарт == "соотвествующий продукт M$", а все остальные вынуждены их имитировать. Поэтому когда создатели поделок наконец-то смогут конкурировать с M$ - мелкомягкие просто выпустят новую линейку и все.

Прецеденты с "улучшением" различных решений в ущерб совместимости у мелкомягких уже были (JavaScript, MSJVM).

А вспомните когда сантехники кого-нибудь душили спецификацией JSP или EJB? Стандарты там вообще двигают далеко не только сантехники, JPA например вообще появился из Hibernate (наиболее успешный ORM), который разрабатывался в рамках JBoss, который является прямым конкурентом SJSAS и WebSphere. И тем не менее теперь это стандарт.

Есть безусловно и частные решения, никак не описанные какими-либо JSR, самое большое и универсальное из них это Spring, но при этом в тот же самый спринг можно без проблем встраивать другие вещи, которые уже описываются этими самыми спецификациями: хочешь пул соединений - без проблем (использую commons-dbcp)! хочешь JPA - без проблем (OpenJPA)! хочешь RMI поверх SLL с произвольной ssl библиотекой и хранением ключей там где тебе удобно - без проблем (commons-ssl)! При этом в большинстве случаев эти компоненты можно заменить аналогами (OpenJPA->TopLink).

И в результате без лишних усилий получается каркас распределенного защищенного stateless приложения (на тот случай когда серверы приложений оказываются слишком тяжелыми) и все дальнейшая работа сводится к написания сервисов для RMI, код которых вряд ли будет слишком большим за счет того, что JPA сущность можно вытащить из одной базы - передать по RMI и тут же сохранить в другую базу. На все про все уйдет всего лишь пара рабочих дней. А потом только гонять в профайлере, отлаживать и полировать... И наконец учтите, что получается оно лицензионно чистым (стоимость "0").

В результате довольно сложные программы можно собирать из готовых кусков, описывая их в одном файлике spring.xml - это к вопросу зачем нужен IoC вообще и Spring в частности.

>IIS аналогичен Tomcat. ASP.NET аналогична JSP/Servlets. ADO.NET (COM+) аналогична Stateless Session Bean's. Ну есть ещё система очередей сообщений MSMQ аналогична JMS. Есть монитор распределённых транзакций (COM+) как в J2EE. Средства кластеризации системы как в Tomcat.

Заметьте, что в случае с M$ идут конкретные продукт не имеющие эквивалентной замены, а в случае жабы тоже конкретные продукты, только реализующие стандартные спецификации, поэтому без проблем возможно следующая замена Tomcat<->Jetty JBoss<->Glassfish<->WebSphere<->.......<->Geronimo Хотя средаства кластеризации по-моему не стандартизированы.

Проблема Mono и dotGNU, которую в упор не хотят видеть поклонники этих быдлоподелок, в том что в мире .Net есть только один источник выработки стандартов - это M$. Поэтому стандарт == "соотвествующий продукт M$", а все остальные вынуждены их имитировать. Поэтому когда создатели поделок наконец-то смогут конкурировать с M$ - мелкомягкие просто выпустят новую линейку и все.

Прецеденты с "улучшением" различных решений в ущерб совместимости у мелкомягких уже были (JavaScript, MSJVM).

А вспомните когда сантехники кого-нибудь душили спецификацией JSP или EJB? Стандарты там вообще двигают далеко не только сантехники, JPA например вообще появился из Hibernate (наиболее успешный ORM), который разрабатывался в рамках JBoss, который является прямым конкурентом SJSAS и WebSphere. И тем не менее теперь это стандарт.

Есть безусловно и частные решения, никак не описанные какими-либо JSR, самое большое и универсальное из них это Spring, но при этом в тот же самый спринг можно без проблем встраивать другие вещи, которые уже описываются этими самыми спецификациями: хочешь пул соединений - без проблем (использую commons-dbcp)! хочешь JPA - без проблем (OpenJPA)! хочешь RMI поверх SLL с произвольной ssl библиотекой и хранением ключей там где тебе удобно - без проблем (commons-ssl)! При этом в большинстве случаев эти компоненты можно заменить аналогами (OpenJPA->TopLink).

И в результате без лишних усилий получается каркас распределенного защищенного stateless приложения (на тот случай когда серверы приложений оказываются слишком тяжелыми) и все дальнейшая работа сводится к написания сервисов для RMI, код которых вряд ли будет слишком большим за счет того, что JPA сущность можно вытащить из одной базы - передать по RMI и тут же сохранить в другую базу. На все про все уйдет всего лишь пара рабочих дней. А потом только гонять в профайлере, отлаживать и полировать... И наконец учтите, что получается оно лицензионно чистым (стоимость "0").

В результате довольно сложные программы можно собирать из готовых кусков, описывая их в одном файлике spring.xml - это к вопросу зачем нужен IoC вообще и Spring в частности.

+1 Только бессмысленно это все говорить M$-троллям, которые предпочитают "дженерики без боксинга" кроссплатформенности. Они мяслят другими, более местечковыми категориями. Просто когда они пойдут искать работу со знанием только ".Net", будет забавно. "Серъезные, масштабируемые Web-решения на основе технологии .Net !". Смешно, да ? Так и будут писать мелкие конъюнктурные поделия.

Завалили троля - снесли весь топик :(

>Завалили троля - снесли весь топик :(

А нехрень тролить, будем делать из ЛОРа приличный форум!

>> Завалили троля - снесли весь топик :(

> А нехрень тролить, будем делать из ЛОРа приличный форум!

Анонимус нам поможет.

> Моно - нужен. Монодевелоп - не нужен как недоделанный брат MSVS. > r *** (*) (23.12.2007 17:07:04)

Виндовоз на сайте! Забаньте его!!!

> Проблема Mono и dotGNU, которую в упор не хотят видеть поклонники этих быдлоподелок, в том что в мире .Net есть только один источник выработки стандартов - это M$.

Проблема на самом деле хуже. В мире Java тоже один источник стандартов - Sun. Другое дело, что в мире .Net один источник не только стандартов, но и _решений_. А это уже криминал.

> Только бессмысленно это все говорить M$-троллям, которые предпочитают "дженерики без боксинга" кроссплатформенности.

.Net программисты настолько суровы, что пишут огромные приложения масштабов локальной сети (неужто A-class?), на кросс-платформенном C#, обеспечивая при этом безопасность с помощью unsafe managed, и без всяких, заметьте, контейнеров, а также обеспечивают надежность системы с помощью одних только stateless сообщений...

Я даже боюсь представить, что они используют в качестве AS :D

>В мире Java тоже один источник стандартов - Sun. Другое дело, что в мире

Неверно. Сан давно создал Java Community Process. Стандарты вырабатываются сообществом - игроками рынка. Куча JSRов принята другими компаниями в совместном процессе. Там политика подобная w3c.

Встретить малознающего и не очень вежливого тролля - это еще не значит иметь дело с .NET программистами. Он откровенно лажался пару раз, но зато всем было весело читать :)

Многое зависит от рыночной ниши. Вероятно, в области server side development решениям на основе Java нет равных. Но для client side application development дотнетовские решения смотрятся достаточно неплохо, по крайней мере, они выглядят предпочтительнее в виндоус-сегменте, а именно он покрывает наибольшую часть указанного рынка.

Лично мне нравятся обе технологии. Если бы выбор зависел от меня - я бы использовал в нашем проекте Java с самого начала, хотя бы для той же много-платформенности, и занимался бы разработкой, скорее всего, сидя на Линуксе... К тому же, некоторые аппетитные юзеры сидят на Mac OS X, и Java - очень хороший способ подобраться к ним :)

В общем, давайте без фанатизма! Не достойно это почетного звания System Architect ;)

> пока прогер на питоне бкдет на очередную быдложигули копить, проген на C# будет на бентли кататься. питон не нужен.

Ха-ха-ха! Смеётся программист на Питоне, работающий на телекомы, катаясь на личной новой БМВ со 100% начинкой... И ухмыляясь коллегам на C#, катающимся на старых Рено, Опелях и им подобных... Реальность бывает разная и у меня она именно такая. Вы не со всем знакомы, молодой человек, либо у вас окружение неправильное!

> Больше 500 форм с интерфейсом к БД MS SQL Server 2005 (724 таблицы, 1417 хранимых процедур, 4414 триггеров, 661 вида) + ASP.Net Web Services + ...

> На Пидоне осилишь?

Без проблем, тем более проекты и посерьёзнее имеются. Опыта у тебя видимо маловато и Моно съел твой мозг.

> Как там кстати называется технология доступа к БД?

А тебе о какой именно рассказать?

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

А ты ещё до этого не дошёл в букваре?

> А визуальный редактор форм там вообще есть?

Есть. А тебе для чего? Ты ещё и дизайнер интерфейсов на подработке?

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

Читай, пробуй, спрашивай... Поможет!

>> Как там кстати называется технология доступа к БД? Визуальные контолы могут быть привязаны к источникам данных? А визуальный редактор форм там вообще есть?

> Короче говоря, "костыли" для убогого язычка.

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

>А нехрень тролить, будем делать из ЛОРа приличный форум!

Приличных форумов и так хватает. forum.ixbt.com, как пример, где давно любые дискуссии выжыгаются каленым железом и люди ходят только справки наводить. Да вот ответов толковых нам не дождешься по причине что отвечают такие же, которые пришли справки наводить. Замкнутый круг. Специалистам там просто скучно. зато приличный форум, болото с черепахами-тортиллами

>Но для client side application development дотнетовские решения смотрятся достаточно неплохо, по крайней мере, они выглядят предпочтительнее в виндоус-сегменте, а именно он покрывает наибольшую часть указанного рынка.

Не перечисли 2-10-30. Хотя бы. Покажи хотя бы аналог www.oxygenxml.com

> Сан давно создал Java Community Process. Стандарты вырабатываются сообществом - игроками рынка. Куча JSRов принята другими компаниями в совместном процессе. Там политика подобная w3c.

Да нет, это больше напоминает развитие OpenOffice. Впрочем, замечание по сути верное.

> Многое зависит от рыночной ниши.

Безусловно. Например - не так давно начинали мы очередной стартапчик, и к нему надо было пригласить программиста. Программисту дали волю выбирать любой удобный фреймворк, на котором он быстрее всего сможет выполнить задачу (нужна была демка для инвестора). Хоть PHP, хоть на C++ пиши - только не на .Net. Почему? Потому что сервер на FreeBSD - нет там никакого .Net.

> Но для client side application development дотнетовские решения смотрятся достаточно неплохо, по крайней мере, они выглядят предпочтительнее в виндоус-сегменте, а именно он покрывает наибольшую часть указанного рынка.

Именно потому что там нивелируется основной недостаток .Net - отсутствие реальной кроссплатформенности. После этого уже можно обсуждать особенности реализации дженериков и качество документации.

Но тут мы уже вступим на постоянно меняющееся поле клиентских технологий, например можно сравнивать Java+Swing против .Net+WinForms, а можно Java+Qt против Mono.

> В общем, давайте без фанатизма!

Да я вроде и не начинал... :)

А вообще, с ростом доли не-Windows решений политика Microsoft "делаем все Win-only" из положительной спирали перейдет в отрицательную. И тогда все эти .Net, DirectX, закрытые форматы офисов и другие подобные шутки либо резко станут открытыми, либо помрут, захватив с собой бюджет на их разработку.

С Java на Win-платформе есть следующая проблема - нужно тащить JRE. Есть другой путь - использовать что-то типа Excelsior JIT. Просить же пользователя самому установить JRE - не каждый пользователь осилит такое. Для небольших приложений (< 8Мб) это неприятно.

С дотнетом много проще - привилегия иметь свою систему.

Потом оборотной стороной кросс-платформенности является некоторая обособленность или отчужденность среды выполнения (Java/Qt/Gtk) от системы. Это значит, что многие системные вещи будут недоступны. Для некоторых десктопных приложений это может быть неприятно. Как то: более ограниченная работа с системными сервисами типа Clipboard или трейя, трудности при перехвате системных сообщений и т.п.

Например, некоторые библиотеко-строители предпочитают делать общий update какого-нибудь вин-контрола простым игнором системного сообщение paint, пока обновляются данные... да уж... И это иногда очень хорошие во многих других отношениях контролы (XPTable).

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

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

>Потом оборотной стороной кросс-платформенности является некоторая обособленность или отчужденность среды выполнения (Java/Qt/Gtk) от системы. Это значит, что многие системные вещи будут недоступны.

Это прежде всего значит, что пользователь увидит, что его программа работает также и в Linux и он не обязан больше Windows покупать! Многие ведь ищут на Linux аналоги своих любимых The Bat!, Dr.Web, Trillian, LightAlloy Player и т.п. и не находят.

>Пусть будет лучше конкуренция, желательно честная конкуренция. :)

Пусть лучше будет коммунизм и техно..изм, как завещал Великий Луговский. Потому что результаты конкуренции мы видим с 1990 года на улицах наших городов, в магазинах, в счетах за квартиру, в билетах на самолет. Скажи, почему ни с того ни с хрена цена на молоко выросла на 50%? В Европе что-то там поднялось? На сколько, на 50%? Или на 5% подорожало в Европе, и не молоко? А у нас с радостью "конкурирующие" между собой ретэйл-сети подняли сразу на все на 50%! О как. Лучше пусть будет коммунизм, а директора этих сетей работают управдомами и чинят лифты в моем подъезде. Это точно будет лучше. А честная конкуренция это то же что и сухая вода. Оксиморон.

>Просить же пользователя самому установить JRE - не каждый пользователь осилит такое. Для небольших приложений (< 8Мб) это неприятно.

а) DirectX себе большинство устанавливает, многие не только с прилагаемого к материнке или игре CD, но и качают с инета. Для этого не нужно быть доктором наук, как многие хотят себе это представить. Достаточно Sun перевести страницу загрузки JRE на нормальный русский язык и снабдить пояснениями насчет прав администратора и UAC.

б) С большинством приложений >10Mb JRE идет "в коробке", можно выбрать "Скачать приложение" и "Для тех, кто знает, что делает: скачать приложение без JRE". Достаточно грамотные варианты. Для их понимания тоже не надо быть доктором наук.

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

> цена на молоко выросла на 50%?

Вот поэтому самому и нужна конкуренция! Просто у нас ее .. нету или совсем мало. Может быть, для тебя секрет, но российская экономика - очень монополизированая. У нас только фасад рыночный, а суть совсем нерыночная... И капитал страны сконцентрирован в руках очень маленькой прослойки людей - это они с сами с собою что-ли конкурируют?! :)

Возвращаясь к нашим баранам. Вот, чтобы таких процессов не было и в области программирования - нужна конкуренция. Пусть будут сосуществовать Linux, Mac OS X, Solaris, Windows и все прочие. Вертикаль, выстроенная вокруг одной Единой Системы тут ни к чему. Плохо будет от этого только. И прежде всего самой системе - загниет. Тогда найдутся другие и обгонят.

На счет Direct X. Полагаю, что большинство пользователей Windows плохо представляет себе, что это такое... И с этим бесполезно бороться. Это нужно воспринимать как данность.

>Вот поэтому самому и нужна конкуренция! Просто у нас ее .. нету или совсем мало. Может быть, для тебя секрет, но российская экономика - очень монополизированая. У нас только фасад рыночный, а суть совсем нерыночная... И капитал страны сконцентрирован в руках очень маленькой прослойки людей - это они с сами с собою что-ли конкурируют?! :)

А не будет у нас конкуренции, родной, все, проехали уже. Не будет. В 90-х годах все это прошли. Конкуренция возможна только в условиях защиты бизнеса от рэкета и рейдерства, то есть только при наличии поправки номер 2. Поскольку в РФии такой поправки никогда не введут, то и монополии во всех отраслях - наш удел. Только теперь монополии по факту хуже, чем они были при совке, тогда ими хоть образованные и подготовленные кадры управляли, теперь же кадры приходится из-за границы импортировать.

>Вертикаль, выстроенная вокруг одной Единой Системы тут ни к чему. Плохо будет от этого только. И прежде всего самой системе - загниет.

Опять будешь твердить мантру, что жаба без конкуренции загнила и C# подтолкнул жабистов к внедрению генериков? Но я много раз читал неоднозначные мнения о том, что генерики в жабу введены неидеально, и толку от них не так много, как МОГЛО БЫ БЫТЬ, и как от них есть толк в C#.

>Полагаю, что большинство пользователей Windows плохо представляет себе, что это такое... И с этим бесполезно бороться. Это нужно воспринимать как данность.

Не будем о быдле. DRM таким пользователям в зубы и TCPA в спину. Чтобы посреди празднования Нового года их компьютер выдал черный экран и предложения оплатить его использование, а плату принимали только после 14-го января.

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