Big switch или жизнь после Microsoft: Почему мы сказали .NET'у нет

До недавнего времени предано нес знамя Microsoft .NET. Восхвалял Silverlight, ASP.NET MVC и верил в чудеса. За четыре года работы c .NET стал сертифицированным разработчиком по широкому спектру
технологий: ASP.NET, WCF, WPF, ADO.NET. Однако за год существования собственного интернет агентства разочаровался в выбранном пути и обратился в другую веру.
image

В серии статей “Big switch или жизнь после Microsoft” я расскажу об опыте полученном нашей командой при переходе со стэка веб-технологий Windows + .NET на Linux + Ruby on Rails, а также приведу конкретные инструкции к применению, которые помогут на первых порах.

Начну я с 3-х причин, которые побудили нас сказать .NET'у нет.


1. Зависимость


image

Работая с продуктами .NET вы обрекаете себя на зависимость. Зависимость от платного программного обеспечения и бесконечного множества платных компонент, начиная от графического интерфейса и заканчивая банальным сбором почты по протоколу IMAP.

Вы тратите львиную долю времени на изучение лицензий и цен для поиска подходящей конфигурации. Вам приходится мириться с тем, что remote desktop не поддерживает двух подключений, а в состав windows web server 2008 не входит dns-сервер.

Если вы хотите масштабировать ваши решения лишь ценой покупки или аренды аппаратного обеспечения, то .NET не для вас.

2. Закрытость


Дополнительные затраты времени и ресурсов на борьбу с лицензиями это только пол беды, куда более страшным является закрытость технологии .NET и ее сообщества.

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

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

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

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

Стоит отметить, что Майкрософт начал делать шаги в сторону открытого исходного кода. Однако пока это можно назвать лишь поползновениями, так как в реальности выкладываются лишь срезы соответствующие определенной бете или релизу. В результате чего сообщество по-прежнему безучастно в жизни продукта и со слюной у рта ждет очередного релиза. Для убедительности приведу лог коммитов проекта ASP.NET MVC:

image

3. Microsoft way


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

Еще вчера Майкрософт делал собственный JavaScript фреймворк и благо в конечном итоге внедрил Jquery. Тоже самое можно сказать и о технологии ASP.NET, которая за 5 лет до появления ASP.NET MVC показала свою полную несостоятельность.

Несмотря на положительную тенденцию, которые задал ASP.NET MVC (веб-фреймворк полностью дублирующий Ruby on Rails, однако, лишенный прелестей динамического языка) Майкрософт по прежнему наступает на те же грабли. Так, например, в новой версии вместо адаптации Haml нам обещают Razor, который будет «очень удобен» и все будут «счастливы».

Подобная тенденция наблюдается и у рядовых разработчиков .NET. Все они без исключения пишут свои фреймворки аутентификации, авторизации, в ручную реализуют управления жизненным циклом сессии в БД и этот список можно продолжать бесконечно. Однако подобная самодеятельность не всегда хорошо отражается на качестве проектов.

image

В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов», что крайне негативно сказывается на сроках разработки.

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

В последующих статьях данного цикла я на конкретных примерах покажу преимущества Ruby on Rails над ASP.NET MVC и другими продуктами Майкрософт, приведу инструкции по безболезненному переходу на Ruby on Rails для людей далеких от мира Linux и открытых технологий.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 253
  • +22
    Аргументы притянуты за уши.
    • +29
      Конкретные примеры будут в последующих статьх. Здесь я выделил три фундаментальные проблемы, которые мешали нашей команде.
      • +40
        >> Работая с продуктами .NET вы обрекаете себя на зависимость. Зависимость от платного программного обеспечения и бесконечного множества платных компонент, начиная от графического интерфейса и заканчивая банальным сбором почты по протоколу IMAP.

        Я так понимаю, на сайте codeplex.com вас забанили. Вот кстати про IMAP
        www.codeplex.com/site/search?query=imap

        >> Вы тратите львиную долю времени на изучение лицензий и цен для поиска подходящей конфигурации.

        Это ваша проблема. Все лицензии легко определются по признакам royality-free/per-server и site/per-developer. Остальное не существенные мелочи.

        >> Вам приходится мириться с тем, что remote desktop не поддерживает двух подключений, а в состав windows web server 2008 не входит dns-сервер.

        DNS сервер у регистратора домена или хостера. Зачем свой? Для публикации web приложений не нужен remote desktop.

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

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

        >> Качество продукта с открытым исходным кодом можно оценить основываясь на более весомых факторах:
        >> * Покрытие тестами.
        >> * Частота обновлений.
        >> * Количество загрузок.
        >> * Количество и личности разработчиков.

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

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

        Работая с закрытыми технологиями тоже. Вот например HTMLayout библиотека с закрытым кодом. Но я по скайпу сообщаю автору о багах и исправленная версия бывает доступна в тот же день. Это при том, что у него в клиентах Symantec, Motorola и другие компании по сравнению с которыми я никто и звать меня никак. Это вопрос цикла разработки, а не открытости кода.

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

        Ваши фантазии не могут служить аргументами.

        >> Для убедительности приведу лог коммитов проекта ASP.NET MVC:

        ОК, посмотрели скриншот. Увидели коммит не для публики. Дальше что?

        >> Подобная тенденция наблюдается и у рядовых разработчиков .NET. Все они без исключения пишут свои фреймворки аутентификации, авторизации, вручную реализуют управления жизненным циклом сессии в БД и этот список можно продолжать бесконечно. Однако подобная самодеятельность не всегда хорошо отражается на качестве проектов.

        Вы в зеркало смотрели когда это говорили? Кто кроме вас «вручную реализует управление жизненным циклом сессии в БД»? Это же какая бредятина-то!
        • –10
          На codeplex.com, конечно, много что есть. Но все под странными лицензиями, чистый LGPL весьма редкостен.
          • +36
            >> Я так понимаю, на сайте codeplex.com вас забанили. Вот кстати про IMAP
            www.codeplex.com/site/search?query=imap

            Сodeplex — это хорошо. Но он все больше и возможно безнадежно отстал от Github.

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

            >> DNS сервер у регистратора домена или хостера. Зачем свой? Для публикации web приложений не нужен remote desktop.

            Свой DNS сервер удобен, когда у компании много сайтов, а домены разбросаны по разным регистраторам.

            Remote desktop нужен для управления собственным удаленным сервером.

            >> ОК, посмотрели скриншот. Увидели коммит не для публики. Дальше что?

            Суть в том, что ASP.NET MVC это проект в который нельзя сделать Fork, а его коммиты не публичны. Выкладываются лишь срезу за определенный период.

            >>Вы в зеркало смотрели когда это говорили? Кто кроме вас «вручную реализует управление жизненным циклом сессии в БД»? Это же какая бредятина-то!

            ASP.NET MVC не регламетнирует момент освободжение объектов типа LTS, EF датаконтекстов. Всем разработчикам надо самим решить где и когда они будут создаваться и освободжаться.

            • НЛО прилетело и опубликовало эту надпись здесь
              • +21
                Платно != качественно. Бесплатно != некачественно
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +7
                    Не буду холиварить по поводу того, что использовать, но почти в любом языке программирования есть функция, которая вычисляет зависимость качества продукта от цены. И её название — random.
              • +11
                Давно не обновляется это не так уж и критично. log4net тоже обновлялся редко и давно, но это не делает библиотеку менее ценной. Частые обновления сами по себе не являются положительной характеристикой.

                Есть разница между своим DNS сервером и своим DNS сервером совмещённым c web сервером. Remote desktop НЕ нужен для удалённого управления IIS. Нужен PP2T incoming connection и локально установленная оснастка MMC.

                Предположим, что вам действительно надо править исходники фреймворка. Но зачем вам делать публичный fork ASP.Net MVC? Даже если бы вы имели доступ к основному репозиторию, это был бы read-only доступ. Вы бы всё равно не смогли бы сделать ветку в том же репозитории.
              • +28
                > Это ваша проблема.
                Прекрасный аргумент :)

                > Все лицензии легко определются по признакам royality-free/per-server и site/per-developer. Остальное не существенные мелочи.
                Мелочи зачастую очень даже существенны. Одна из прелестей opensource — малый набор лицензий, разобравшись в зоопарке которых единожды, больше не нужно тратить время на понимание тех или иных аспектов.

                > DNS сервер у регистратора домена или хостера. Зачем свой?
                Чудесный способ решения проблем. Если чего-то нет, то и «не нужно». Мне, может быть, нужно.

                > Частота обновлений и количество загрузок параметры не специфичные для открытого кода
                Кто сказал?
                Количество загрузок — да, но частота обновления выше. Хотя бы тем, что можно взять свежий срез из VCS-репозитория.
                Да и release early, release often никто не отменял.
                • +1
                  >Одна из прелестей opensource — малый набор лицензий

                  *поперхнулся*

                  чтоооо? www.opensource.org/licenses/category

                  Не говоря уже о том, что они через одну несовместимы друг с другом.

                  Типов коммерческих лицензий намного ментше и их термины намного прозрачнее и понятнее
                  • 0
                    Отлично! Хотя бы примерное количество и типы лицензий opensource мы знаем.

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

                    > Не говоря уже о том, что они через одну несовместимы друг с другом.
                    Большинство — совместимы друг с другом. Но есть исключения, согласен.

                    > Типов коммерческих лицензий намного ментше
                    Откуда дровишки?

                    > их термины намного прозрачнее и понятнее
                    «Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию. У проприетарщиков так же?

                    По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта. А вы можете поручиться, что в коммерческих все так же просто?
                    • 0
                      > Большинство — совместимы друг с другом.

                      Досаточно появиться GPL — и до свидания

                      > Откуда дровишки?

                      Оттуда же :)

                      Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.

                      > «Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию.

                      Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.

                      > По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта.

                      Угу, это если повезет с лицензиями типа Apache или MIT.

                      > А вы можете поручиться, что в коммерческих все так же просто?

                      Гарантий нет никаких ;) Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
                      • 0
                        > Досаточно появиться GPL — и до свидания
                        Линковать с GPL можно что угодно — нужно лишь сделать результирующий проект под gpl. А это уж, извините, детали :)

                        > Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.
                        И приходим к вопросу о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.

                        > Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
                        Но они хотя бы есть ;)

                        > Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
                        LGPL чем не нравится? Ну да, нужно публиковать изменения, вносимые в оригинал, но чем плохо развитие этого проекта?
                        Да и BSD тоже довольно неплоха.

                        Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом. Я регулярно залезаю в исходники Qt, чтобы поглядеть, как реализованы те или иные вещи.
                        • 0
                          > Линковать с GPL можно что угодно — нужно лишь сделать результирующий проект под gpl. А это уж, извините, детали :)

                          Это — далеко не детали ;)

                          > о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.

                          Есь такое :)

                          >> Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
                          > Но они хотя бы есть ;)

                          А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.

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

                          А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.

                          Но:
                          — для некоммерческой разработки оно под GPL: www.sencha.com/products/license.php
                          — вопрос о том, надо ли в таком случае открывать и исходники серверной части под баааальшим вопросом, на который никто, повторю — никто — не знает ответа
                          — как с коммерческой лицензией соотносятся опенсорс-плагины к ExtJS?
                          — как с GPL продукта соотносятся коммерческие плагины (если такие есть)?
                          — как с GPL продукта соотносятся плагины, которые могут быть в лицензиях, несовместимых с GPL?

                          и т.д. и т.п. :)

                          А так да — я бы хотел ExtJS под MIT :)

                          > Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом.

                          Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
                          • +1
                            > Это — далеко не детали ;)
                            Вопрос был про количество лицензий и их понятность. Содержимое мы, вроде как, не рассматривали. В этом случае тогда могу приплести, что GPL-программы обычно (не всегда) бесплатны. Но, повторюсь, этот вопрос стоит вне начала дискуссии.

                            > А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
                            Не интересовался этим вопросом, поэтому не могу сказать точно. Быстрый гуглопоиск показал, что в GPLv3 это, вроде, разрешили.

                            > А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.
                            Наверное, я не так понял вашу мысль. Я подумал, что там было высказывание в общем про выбор лицензии. А их обычно для своих продуктов выбирают :)

                            > Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
                            Не всегда документация дает нормальный ответ о поведении того или иного объекта. С PHP или Python из исходников на C мало что вынесешь, но, полагаю, разбор какого-нибудь фреймворка был бы довольно полезен. В общем и целом — согласен с мыслью.

                            Я больше по десктопным и серверным приложениям специализируюсь. По таким, которые компилируются, линкуются и подгружаются. Все подобные нюансы прописаны еще в GPLv2. Поэтому на ваши вопросы однозначных ответов дать не могу.
                            На мой взгляд, если подобные вопросы возникают, то это проблема создателя продукта, что он выбрал не ту лицензию и можно попросить у него разъяснений по данному вопросу.
                            • 0
                              На самом деле, мы говорим на одном языке, поэтому это, по большому счету спор ради спора :)

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

                              :)
                              • 0
                                Согласен, закончим, пожалуй :)
                            • 0
                              Результирующий проект под gpl часто не проблема: если сервер под gpl и предоставляет network api, то создатель не обязан предоставлять исходники, так как фактически дистрибуции не происходит. Таким образом, если проект — web site или web service, к которому продается доступ, то он может быть без проблем написан под gpl лицензией. (Что бы запретить эту схему была разработана agpl)

                              Дугой вариант, когда софт пишется под заказ и у него один потребитель. Тут тоже gpl не проблема.
                              • 0
                                > Результирующий проект под gpl часто не проблема: если сервер под gpl и предоставляет network api, то создатель не обязан предоставлять исходники, так как фактически дистрибуции не происходит

                                И тут начинаются подводные камни с определением того самого network API ;)
                              • 0
                                > А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.

                                Естественно, можно.

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

                                Вы должны открывать исходники своим заказчикам, т.к. они являются непосредственными пользователями ПО.
                  • 0
                    Ждём, с нетерпением, продолжения.
                • +3
                  Вам приходится мериться с тем...
                  «мериться» от слова «мера»
                • +23
                  Ох зря вы начали с «вводной» холиварной статьи — они лишь бударажат, вызывают массу вопросов (адресованных к последующим частям) и вас нахлобучат, за то что нет аргументов, все притянуто за уши. Если бы смержили вводную с «конкретными примерами преимущества» было бы что обсуждать и две(?) хаброволны столкнулись бы в очередном буйстве (да, да, каждому инструменту есть своя область применения, где он идеален, бла-бла-бла, только всем пох, когда обидели их инструментарий), ведь ваша цель — дать лишний повод миграции тем, кто сомневается или не знает как перевести текущую «инфраструктуру» безболезненно. А ваш инструмент — убеждение на примере + имеющийся опыт миграции. И, да, .net — херня :)
                  • +6
                    зачем такой мелкий текст?
                    • –5
                      Извините, просто выхлоп на полстраницы получился, а остановиться уже не мог. Пришлось кукожить, чтобы не поломать чье-нибудь хрупкое сознание.
                      • +21
                        Зато похоже вы поломаете кому-то глаза…
                  • –2
                    Надеюсь автора не сольют.
                    • –6
                      Этот комментарий, вне всяких сомнений, заслуживает 4 минуса в карму. Обожаю хабр.
                    • +28
                      лишенный прелестей динамического языка

                      Субъективно. Для меня больше прелестей в статическом.
                      • +6
                        а тут просто проблема в поиске — DLR
                        • +6
                          DLR — это хорошо. Но пока тот же IronRuby не может заменить оригинал, так нет возможности работать с gem'ами, которые содержат native code на C. А таких очень много, причем самых критичных.
                          • +1
                            Есть ограничения, но я с ними не сталкивался, мне хватает.
                          • –1
                            И? Есть решение, которое уже можно использовать в продакшене, на базе DLR?
                          • 0
                            В контексте веб-фреймворка статика сильно мешает. Она провоцирует создание дополнительной прослойки из PresentationModel классов, которые растут как грибы после дождя (Пример: UserRegistrationInputModel, UserChangePasswordInputModel, UserLoginInputModel) итд.
                            • +8
                              В ASP.Net MVC 3 используется dynamic model. И, кстати, во второй версии его можно очень просто прикрутить — код ASP.Net MVC открыт и доступен для изменений.
                              • –1
                                Хорошее нововведение, а в обратную сторону оно работает? То есть когда модель передается при посте из формы.
                                • 0
                                  Думаю, в общем случае работать не будет, так как при посте формы передаются строки и по входящей информации непонятно, как точно их парсить — все же C# язык статический, и вам вряд ли нужно, чтобы все свойства обьекта были строками.
                                  С другой стороны, есть еще одна фича, которая позволяет передавать в метод JSON-обьект, и, мне кажется, не так уж и сложно парсить его и присваивать значения свойствам какого-нибуть ExpandoObject.
                                  • –1
                                    Но он не сможет привести типы если входной параметр экшена не будет строготипизрованной моделью.
                                    • +4
                                      По JSON-обьекту все же можно определить, какого типа каждое из его свойств, в отличии от обычной формы, переданой в пост-запросе.
                                      Например:
                                      var obj = {
                                        StringProperty: 'some string',
                                        IntegerProperty: 100500,
                                        ArrayProperty: ['aaa', 'bbb'],
                                        ObjectProperty: {
                                          IntegerProperty: -1
                                        }
                                      }
                                      

                                      вполне легко распарсить как вот такой обьект на C#:
                                            dynamic obj = new ExpandoObject();
                                            obj.StringProperty = "some string";
                                            obj.IntegerProperty = 100500;
                                            obj.ArrayProperty = new[] {"aaa", "bbb"};
                                            obj.ObjectProperty = (dynamic)new ExpandoObject();
                                            obj.ObjectProperty.IntegerProperty = -1;
                                      
                            • 0
                              +1, статика лучше
                              stas-agarkov.livejournal.com/18487.html
                              • +3
                                Угу, по ссылке рассказывают о том, какая динамика плохая на примере слаботипизированого динамического РНР, у которого еще дикие проблемы в плане архитектуры и продуманности фич.

                                Берется в руки строго типзированый динамический Python или Erlang и обретается щастя

                                • –3
                                  я не согласен.
                                  с python-ом intellisense в idea очень плохо работает
                                  • +2
                                    Не интеллисенсом единым ;)
                            • +7
                              Пока это фигня какая-то с кучей ненужных картинок. Подожду следующей статьи, но начало неправильное.
                              • +16
                                > Работая с открытыми технологиями, вы можете непосредственно влиять на разработку. Люди, разрабатывающие продукт, публично известны и с ними легко можно установить прямой контакт. Возникшую проблему можно решить и самостоятельно, а решение отправить на суд разработчикам и другим членам сообщества.

                                Ну с платными технологиями такая же штуковина. Всё зависит от, на самом деле. Бывают и плохо поддерживаемые откртые проекты, и хорошо поддерживаемые проприетарные.

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

                                Ну что-то качеством открытые библиотеки для Java, которые я использую на работе, не отличаются. А вот на прошлом месте работы мы как раз юзали .NET и нареканий не было. Впрочем, там ситуация неоднозначная. Вот у меня много ругани вызывает связка JasperReports + iReport + jfreechart, причём порой оказывается, что нужная фича таки есть, но прикручена она куда-нибудь глубоко внутрь и совсем не документирована. А индусы, которые пишут всякие руководства, как правило, идут по пути индус-way, так что для решения проблемы приходится тщательно изучать код самому. Можно, конечно, купить книжечку по JasperReports, но это уже денежки.

                                > лишенный прелестей динамического языка

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

                                > В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов»

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

                                А вообще, заголовок статьи немного провокационный. Да, у дотнета есть определённые проблемы с web. Но дотнет вебом не ограничивается. Там ещё куча технологий. Например, лучше WPF в плане построения пользовательских интерфейсов, я ещё ничего не видел. Какой-нибудь Swing, который я сейчас использую, и для которого приходится изобретать кучу велосипедов и применять множество костылей, даже рядом не валялся. Так что может стоило назвать «почему мы сказали ASP.NET'у нет»?
                                • +11
                                  Жаба отстала серьезно, причем с .net 2.0.
                                  • +4
                                    Ну да, отстала. Но мне Java больше нравится по политическим соображениям, нежели чем по технологическим. А начиная где-то версии 5-6, мне на ней хотя бы не противно писать. Ненавижу мелкомягких менеджеров, которые своей политикой гробят такую прекрасную технологию.
                                    • 0
                                      После последнего демарша от Oracle — .Net с наличием Моно становится более привлекательным… :)
                                    • –11
                                      .NET научился деплоиться и скейлится на OpenSource за 0.00$? Или может MS любит альтернативные языки и вовсе не сократил команду IronRuby, в то время как над JRuby работает топовый Ruby-shop имени EngineYard? Ах, да Windows Phone далеко впереди Google Android. Да и такие передовые технологии Hadoop & GWT небось тоже на .NET?
                                    • –2
                                      В .net есть кроссплатформенная обертка над механизмом select файловых дескрипторов, которая под linux 2.6 использует epoll? Подумайте над этим. Синтаксические плюшки со временем приедаются.

                                      (.net-чик, обращенный в java)
                                      • +3
                                        вероятно для вас, как бывшего .net-чика, будет интересно узнать, что .net не работает под линукс 2.6
                                        • +4
                                          Я знаю. Собственно это и заставило перейти на Java. А потом я узнал, что получил гораздо больше, чем потерял.
                                          • –1
                                            Я знаю. Только это не .NET — это Mono
                                            • +1
                                              Проблема только в том, что .net != mono
                                          • +7
                                            • +3
                                              Щас уже Java EE 6 и JSF 2.0 вобще-то на дворе.
                                              • +7
                                                Никто не заставляет использовать JSF. Там милион и маленькая тележка фреймворков.
                                          • +6
                                            мы не в 90х живем, тормознутость динамических языков с лихвой компенсируется достаточно недорогим серверным железом и высокой скоростью разработки.

                                            Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python…

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

                                              Замечательно. Если язык/платформа позволяет сильно удешевить процесс разработки/поддержки по сравнению с другой платформой, но при этом требует больше вычислительных мощностей, то всё равно мы её предпочтём. Тогда внимание: какие преимущества с точки зрения скорости разработки у динамически типизированных языков перед статически типизированными?

                                              > Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python

                                              … но ни одна из этих IDE не сможет даже близко повторить тот функционал, который поддерживает для Java NetBeans, Eclipse JDT, IDEA или VS + Resharper для C#. Ну хотя бы рефакторинг. Если сигнатура метода неизвестна заранее, то вряд ли мы сможем его автоматом переименовать. Или, скажем, исключить рудиментарный параметр, не нагородив при этом потенциальных ошибок. Ну или так. Вот пишу я в Java:
                                              list.get(i).
                                              Где list имеет тип List. Что вывалится в том же NetBeans, я прекрасно представляю. А вот в случае Ruby не вывалится ничего.
                                              • +2
                                                Ой, хабр съел кусочек сообщения. «Где list имеет тип List» следует читать как «Где list имеет тип List<MyClass>». Вот как полезно бывает юзать предпросмотр
                                                • +2
                                                  Что касается производительности, то это проблема решается за счет native кода написанного для узких мест. Также очень просто сконфигурировать проект для запуска на нескольких инстансах.

                                                  В целом думаю проблема производительности относительно надумана, так как уже есть не мало нагруженных проектов на Rails: github, twitter.

                                                  Мы используем JetBrains RubyMine 2.5 EAP. Рефакторингов меньше, но они есть. Интелисенс тоже есть, но не везде. Отмечу, что ошибок связанных с динамической типизации почти не делаем.

                                                  Ошибок в написании переменных, классов тоже практически нет, просто пишешь правильно на английском языке, а spell сhecker в IDE сразу увидит если что не так.

                                                  • –2
                                                    Ну вот, начинаются костыли для того, чтобы «писать правильно». Кстати, это не мешает писать ещё и медленно, ибо проблемы с автокомплитом. А вот о преимуществах, ради которых приходится покупать оборудование помощнее, что-то никто не пишет.
                                                    • +4
                                                      Не пишут, чтобы не начинать бесполезный холивар, в который, вы, очевидно, хотите погрузиться.

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

                                                      Тон «свысока» тут неуместен ни с той, ни с другой стороны.
                                                      • +8
                                                        Я когда то писал на Java, и меня от перехода на RoR останавливало именно отсутствие автокомплита.

                                                        Но когда я перешел, он мне оказался не нужен. Как бы это сформулировать поточнее — я просто не пишу теперь столько текста, чтобы мне нужен был автокомплит. Мои модели порой короче чем один только ( конечно, автоматически сгенеренный) список импортов для модели из Java EE проекта. Но получается, что вся эта чудовищная избыточность и порождает проблему в виде костылей из автокомплитов, сложных рефакторингов и проч.
                                                        • +1
                                                          +100500! Глядя на свои старые проекты на яве я просто ужасаюсь сколько приходилось писать кода на любой чих. С рельсами такой фигни просто не существует.
                                                • –1
                                                  А индусы, которые пишут всякие руководства, как правило, идут по пути индус-way, так что для решения проблемы приходится тщательно изучать код самому. Можно, конечно, купить книжечку по JasperReports, но это уже денежки.


                                                  Отличительная особенность ruby от java в том, что в ruby-комьюнити практически отсутствуют индусы.
                                                  • 0
                                                    Не люблю националистов. Тем более индусы есть, и их много.

                                                    Я вот подозреваю, что aria, к примеру, индус.
                                                    • +1
                                                      Это ни разу не национализм. Просто устоялось мнение что индусы == специально обученные генераторы кода, который, зачастую, сложно поддерживать.
                                                • +7
                                                  Самые большие минусы: неадекватно большая цена за SQL Server. И ленятся фиксить баги по много лет.
                                                  • +7
                                                    Да. Думаю, про Express-версию mssql (с довольно жесткими лимитами) многие знают. Но может кому-нибудь будет интересно: IBM DB2 (очень серьезная субд) так же доступна в экспресс-версии, но без ограничений по размеру субд.
                                                    Удивляюсь, что редко кто думает о замене на эту систему в связке с тем же .net.
                                                    • 0
                                                      * т. е. по размеру базы
                                                      • +1
                                                        Дя, мы не думали про IBM DB2. Подумаем. Спасибо! :)
                                                        • 0
                                                          А как там с драйверами?
                                                          • 0
                                                            Для дотнета? Есть.
                                                            www-01.ibm.com/software/data/db2/ad/dotnet.html
                                                            • 0
                                                              угу, и последняя версия валится при попытке запихнуть несколько классов в модель EF
                                                              • 0
                                                                Ужасные! Аж странно, что для такой платформы как .NET, IBM не удосужились написать нормальные современные провайдеры.
                                                                • 0
                                                                  IBM, как и Oracle, не ставят перед собой цель поддерживать технологии конкурента…

                                                                  Поэтому что у одного, что у другого такие глюкавые драйвера…
                                                                  Смех-смехом, но за 10 лет уже можно было devArt какой скупить и не тужиться…
                                                            • +2
                                                              Для интересующихся, немного подробнее:
                                                              Бесплатная версия называется IBM DB2 Express-C, берется здесь, по ограничениям — 2 ядра процессора, 2ГБ оперативной памяти. Объем баз не лимитирован.
                                                              • +1
                                                                Справедливости ради, стоит добавить, что в последней редакции Экспреса от МС ограничение по месту стало 10ГБ, а это уже хорошо :)

                                                                www.microsoft.com/express/database/
                                                              • +4
                                                                А цена не то чтобы неадекватная, это такой порядок цен на корпоративные субд (oracle/db2/mssql/sybase). Но есть же и опенсорс, и они все так же работают на windows server.
                                                                • 0
                                                                  Уфф, почему никто не упомянул NoSQL? :) Никто не заставляет использовать SQL Server.
                                                                  • 0
                                                                    Потому что это недоразумение…
                                                                • +22
                                                                  Да начнется же холивар
                                                                  • +2
                                                                    мегораспект вам за переход на Ruby on Rails, однако, и при выборе RoR вы остаетесь зависимыми. Недавно читал интервью с DHH в котором он прямым текстом говорил, что разрабатывая RoR они стремятся удовлетворить конкретно свои желания (свои в смысле 37signals), а не желания других разработчиков, оно и понятно, и так практически с каждым фреймворком, который изначально разрабатывается какой-либо компанией для себя, а не как «подарок миру». Ничего в этом плохого нет, но вы остаетесь зависимыми от мозгов 37signals и DHH в частности. Достойных альтернатив для RoR лишенных этого недостатка не знаю… Раньше был Merb, но…

                                                                    P.S. Цыкл статей безусловно заинтересовал, с нетерпением жду новых ;-)

                                                                    P.P.S. Что за агентство если не секрет? Ссылку на сайт можно?
                                                                    • +14
                                                                      У opensource приложений есть одно НО, даже если все мозги из 37signals сойдут с ума, начнут лепить невесть что, можно форкнуть RoR, .NET ты не форкнешь, если разрабам моча в голову ударит.
                                                                      Тоже самое касается и того, если вдруг всех разрабов .NET'а вместе с манагерами переедет самосвал.
                                                                      • +3
                                                                        Не знаю кто вас минусует, Gorthauer87. Как по мне, вы правы на 100%.
                                                                        • +4
                                                                          А OpenSolaris форкнули? Или MySQL? Какое-то очень скользкое «можно» получается.
                                                                          • +5
                                                                            Illumos и MariaDB соответственно.
                                                                            Насколько хорошо они развиваются — вопрос второй, но как факт — да, форкали.
                                                                            • 0
                                                                              > www.percona.com/software/percona-server/
                                                                              > mariadb.org/

                                                                              Наличие аж двух форков MySQL вселяет сомнения. Какой выбрать в случае начала его лицензирования? Или городить Another One Fork of MySQL?

                                                                              > www.illumos.org/

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

                                                                              P.S. А насколько хорошо они развиваются — вопрос без номера. Эдакий триггер востребованности.
                                                                              • +3
                                                                                Да, но я говорю только о факте совершения форков.
                                                                                MySQL — в принципе непонятно, что сейчас может заставлять в срочном порядке искать альтернативу в виде форка, кроме туманного будущего опенсорсного наследия Sun. Ее разработку официально никто не прекращал.
                                                                                OpenSolaris — в большинстве связанных с ней последних новостей я постоянно видел отзывы в стиле «я OpenSolaris не пользовался, но сочувствую». Т. е. круг пользователей мне представляется весьма небольшим. В большинстве случаев это либо люди, пользовавшиеся другими опенсорс-юниксами и пробующие OS после открытия кода, либо пользователи обычного Solaris, перешедшие на OS.
                                                                                Первые в большинстве своем безболезненно вернутся на Linux/BSD, вторые — либо на Oracle Solaris (при наличии денег), либо станут той узкой прослойкой заинтересованных в Illumos и подобных форках.

                                                                                Т. е. я считаю потенциальную аудиторию несоизмеримо меньшей, чем потребовалась бы для развития проектов такого размера.
                                                                                RoR, при текущей популярности и объеме кода никуда не денется даже если 37signals и DHH завтра иссчезнут.
                                                                            • 0
                                                                              вроде бы форкнули и то и другое (MariaDB)?
                                                                              • +3
                                                                                > А OpenSolaris форкнули?

                                                                                Да.

                                                                                > MySQL?

                                                                                Да.
                                                                                • +8
                                                                                  Более того, был проект XFree86, после того, как его разработчикам таки ударила в голову моча, родился форк xorg, который поддержали разработчики и основные мейнтейнеры линукса и bsd систем. И в итоге XFree86 умер, а форк остался жить.
                                                                                  Openoffice по аналогичной схеме форкнулся, пройдет полгода и во всех дистрах вместо него будет libreoffice.
                                                                                • –1
                                                                                  Мелкософт регулярно проверяет анализы мочи… которые включают в стоймость конечного продукта.
                                                                                  • +1
                                                                                    Интересно, сколько народу реально готовы «форкнуть», да так, чтобы всерьез, и этим можно было пользоваться.
                                                                                    Если разрабов .NET переедет самосвал (чего не произойдет, но если даже гипотетически), то берем исходники .NET и форкаем. Собственно, уже и так есть Mono.

                                                                                    В конце концов, всегда, при абсолютно любых условиях, если на другую половину Земли (где по несчастью находился вендор технологии) упал огромный метеорит, можно взять и с нуля освоить любую другую технологию.
                                                                                • +9
                                                                                  Хоть бы одну причину оригинальную написали. Ну кто об этом не знает?

                                                                                  Проблема в том, что в мире нет идеального ПО. Те кто используют .Net и Windows — прекрасно знают о его платности, закрытости и пр. Однако используют, ибо бесплатное ПО имеет СВОИ существенные недостатки.
                                                                                  • +1
                                                                                    >В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов», что крайне негативно сказывается на сроках разработки.

                                                                                    Есть такое. Зачастую хочется все выкинуть и написать заново, чем кастомайзить то что есть под какой-то чуть другой сценарий нежели придумало MS.
                                                                                    • +9
                                                                                      а можно поподробнее про технологию ASP.NET и «полную несостоятельность», которую она «показала за 5 лет до появления ASP.NET MVC», а точнее показывает уже почти 10 лет? :)

                                                                                      Тысячи успешных веб-приложений плюс корпоративный сектор с Sharepoint'ом во главе внимательно следят за постом.
                                                                                      • +23
                                                                                        SharePoint тут не самый удачный пример, для многих разработчиков это страшный сон.
                                                                                        • +21
                                                                                          Ахахаа, Шарепоинт, школьник иди собирай ранец завтра в школу, такого глючно-тормозного говна еще мир не видал, а разработка под него это просто нечто, если бы не пронырливые менеджерки с откатами гнить этому говну на помойке сразу после выпуска
                                                                                          • +2
                                                                                            Давно видимо его не видели, серьезно улучшают его с каждой версией. + Неслабая интеграция с другими технологиями от мс. Да, для разрабов хреново, все из-за sharepoint-way, который слабо похож на все остальное. Но тут дело привычки, при правильном применении (то есть там, где инфраструктура целиком и полностью от мс) шарик очень даже неплох.
                                                                                          • +9
                                                                                            SharePoint это как раз не особо хороший пример вне зависимости от критерия. Хотя продается хорошо, не спорю.
                                                                                          • +3
                                                                                            Я считаю пост отличный, но реакция на него предсказуема. Практически все разработчики выбирают инструмент по себе. Им невозможно открыть глаза на что либо. Если выражаться конкретнее, то адекватные люди уже выбрали хорошие инструменты. А неадекватные выбрали кал, и слушать ничего не будут — для этого нужно уметь думать. Ваш пост не сможет сделать из неадекватных людей — адекватных. Увы.
                                                                                            • +1
                                                                                              Я немного проспойлерю, топикстартер видимо постеснялся дать ссылку на видео-доклад
                                                                                              blog.byndyu.ru/2010/10/big-switch-microsoft.html
                                                                                              • +3
                                                                                                Доклад очень несерьезный получился. ((
                                                                                                • +2
                                                                                                  Я его фрагментами смотрел день-два назад.
                                                                                                  Я к нему отношения не имею, просто не нашел ссылки в топике, решил оставить здесь. Если автор не хотел показывать видео — пардон ;)
                                                                                              • +1
                                                                                                > лишенный прелестей динамического языка

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

                                                                                                Так же нельзя не заметить, что синтаксис ruby не красивее чем у C#, но это уже скорее дело вкуса =)
                                                                                                • 0
                                                                                                  Следует понимать данное замечание прежде всего в контектсе веб-фреймворка.
                                                                                                  • 0
                                                                                                    Ошибаетесь. Я люблю .NET/C#. Но в плане выразительности Ruby и Rails на его основе дадут сто очков вперёд любым альтернативам, включая C#/ASP.NET, Python/Django etc.

                                                                                                    Что не мешает мне любить C# :)
                                                                                                    • +2
                                                                                                      Обычно считается, что динамичность языка это плюс к скорости разработки и минус к скорости выполнения, а у вас как-то выходит, что это сплошные минусы. Почему тогда они столь популярны?
                                                                                                      • 0
                                                                                                        Что значит считается? Считается что Менделеев водку изобрел.
                                                                                                        Я еще не видел нигде такой качественной поддержки кода как в VS, а она основана на строгой типизации объектов. Работая с несложными объектами можно, фактически, без документации разобраться по подсказкам автокомлитера.

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

                                                                                                        Может мой пост и получился чересчур приземленным, но работа с динамическими языками ничего кроме как неопределенности и головной боли не доставляет.
                                                                                                        • +1
                                                                                                          То и значит, что объективных данных нет, афаик, но это устоявшееся мнение, основанное хотя бы на том, что объём кода при решении одной и той же задачи получается меньше, т. к. ненужно, по крайней мере, объявлять тип.

                                                                                                          А когда я пишу в VS на динамическом языке, его поддержка качественная или нет? А если пишу на C# в Eclipse? А если в vim или блокноте? И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали? И вообще, мы обсуждаем IDE или языки? К Си-подобным языкам синтаксически относится, кстати, и всеми «любимый» PHP и «ваш» Javascript.

                                                                                                          О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :) Мне вот головную боль и резь в глазах доставляют строгие статические языки от обилия объявления и приведения типов в коде, за которыми теряется логика выражения, так что головная боль это не показатель.
                                                                                                          • 0
                                                                                                            >>То и значит, что объективных данных нет, афаик, но это устоявшееся мнение, основанное хотя бы на том, что объём кода при решении одной и той же задачи получается меньше, т. к. ненужно, по крайней мере, объявлять тип.
                                                                                                            Это мелочи, которые тут же оборачиваются головной болью. Сложно держать все в голове, знать все возвращаемые и принимаемые типы. А в случае необходимости сразу же лезть в документацию.
                                                                                                            >>И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали?
                                                                                                            Вы меня не так поняли, я имел ввиду, что некоторые IDE по дефолту имеют только один список, которые подставляют к любому объекту.
                                                                                                            >>И вообще, мы обсуждаем IDE или языки?
                                                                                                            Тут обсуждается стек технологий .net, частью которой можно считать и VS. К тому же без хорошей поддержки IDE скорость разработки страдает.
                                                                                                            >>О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :)
                                                                                                            … вот только когда компилируется, ведет себя как утюг. 90% ошибок синтаксического кода в статических языках уже выявляются на этапе компиляции.
                                                                                                            • 0
                                                                                                              У меня тоже 90% ошибок выявляется на этапе компиляции интерпретации за счет запущенного в фоне autotest. (ruby, rails)
                                                                                                              • 0
                                                                                                                «90% ошибок синтаксического кода»
                                                                                                                Это вы о чем вообще? :)

                                                                                                                Что касается .NET, там есть еще такая вещь, как статический анализ кода (с помощью FxCop) — очень полезная вещь для написания качественного и безопасного кода.
                                                                                                                • 0
                                                                                                                  Документация идёт в коде, тот же javadoc придумали не для динамического языка

                                                                                                                  Некоторые может быть, ну так и некоторые для статических языков так же поступают, а в некоторых вообще никакого автодополнения нет. Может для динамических таких больше, но я чаще сталкивался с проблемой, что методов/свойств не хватает (IDE смогла определить только базовый класс), чем их избыток :)

                                                                                                                  По треду только вы только что упомянули .NET, до этого говорили о языке C#. Причём С# и .NET это не то, что не синонимы, но даже не вложенные множества. Не всё, что пишется на С# пишется под .NET — я вот прямо сейчас пишу на C# под Linux'ом, где никаким .NET и VS не пахнет.

                                                                                                                  Как бы самые популярные языки с динамической типизацией являются интерпретируемыми, так что этапа компиляции там просто нет, максимум перевод в байт-код. И зачем выявлять на этапе компиляции ошибки, которых в динамических языках просто не может быть по определению (забыли объявить или привести тип, например)?
                                                                                                              • +1
                                                                                                                То, что с вашей колокольни кажется серьезной проблемой, с нашей колокольни проблемой совсем не кажется)

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

                                                                                                                Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.

                                                                                                                Еще можно заметить, что ide для javascript и правда никакие, для python, php и ruby все гораздо лучше.

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

                                                                                                                Я тут недавно пробовал написать что-то на Objective-C (при том, что C знаю хорошо), это ничего кроме неопределенности и головной боли не доставило (при всех автокомплитах и тд), и это никак не недостаток Objective-C, а просто я этот язык не знаю.
                                                                                                                • 0
                                                                                                                  >>То, что с вашей колокольни кажется серьезной проблемой, с нашей колокольни проблемой совсем не кажется)
                                                                                                                  Я не считаю это серьезной проблемой, просто из таких мелочей складываются очень неприятные ощущения.
                                                                                                                  >>Например, зачем гадать и разбираться по подсказкам автокомплитера, если всегда можно по-быстрому глянуть исходник или запустить интерактивный интерпретатор. А в простых случаях подсказки и так есть, и вполне все с ними нормально.
                                                                                                                  Зачем гадать? Автокомплитер помогает «вспомнить код», экономит 90% времени на рутинных операциях. Так же по названиям методов и возвращаемым значениям, помогает понять новый. Если уж нужно разобраться, как что работает то да, нужно лезть в исходники.
                                                                                                                  >>Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.
                                                                                                                  Я ни в коем случае не приверженец этого подхода.
                                                                                                                  >>И ясно-понятно, работа с динамическими языками будет доставлять головную боль, т.к. я почему-то уверен, что вы их знаете хуже. Мне тоже с малознакомыми языками сначала тяжко, тот же javascript довольно сложен и сильно отличается от других языков.
                                                                                                                  Да хуже, но я не представляю, как можно все это держать в голове
                                                                                                                  • 0
                                                                                                                    но я не представляю, как можно все это держать в голове

                                                                                                                    Ровно так же, как и вы держите в голове все типы, их размеры, правила работы с указателями, динамической памятью, разновидности функций-членов и свойств и т.п.
                                                                                                                • 0
                                                                                                                  после многих лет работы с C-подобными языками.

                                                                                                                  Это ключевая фраза в вашем комментарии. Вы просто не привыкли обходиться без подсказок интеллисенса.
                                                                                                            • +10
                                                                                                              Вы знаете, я посмотрел большой кусок вашей видео-презентации и у меня сложилось впечатление, что ваши аргументы против ASP.Net MVC и за Rails сводятся к тому, что
                                                                                                              а) «в Rails не надо думать»
                                                                                                              б) «в ASP.Net MVC нельзя (тут либо фича, которая уже анонсирована в MVC 3, либо вы просто не поняли как это сделать)»
                                                                                                              По пункту а) могу сказать, что думать лично мне нравится думать и я вообще считаю, что в этом и состоит работа программиста. По пункту б) — без коментариев.
                                                                                                              На самом деле, у меня опять же складывается впечатление, что ваши проекты довольно мелкие и скорее ближе к таргет-аудитории www.asp.net/webmatrix, чем к ASP.Net MVC, который все же более гибкий и низкоуровневый фреймворк, рассчитаный на крупные проекты (несколько человеко-лет разработки и многие годы сапорта).
                                                                                                              • –5
                                                                                                                На момент подготовки данной видеопрезентации у меня не было достаточно времени подготовить примеры. Именно поэтому я решил написать серию постов, где остановлюсь на каждом аспекте подробнее.

                                                                                                                В Rails действительно надо меньше думать о том как построить приложение и больше времени можно уделить непосредственно самому веб-приложению.

                                                                                                                Сейчас мы делаем в основном многпользовательские веб-проекты, которые нельзя назвать тривиальными. Вот например: keekme.ru
                                                                                                                • +5
                                                                                                                  К презентациям надо готовиться! Раздражают неподготовленные доклады.
                                                                                                                  • +2
                                                                                                                    Не увидел в keekmе.ru ничего нетривиального.
                                                                                                                • +2
                                                                                                                  Еще один все понял.
                                                                                                                  • –4
                                                                                                                    Прогнозирую 300+ холиварных комментариев.
                                                                                                                    • –1
                                                                                                                      «MVC показала свою полную несостоятельность»
                                                                                                                      «Ruby on Rails предоставляет архитектурный образец Model-View-Controller » — Wiki
                                                                                                                      Совсем запутали.
                                                                                                                      • +1
                                                                                                                        Имелось в виду ASP.NET mvc
                                                                                                                        • +2
                                                                                                                          MVC != ASP.NET MVC
                                                                                                                        • +10
                                                                                                                          То, что решили расширить кругозор за пределы «железного занавеса» дотнет — это абсолютно правильно. Особенно для веб-разработчика, в вебе дотнет сильно отстал и последние годы, как вы правильно заметили, занимается тем, что навёрстывает упущенное.

                                                                                                                          Так что добро пожаловать в мир открытых технологий, только один совет — не меняйте шило на мыло, в смысле не сосредотачевайтесь исключительно на рельсах. Я ни в коей мере не умаляю заслуг этого фреймворка — рельсы по сути дали толчёк всему хорошему, что было в вебе за последние 5 лет. Тем не менее сами они — вещь в себе, причём довольно консервативная, так например нововведения из Rails 3 существовали в Django уже довольно долго, собственно потому появился Merb и др. Плюс сам язык Ruby мягко говоря на любителя. Так что и в Python есть на что посмотреть, и в Java. Вот вы говорите ASP.NET MVC дублирует рельсы — это не так, он слизывает всё один в один со Spring@MVC в частности и со спринга вообще.

                                                                                                                          Так что не надо останавливаться — двигайтесь дальше, исследуйте. На сегодняшний день «классические» MVC фреймворки уже ничем не могут удивить (даже новые PHP-фреймворки в некоторых аспектах могут дать фору Rails/Django, хотя работы ещё предстоит много), Веб развивается, сейчас уже более актуально асинхронное программирование и NoSQL базы, как следствие набирают обороты фреймворки/языки, в которых сильная функциональная составляющая — Scala, Javascript, Erlang.
                                                                                                                          • +1
                                                                                                                            На рельсах мы не останавливаемся. Сейчас также смотрим в сторону Scala на одном из новых проектов.
                                                                                                                            • +11
                                                                                                                              Прикольно там у вас работать ). Надоел .NET — переходишь на RoR, надоел RoR — переходишь на Scala, надоела Scala — ну вы поняли (с).
                                                                                                                              • 0
                                                                                                                                Мы не переходим с Rails на Scala. Использование Scala обусловленно зависимость от ряда явовских библиотек в конкретном проекте.

                                                                                                                                В Scala я виже хорошу возможность использовать накопленный в Java опыт, при этом юзать все плюшки современных языков, такие как closure.
                                                                                                                                • 0
                                                                                                                                  Я так понял, у вас зоопарк проектов, и все на разных платформах. Интересно, как этим всем управлять: организация работы, люди, финансовые аспекты — если будет время, то напишите, почитал бы с удовольствием.
                                                                                                                              • +3
                                                                                                                                У нас многие приложения пишутся на рельсе, а высоконагруженная часть оборачивается во внутренний закрытый REST-сервис на scala(liftweb).
                                                                                                                              • +1
                                                                                                                                Подпишусь под каждым словом

                                                                                                                                Такое ощущение, что в этом топике перепутались кнопки «хороший/плохой комментарий» =)
                                                                                                                                • –2
                                                                                                                                  Если бы только в этом…
                                                                                                                                • +4
                                                                                                                                  Про технологический кругозор, про то, что его надо расширять — согласен полностью.

                                                                                                                                  Про «железный занавес .NET» — не согласен ни грамма. .NET ничуть не хуже работает и с альтернативными БД, и с NoSQL, и поддерживает функциональный стиль (F#).

                                                                                                                                  «в вебе дотнет сильно отстал и последние годы, как вы правильно заметили, занимается тем, что навёрстывает упущенное»
                                                                                                                                  Вот это никак не аргументировано. В чем именно он отстал? Чего в нем такого нет, что есть где-то еще?
                                                                                                                                  • 0
                                                                                                                                    до сих пор не хватает динамики (то, что вносит DLR).

                                                                                                                                    ну и для Web там до сих пор мало всего, если смотреть с точки зрения рельсовика.
                                                                                                                                    • 0
                                                                                                                                      Ну динамика — это, как говорится, «на вкус и цвет», но, действительно, есть же DLR.

                                                                                                                                      А вот по поводу «Web» слово «мало» в контексте .NET, как по мне, не вяжется совершенно. Ибо там есть все. О чем конкретно идет речь, чего не хватает (с точки зрения RoR-dev)?
                                                                                                                                      • 0
                                                                                                                                        Не хватает большого выбора библиотек для добавления нужных фич.

                                                                                                                                        Просто добавляем в модель acts_as_taggable, и теперь она поддерживает тэггирование, добавляем acts_as_nested_set, появляется возможность вложения. Пишем — has_attached_file :avatar, :styles => { :medium => «300x300>», :thumb => «100x100>» }, и вы имеете колонку для загрузки файлов с набором миниатюр…
                                                                                                                                        • 0
                                                                                                                                          И при этом обычно имеется набор готовых хелперов для взаимодействия этих интерфейсов с пользователем.
                                                                                                                                          • 0
                                                                                                                                            Ну в чем-то я соглашусь — не хватает некоторого стандартизированного фреймворка уже поверх существующего фреймворка ASP.NET MVC. Набор хелперов — не совсем то, нужна какая-то более удобная для использования абстракция над View и View-моделями.

                                                                                                                                            Что касается модели, то она может реализовать интерфейс, скажем, ITaggable, и будет поддерживать теги, и так далее. Думаю, было бы удобно, чтобы на основе соглашений, View-модель (а также View) каким-то образом автоматически начинала поддерживать теги, если модель их начинает поддерживать. Но сдается мне, что это просто разные подходы, и я не назвал бы это «мало для веба».
                                                                                                                                  • +13
                                                                                                                                    Как сказал один знакомый адепт корпоративной культуры программирования Microsoft:
                                                                                                                                    «PHP — это мертворожденный язык. Скоро все будет только на .NET

                                                                                                                                    Я только улыбнулся в ответ, потому как попытки объяснить, что большая часть сайтов уже работает на PHP ни к чему не привели.
                                                                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                      • +1
                                                                                                                                        Завербовал таки?)) Просветлил так сказать…
                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                      • –20
                                                                                                                                        Сертифицированым говорите? За 4 года?

                                                                                                                                        Номера в студию.
                                                                                                                                        • +5
                                                                                                                                          Нет проблем:

                                                                                                                                          • +22
                                                                                                                                            70-536 TS: Microsoft .NET Framework, Application Development Foundation
                                                                                                                                            70-502 TS: Microsoft .NET Framework 3.5, Windows Presentation Foundation Application Development
                                                                                                                                            70-503 TS: Microsoft .NET Framework 3.5, Windows Communication Foundation
                                                                                                                                            70-561 TS: Microsoft .NET Framework 3.5, ADO.NET Application Development
                                                                                                                                            70-562 TS: Microsoft .NET Framework 3.5, ASP.NET Application Development
                                                                                                                                            70-564 PRO: Designing and Developing ASP.NET Applications using Microsoft .NET Framework 3.5
                                                                                                                                            • –12
                                                                                                                                              Давайте транскрипцию, а то это только пустые слова.

                                                                                                                                              Вот к примеру длинна моей [s]пи[/s]: https://mcp.microsoft.com/authenticate/validatemcp.aspx

                                                                                                                                              Transcript ID 823289
                                                                                                                                              Access Code ts332200
                                                                                                                                              • +10
                                                                                                                                                Окей.

                                                                                                                                                https://mcp.microsoft.com/authenticate/validatemcp.aspx

                                                                                                                                                Transcript ID 854899
                                                                                                                                                Access Code dxScK8VT
                                                                                                                                                • –3
                                                                                                                                                  Простите, конечно, но стиль Вашего текста — совершенно нетехнические, и в чем-то вообще детские упрёки в отношение WebForms, почему-то называемому везде просто как ASP.NET — совершенно не вяжутся с уровнем сертифицированных технологий.
                                                                                                                                                  Нет, я понимаю, что может быть в силу возраста хочется какого-то максимализма — и тогда без разницы что критиковать, но ведь если Вы настолько хорошо разбираетесь в «технологиях врага», ведь можно критиковать как-то более адресно.

                                                                                                                                                  А так читаешь Вас и думаешь, что пишет очередной программист-неудачник, который так и не смог осилить даже базовые вещи в ASP.NET.

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

                                                                                                                                                  Не знаю как у Вас, но у меня без проблем получается написать полностью RESTful сайты на ASP.NET WebForms пользуясь только ASP.NET Routing и полностью вырубая ViewState у страниц. И отлично работает, и легко отлаживается, и работы немного.

                                                                                                                                                  Да, у WebForms есть свои проблемы, и как в случае любого ASP нет возможности покрыть его unit-тестами (в MVC тоже отнюдь не все части можно покрыть unit-тестами), но все эти проблемы давно известны и уж MCPD решает их сравнительно быстро. Говорю это как MCPD ;-)
                                                                                                                                          • +1
                                                                                                                                            А что удивительного? Я сдал первых два экзамена года через полтора после того как начал работать. Сейчас вот собираюсь сдавать MCPD — и как раз три года как я начал работать разработчиком будет в конце октября.