Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 253
Аргументы притянуты за уши.
Конкретные примеры будут в последующих статьх. Здесь я выделил три фундаментальные проблемы, которые мешали нашей команде.
>> Работая с продуктами .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. Все они без исключения пишут свои фреймворки аутентификации, авторизации, вручную реализуют управления жизненным циклом сессии в БД и этот список можно продолжать бесконечно. Однако подобная самодеятельность не всегда хорошо отражается на качестве проектов.
Вы в зеркало смотрели когда это говорили? Кто кроме вас «вручную реализует управление жизненным циклом сессии в БД»? Это же какая бредятина-то!
Я так понимаю, на сайте 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. Все они без исключения пишут свои фреймворки аутентификации, авторизации, вручную реализуют управления жизненным циклом сессии в БД и этот список можно продолжать бесконечно. Однако подобная самодеятельность не всегда хорошо отражается на качестве проектов.
Вы в зеркало смотрели когда это говорили? Кто кроме вас «вручную реализует управление жизненным циклом сессии в БД»? Это же какая бредятина-то!
На codeplex.com, конечно, много что есть. Но все под странными лицензиями, чистый LGPL весьма редкостен.
>> Я так понимаю, на сайте 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 датаконтекстов. Всем разработчикам надо самим решить где и когда они будут создаваться и освободжаться.
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 датаконтекстов. Всем разработчикам надо самим решить где и когда они будут создаваться и освободжаться.
Давно не обновляется это не так уж и критично. log4net тоже обновлялся редко и давно, но это не делает библиотеку менее ценной. Частые обновления сами по себе не являются положительной характеристикой.
Есть разница между своим DNS сервером и своим DNS сервером совмещённым c web сервером. Remote desktop НЕ нужен для удалённого управления IIS. Нужен PP2T incoming connection и локально установленная оснастка MMC.
Предположим, что вам действительно надо править исходники фреймворка. Но зачем вам делать публичный fork ASP.Net MVC? Даже если бы вы имели доступ к основному репозиторию, это был бы read-only доступ. Вы бы всё равно не смогли бы сделать ветку в том же репозитории.
Есть разница между своим DNS сервером и своим DNS сервером совмещённым c web сервером. Remote desktop НЕ нужен для удалённого управления IIS. Нужен PP2T incoming connection и локально установленная оснастка MMC.
Предположим, что вам действительно надо править исходники фреймворка. Но зачем вам делать публичный fork ASP.Net MVC? Даже если бы вы имели доступ к основному репозиторию, это был бы read-only доступ. Вы бы всё равно не смогли бы сделать ветку в том же репозитории.
> Это ваша проблема.
Прекрасный аргумент :)
> Все лицензии легко определются по признакам royality-free/per-server и site/per-developer. Остальное не существенные мелочи.
Мелочи зачастую очень даже существенны. Одна из прелестей opensource — малый набор лицензий, разобравшись в зоопарке которых единожды, больше не нужно тратить время на понимание тех или иных аспектов.
> DNS сервер у регистратора домена или хостера. Зачем свой?
Чудесный способ решения проблем. Если чего-то нет, то и «не нужно». Мне, может быть, нужно.
> Частота обновлений и количество загрузок параметры не специфичные для открытого кода
Кто сказал?
Количество загрузок — да, но частота обновления выше. Хотя бы тем, что можно взять свежий срез из VCS-репозитория.
Да и release early, release often никто не отменял.
Прекрасный аргумент :)
> Все лицензии легко определются по признакам royality-free/per-server и site/per-developer. Остальное не существенные мелочи.
Мелочи зачастую очень даже существенны. Одна из прелестей opensource — малый набор лицензий, разобравшись в зоопарке которых единожды, больше не нужно тратить время на понимание тех или иных аспектов.
> DNS сервер у регистратора домена или хостера. Зачем свой?
Чудесный способ решения проблем. Если чего-то нет, то и «не нужно». Мне, может быть, нужно.
> Частота обновлений и количество загрузок параметры не специфичные для открытого кода
Кто сказал?
Количество загрузок — да, но частота обновления выше. Хотя бы тем, что можно взять свежий срез из VCS-репозитория.
Да и release early, release often никто не отменял.
>Одна из прелестей opensource — малый набор лицензий
*поперхнулся*
чтоооо? www.opensource.org/licenses/category
Не говоря уже о том, что они через одну несовместимы друг с другом.
Типов коммерческих лицензий намного ментше и их термины намного прозрачнее и понятнее
*поперхнулся*
чтоооо? www.opensource.org/licenses/category
Не говоря уже о том, что они через одну несовместимы друг с другом.
Типов коммерческих лицензий намного ментше и их термины намного прозрачнее и понятнее
Отлично! Хотя бы примерное количество и типы лицензий opensource мы знаем.
Но хочу заметить: мы здесь обсуждаем лицензии на код, а в том списке указаны многие лицензии, которые авторами названы deprecated и более не используются.
> Не говоря уже о том, что они через одну несовместимы друг с другом.
Большинство — совместимы друг с другом. Но есть исключения, согласен.
> Типов коммерческих лицензий намного ментше
Откуда дровишки?
> их термины намного прозрачнее и понятнее
«Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию. У проприетарщиков так же?
По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта. А вы можете поручиться, что в коммерческих все так же просто?
Но хочу заметить: мы здесь обсуждаем лицензии на код, а в том списке указаны многие лицензии, которые авторами названы deprecated и более не используются.
> Не говоря уже о том, что они через одну несовместимы друг с другом.
Большинство — совместимы друг с другом. Но есть исключения, согласен.
> Типов коммерческих лицензий намного ментше
Откуда дровишки?
> их термины намного прозрачнее и понятнее
«Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию. У проприетарщиков так же?
По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта. А вы можете поручиться, что в коммерческих все так же просто?
> Большинство — совместимы друг с другом.
Досаточно появиться GPL — и до свидания
> Откуда дровишки?
Оттуда же :)
Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.
> «Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию.
Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
> По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта.
Угу, это если повезет с лицензиями типа Apache или MIT.
> А вы можете поручиться, что в коммерческих все так же просто?
Гарантий нет никаких ;) Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
Досаточно появиться GPL — и до свидания
> Откуда дровишки?
Оттуда же :)
Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.
> «Прозрачность» и «понятность» — два самых объективных критерия оценки. Любая более-менее популярная лицензия в opensource написана профессиональными юристами и существует множество статей, посвященных их толкованию.
Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
> По большей части, все требования opensource-лицензий сводятся к соблюдению десятка требований по поводу указания авторства, публикации изменений в оригинальном продукте и/или предоставления исходного кода результирующего продукта.
Угу, это если повезет с лицензиями типа Apache или MIT.
> А вы можете поручиться, что в коммерческих все так же просто?
Гарантий нет никаких ;) Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
> Досаточно появиться GPL — и до свидания
Линковать с GPL можно что угодно — нужно лишь сделать результирующий проект под gpl. А это уж, извините, детали :)
> Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.
И приходим к вопросу о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.
> Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
Но они хотя бы есть ;)
> Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
LGPL чем не нравится? Ну да, нужно публиковать изменения, вносимые в оригинал, но чем плохо развитие этого проекта?
Да и BSD тоже довольно неплоха.
Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом. Я регулярно залезаю в исходники Qt, чтобы поглядеть, как реализованы те или иные вещи.
Линковать с GPL можно что угодно — нужно лишь сделать результирующий проект под gpl. А это уж, извините, детали :)
> Подписка, royalty, royalty-ree, per-site, per-developer, per-CPU. Без проблем с совместимостью друг с другом.
И приходим к вопросу о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.
> Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
Но они хотя бы есть ;)
> Но, во всяком случае, коммерческие лицензии, что мне попадались, все бли намного вменяемее, чем опенсорсные (за исключением MIT/Apache)
LGPL чем не нравится? Ну да, нужно публиковать изменения, вносимые в оригинал, но чем плохо развитие этого проекта?
Да и BSD тоже довольно неплоха.
Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом. Я регулярно залезаю в исходники Qt, чтобы поглядеть, как реализованы те или иные вещи.
> Линковать с GPL можно что угодно — нужно лишь сделать результирующий проект под gpl. А это уж, извините, детали :)
Это — далеко не детали ;)
> о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.
Есь такое :)
>> Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
> Но они хотя бы есть ;)
А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
> LGPL чем не нравится? Ну да, нужно публиковать изменения, вносимые в оригинал, но чем плохо развитие этого проекта?
> Да и BSD тоже довольно неплоха.
А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.
Но:
— для некоммерческой разработки оно под GPL: www.sencha.com/products/license.php
— вопрос о том, надо ли в таком случае открывать и исходники серверной части под баааальшим вопросом, на который никто, повторю — никто — не знает ответа
— как с коммерческой лицензией соотносятся опенсорс-плагины к ExtJS?
— как с GPL продукта соотносятся коммерческие плагины (если такие есть)?
— как с GPL продукта соотносятся плагины, которые могут быть в лицензиях, несовместимых с GPL?
и т.д. и т.п. :)
А так да — я бы хотел ExtJS под MIT :)
> Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом.
Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
Это — далеко не детали ;)
> о том, что же лучше: открыть код проекта, или мириться с ограничениями? Тут уж как сравнивать теплое с мягким.
Есь такое :)
>> Угу. Предлагаю поискать толкования GPL'я, например. Нет двух одинаковых толкований.
> Но они хотя бы есть ;)
А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
> LGPL чем не нравится? Ну да, нужно публиковать изменения, вносимые в оригинал, но чем плохо развитие этого проекта?
> Да и BSD тоже довольно неплоха.
А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.
Но:
— для некоммерческой разработки оно под GPL: www.sencha.com/products/license.php
— вопрос о том, надо ли в таком случае открывать и исходники серверной части под баааальшим вопросом, на который никто, повторю — никто — не знает ответа
— как с коммерческой лицензией соотносятся опенсорс-плагины к ExtJS?
— как с GPL продукта соотносятся коммерческие плагины (если такие есть)?
— как с GPL продукта соотносятся плагины, которые могут быть в лицензиях, несовместимых с GPL?
и т.д. и т.п. :)
А так да — я бы хотел ExtJS под MIT :)
> Одно из основных преимуществ опенсорса (лично для меня по крайней мере) — возможность узнать, что под капотом.
Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
> Это — далеко не детали ;)
Вопрос был про количество лицензий и их понятность. Содержимое мы, вроде как, не рассматривали. В этом случае тогда могу приплести, что GPL-программы обычно (не всегда) бесплатны. Но, повторюсь, этот вопрос стоит вне начала дискуссии.
> А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
Не интересовался этим вопросом, поэтому не могу сказать точно. Быстрый гуглопоиск показал, что в GPLv3 это, вроде, разрешили.
> А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.
Наверное, я не так понял вашу мысль. Я подумал, что там было высказывание в общем про выбор лицензии. А их обычно для своих продуктов выбирают :)
> Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
Не всегда документация дает нормальный ответ о поведении того или иного объекта. С PHP или Python из исходников на C мало что вынесешь, но, полагаю, разбор какого-нибудь фреймворка был бы довольно полезен. В общем и целом — согласен с мыслью.
Я больше по десктопным и серверным приложениям специализируюсь. По таким, которые компилируются, линкуются и подгружаются. Все подобные нюансы прописаны еще в GPLv2. Поэтому на ваши вопросы однозначных ответов дать не могу.
На мой взгляд, если подобные вопросы возникают, то это проблема создателя продукта, что он выбрал не ту лицензию и можно попросить у него разъяснений по данному вопросу.
Вопрос был про количество лицензий и их понятность. Содержимое мы, вроде как, не рассматривали. В этом случае тогда могу приплести, что GPL-программы обычно (не всегда) бесплатны. Но, повторюсь, этот вопрос стоит вне начала дискуссии.
> А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
Не интересовался этим вопросом, поэтому не могу сказать точно. Быстрый гуглопоиск показал, что в GPLv3 это, вроде, разрешили.
> А что, у меня внезапно появилась возможность выбора лицензии? :) Например, мне нравится ExtJS.
Наверное, я не так понял вашу мысль. Я подумал, что там было высказывание в общем про выбор лицензии. А их обычно для своих продуктов выбирают :)
> Справедливо и актуально для достаточно узкого круга продуктов и для достаточно небольшого количества разработчиков.
Не всегда документация дает нормальный ответ о поведении того или иного объекта. С PHP или Python из исходников на C мало что вынесешь, но, полагаю, разбор какого-нибудь фреймворка был бы довольно полезен. В общем и целом — согласен с мыслью.
Я больше по десктопным и серверным приложениям специализируюсь. По таким, которые компилируются, линкуются и подгружаются. Все подобные нюансы прописаны еще в GPLv2. Поэтому на ваши вопросы однозначных ответов дать не могу.
На мой взгляд, если подобные вопросы возникают, то это проблема создателя продукта, что он выбрал не ту лицензию и можно попросить у него разъяснений по данному вопросу.
Результирующий проект под gpl часто не проблема: если сервер под gpl и предоставляет network api, то создатель не обязан предоставлять исходники, так как фактически дистрибуции не происходит. Таким образом, если проект — web site или web service, к которому продается доступ, то он может быть без проблем написан под gpl лицензией. (Что бы запретить эту схему была разработана agpl)
Дугой вариант, когда софт пишется под заказ и у него один потребитель. Тут тоже gpl не проблема.
Дугой вариант, когда софт пишется под заказ и у него один потребитель. Тут тоже gpl не проблема.
> А толку? Ни одно из толкований не дает ответа, например, на вопрос о применимости GPL в веб-приложениях.
Естественно, можно.
> — вопрос о том, надо ли в таком случае открывать и исходники серверной части под баааальшим вопросом, на который никто, повторю — никто — не знает ответа
Вы должны открывать исходники своим заказчикам, т.к. они являются непосредственными пользователями ПО.
Естественно, можно.
> — вопрос о том, надо ли в таком случае открывать и исходники серверной части под баааальшим вопросом, на который никто, повторю — никто — не знает ответа
Вы должны открывать исходники своим заказчикам, т.к. они являются непосредственными пользователями ПО.
Ждём, с нетерпением, продолжения.
Вам приходится мериться с тем...
«мериться» от слова «мера»
«мериться» от слова «мера»
Ох зря вы начали с «вводной» холиварной статьи — они лишь бударажат, вызывают массу вопросов (адресованных к последующим частям) и вас нахлобучат, за то что нет аргументов, все притянуто за уши. Если бы смержили вводную с «конкретными примерами преимущества» было бы что обсуждать и две(?) хаброволны столкнулись бы в очередном буйстве (да, да, каждому инструменту есть своя область применения, где он идеален, бла-бла-бла, только всем пох, когда обидели их инструментарий), ведь ваша цель — дать лишний повод миграции тем, кто сомневается или не знает как перевести текущую «инфраструктуру» безболезненно. А ваш инструмент — убеждение на примере + имеющийся опыт миграции. И, да, .net — херня :)
Надеюсь автора не сольют.
лишенный прелестей динамического языка
Субъективно. Для меня больше прелестей в статическом.
а тут просто проблема в поиске — DLR
В контексте веб-фреймворка статика сильно мешает. Она провоцирует создание дополнительной прослойки из PresentationModel классов, которые растут как грибы после дождя (Пример: UserRegistrationInputModel, UserChangePasswordInputModel, UserLoginInputModel) итд.
В ASP.Net MVC 3 используется dynamic model. И, кстати, во второй версии его можно очень просто прикрутить — код ASP.Net MVC открыт и доступен для изменений.
Хорошее нововведение, а в обратную сторону оно работает? То есть когда модель передается при посте из формы.
Думаю, в общем случае работать не будет, так как при посте формы передаются строки и по входящей информации непонятно, как точно их парсить — все же C# язык статический, и вам вряд ли нужно, чтобы все свойства обьекта были строками.
С другой стороны, есть еще одна фича, которая позволяет передавать в метод JSON-обьект, и, мне кажется, не так уж и сложно парсить его и присваивать значения свойствам какого-нибуть ExpandoObject.
С другой стороны, есть еще одна фича, которая позволяет передавать в метод JSON-обьект, и, мне кажется, не так уж и сложно парсить его и присваивать значения свойствам какого-нибуть ExpandoObject.
Но он не сможет привести типы если входной параметр экшена не будет строготипизрованной моделью.
По JSON-обьекту все же можно определить, какого типа каждое из его свойств, в отличии от обычной формы, переданой в пост-запросе.
Например:
вполне легко распарсить как вот такой обьект на C#:
Например:
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;
+1, статика лучше
stas-agarkov.livejournal.com/18487.html
stas-agarkov.livejournal.com/18487.html
Пока это фигня какая-то с кучей ненужных картинок. Подожду следующей статьи, но начало неправильное.
> Работая с открытыми технологиями, вы можете непосредственно влиять на разработку. Люди, разрабатывающие продукт, публично известны и с ними легко можно установить прямой контакт. Возникшую проблему можно решить и самостоятельно, а решение отправить на суд разработчикам и другим членам сообщества.
Ну с платными технологиями такая же штуковина. Всё зависит от, на самом деле. Бывают и плохо поддерживаемые откртые проекты, и хорошо поддерживаемые проприетарные.
> Выбирая платную библиотеку вы, как правило, руководствуетесь не качеством, а рекламным слоганом, написанным на сайте.
Ну что-то качеством открытые библиотеки для Java, которые я использую на работе, не отличаются. А вот на прошлом месте работы мы как раз юзали .NET и нареканий не было. Впрочем, там ситуация неоднозначная. Вот у меня много ругани вызывает связка JasperReports + iReport + jfreechart, причём порой оказывается, что нужная фича таки есть, но прикручена она куда-нибудь глубоко внутрь и совсем не документирована. А индусы, которые пишут всякие руководства, как правило, идут по пути индус-way, так что для решения проблемы приходится тщательно изучать код самому. Можно, конечно, купить книжечку по JasperReports, но это уже денежки.
> лишенный прелестей динамического языка
Это какие у динамических языков прелести? Я вот к недостаткам, помимо тормознутости, могу прибавить ещё и большую сложность разработки, ибо IDE просто на порядки лучше поддерживает статически-типизированные языки.
> В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов»
Честно говоря, с какой бы технологией я не работал, никогда не видел, чтобы удалось полностью избежать описанного.
А вообще, заголовок статьи немного провокационный. Да, у дотнета есть определённые проблемы с web. Но дотнет вебом не ограничивается. Там ещё куча технологий. Например, лучше WPF в плане построения пользовательских интерфейсов, я ещё ничего не видел. Какой-нибудь Swing, который я сейчас использую, и для которого приходится изобретать кучу велосипедов и применять множество костылей, даже рядом не валялся. Так что может стоило назвать «почему мы сказали ASP.NET'у нет»?
Ну с платными технологиями такая же штуковина. Всё зависит от, на самом деле. Бывают и плохо поддерживаемые откртые проекты, и хорошо поддерживаемые проприетарные.
> Выбирая платную библиотеку вы, как правило, руководствуетесь не качеством, а рекламным слоганом, написанным на сайте.
Ну что-то качеством открытые библиотеки для Java, которые я использую на работе, не отличаются. А вот на прошлом месте работы мы как раз юзали .NET и нареканий не было. Впрочем, там ситуация неоднозначная. Вот у меня много ругани вызывает связка JasperReports + iReport + jfreechart, причём порой оказывается, что нужная фича таки есть, но прикручена она куда-нибудь глубоко внутрь и совсем не документирована. А индусы, которые пишут всякие руководства, как правило, идут по пути индус-way, так что для решения проблемы приходится тщательно изучать код самому. Можно, конечно, купить книжечку по JasperReports, но это уже денежки.
> лишенный прелестей динамического языка
Это какие у динамических языков прелести? Я вот к недостаткам, помимо тормознутости, могу прибавить ещё и большую сложность разработки, ибо IDE просто на порядки лучше поддерживает статически-типизированные языки.
> В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов»
Честно говоря, с какой бы технологией я не работал, никогда не видел, чтобы удалось полностью избежать описанного.
А вообще, заголовок статьи немного провокационный. Да, у дотнета есть определённые проблемы с web. Но дотнет вебом не ограничивается. Там ещё куча технологий. Например, лучше WPF в плане построения пользовательских интерфейсов, я ещё ничего не видел. Какой-нибудь Swing, который я сейчас использую, и для которого приходится изобретать кучу велосипедов и применять множество костылей, даже рядом не валялся. Так что может стоило назвать «почему мы сказали ASP.NET'у нет»?
Жаба отстала серьезно, причем с .net 2.0.
Ну да, отстала. Но мне Java больше нравится по политическим соображениям, нежели чем по технологическим. А начиная где-то версии 5-6, мне на ней хотя бы не противно писать. Ненавижу мелкомягких менеджеров, которые своей политикой гробят такую прекрасную технологию.
.NET научился деплоиться и скейлится на OpenSource за 0.00$? Или может MS любит альтернативные языки и вовсе не сократил команду IronRuby, в то время как над JRuby работает топовый Ruby-shop имени EngineYard? Ах, да Windows Phone далеко впереди Google Android. Да и такие передовые технологии Hadoop & GWT небось тоже на .NET?
Да очень жаль, что из MS ушел Jimmy Schementi- blog.jimmy.schementi.com/
мы не в 90х живем, тормознутость динамических языков с лихвой компенсируется достаточно недорогим серверным железом и высокой скоростью разработки.
Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python…
Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python…
> тормознутость динамических языков с лихвой компенсируется достаточно недорогим серверным железом и высокой скоростью разработки.
Замечательно. Если язык/платформа позволяет сильно удешевить процесс разработки/поддержки по сравнению с другой платформой, но при этом требует больше вычислительных мощностей, то всё равно мы её предпочтём. Тогда внимание: какие преимущества с точки зрения скорости разработки у динамически типизированных языков перед статически типизированными?
> Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python
… но ни одна из этих IDE не сможет даже близко повторить тот функционал, который поддерживает для Java NetBeans, Eclipse JDT, IDEA или VS + Resharper для C#. Ну хотя бы рефакторинг. Если сигнатура метода неизвестна заранее, то вряд ли мы сможем его автоматом переименовать. Или, скажем, исключить рудиментарный параметр, не нагородив при этом потенциальных ошибок. Ну или так. Вот пишу я в Java:
list.get(i).
Где list имеет тип List. Что вывалится в том же NetBeans, я прекрасно представляю. А вот в случае Ruby не вывалится ничего.
Замечательно. Если язык/платформа позволяет сильно удешевить процесс разработки/поддержки по сравнению с другой платформой, но при этом требует больше вычислительных мощностей, то всё равно мы её предпочтём. Тогда внимание: какие преимущества с точки зрения скорости разработки у динамически типизированных языков перед статически типизированными?
> Для Ruby есть множество IDE, которые отлично с ним ладят, я уже не говорю о Python
… но ни одна из этих IDE не сможет даже близко повторить тот функционал, который поддерживает для Java NetBeans, Eclipse JDT, IDEA или VS + Resharper для C#. Ну хотя бы рефакторинг. Если сигнатура метода неизвестна заранее, то вряд ли мы сможем его автоматом переименовать. Или, скажем, исключить рудиментарный параметр, не нагородив при этом потенциальных ошибок. Ну или так. Вот пишу я в Java:
list.get(i).
Где list имеет тип List. Что вывалится в том же NetBeans, я прекрасно представляю. А вот в случае Ruby не вывалится ничего.
Ой, хабр съел кусочек сообщения. «Где list имеет тип List» следует читать как «Где list имеет тип List<MyClass>». Вот как полезно бывает юзать предпросмотр
Что касается производительности, то это проблема решается за счет native кода написанного для узких мест. Также очень просто сконфигурировать проект для запуска на нескольких инстансах.
В целом думаю проблема производительности относительно надумана, так как уже есть не мало нагруженных проектов на Rails: github, twitter.
Мы используем JetBrains RubyMine 2.5 EAP. Рефакторингов меньше, но они есть. Интелисенс тоже есть, но не везде. Отмечу, что ошибок связанных с динамической типизации почти не делаем.
Ошибок в написании переменных, классов тоже практически нет, просто пишешь правильно на английском языке, а spell сhecker в IDE сразу увидит если что не так.
В целом думаю проблема производительности относительно надумана, так как уже есть не мало нагруженных проектов на Rails: github, twitter.
Мы используем JetBrains RubyMine 2.5 EAP. Рефакторингов меньше, но они есть. Интелисенс тоже есть, но не везде. Отмечу, что ошибок связанных с динамической типизации почти не делаем.
Ошибок в написании переменных, классов тоже практически нет, просто пишешь правильно на английском языке, а spell сhecker в IDE сразу увидит если что не так.
Ну вот, начинаются костыли для того, чтобы «писать правильно». Кстати, это не мешает писать ещё и медленно, ибо проблемы с автокомплитом. А вот о преимуществах, ради которых приходится покупать оборудование помощнее, что-то никто не пишет.
Не пишут, чтобы не начинать бесполезный холивар, в который, вы, очевидно, хотите погрузиться.
У вас же уже есть точка зрения, и изменить ее какими-то доводами никто не сможет. Изменить ее может помочь только опыт, причем тот опыт, который нельзя получить, придерживаясь этой точки зрения. Так что для всех продуктивнее будет остановиться сейчас — вы будете плеваться на отсутствие умных IDE и проверки типов на этапе сборки, мы будем плеваться на полотна кода и то, что все нужно делать через одно место (= вручную реализовывать паттерны проектирования) вместо того, чтобы воспользоваться возможностями языка.
Тон «свысока» тут неуместен ни с той, ни с другой стороны.
У вас же уже есть точка зрения, и изменить ее какими-то доводами никто не сможет. Изменить ее может помочь только опыт, причем тот опыт, который нельзя получить, придерживаясь этой точки зрения. Так что для всех продуктивнее будет остановиться сейчас — вы будете плеваться на отсутствие умных IDE и проверки типов на этапе сборки, мы будем плеваться на полотна кода и то, что все нужно делать через одно место (= вручную реализовывать паттерны проектирования) вместо того, чтобы воспользоваться возможностями языка.
Тон «свысока» тут неуместен ни с той, ни с другой стороны.
Я когда то писал на Java, и меня от перехода на RoR останавливало именно отсутствие автокомплита.
Но когда я перешел, он мне оказался не нужен. Как бы это сформулировать поточнее — я просто не пишу теперь столько текста, чтобы мне нужен был автокомплит. Мои модели порой короче чем один только ( конечно, автоматически сгенеренный) список импортов для модели из Java EE проекта. Но получается, что вся эта чудовищная избыточность и порождает проблему в виде костылей из автокомплитов, сложных рефакторингов и проч.
Но когда я перешел, он мне оказался не нужен. Как бы это сформулировать поточнее — я просто не пишу теперь столько текста, чтобы мне нужен был автокомплит. Мои модели порой короче чем один только ( конечно, автоматически сгенеренный) список импортов для модели из Java EE проекта. Но получается, что вся эта чудовищная избыточность и порождает проблему в виде костылей из автокомплитов, сложных рефакторингов и проч.
А индусы, которые пишут всякие руководства, как правило, идут по пути индус-way, так что для решения проблемы приходится тщательно изучать код самому. Можно, конечно, купить книжечку по JasperReports, но это уже денежки.
Отличительная особенность ruby от java в том, что в ruby-комьюнити практически отсутствуют индусы.
Самые большие минусы: неадекватно большая цена за SQL Server. И ленятся фиксить баги по много лет.
Да. Думаю, про Express-версию mssql (с довольно жесткими лимитами) многие знают. Но может кому-нибудь будет интересно: IBM DB2 (очень серьезная субд) так же доступна в экспресс-версии, но без ограничений по размеру субд.
Удивляюсь, что редко кто думает о замене на эту систему в связке с тем же .net.
Удивляюсь, что редко кто думает о замене на эту систему в связке с тем же .net.
* т. е. по размеру базы
Дя, мы не думали про IBM DB2. Подумаем. Спасибо! :)
А как там с драйверами?
Для дотнета? Есть.
www-01.ibm.com/software/data/db2/ad/dotnet.html
www-01.ibm.com/software/data/db2/ad/dotnet.html
Для интересующихся, немного подробнее:
Бесплатная версия называется IBM DB2 Express-C, берется здесь, по ограничениям — 2 ядра процессора, 2ГБ оперативной памяти. Объем баз не лимитирован.
Бесплатная версия называется IBM DB2 Express-C, берется здесь, по ограничениям — 2 ядра процессора, 2ГБ оперативной памяти. Объем баз не лимитирован.
Справедливости ради, стоит добавить, что в последней редакции Экспреса от МС ограничение по месту стало 10ГБ, а это уже хорошо :)
www.microsoft.com/express/database/
www.microsoft.com/express/database/
А цена не то чтобы неадекватная, это такой порядок цен на корпоративные субд (oracle/db2/mssql/sybase). Но есть же и опенсорс, и они все так же работают на windows server.
Уфф, почему никто не упомянул NoSQL? :) Никто не заставляет использовать SQL Server.
Да начнется же холивар
мегораспект вам за переход на Ruby on Rails, однако, и при выборе RoR вы остаетесь зависимыми. Недавно читал интервью с DHH в котором он прямым текстом говорил, что разрабатывая RoR они стремятся удовлетворить конкретно свои желания (свои в смысле 37signals), а не желания других разработчиков, оно и понятно, и так практически с каждым фреймворком, который изначально разрабатывается какой-либо компанией для себя, а не как «подарок миру». Ничего в этом плохого нет, но вы остаетесь зависимыми от мозгов 37signals и DHH в частности. Достойных альтернатив для RoR лишенных этого недостатка не знаю… Раньше был Merb, но…
P.S. Цыкл статей безусловно заинтересовал, с нетерпением жду новых ;-)
P.P.S. Что за агентство если не секрет? Ссылку на сайт можно?
P.S. Цыкл статей безусловно заинтересовал, с нетерпением жду новых ;-)
P.P.S. Что за агентство если не секрет? Ссылку на сайт можно?
У opensource приложений есть одно НО, даже если все мозги из 37signals сойдут с ума, начнут лепить невесть что, можно форкнуть RoR, .NET ты не форкнешь, если разрабам моча в голову ударит.
Тоже самое касается и того, если вдруг всех разрабов .NET'а вместе с манагерами переедет самосвал.
Тоже самое касается и того, если вдруг всех разрабов .NET'а вместе с манагерами переедет самосвал.
Не знаю кто вас минусует, Gorthauer87. Как по мне, вы правы на 100%.
А OpenSolaris форкнули? Или MySQL? Какое-то очень скользкое «можно» получается.
Illumos и MariaDB соответственно.
Насколько хорошо они развиваются — вопрос второй, но как факт — да, форкали.
Насколько хорошо они развиваются — вопрос второй, но как факт — да, форкали.
> www.percona.com/software/percona-server/
> mariadb.org/
Наличие аж двух форков MySQL вселяет сомнения. Какой выбрать в случае начала его лицензирования? Или городить Another One Fork of MySQL?
> www.illumos.org/
Впечатление, что этим форком занимается от силы десяток человек. Поживем — увидим.
P.S. А насколько хорошо они развиваются — вопрос без номера. Эдакий триггер востребованности.
> mariadb.org/
Наличие аж двух форков MySQL вселяет сомнения. Какой выбрать в случае начала его лицензирования? Или городить Another One Fork of MySQL?
> www.illumos.org/
Впечатление, что этим форком занимается от силы десяток человек. Поживем — увидим.
P.S. А насколько хорошо они развиваются — вопрос без номера. Эдакий триггер востребованности.
Да, но я говорю только о факте совершения форков.
MySQL — в принципе непонятно, что сейчас может заставлять в срочном порядке искать альтернативу в виде форка, кроме туманного будущего опенсорсного наследия Sun. Ее разработку официально никто не прекращал.
OpenSolaris — в большинстве связанных с ней последних новостей я постоянно видел отзывы в стиле «я OpenSolaris не пользовался, но сочувствую». Т. е. круг пользователей мне представляется весьма небольшим. В большинстве случаев это либо люди, пользовавшиеся другими опенсорс-юниксами и пробующие OS после открытия кода, либо пользователи обычного Solaris, перешедшие на OS.
Первые в большинстве своем безболезненно вернутся на Linux/BSD, вторые — либо на Oracle Solaris (при наличии денег), либо станут той узкой прослойкой заинтересованных в Illumos и подобных форках.
Т. е. я считаю потенциальную аудиторию несоизмеримо меньшей, чем потребовалась бы для развития проектов такого размера.
RoR, при текущей популярности и объеме кода никуда не денется даже если 37signals и DHH завтра иссчезнут.
MySQL — в принципе непонятно, что сейчас может заставлять в срочном порядке искать альтернативу в виде форка, кроме туманного будущего опенсорсного наследия Sun. Ее разработку официально никто не прекращал.
OpenSolaris — в большинстве связанных с ней последних новостей я постоянно видел отзывы в стиле «я OpenSolaris не пользовался, но сочувствую». Т. е. круг пользователей мне представляется весьма небольшим. В большинстве случаев это либо люди, пользовавшиеся другими опенсорс-юниксами и пробующие OS после открытия кода, либо пользователи обычного Solaris, перешедшие на OS.
Первые в большинстве своем безболезненно вернутся на Linux/BSD, вторые — либо на Oracle Solaris (при наличии денег), либо станут той узкой прослойкой заинтересованных в Illumos и подобных форках.
Т. е. я считаю потенциальную аудиторию несоизмеримо меньшей, чем потребовалась бы для развития проектов такого размера.
RoR, при текущей популярности и объеме кода никуда не денется даже если 37signals и DHH завтра иссчезнут.
вроде бы форкнули и то и другое (MariaDB)?
Более того, был проект XFree86, после того, как его разработчикам таки ударила в голову моча, родился форк xorg, который поддержали разработчики и основные мейнтейнеры линукса и bsd систем. И в итоге XFree86 умер, а форк остался жить.
Openoffice по аналогичной схеме форкнулся, пройдет полгода и во всех дистрах вместо него будет libreoffice.
Openoffice по аналогичной схеме форкнулся, пройдет полгода и во всех дистрах вместо него будет libreoffice.
Мелкософт регулярно проверяет анализы мочи… которые включают в стоймость конечного продукта.
Интересно, сколько народу реально готовы «форкнуть», да так, чтобы всерьез, и этим можно было пользоваться.
Если разрабов .NET переедет самосвал (чего не произойдет, но если даже гипотетически), то берем исходники .NET и форкаем. Собственно, уже и так есть Mono.
В конце концов, всегда, при абсолютно любых условиях, если на другую половину Земли (где по несчастью находился вендор технологии) упал огромный метеорит, можно взять и с нуля освоить любую другую технологию.
Если разрабов .NET переедет самосвал (чего не произойдет, но если даже гипотетически), то берем исходники .NET и форкаем. Собственно, уже и так есть Mono.
В конце концов, всегда, при абсолютно любых условиях, если на другую половину Земли (где по несчастью находился вендор технологии) упал огромный метеорит, можно взять и с нуля освоить любую другую технологию.
Хоть бы одну причину оригинальную написали. Ну кто об этом не знает?
Проблема в том, что в мире нет идеального ПО. Те кто используют .Net и Windows — прекрасно знают о его платности, закрытости и пр. Однако используют, ибо бесплатное ПО имеет СВОИ существенные недостатки.
Проблема в том, что в мире нет идеального ПО. Те кто используют .Net и Windows — прекрасно знают о его платности, закрытости и пр. Однако используют, ибо бесплатное ПО имеет СВОИ существенные недостатки.
>В один момент мы поняли, что в наших проектах мы тратим более половины времени на доработку изъянов .NET и изобретение собственных «велосипедов», что крайне негативно сказывается на сроках разработки.
Есть такое. Зачастую хочется все выкинуть и написать заново, чем кастомайзить то что есть под какой-то чуть другой сценарий нежели придумало MS.
Есть такое. Зачастую хочется все выкинуть и написать заново, чем кастомайзить то что есть под какой-то чуть другой сценарий нежели придумало MS.
а можно поподробнее про технологию ASP.NET и «полную несостоятельность», которую она «показала за 5 лет до появления ASP.NET MVC», а точнее показывает уже почти 10 лет? :)
Тысячи успешных веб-приложений плюс корпоративный сектор с Sharepoint'ом во главе внимательно следят за постом.
Тысячи успешных веб-приложений плюс корпоративный сектор с Sharepoint'ом во главе внимательно следят за постом.
SharePoint тут не самый удачный пример, для многих разработчиков это страшный сон.
Ахахаа, Шарепоинт, школьник иди собирай ранец завтра в школу, такого глючно-тормозного говна еще мир не видал, а разработка под него это просто нечто, если бы не пронырливые менеджерки с откатами гнить этому говну на помойке сразу после выпуска
SharePoint это как раз не особо хороший пример вне зависимости от критерия. Хотя продается хорошо, не спорю.
Я немного проспойлерю, топикстартер видимо постеснялся дать ссылку на видео-доклад
blog.byndyu.ru/2010/10/big-switch-microsoft.html
blog.byndyu.ru/2010/10/big-switch-microsoft.html
> лишенный прелестей динамического языка
Я бы не сказал, что динамичность языка это плюс, и на производительность и на скорость разработки это влияет отрицательно, т.к. в случае с статической типизацией многие ошибки будут найдены еще на этапе компиляции.
Так же нельзя не заметить, что синтаксис ruby не красивее чем у C#, но это уже скорее дело вкуса =)
Я бы не сказал, что динамичность языка это плюс, и на производительность и на скорость разработки это влияет отрицательно, т.к. в случае с статической типизацией многие ошибки будут найдены еще на этапе компиляции.
Так же нельзя не заметить, что синтаксис ruby не красивее чем у C#, но это уже скорее дело вкуса =)
Следует понимать данное замечание прежде всего в контектсе веб-фреймворка.
Ошибаетесь. Я люблю .NET/C#. Но в плане выразительности Ruby и Rails на его основе дадут сто очков вперёд любым альтернативам, включая C#/ASP.NET, Python/Django etc.
Что не мешает мне любить C# :)
Что не мешает мне любить C# :)
Обычно считается, что динамичность языка это плюс к скорости разработки и минус к скорости выполнения, а у вас как-то выходит, что это сплошные минусы. Почему тогда они столь популярны?
Что значит считается? Считается что Менделеев водку изобрел.
Я еще не видел нигде такой качественной поддержки кода как в VS, а она основана на строгой типизации объектов. Работая с несложными объектами можно, фактически, без документации разобраться по подсказкам автокомлитера.
В большинстве сред, что я видел, при обращении к объекту автокомлитер выдает все свойства и методы, которые он знает, это крайне раздражает. Работа в этом плане с js это для меня вообще тихий ужас после многих лет работы с C-подобными языками.
Может мой пост и получился чересчур приземленным, но работа с динамическими языками ничего кроме как неопределенности и головной боли не доставляет.
Я еще не видел нигде такой качественной поддержки кода как в VS, а она основана на строгой типизации объектов. Работая с несложными объектами можно, фактически, без документации разобраться по подсказкам автокомлитера.
В большинстве сред, что я видел, при обращении к объекту автокомлитер выдает все свойства и методы, которые он знает, это крайне раздражает. Работа в этом плане с js это для меня вообще тихий ужас после многих лет работы с C-подобными языками.
Может мой пост и получился чересчур приземленным, но работа с динамическими языками ничего кроме как неопределенности и головной боли не доставляет.
То и значит, что объективных данных нет, афаик, но это устоявшееся мнение, основанное хотя бы на том, что объём кода при решении одной и той же задачи получается меньше, т. к. ненужно, по крайней мере, объявлять тип.
А когда я пишу в VS на динамическом языке, его поддержка качественная или нет? А если пишу на C# в Eclipse? А если в vim или блокноте? И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали? И вообще, мы обсуждаем IDE или языки? К Си-подобным языкам синтаксически относится, кстати, и всеми «любимый» PHP и «ваш» Javascript.
О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :) Мне вот головную боль и резь в глазах доставляют строгие статические языки от обилия объявления и приведения типов в коде, за которыми теряется логика выражения, так что головная боль это не показатель.
А когда я пишу в VS на динамическом языке, его поддержка качественная или нет? А если пишу на C# в Eclipse? А если в vim или блокноте? И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали? И вообще, мы обсуждаем IDE или языки? К Си-подобным языкам синтаксически относится, кстати, и всеми «любимый» PHP и «ваш» Javascript.
О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :) Мне вот головную боль и резь в глазах доставляют строгие статические языки от обилия объявления и приведения типов в коде, за которыми теряется логика выражения, так что головная боль это не показатель.
>>То и значит, что объективных данных нет, афаик, но это устоявшееся мнение, основанное хотя бы на том, что объём кода при решении одной и той же задачи получается меньше, т. к. ненужно, по крайней мере, объявлять тип.
Это мелочи, которые тут же оборачиваются головной болью. Сложно держать все в голове, знать все возвращаемые и принимаемые типы. А в случае необходимости сразу же лезть в документацию.
>>И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали?
Вы меня не так поняли, я имел ввиду, что некоторые IDE по дефолту имеют только один список, которые подставляют к любому объекту.
>>И вообще, мы обсуждаем IDE или языки?
Тут обсуждается стек технологий .net, частью которой можно считать и VS. К тому же без хорошей поддержки IDE скорость разработки страдает.
>>О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :)
… вот только когда компилируется, ведет себя как утюг. 90% ошибок синтаксического кода в статических языках уже выявляются на этапе компиляции.
Это мелочи, которые тут же оборачиваются головной болью. Сложно держать все в голове, знать все возвращаемые и принимаемые типы. А в случае необходимости сразу же лезть в документацию.
>>И вы хотите, чтобы он не выдавал известные ему методы и свойства текущего объекта или класса, а вы их сами набирали?
Вы меня не так поняли, я имел ввиду, что некоторые IDE по дефолту имеют только один список, которые подставляют к любому объекту.
>>И вообще, мы обсуждаем IDE или языки?
Тут обсуждается стек технологий .net, частью которой можно считать и VS. К тому же без хорошей поддержки IDE скорость разработки страдает.
>>О какой неопределенности вы говорите? То, что выглядит как утка, летает как утка, крякает как утка можно считать уткой :)
… вот только когда компилируется, ведет себя как утюг. 90% ошибок синтаксического кода в статических языках уже выявляются на этапе компиляции.
У меня тоже 90% ошибок выявляется на этапе компиляции интерпретации за счет запущенного в фоне autotest. (ruby, rails)
«90% ошибок синтаксического кода»
Это вы о чем вообще? :)
Что касается .NET, там есть еще такая вещь, как статический анализ кода (с помощью FxCop) — очень полезная вещь для написания качественного и безопасного кода.
Это вы о чем вообще? :)
Что касается .NET, там есть еще такая вещь, как статический анализ кода (с помощью FxCop) — очень полезная вещь для написания качественного и безопасного кода.
Документация идёт в коде, тот же javadoc придумали не для динамического языка
Некоторые может быть, ну так и некоторые для статических языков так же поступают, а в некоторых вообще никакого автодополнения нет. Может для динамических таких больше, но я чаще сталкивался с проблемой, что методов/свойств не хватает (IDE смогла определить только базовый класс), чем их избыток :)
По треду только вы только что упомянули .NET, до этого говорили о языке C#. Причём С# и .NET это не то, что не синонимы, но даже не вложенные множества. Не всё, что пишется на С# пишется под .NET — я вот прямо сейчас пишу на C# под Linux'ом, где никаким .NET и VS не пахнет.
Как бы самые популярные языки с динамической типизацией являются интерпретируемыми, так что этапа компиляции там просто нет, максимум перевод в байт-код. И зачем выявлять на этапе компиляции ошибки, которых в динамических языках просто не может быть по определению (забыли объявить или привести тип, например)?
Некоторые может быть, ну так и некоторые для статических языков так же поступают, а в некоторых вообще никакого автодополнения нет. Может для динамических таких больше, но я чаще сталкивался с проблемой, что методов/свойств не хватает (IDE смогла определить только базовый класс), чем их избыток :)
По треду только вы только что упомянули .NET, до этого говорили о языке C#. Причём С# и .NET это не то, что не синонимы, но даже не вложенные множества. Не всё, что пишется на С# пишется под .NET — я вот прямо сейчас пишу на C# под Linux'ом, где никаким .NET и VS не пахнет.
Как бы самые популярные языки с динамической типизацией являются интерпретируемыми, так что этапа компиляции там просто нет, максимум перевод в байт-код. И зачем выявлять на этапе компиляции ошибки, которых в динамических языках просто не может быть по определению (забыли объявить или привести тип, например)?
То, что с вашей колокольни кажется серьезной проблемой, с нашей колокольни проблемой совсем не кажется)
Например, зачем гадать и разбираться по подсказкам автокомплитера, если всегда можно по-быстрому глянуть исходник или запустить интерактивный интерпретатор. А в простых случаях подсказки и так есть, и вполне все с ними нормально.
Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.
Еще можно заметить, что ide для javascript и правда никакие, для python, php и ruby все гораздо лучше.
И ясно-понятно, работа с динамическими языками будет доставлять головную боль, т.к. я почему-то уверен, что вы их знаете хуже. Мне тоже с малознакомыми языками сначала тяжко, тот же javascript довольно сложен и сильно отличается от других языков.
Я тут недавно пробовал написать что-то на Objective-C (при том, что C знаю хорошо), это ничего кроме неопределенности и головной боли не доставило (при всех автокомплитах и тд), и это никак не недостаток Objective-C, а просто я этот язык не знаю.
Например, зачем гадать и разбираться по подсказкам автокомплитера, если всегда можно по-быстрому глянуть исходник или запустить интерактивный интерпретатор. А в простых случаях подсказки и так есть, и вполне все с ними нормально.
Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.
Еще можно заметить, что ide для javascript и правда никакие, для python, php и ruby все гораздо лучше.
И ясно-понятно, работа с динамическими языками будет доставлять головную боль, т.к. я почему-то уверен, что вы их знаете хуже. Мне тоже с малознакомыми языками сначала тяжко, тот же javascript довольно сложен и сильно отличается от других языков.
Я тут недавно пробовал написать что-то на Objective-C (при том, что C знаю хорошо), это ничего кроме неопределенности и головной боли не доставило (при всех автокомплитах и тд), и это никак не недостаток Objective-C, а просто я этот язык не знаю.
>>То, что с вашей колокольни кажется серьезной проблемой, с нашей колокольни проблемой совсем не кажется)
Я не считаю это серьезной проблемой, просто из таких мелочей складываются очень неприятные ощущения.
>>Например, зачем гадать и разбираться по подсказкам автокомплитера, если всегда можно по-быстрому глянуть исходник или запустить интерактивный интерпретатор. А в простых случаях подсказки и так есть, и вполне все с ними нормально.
Зачем гадать? Автокомплитер помогает «вспомнить код», экономит 90% времени на рутинных операциях. Так же по названиям методов и возвращаемым значениям, помогает понять новый. Если уж нужно разобраться, как что работает то да, нужно лезть в исходники.
>>Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.
Я ни в коем случае не приверженец этого подхода.
>>И ясно-понятно, работа с динамическими языками будет доставлять головную боль, т.к. я почему-то уверен, что вы их знаете хуже. Мне тоже с малознакомыми языками сначала тяжко, тот же javascript довольно сложен и сильно отличается от других языков.
Да хуже, но я не представляю, как можно все это держать в голове
Я не считаю это серьезной проблемой, просто из таких мелочей складываются очень неприятные ощущения.
>>Например, зачем гадать и разбираться по подсказкам автокомплитера, если всегда можно по-быстрому глянуть исходник или запустить интерактивный интерпретатор. А в простых случаях подсказки и так есть, и вполне все с ними нормально.
Зачем гадать? Автокомплитер помогает «вспомнить код», экономит 90% времени на рутинных операциях. Так же по названиям методов и возвращаемым значениям, помогает понять новый. Если уж нужно разобраться, как что работает то да, нужно лезть в исходники.
>>Для меня как для человека из другого лагеря подход «выбирать язык по ide» представляется какой-то дикостью — код за вас ide написать-то сможет (это 20% усилий), а вот прочитать получившиеся килобайты (это 80% усилий) — уже не сможет.
Я ни в коем случае не приверженец этого подхода.
>>И ясно-понятно, работа с динамическими языками будет доставлять головную боль, т.к. я почему-то уверен, что вы их знаете хуже. Мне тоже с малознакомыми языками сначала тяжко, тот же javascript довольно сложен и сильно отличается от других языков.
Да хуже, но я не представляю, как можно все это держать в голове
после многих лет работы с C-подобными языками.
Это ключевая фраза в вашем комментарии. Вы просто не привыкли обходиться без подсказок интеллисенса.
Вы знаете, я посмотрел большой кусок вашей видео-презентации и у меня сложилось впечатление, что ваши аргументы против ASP.Net MVC и за Rails сводятся к тому, что
а) «в Rails не надо думать»
б) «в ASP.Net MVC нельзя (тут либо фича, которая уже анонсирована в MVC 3, либо вы просто не поняли как это сделать)»
По пункту а) могу сказать, что думать лично мне нравится думать и я вообще считаю, что в этом и состоит работа программиста. По пункту б) — без коментариев.
На самом деле, у меня опять же складывается впечатление, что ваши проекты довольно мелкие и скорее ближе к таргет-аудитории www.asp.net/webmatrix, чем к ASP.Net MVC, который все же более гибкий и низкоуровневый фреймворк, рассчитаный на крупные проекты (несколько человеко-лет разработки и многие годы сапорта).
а) «в Rails не надо думать»
б) «в ASP.Net MVC нельзя (тут либо фича, которая уже анонсирована в MVC 3, либо вы просто не поняли как это сделать)»
По пункту а) могу сказать, что думать лично мне нравится думать и я вообще считаю, что в этом и состоит работа программиста. По пункту б) — без коментариев.
На самом деле, у меня опять же складывается впечатление, что ваши проекты довольно мелкие и скорее ближе к таргет-аудитории www.asp.net/webmatrix, чем к ASP.Net MVC, который все же более гибкий и низкоуровневый фреймворк, рассчитаный на крупные проекты (несколько человеко-лет разработки и многие годы сапорта).
На момент подготовки данной видеопрезентации у меня не было достаточно времени подготовить примеры. Именно поэтому я решил написать серию постов, где остановлюсь на каждом аспекте подробнее.
В Rails действительно надо меньше думать о том как построить приложение и больше времени можно уделить непосредственно самому веб-приложению.
Сейчас мы делаем в основном многпользовательские веб-проекты, которые нельзя назвать тривиальными. Вот например: keekme.ru
В Rails действительно надо меньше думать о том как построить приложение и больше времени можно уделить непосредственно самому веб-приложению.
Сейчас мы делаем в основном многпользовательские веб-проекты, которые нельзя назвать тривиальными. Вот например: keekme.ru
Еще один все понял.
Прогнозирую 300+ холиварных комментариев.
«MVC показала свою полную несостоятельность»
«Ruby on Rails предоставляет архитектурный образец Model-View-Controller » — Wiki
Совсем запутали.
«Ruby on Rails предоставляет архитектурный образец Model-View-Controller » — Wiki
Совсем запутали.
То, что решили расширить кругозор за пределы «железного занавеса» дотнет — это абсолютно правильно. Особенно для веб-разработчика, в вебе дотнет сильно отстал и последние годы, как вы правильно заметили, занимается тем, что навёрстывает упущенное.
Так что добро пожаловать в мир открытых технологий, только один совет — не меняйте шило на мыло, в смысле не сосредотачевайтесь исключительно на рельсах. Я ни в коей мере не умаляю заслуг этого фреймворка — рельсы по сути дали толчёк всему хорошему, что было в вебе за последние 5 лет. Тем не менее сами они — вещь в себе, причём довольно консервативная, так например нововведения из Rails 3 существовали в Django уже довольно долго, собственно потому появился Merb и др. Плюс сам язык Ruby мягко говоря на любителя. Так что и в Python есть на что посмотреть, и в Java. Вот вы говорите ASP.NET MVC дублирует рельсы — это не так, он слизывает всё один в один со Spring@MVC в частности и со спринга вообще.
Так что не надо останавливаться — двигайтесь дальше, исследуйте. На сегодняшний день «классические» MVC фреймворки уже ничем не могут удивить (даже новые PHP-фреймворки в некоторых аспектах могут дать фору Rails/Django, хотя работы ещё предстоит много), Веб развивается, сейчас уже более актуально асинхронное программирование и NoSQL базы, как следствие набирают обороты фреймворки/языки, в которых сильная функциональная составляющая — Scala, Javascript, Erlang.
Так что добро пожаловать в мир открытых технологий, только один совет — не меняйте шило на мыло, в смысле не сосредотачевайтесь исключительно на рельсах. Я ни в коей мере не умаляю заслуг этого фреймворка — рельсы по сути дали толчёк всему хорошему, что было в вебе за последние 5 лет. Тем не менее сами они — вещь в себе, причём довольно консервативная, так например нововведения из Rails 3 существовали в Django уже довольно долго, собственно потому появился Merb и др. Плюс сам язык Ruby мягко говоря на любителя. Так что и в Python есть на что посмотреть, и в Java. Вот вы говорите ASP.NET MVC дублирует рельсы — это не так, он слизывает всё один в один со Spring@MVC в частности и со спринга вообще.
Так что не надо останавливаться — двигайтесь дальше, исследуйте. На сегодняшний день «классические» MVC фреймворки уже ничем не могут удивить (даже новые PHP-фреймворки в некоторых аспектах могут дать фору Rails/Django, хотя работы ещё предстоит много), Веб развивается, сейчас уже более актуально асинхронное программирование и NoSQL базы, как следствие набирают обороты фреймворки/языки, в которых сильная функциональная составляющая — Scala, Javascript, Erlang.
На рельсах мы не останавливаемся. Сейчас также смотрим в сторону Scala на одном из новых проектов.
Прикольно там у вас работать ). Надоел .NET — переходишь на RoR, надоел RoR — переходишь на Scala, надоела Scala — ну вы поняли (с).
У нас многие приложения пишутся на рельсе, а высоконагруженная часть оборачивается во внутренний закрытый REST-сервис на scala(liftweb).
Про технологический кругозор, про то, что его надо расширять — согласен полностью.
Про «железный занавес .NET» — не согласен ни грамма. .NET ничуть не хуже работает и с альтернативными БД, и с NoSQL, и поддерживает функциональный стиль (F#).
«в вебе дотнет сильно отстал и последние годы, как вы правильно заметили, занимается тем, что навёрстывает упущенное»
Вот это никак не аргументировано. В чем именно он отстал? Чего в нем такого нет, что есть где-то еще?
Про «железный занавес .NET» — не согласен ни грамма. .NET ничуть не хуже работает и с альтернативными БД, и с NoSQL, и поддерживает функциональный стиль (F#).
«в вебе дотнет сильно отстал и последние годы, как вы правильно заметили, занимается тем, что навёрстывает упущенное»
Вот это никак не аргументировано. В чем именно он отстал? Чего в нем такого нет, что есть где-то еще?
до сих пор не хватает динамики (то, что вносит DLR).
ну и для Web там до сих пор мало всего, если смотреть с точки зрения рельсовика.
ну и для Web там до сих пор мало всего, если смотреть с точки зрения рельсовика.
Ну динамика — это, как говорится, «на вкус и цвет», но, действительно, есть же DLR.
А вот по поводу «Web» слово «мало» в контексте .NET, как по мне, не вяжется совершенно. Ибо там есть все. О чем конкретно идет речь, чего не хватает (с точки зрения RoR-dev)?
А вот по поводу «Web» слово «мало» в контексте .NET, как по мне, не вяжется совершенно. Ибо там есть все. О чем конкретно идет речь, чего не хватает (с точки зрения RoR-dev)?
Не хватает большого выбора библиотек для добавления нужных фич.
Просто добавляем в модель acts_as_taggable, и теперь она поддерживает тэггирование, добавляем acts_as_nested_set, появляется возможность вложения. Пишем — has_attached_file :avatar, :styles => { :medium => «300x300>», :thumb => «100x100>» }, и вы имеете колонку для загрузки файлов с набором миниатюр…
Просто добавляем в модель acts_as_taggable, и теперь она поддерживает тэггирование, добавляем acts_as_nested_set, появляется возможность вложения. Пишем — has_attached_file :avatar, :styles => { :medium => «300x300>», :thumb => «100x100>» }, и вы имеете колонку для загрузки файлов с набором миниатюр…
И при этом обычно имеется набор готовых хелперов для взаимодействия этих интерфейсов с пользователем.
Ну в чем-то я соглашусь — не хватает некоторого стандартизированного фреймворка уже поверх существующего фреймворка ASP.NET MVC. Набор хелперов — не совсем то, нужна какая-то более удобная для использования абстракция над View и View-моделями.
Что касается модели, то она может реализовать интерфейс, скажем, ITaggable, и будет поддерживать теги, и так далее. Думаю, было бы удобно, чтобы на основе соглашений, View-модель (а также View) каким-то образом автоматически начинала поддерживать теги, если модель их начинает поддерживать. Но сдается мне, что это просто разные подходы, и я не назвал бы это «мало для веба».
Что касается модели, то она может реализовать интерфейс, скажем, ITaggable, и будет поддерживать теги, и так далее. Думаю, было бы удобно, чтобы на основе соглашений, View-модель (а также View) каким-то образом автоматически начинала поддерживать теги, если модель их начинает поддерживать. Но сдается мне, что это просто разные подходы, и я не назвал бы это «мало для веба».
Как сказал один знакомый адепт корпоративной культуры программирования Microsoft:
Я только улыбнулся в ответ, потому как попытки объяснить, что большая часть сайтов уже работает на PHP ни к чему не привели.
«PHP — это мертворожденный язык. Скоро все будет только на .NET.»
Я только улыбнулся в ответ, потому как попытки объяснить, что большая часть сайтов уже работает на PHP ни к чему не привели.
Сертифицированым говорите? За 4 года?
Номера в студию.
Номера в студию.
Нет проблем:
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
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
Давайте транскрипцию, а то это только пустые слова.
Вот к примеру длинна моей [s]пи[/s]: https://mcp.microsoft.com/authenticate/validatemcp.aspx
Transcript ID 823289
Access Code ts332200
Вот к примеру длинна моей [s]пи[/s]: https://mcp.microsoft.com/authenticate/validatemcp.aspx
Transcript ID 823289
Access Code ts332200
Окей.
https://mcp.microsoft.com/authenticate/validatemcp.aspx
Transcript ID 854899
Access Code dxScK8VT
https://mcp.microsoft.com/authenticate/validatemcp.aspx
Transcript ID 854899
Access Code dxScK8VT
Простите, конечно, но стиль Вашего текста — совершенно нетехнические, и в чем-то вообще детские упрёки в отношение WebForms, почему-то называемому везде просто как ASP.NET — совершенно не вяжутся с уровнем сертифицированных технологий.
Нет, я понимаю, что может быть в силу возраста хочется какого-то максимализма — и тогда без разницы что критиковать, но ведь если Вы настолько хорошо разбираетесь в «технологиях врага», ведь можно критиковать как-то более адресно.
А так читаешь Вас и думаешь, что пишет очередной программист-неудачник, который так и не смог осилить даже базовые вещи в ASP.NET.
Ну ведь там есть большинство из того, что Вы так упорно отрицаете: и веб-тесты от MSTest-фреймвока и TFS, и прекрасная работа с сессиями, легко и гибко настраиваемая — никогда еще мне ничего вручную не приходилось делать, и поддержка нормальная Аякса с частичным обновлением страницы работает быстро, легко понимается и легко применяется.
Не знаю как у Вас, но у меня без проблем получается написать полностью RESTful сайты на ASP.NET WebForms пользуясь только ASP.NET Routing и полностью вырубая ViewState у страниц. И отлично работает, и легко отлаживается, и работы немного.
Да, у WebForms есть свои проблемы, и как в случае любого ASP нет возможности покрыть его unit-тестами (в MVC тоже отнюдь не все части можно покрыть unit-тестами), но все эти проблемы давно известны и уж MCPD решает их сравнительно быстро. Говорю это как MCPD ;-)
Нет, я понимаю, что может быть в силу возраста хочется какого-то максимализма — и тогда без разницы что критиковать, но ведь если Вы настолько хорошо разбираетесь в «технологиях врага», ведь можно критиковать как-то более адресно.
А так читаешь Вас и думаешь, что пишет очередной программист-неудачник, который так и не смог осилить даже базовые вещи в ASP.NET.
Ну ведь там есть большинство из того, что Вы так упорно отрицаете: и веб-тесты от MSTest-фреймвока и TFS, и прекрасная работа с сессиями, легко и гибко настраиваемая — никогда еще мне ничего вручную не приходилось делать, и поддержка нормальная Аякса с частичным обновлением страницы работает быстро, легко понимается и легко применяется.
Не знаю как у Вас, но у меня без проблем получается написать полностью RESTful сайты на ASP.NET WebForms пользуясь только ASP.NET Routing и полностью вырубая ViewState у страниц. И отлично работает, и легко отлаживается, и работы немного.
Да, у WebForms есть свои проблемы, и как в случае любого ASP нет возможности покрыть его unit-тестами (в MVC тоже отнюдь не все части можно покрыть unit-тестами), но все эти проблемы давно известны и уж MCPD решает их сравнительно быстро. Говорю это как MCPD ;-)
А что удивительного? Я сдал первых два экзамена года через полтора после того как начал работать. Сейчас вот собираюсь сдавать MCPD — и как раз три года как я начал работать разработчиком будет в конце октября.
Чтобы понять почему ASP* — говно, достаточно посмотреть HTML который оно генерирует, особенно формы. Сколько в них мусора, реализующего какую-то магию фреймворка, неконтролируемую разработчиком! Сразу понятно что и внутренняя архитектура там не ok.
Признайте, что вы просто не «в теме», и не знаете, что такое ASP.NET. Называть что-то говном, не зная о чем идет речь — не лучший аргумент за или против.
«Сразу понятно что и внутренняя архитектура там не ok.»
Ничего вам не понятно.
«Сразу понятно что и внутренняя архитектура там не ok.»
Ничего вам не понятно.
Лично я с вами не соглашусь. Причина в том, что ASP.NET не подходит под парадигму http (который stateless). А MVC--подходит. Кроме того, MVC фактически добавляет еще один слой в приложение (контроллеры), которого по умолчанию нет в ASP.NET.
Дело вот в чем. Человек говорит про ASP.NET в целом, не разбирая что к чему.
ASP.NET и stateless-http никак не взаимозависимо.
ASP.NET — это runtime. Для него есть технология WebForms — одна абстракция, использующая свою модель, и есть ASP.NET MVC — другая абстракция, которая использует другую модель, использующую HTTP именно как HTTP, а не только как транспорт для абстракции более высокого уровня. И нет, ASP.NET MVC — это не надстройка на ASP.NET WebForms.
А MVC (и вообще паттерна Front Controller) по-умолчанию нет в ядре любой серверной back-end технологии. Отличие RoR в том, что там этот паттерн реализован на уровне платформы, только и всего. С таким же успехом и на Руби можно реализовать модель Web Forms.
Так что вот так сказать нельзя:
«Причина в том, что ASP.NET не подходит под парадигму http»
Под эту парадигму не подходит WebForms, но на ASP.NET есть еще ASP.NET MVC, Castle MonoRail, FubuMVC, которые подходят. Да можно хоть свой фреймворк реализовать.
ASP.NET и stateless-http никак не взаимозависимо.
ASP.NET — это runtime. Для него есть технология WebForms — одна абстракция, использующая свою модель, и есть ASP.NET MVC — другая абстракция, которая использует другую модель, использующую HTTP именно как HTTP, а не только как транспорт для абстракции более высокого уровня. И нет, ASP.NET MVC — это не надстройка на ASP.NET WebForms.
А MVC (и вообще паттерна Front Controller) по-умолчанию нет в ядре любой серверной back-end технологии. Отличие RoR в том, что там этот паттерн реализован на уровне платформы, только и всего. С таким же успехом и на Руби можно реализовать модель Web Forms.
Так что вот так сказать нельзя:
«Причина в том, что ASP.NET не подходит под парадигму http»
Под эту парадигму не подходит WebForms, но на ASP.NET есть еще ASP.NET MVC, Castle MonoRail, FubuMVC, которые подходят. Да можно хоть свой фреймворк реализовать.
Да, при таких определениях вы правы. Но тогда в моем посте и посте VasilioRuzanni замените ASP.NET на ASP.NET WebForms.
В конце концов, говоря ASP.NET почти всегда имеют в виду еще WebForms--все-таки, ASP.NET проектировалась для WebForms. При MVC custom handlers вообще неактуальны, custom modules тоже; про Page LifeCycle забываем. Если бы ASP.NET как рантайм проектировалась хотя бы с учетом двух парадигм (WebForms и MVC), то была бы она совсем другой.
И с предыдущим комментатором про архитектуру (WebForms) я соглашусь. Посмотрите, насколько ASP.NET WebForms плохо расширяемы и тестируемы. Хотя понятию модульности уже 40 лет как минимум, да и юнит-тесты тогда были. Неспроста во второй версии появились всякие уродливые штуки типа control adapters, Page_PreInit и тп.
В конце концов, говоря ASP.NET почти всегда имеют в виду еще WebForms--все-таки, ASP.NET проектировалась для WebForms. При MVC custom handlers вообще неактуальны, custom modules тоже; про Page LifeCycle забываем. Если бы ASP.NET как рантайм проектировалась хотя бы с учетом двух парадигм (WebForms и MVC), то была бы она совсем другой.
И с предыдущим комментатором про архитектуру (WebForms) я соглашусь. Посмотрите, насколько ASP.NET WebForms плохо расширяемы и тестируемы. Хотя понятию модульности уже 40 лет как минимум, да и юнит-тесты тогда были. Неспроста во второй версии появились всякие уродливые штуки типа control adapters, Page_PreInit и тп.
Ну да, про WebForms я и не говорю, у них реально много недостатков для современной команды.
Но не знаю, насколько другой была бы ASP.NET Runtime. Как по мне — там есть, что поменять, но с точки зрения архитектуры — несущественно. В конце концов Page Lifecycle — это абстракция над Request Lifecycle, но не наоборот.
А всякие custom handler'ы и modules отнюдь не неактуальны — они имеют свое применение и в контексте MVC, ведь они — часть цепочки выполнения Request'а.
Но не знаю, насколько другой была бы ASP.NET Runtime. Как по мне — там есть, что поменять, но с точки зрения архитектуры — несущественно. В конце концов Page Lifecycle — это абстракция над Request Lifecycle, но не наоборот.
А всякие custom handler'ы и modules отнюдь не неактуальны — они имеют свое применение и в контексте MVC, ведь они — часть цепочки выполнения Request'а.
А в Ruby, например, до сих пор присутствует библиотека генерации HTML3.2.
Не нравится генерируемый код — пишите сами, чего инструмент обвинять?
Не нравится генерируемый код — пишите сами, чего инструмент обвинять?
Газеты пишут про какого-то Пастернака. Будто бы есть такой писатель. Ничего о нём я до сих пор не знал, никогда его книг не читал… это не писатель, а белогвардеец… я не читал Пастернака. Но знаю: в литературе без лягушек лучше
Мдаа, пост и правда холиварный, поэтому не буду говорить о том, что действительно лучше (ибо точного ответа нет), но повторю не раз указанный аргумент о том, что все притянуто за уши и очень субъективно.
Однако в посте чего только не приводят в пример. Ощущение, будто народ считает, что .NET — это закрытое сообщество исключительно с собственными технологиями, исключительно от MS, и те, кто используют .NET не знают ничего «об остальном мире технологий».
Так вот, я с этим в корне не согласен. Все, кто более менее долго работает с .NET прекрасно знают, что происходит вокруг и большая часть используемых технологий — это опен-сорс (Hello, ALT.NET).
Как можно назвать использование .NET с MySQL, MongoDB, Memcached, jQuery, NHaml итд, итп «закрытостью» и «Microsoft Way»?
К слову — .NET крут своей целостностью и всеобъемлемостью, а ASP.NET MVC — только одна из технологий. Каждый элемент в нем заменяемый, и если вам нужно MVC — вы не ограничены ASP.NET MVC ни в каком виде. И если хочется действительно крутых альтернатив, тут дело не в самой платформе — пример тому — действительно крутой FubuMVC.
Однако в посте чего только не приводят в пример. Ощущение, будто народ считает, что .NET — это закрытое сообщество исключительно с собственными технологиями, исключительно от MS, и те, кто используют .NET не знают ничего «об остальном мире технологий».
Так вот, я с этим в корне не согласен. Все, кто более менее долго работает с .NET прекрасно знают, что происходит вокруг и большая часть используемых технологий — это опен-сорс (Hello, ALT.NET).
Как можно назвать использование .NET с MySQL, MongoDB, Memcached, jQuery, NHaml итд, итп «закрытостью» и «Microsoft Way»?
К слову — .NET крут своей целостностью и всеобъемлемостью, а ASP.NET MVC — только одна из технологий. Каждый элемент в нем заменяемый, и если вам нужно MVC — вы не ограничены ASP.NET MVC ни в каком виде. И если хочется действительно крутых альтернатив, тут дело не в самой платформе — пример тому — действительно крутой FubuMVC.
Я всеми руками за ALT.NET и в наших проектах мы почти полностью исключали проприетарные библиотеки, но подобная активность в .NET ниже. Как это не печально но думаю fubuMVC как и MonoRails не станут мейнстримом.
Не думаю, что Rails покроет все наши нужды, но в контексте легких многопользовательских веб-приложений он идеален для нашей команды.
Не думаю, что Rails покроет все наши нужды, но в контексте легких многопользовательских веб-приложений он идеален для нашей команды.
«Как это не печально но думаю fubuMVC»
Это в любом случае, что, впрочем, не мешает его использовать.
«Не думаю, что Rails покроет все наши нужды, но в контексте легких многопользовательских веб-приложений он идеален для нашей команды.»
Ну вот в этом и дело — том, что вашей команде удобен Rails (и это хороший аргумент), и что именно вам почему-то не удобен .NET, а не в самом .NET.
Это в любом случае, что, впрочем, не мешает его использовать.
«Не думаю, что Rails покроет все наши нужды, но в контексте легких многопользовательских веб-приложений он идеален для нашей команды.»
Ну вот в этом и дело — том, что вашей команде удобен Rails (и это хороший аргумент), и что именно вам почему-то не удобен .NET, а не в самом .NET.
azakharov, Использовали вы IronRuby?
Я хотел с него начать. Но в силу отсутствия поддержку native code руби гемов это оказалось невозможным, так как для полноценного использования Ruby on Rails такие гемы есть.
Хочу попробывать IronRuby в контексте MonoTouch.
Хочу попробывать IronRuby в контексте MonoTouch.
«Я хотел с него начать. Но в силу отсутствия поддержку native code руби гемов это оказалось невозможным»
Сам не давно столкнулся на Windows с тем что гемы некоторые надо компилять. Есть такой проект rubyinstaller.org у них есть вот такая штуковина rubyinstaller.org/add-ons/devkit/ эта шутка позволяет компилировать гемы под Windows.
И еще у этого проекта есть еще пару полезных штук вот тут rubyinstaller.org/add-ons/
Сам не давно столкнулся на Windows с тем что гемы некоторые надо компилять. Есть такой проект rubyinstaller.org у них есть вот такая штуковина rubyinstaller.org/add-ons/devkit/ эта шутка позволяет компилировать гемы под Windows.
И еще у этого проекта есть еще пару полезных штук вот тут rubyinstaller.org/add-ons/
Также судьба IronRuby стала очень туманна после ухода Jimmy Schementi — blog.jimmy.schementi.com/
Пост ниочем но зато +76. Это Хабр, детка :)
Что-то мне это напоминает:
— Здравтвуйте. Меня зовут Алексей и несколько лет я плотно сидел на дот-нете.
— Здравствуй, Алексей (все одобряюще аплодируют). Молодец, что нашёл в себе силы завязать.
— Здравтвуйте. Меня зовут Алексей и несколько лет я плотно сидел на дот-нете.
— Здравствуй, Алексей (все одобряюще аплодируют). Молодец, что нашёл в себе силы завязать.
автору респект за смелость и поиски, надеюсь, когда-нибудь узнаем правду
Таки вывел свой холивар на всероссийский уровень? ;)
Молодец!
Аргументы вполне жизненные и понятные, на мой взгляд.
Единственный вопрос: как делался выбор между Руби и Питоном?
Молодец!
Аргументы вполне жизненные и понятные, на мой взгляд.
Единственный вопрос: как делался выбор между Руби и Питоном?
Я являюсь поклонником творчества 37 signals. Наверно поэтому при выборе между Django и Rails я выбрал Rails.
Всё это полная фигня, в этом я с adontz согласен. Всё намного проще.
ASP.NET очень хорошо подходит для корпоративного рынка. Свободные и открытые решения хорошо подходят для отдельно стоящих сайтов и веб-приложений.
Одна из причин кстати: многие корпоративные заказчики любят, чтобы вендор использовал стек технологий MS, в частности потому что код закрыт — опасаются что в открытом коде легко находятся уязвимости через которые можно хакнуть систему.
ASP.NET очень хорошо подходит для корпоративного рынка. Свободные и открытые решения хорошо подходят для отдельно стоящих сайтов и веб-приложений.
Одна из причин кстати: многие корпоративные заказчики любят, чтобы вендор использовал стек технологий MS, в частности потому что код закрыт — опасаются что в открытом коде легко находятся уязвимости через которые можно хакнуть систему.
Наши заказчики из США как раз наооборот хотят не .NET, так как им важно минимизировать затраты на поддежание проекта.
Может вот с этого и надо было начинать в посте. Написали бы вот так: «Заказчик против .Net. Пришлось перейти на Rails, оказалось, что там тоже все возможно.» Честно бы признались в причинах перехода, а не подымали holywar.
У большинства корпоративных клиентов из США запрет на open-source.
Просто потому, что если что-то сломается, засудить некого будет.
Поэтому дешевле компоненты какие-то купить, чем взять open-source library какую-нибудь. Тем более, что она может оказаться GPL, тогда вообще секир-башка…
Просто потому, что если что-то сломается, засудить некого будет.
Поэтому дешевле компоненты какие-то купить, чем взять open-source library какую-нибудь. Тем более, что она может оказаться GPL, тогда вообще секир-башка…
Наивно думать, что коммерческое закрытое (проприетарное) ПО в этом смысле даёт какие-то преимущества. Посмотрите повнимательнее лицензии такого ПО (от того же Microsoft, например), там обязательно есть раздел «Отказ от гарантий», в котором явно написано что-то вроде: «мы не несём никакой ответственности, если наше ПО нанесло вам какие-то убытки и иной ущерб, вы его используете на свой страх и риск».
Т.е., не смотря на закрытость и платность, гарантии такие же, как и у открытого ПО. А раз нет разницы, то зачем платить больше?
Т.е., не смотря на закрытость и платность, гарантии такие же, как и у открытого ПО. А раз нет разницы, то зачем платить больше?
Ну речь идет не столько о «засудить», сколько о технической поддержке, документации и всем, что называется коммерческий продукт.
Техническая поддержка — это отдельная коммерческая услуга, и она может одинаково существовать как для закрытых продуктов, так и для открытых.
Причём, в случае проприетарного производителя ПО есть монополия на поддержку (её предоставляет только компания-разработчик или иногда ещё дополнительно некие сертифицированные партнёры), а в случае открытого ПО ты волен сам выбирать любую компанию, которая его будет поддерживать, т.к. монополии нет.
Причём, в случае проприетарного производителя ПО есть монополия на поддержку (её предоставляет только компания-разработчик или иногда ещё дополнительно некие сертифицированные партнёры), а в случае открытого ПО ты волен сам выбирать любую компанию, которая его будет поддерживать, т.к. монополии нет.
Дело скорее не в закрытости, а в наличии технической поддержки. В корпорации не станут использовать библиотеки, у которых нет нормальной платной технической поддержки. А такая поддержка может быть только у крупных проектов, которые зачастую коммерческие и закрытые.
Фреймворки это круто. Но я, как системный программист (win), предпочитаю С++, ибо разрабатываемые мной системы практически всегда имеют высокие требования к производительности. Было время, писал на C#, остался категорически недоволен.
Большинство библиотек производительность которых критинчна написаны в руби на C.
У меня друг в Microsoft на спор писал на C# любой код, написанный на C++ который работал либо так же, либо быстрее.
Если простые примеры вроде перемножения матриц, то скорость может и будет одинаковой, но в при больших объемах кода C++ значительно быстрей в производительности чем C# (как вообщем и любой другой язык с ВМ и автосборкой мусора). Ну, к примеру весь серьезный GameDev — это C++, как впрочем и все, что связано со сложной 3d-графикой (CAD/CAM и т.д.).
CAD/CAE еще и на фортране встречается, как ни странно.
При всем его библиотечно-алгоритмическом наследии совсем не странно. Фортран еще и нас с вами переживет :-)
Он кстати еще и совершенствуется похоже. Интел даже компилятор для него поддерживает…
Я вам скажу больше--на всех суперкомпьютерах стоят только компиляторы C++ (gcc, icc), и фортрана. Никаких java/C#. В по-настоящему сложных расчетах нужно даже оптимизировать вызовы виртуальных функций, иначе производительность может сильно падать (sic!) (а мы в универе смеялись над старыми преподами, которые так говорили). Так что никаких GC.
Всегда надо понимать, что часть кода можно переписать на низкий уровень.
Ребята знакомые пишут игры на XNA (.NET), и на скорость не жалуются.
Ребята знакомые пишут игры на XNA (.NET), и на скорость не жалуются.
Попросите друга посоревноваться с Кармаком, например, пусть хотя бы часть движка id Tech на шарпе перепишет, что бы было как минимум не хуже. А то в векторы умножать да массивы сортировать много ума не нужно :)
То есть недовольство C# только из-за его скорости?
В таком случае мне интересно что думают C#/++ программисты про язык Vala live.gnome.org/Vala/ValaForCSharpProgrammers Производительность программ написанных на Vala приближается к чистому С.
В таком случае мне интересно что думают C#/++ программисты про язык Vala live.gnome.org/Vala/ValaForCSharpProgrammers Производительность программ написанных на Vala приближается к чистому С.
В конце статьи надо было добавить «Ваш К.О.»
Годный «вброс», у .net'чиков попаболь. С удовольствием почитаю продолжение, спасибо.
Razor-то вам чем не угодил?!
Ну не нравится он, используйте что-то другое - шаблоных фреймворков полно.
Ну не нравится он, используйте что-то другое - шаблоных фреймворков полно.
Холивар нынче измельчал. Мысль за пустыми картинками разглядеть можно, но примеры больше показывают непонимание ситуации, чем недостатки .NET. Самый главный момент так и не был озвучен — что вы пишите и для кого, какая бизнес-модель итд.
В 90% случаев уровень подготовки разработчика имеет бОльшее значение чем инструментарий. Почитайте вот
http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/. ROR это всего лишь инструмент.
В 90% случаев уровень подготовки разработчика имеет бОльшее значение чем инструментарий. Почитайте вот
http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/. ROR это всего лишь инструмент.
Сразу вспоминается короткометражка про MS vs Java :) Людям, которые увидели в 2010 уналог гемов и эггов(хотя питонорубипхпперлы это уже давно умеют) доказать что-то не получится, они пишут не веб приложения с обработкой 1000 запросов в секунду.
Хочешь поднять рейтинг, карму и заработать инвайт?
Выход есть: холиварный пост на тему перехода от технологии Microsoft!
Выход есть: холиварный пост на тему перехода от технологии Microsoft!
А почему на Java/Spring, все же ближе к .Net?
Разве что C#-код выполняется гораздо быстрее, чем Ruby, благодаря своей статической типизации.
Выбор технологии вещь субьективная и часто случайная.
Интереснее другое — четыре года работать в одной парадигме, а потом резко перевести команду на другие рельсы. Это от большого ума или за чужой счёт?
Я бы ещё понял если бы использовались две технологии и одна выжила а вторая нет, но такие резкие повороты могут повредить бизнесу.
Прочитал недостатки, подумал, что я, наверное, какой-то не тот dotnet использую.
Интереснее другое — четыре года работать в одной парадигме, а потом резко перевести команду на другие рельсы. Это от большого ума или за чужой счёт?
Я бы ещё понял если бы использовались две технологии и одна выжила а вторая нет, но такие резкие повороты могут повредить бизнесу.
Прочитал недостатки, подумал, что я, наверное, какой-то не тот dotnet использую.
Razor, как мне кажется, не вместо haml, а вместо erb. Все-таки haml нравится не всем (хотя мне вот нравится =)), и встраивать его в сам ASP.NET MVC не стоит.
И вообще есть nhaml (http://github.com/NHaml/NHaml).
И вообще есть nhaml (http://github.com/NHaml/NHaml).
Даешь подробные статьи ASP.NET MVC vs RoR…
Включая:
1) Обзор сопутствующий сред разработки (refactoring, WYSIWIG-editors, debugging).
2) Обзор библиотек доступа к БД (Linq 2 SQL vs ActiveRecord), производительности DB драйверов (Oracle, MSSQL).
3) Обзор технологий масштабирования, fail-over, app recycling, cold-start, app monitoring и прочие вкусности.
4) Обзор технологий WS*-web-сервисов, а также RESTful сервисов.
Ждем-с
Включая:
1) Обзор сопутствующий сред разработки (refactoring, WYSIWIG-editors, debugging).
2) Обзор библиотек доступа к БД (Linq 2 SQL vs ActiveRecord), производительности DB драйверов (Oracle, MSSQL).
3) Обзор технологий масштабирования, fail-over, app recycling, cold-start, app monitoring и прочие вкусности.
4) Обзор технологий WS*-web-сервисов, а также RESTful сервисов.
Ждем-с
А wysiwig-editors-то вам в веб-разработке зачем?
Мне это напомнило высказывание, что то вроде «любой пишущий 'hello world' на Java через некоторое время обнаруживает себя разрабатывающим ERP систему».
У меня есть подозрение, что некоторые разработчики сами любят раздувать сложность и важность своих веб проектов, видимо стыдно что ли признать себе, что делают банальные сайты, а хочется делать вундервафли.
У меня есть подозрение, что некоторые разработчики сами любят раздувать сложность и важность своих веб проектов, видимо стыдно что ли признать себе, что делают банальные сайты, а хочется делать вундервафли.
«Обзор библиотек доступа к БД (Linq 2 SQL vs ActiveRecord)»
Ну это неправильная формулировка «vs». Тут нет никакого versus. В .NET флагман по части Data Access — NHibernate, а за ним — Entity Framework. И есть Active Record, в виде NHibernate и SubSonic.
Ну это неправильная формулировка «vs». Тут нет никакого versus. В .NET флагман по части Data Access — NHibernate, а за ним — Entity Framework. И есть Active Record, в виде NHibernate и SubSonic.
Пусть этот .NET «флагман» сначала на .NET 4.0 перейдет и от Eisy.Collections избавится, тогда и поговорим…
В NHibernate достаточно архаизмов, включая Criteria API, а также наличие XML-конфигурации (давно должны быть только Fluent-интерфейсы), но это нисколько не умаляет его проверенности, надежности и мощности. Там предусмотрено все, что необходимо, и ни одна (за редким исключением) ORM на .NET не предлагает такой гибкости.
Что касается «редкого исключения» — приходилось использовать MindScape LightSpeed — так вот это Вещь, если уж говорить о настоящих флагманах. Но, к сожалению, очень сильно не бесплатная.
Что касается «редкого исключения» — приходилось использовать MindScape LightSpeed — так вот это Вещь, если уж говорить о настоящих флагманах. Но, к сожалению, очень сильно не бесплатная.
Да, а баги полугодичной давности как были, так и остались…
Даже пожаловаться некому, ведь бесплатное всё, никто никому ничего не должен.
Фиксить баг или нет решает средний палец на правой ноги координатора проекта.
(Вот так NHibernate и пролетем мимо нас — полгода багфикс подождали, плюнули и выкинули)
Даже пожаловаться некому, ведь бесплатное всё, никто никому ничего не должен.
Фиксить баг или нет решает средний палец на правой ноги координатора проекта.
(Вот так NHibernate и пролетем мимо нас — полгода багфикс подождали, плюнули и выкинули)
Напишите в будущих материалах о том насколько больше (или может быть меньше) денег ваша фирма стала зарабатывать после перехода на другую технологию. Только хотелось бы чтобы это было ретроспективное детальное сравнение. Не только про то что теперь вы не платите за средства разработки и ОС но и про то как у вас изменилась скорость разработки и затраты на поддержку.
Ууух сколько тут анальных рабов Microsoft.
На мой взгляд нельзя сравнивать Ruby on Rails и ASP.NET MVC. Работая в гос. конторе, либо большой корпорации вы бы узнали тайну, почему все бизнес приложения пишутся на решениях от Microsoft, как не печально, но большинство продуктов пишется для «галочки», ради никому не нужного внедрения «новый технологий», получения откатов и тд. Такова участь платиновых партнеров, им приходится внедрять у себя бизнес талк и тд. Поэтому ваши аргументы, я думаю, нацелены на пустоту. На руби-он-рэилс я бы писал чтобы сохранить деньги компании и ускорить разработку, но если от программиста требуется другая задача, если он должен поднять стоимость проекта?=)
Искренне надеюсь эта статья повлияет на ваших коллег! Хватит быть рабом корпорации
Не совсем понял кто чей раб, ну да ладно, вы похоже не видите текста, или не хотите видеть. Люди деньги на этом делают огромные, ДЕНЬГИ, понимаете?
Кто делает? программист, который пишет на .NET?
Директора, начальники, программист же работает на том, на чем ему скажут. Требуется внедрить какую-то технологию, пусть даже устаревшую как мир, например ASP, программист делает.
Конечно это отвратительно, при таких условиях создать чтото хорошее и успешное крайне невероятно(
I have also seen on numerous occasions developers build their own libraries and frameworks to solve well understood problems in curiously terrible ways.
Извиняюсь, нечаянный сабмит. Скажите, автор, вы просто перевели этот пост? Набор аргументов тот же самый.
Странно, что в статье нет ни одного слова про Mono, а ведь две причины из трёх он убирает по опредлению, да и не просто тупо реализуют интерфейсы MS, а миграция была бы куда проще.
А вообще было бы интересно увидеть не только «почему RoR, а не ASP .NET MVC», но и «почему именно RoR, а не Django/Pylons/.../Symfony/Zend/...». Раз уж вы серьёзно анализировали альтернативные открытые решения, то результаты, думаю, были бы интересны очень многим.
А вообще было бы интересно увидеть не только «почему RoR, а не ASP .NET MVC», но и «почему именно RoR, а не Django/Pylons/.../Symfony/Zend/...». Раз уж вы серьёзно анализировали альтернативные открытые решения, то результаты, думаю, были бы интересны очень многим.
>>Подобная тенденция наблюдается и у рядовых разработчиков .NET. Все они без исключения пишут свои фреймворки аутентификации, авторизации, в ручную реализуют управления жизненным циклом сессии в БД
Э… А вы точно с .net знакомы?
Э… А вы точно с .net знакомы?
А давайте ка лучше начнем статью с начала.
НЕ о том какая платформа.нет редиска.
А о том, как ВЫ начали новый проект на роре и какой Вы получили профит от нее.
И какой получили бы, если был бы проект на.нет'е.
НЕ о том какая платформа.нет редиска.
А о том, как ВЫ начали новый проект на роре и какой Вы получили профит от нее.
И какой получили бы, если был бы проект на.нет'е.
Года через два предвижу статью от того же автора: Big Switch II или жизнь после Ruby on Rails.
Простите мое личное мнение — аргументы попахивают притянутостью за уши.
По одной простой причине — под каждую задачу надо выбирать СВОИ инструменты.
Говорю, как человек прошедший с начала 2000х годов путь от инженера техподдержки рабочих станций до архитектора нескольких ИТ инфраструктур малого бизнеса и .Net программист с конца 2012.
Да, как человек, который с 2007 года знает и умеет готовить Linux/FreeBSD, и прошедший путь от инженера технической поддержки Ukr.Net и Freehost.ua до хостмастера сейчас на двух небольших проектах — я сейчас тоже делаю проект на Rails.
Так вот, на .Net у меня до недавнего времени жила и работала небольшая веббухгалтерия — демо проект, котторый можно было показать клиенту — чего я могу и умею, я в ней вел свои доходы, расходы.
Уйдя работать хостмастером в хостинги я мог бы как Селектел, написать свою панель управления юникс хостингом на дотнете, но ЗАЧЕМ?
Я попытался освоить питон и джанго — мне не подошло, писать на перле — можно, но оказалось, что проще взять Rails.
Но при этом я сейчас включу десктоп, открою студию и буду дописывать клиенту проект на сишарпе.
Я вижу свои плюшки в .Net, как и свои минусы, тоже самое могу сказать про RoR и Perl + Mojolicious, как те вещи, которые лично трогал и изучал
Я на самом деле, хочу донести мысль о том, что у всего есть свою плюсы и минусы, и это мифическое «всё» не было и не будет золотой пулей — ни рельсы, ни дотнет, ни жава с питоном, и через 5 лет о том же го — тоже могут вспоминать как «о боже, что это было?!»
По одной простой причине — под каждую задачу надо выбирать СВОИ инструменты.
Говорю, как человек прошедший с начала 2000х годов путь от инженера техподдержки рабочих станций до архитектора нескольких ИТ инфраструктур малого бизнеса и .Net программист с конца 2012.
Да, как человек, который с 2007 года знает и умеет готовить Linux/FreeBSD, и прошедший путь от инженера технической поддержки Ukr.Net и Freehost.ua до хостмастера сейчас на двух небольших проектах — я сейчас тоже делаю проект на Rails.
Так вот, на .Net у меня до недавнего времени жила и работала небольшая веббухгалтерия — демо проект, котторый можно было показать клиенту — чего я могу и умею, я в ней вел свои доходы, расходы.
Уйдя работать хостмастером в хостинги я мог бы как Селектел, написать свою панель управления юникс хостингом на дотнете, но ЗАЧЕМ?
Я попытался освоить питон и джанго — мне не подошло, писать на перле — можно, но оказалось, что проще взять Rails.
Но при этом я сейчас включу десктоп, открою студию и буду дописывать клиенту проект на сишарпе.
Я вижу свои плюшки в .Net, как и свои минусы, тоже самое могу сказать про RoR и Perl + Mojolicious, как те вещи, которые лично трогал и изучал
Я на самом деле, хочу донести мысль о том, что у всего есть свою плюсы и минусы, и это мифическое «всё» не было и не будет золотой пулей — ни рельсы, ни дотнет, ни жава с питоном, и через 5 лет о том же го — тоже могут вспоминать как «о боже, что это было?!»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Big switch или жизнь после Microsoft: Почему мы сказали .NET'у нет