Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Archive for the ‘Development’ Category

Мысли об облачных IDE

6 комментариев

Мне кажется что никто на сегодняшний день не понимает, что такое облачные IDE. Если посмотреть на то, что люди реально пишут, получается у них следующее

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

  • Возможность сразу использовать 100500 языков, т.к. все компиляторы уже установлены и настроены. (Только в большинстве случаев разработчик использует один язык, но выбор – это все равно хорошо.)

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

  • Коллаборативные возможности вроди sharing (a la GitHub Gist), ветвления (как в IdeOne) и прочие возможности, которые являются фактически source control-ом.

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

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

  • Поддержка тестирования — хочется иметь возможность запускать вагон тестов и фактически использовать серверную часть не только для continuous integration (это слишком просто), но именно для continuous testing в стиле NCrunch и подобных

  • Поддержка профилирования — это проще чем отладка и в принципе должно быть как-то реализуемо.

  • Поддержка деплоймента — чтобы готовые приложения сами разворачивались, клались в NuGet, и все такое

  • Поддержка мониторинга — раз уж на то пошло, почему бы не мониторить приложения и выдавать статистику по ним? Кстати, именно это уже делается в VS Monaco/Azure.

Основная проблема с Cloud IDE – это то что все забыли зачем облако. То есть облака рассматриваются как «социальный дропбокс», хотя на самом деле, облако – это место где хорошо масштабируются ресурсы. Зачем нужны ресурсы?

  • Во-первых, на (общих) серверах можно ставить более серьезное железо. Если учесть что разработчики для всех целей кроме CI не используют все мощности компа постоянно, покупка 32-процессорных систем с FusionIO и прочими вещами уже не кажется такой страшной.

  • Многие вещи параллелизуются. Например компиляция. Я уже какой год использую IncrediBuild вместо встроенного MSBuild. В облаке можно отмасштабировать компиляцию пропорционально размеру проекта.

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

  • Тестовое покрытие (code coverage) – тоже штука дорогая и в принципе на него можно выделать машины побыстрее.

Думаю идея понятна – эластичный рост облака до объема задачи позволит разработчику получать больше информации о своих наработках, и получать эту информацию быстрее (и в идеале – непрервыно). Но самое интересное я оставил напоследок, а именно:

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

  • Перекрестный анализ проектов на предмет использования того или иного API. Мне почему-то кажется, что modus operandi взаимодействия с типовой библиотекой «шаблонизируется», и тем самым может быть использован для предоставляния пользователю более умных подсказок.

  • Можно использовать специализированное железо (например Xeon Phi) – возможность, которая недоступна большинству разработчиков ввиду дороговизны а также невозможности втиснуть такую карту в типичный MBP. (В теории, можно строить специализированное железо для ускорения задач программирования, но боюсь индустрия на такое не способна – не хватает кругозора и понимания вещей.)

Я надеюсь что рано или поздно можно будет использовать эти и другие возможности в облаках и на кластерах тоже. Когда – понятия не имею. Но мысли пока вот такие. А как еще можно использовать облако для разработки? Напишите в комментариях. ■

Реклама

Written by Dmitri

10 марта 2014 at 23:23

Опубликовано в Development

Tagged with , , , ,

Распределенная разработка и проект FreeSpace

13 комментариев

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

С чего все начиналось

Когда я обитал в сфере финансового программирования (было же такое), одна из задач была в том, чтобы “сливать” воедино финансовые показатели из различных источников. Начиналось все достаточно просто – берем какую-то котировку, делаем для нее квантизацию (это когда нужно подсчитать агрегированные значения за последнюю минуту/час/день и т.п.) а потом начинаем считать всякие показатели (к пр. движимое среднее). Сейчас такие задачи делаются с помощью Reactive Extensions, под которым, должен сказать, аггрегаторы и квантизаторы выглядят не лучшим образом. Тогда же это делалось более примитивными методами. Но не суть…

Так вот, в те времена подход GPGPU был не ахти какой популярный, и соответственно все утыкалось в слабый перформанс моего одноядерного процессора. И, естественным путем, я набрел на то, что по-хорошему нужно использовать несколько машин чтобы все эффективно считать. Механизмы общения между компьютерами в те времены были ни ахти какие, соответственно использовались такие извращения как NServiceBus/MSMQ которые, конечно, имеют свои приемущества, но все же “не айс”.

Самым прикольным было написать консоль, которая показывала бы как моя сеть в realtime обсчитывала те или иные показатели. Более того, в те времена я также использовал нейронные сети (MLPs w/backpropagation) и у меня даже остался код, которые по объектным моделям сетей генерировал диаграммы в PowerPoint. Забавное было зрелище.

Сети – это же так соблазнительно!

Качество работы на среднестатистической “винде” прогрессивно снижается. Когда я начинал программировать на Visual Studio 97, в моем компьютере было 16Мб (мегабайт!!!) RAM, но при этом все работало. Сейчас такой experience можно получить разве что скачав EVC++ 4 (завидую эмбедщикам!). У нас же в плане разработки все плохо – сплошные тормоза. Вон только вчера коллега рассказал, что получил удовольствие от использования Visual Studio 2008 для части ReSharper SDK. Когда я его спросил что у него за машина, оказалось что и 16Gb RAM и SSD у него присутствуют. Так что делаем выводы…

Все это наводит на достаточно печальные мысли. Компьютеры будут становиться быстрее, но “затыки” в производительности будут, и со временем они будут все больше и больше. А нам нужно разрабатывать, а не ждать 15 минут пока полсотни референсов в проект добавятся (таргет-файлы рулят!).

Поэтому единственная вменяемая стратегия, к которой я на данный момент пришел сводится к следующим вещам.

Во-первых, я ратую за экологичное программирование, т.е. если вы используете машину для разработки, не стоит на ней ставить доменный контроллер, IIS, AppFabric и еще 100500 различных сервисных примочек. Ни в коем случае не стоит ставить серверные технологии которые используют SQL Server т.к. эта штука сама по себе съест 1-2Gb оперативки, так она еще и будет диск дергать даже когда никто к ней не обращается. А потом, в один прекрасный день, вы увидите что вместо того чтобы разрабатывать, вы думаете как бы засунуть SQL Server’ный кэш в RAM. Или что-то в этом духе.

Во-вторых, я за распределенную разработку. Писать код можно и на одном компьютере. Но держите свои затраты к минимуму. Ставьте десктопную ось (да-да, сейчас модно ставить 2008R2 везде где не попадя, я тоже на это попался в свое время). Если можете себе это позволить – ставьте XP. Windows, VS и ReSharper/dotTrace/dotCover/TortoiseXxx – плагины, естественно по вкусу. Остальное – в топку! А точнее на другой компьютер.

Что это дает?

Я уже слышу крики в стиле “мне всего и так хватает!”. Что же, если вам итак хорошо, рад за вас. Это как извечная дискуссия про мониторы – каждому свое. Но если говорить о приемуществах такого подхода, то их масса.

Главное приемущество – это моментальный фидбэк. Представьте, что у вас есть солюшн который собирается, скажем, две минуты. Две минуты – это вечность. Особенно если билд провалился с какой-то дурацкой ошибкой которую не отловил статический анализатор. Да, мы говорим не про простенькие проектики, мы говорим например про системы где смешан С++ (адски медленная компиляция), C# и Java (да-да, Java – она примешана тут осознанно). Если учесть сложность cross-VM конфигов, все это дело работает не так быстро как хотелось бы.

Так вот, представьте себе систему, где фидбэк по сборке, тестам, и даже покрытию (хотя с покрытием сложнее) получается моментально. Причем он никак не затрагивает ваш разработческий комп, т.к. мы договорились держать его стерильным. Моментальный фидбэк стоит многого! Особенно это затрагивает такую проблему как тестирование на staging-серверах. На Хабре был пост про то, надо ли стабить репозитарии. Так вот что я думаю – если вы можете себе это позволить, тестируйте на staging-базах! Главное чтобы эти тесты не вызывали затыков. А если вызывает затыки – просто добавьте воды машин!

Второе приемущество – это то, что ничего не отвлекает. Я категорически против подхода, когда люди в свою Студию устанавливают 1000 различных дополнений для всяких микро-фич которые, особенно если они используют визуальные элементы, тормозят все до такого состояния, что работать невозможно. Но я не столько про стороннии фичи говорю, сколько про два основных источника потери времени – компиляцию и тестирование. Давайте обсудим их более детально.

Компиляция

Разработчики С++ уже давно поняли что сборка проектов должна быть распределенной, и на рынке есть для этого соответствующие решения. Но если вы думаете, что в .Net все лучше, то вы правы только отчасти. Да, .Net собирается быстрее, хотя я уверен что новый C#5 компилятор будет намного медленнее в силу своей managed структуры. Опять же, еще один аргумент в том, что де нынче MSBuild поддерживает параллелизацию напрямую, и тем самым грамотное использование MSBuild вместе с правильной, loosely coupled архитектурой, как бы избавляет нас от проблем с медленной компиляцией.

А вот и нет!

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

Во-вторых, этот аргумент не применим на mixed-mode проектах. С++ играет по своим правилам, особенно если вы делаете что-то сложное. Да, ваша сборка может скомпилироваться параллельно с другими. Но это не покрывает изначальную проблему – она скомпилируется медленно. Это, кстати, влияет не только на С++ — даже тот же F# компилируется медленнее (что понятно), не говоря уже про языки вроде Scala (reminder: Scala компилируется в 10 раз медленнее Java).

В третьих, все как-то забыли что некоторым проектам нужно собирать несколько конфигураций. В этом случае параллелизация на уровне конфигураций имеет смысл – тут мы билдим staging, а тут – production. Естественно, никто не мешает настроить разные конфигурации на разных build-системах. Действительно, на практике многие разработчики используют TeamCity для параллелизации подобных задач. Одна из самых популярных – параллелизация тестирования. Кстати о нем…

Тестирование

Тестирование бывает разным. Одно дело когда вы нажали F5 на проекте, который открывает VS в дебаг-режиме. Если у вас комп с 4Gb RAM и Раптором – вы попали. Можете смело идти за кофе/чаем/печеньками. Отладочный экспириенс будет адским. Да – и не думайте что удаленная отладка вам поможет. Во-первых, вы замахаетесь ее настраивать (у меня на это полдня ушло), но даже настроив, вы сразу поймете, что игра не стоит свеч – идея неплохая, но скорость – улиточная. Snail speed. Если действительно хочется делать отладку на другой машине, более вменяемым решением мне лично кажется использование VMWare Workstation. Но так или иначе, тормоза будут.

Но я сейчас немного не про это, а скорее про банальное unit/integration-тестирование. Сейчас в этой сфере ведется работы по разным направлениям – например работы связанные с автопрогоном только тех тестов, которые были затронуты изменениями в коде. Примеры таких программ – NCrunch и Mighty Moose. А теперь угадайте, какой основной смысл этих программ? Правильно – экономия ресурсов. Вызывать только те тесты которые были затронуты. А не все подряд.

На самом деле, это очень сложная задача. В чем проблема вызова абсолютно всех тестов? Правильно, в том, что эти тесты могут задевать сотню различных систем. Да-да, я не только про юнит-тесты говорю, но и про интеграционные тесты – включая те, которые например дергают реальные базы или устройства. Их-то тоже хочется тестировать, причем опять же вопрос ставится так: если мы можем тестировать постоянно – почему бы не делать это? Лично я – ярый сторонник непрервыного тестирования. И не только по комиту – а например по любому компилу. Сделал тестовую сборку – она сразу же ушла в тестирование. Если что упало – результаты сразу же возвращаются к разработчику.

Так что там про FreeSpace?

FreeSpace – это мое новое детище. FreeSpace – это Windows-сервис который можно устанавливать на любые машины где угодно. Фактически, этот сервис объединяет машины в ботнет, который умеет заниматься распределенной компиляцией, тестированием, развертыванием, и так далее. FreeSpace работает как на реальных так и на виртуальных машинах, неприхотлив (дружит с ХР) и требует минимальное кол-во конфигурирования.

FreeSpace использует XMPP (в частности – библиотеку MatriX) и механизмы облачной синхронизации файлов. XMPP гарантирует что машины могут беспрепятственно коммуницировать между собой, при условии что у вас стоит XMPP-сервер (поставить какой-нть ejabberd занимает полминуты). А механизмы облачной синхронизации позволяют гарантировать, что на всех инстансах одни и те же файлы. Поскольку сервис работает через MEF, файлы можно обновлять динамически.

Основная цель FreeSpace – балансировка нагрузки, т.е. составление сбалансированных планов исполнения. Собственно выполнение задач на себя берут уже готовые тулзы. Для компиляции, например, это может быть MSBuild, для тестирования – Gallio. Суть в том, что имея информацию о всех нодах в сети, а также агентах на этих нодах (на одной ноде можно бегать более одного агента), можно сформировать сбалансированный план компиляции или тестирования, который оптимально использует все доступные ресурсы и при этом уважает предпочтения самого нода, т.е. знает что нельзя перегружать нод, который уже занят или имеет какие-то другие обязанности.

Одно из приемуществ FreeSpace – системе полностью плевать на домены. Синхронизация через XMPP способна игнорировать все firewall’ы и протаскивать трафик через порт 80, если это надо (ну, это теоретически… это нужно тестировать). При этом трафик можно шифровать, так что идея о том что де кто-то украдет контрольные данные в транзите или подменит их тоже отпадает. А сами файлы синхронизуются с помощью изначально безопасной системы (так по крайней мере нам говорят), поэтому кроме как на нодах к ним не достучаться. И даже достучавшись, система-то распределенная, так что всей картины все равно не получите – хотя конечно подразумевается, что нодам вы доверяете.

Более сложные задачи

Есть более сложные задачи, которые пока не решить ну никак. Во-первых, было бы здорово вынести за пределы компьютера разработчика весь статический анализ и сделать некий ‘FxCop/R#/whatever as a service’. Если это сделать, и если это хоть как-то параллелизуемо (есть подозрение что не очень), это позволит делать намного более глубокий/затратный анализ и тем самым получать намного более умные эвристические подсказки.

Покрытие – запредельно затратная операция, поэтому вынести его наружу тоже хотелось бы. Это, правда, менее приоритетная задача, т.к. я не большой фанат покрытия. Но с другой стороны, имея уже готовый механизм для измерения покрытия (к пр., dotCover), я не вижу никаких причин не применять измерение покрытия, скажем, к разным тестовым фиксчам на разных машинах. Главное чтобы можно было слить все результаты воедино и как-то их продемонстрировать. (Прошу заметить, что в отличии от результатов тестирования, результаты покрытия таки требуют наличие локальной Visual Studio для подсветки и навигации. То же отчасти верно и для обычного юнит-тестирования, хотя там и не нужно вклиниваться в редактор.)

Зато что я люблю так это всякий спекулятивный процессинг. Я бы с удовольствием воспользовался, например, механизмами мутационного тестирования. Ну или например я бы с радостью гонял тесты на производительность параллельных алгоритмов варьируя разные параметры, такие как, к примеру, degree of parallelism.

Вместо заключения

FreeSpace разрабатывается в первую очередь не как коммерческий продукт, а как система, которая сможет, при наличии достаточного количества машин, существенно сэкономить количество времени, требуемое для работы с крупными проектами. Соответственно, пишу я ее в основном для себя, с уклоном в те проблемы (например, тестирование в виртуальной среде – VMM/HyperV) которые являются для меня наиболее насущными.

Я давно не писал в этот блог, но теперь буду писать почаще, особенно если кому-то данная тема покажется интересной. И естественно, я выпущу дистрибутив системы как только у меня будет что релизить. Основной concern в данном случае в том, что я очень хочу сделать систему обновляемой, чтобы она и ее плагины (я использую плагин-архитектуру на основе MEF) могли автоматически обновляться по мере выхода новых версий.

А пока всё! Comments welcome! ■

Written by Dmitri

16 июня 2011 at 23:00

Опубликовано в .NET, Computation, Development

Tagged with ,

Microsoft, инновации и откровенный флейм

54 комментария

Учитывая то количество флейма которое летит в направлении Microsoft/.Net разработчиков, тот пост что я пишу сейчас надо было написать уже давно, дабы попробовать объяснить всем кому интересно чем же .Net стек так привлекателен и что в нем не так. Следуя традициям spbalt.net, попробую осветить проблему с обеих сторон. Если что – комментируйте, буду рад.

Фанатизм Microsoft

Для начала, лучше всего сразу отсекать фанатиков. Предлагаю сделать это первым же абзацем дабы потом не фокусировать на них внимание. Да, существуют фанатики, причем как анти-Microsoft так и pro-Microsoft. Обе группы не несут в себе какого-то адеквата и трезвой аргументации. Я не знаю какая демографика этих групп, но подозреваю что не слишком-то зрелая там аудитория. Зрелая аудитория по крайней мере пытается преставлять хоть какие-то аргументы, и даже если они иногда выглядят как сравнение яблок с апельсинами, это лучше чем ничего.

Интересно было посмотреть на весьма смелый (зная Хабр) пост Александра Ложечкина. Не знаю, ожидал ли он такой флейм или нет, но мне кажется все равно его пост достиг нужной аудитории, и донес до нее главную информацию. Кричали, конечно, различные критики в силу возможности. Первый комментарий (с рейтингом -51) показывает относительную адекватность Хабрапользователя:

Позовите, когда мы сможем попрощаться с Вами вообще.

Комментариев к такому у меня, увы, нет. Интересно что его оставил далеко не самый последний (по рейтингу) пользователь.

Языки – Java vs. C# и аналогичные флеймы

Окей, у меня блог посвященный C# поэтому тут можно обвинить меня в предвзятости. Нет, я не буду пропагандировать C# или сравнивать его, например, с Java потому что подобные действия имеют свойство очень быстро вырождаться в откровенный флейм со стороны MS- и Java- сообществ. Единственное, что я могу сказать насчет языков так это то, что (имхо) C# является фундаментальным мотиватором изучения платформы .Net начинающими разработчиками. Этот язык сложно критиковать, в то время как к любому другому языку можно предъявить море претензий на тему “современности” и т.п. Это не значит что C# кардинально лучше, т.к. понятие “лучше” само по себе ничего не значит – “интереснее”, “прибыльнее” – это уже более адекватные эпитеты. В этом же ключе можно говорить и про распостраненность, цитируемость, и т.п. Де факто, любой язык – даже COBOL – в правильных руках позволит решать задачи, и метрики показывают что за исключением Ассемблера, производительность разработчиков с разными языками для аналогичных тасков примерно одинакова. Но если учитывать что мы не сферических коней в вакууме строим а решаем бизнес-задачи, более корректны (имхо) сравнения на уровне платформ. И то, каждое сравнение автоматически вырождается в флейм. Может не стоит?

К слову хочу заметить что, несмотря на то что Microsoft поспособствовала выпуску ряда альтернативных языков для платформы .Net, их прием в качестве рабочих лошадок заказчиками был и остается минимален. Причины? А вы представьте себя на стороне заказчика – какой проект лучше потом поддерживать, тот что на C# или тот что на IronRuby? Более того, использование не-C# языков очень сложно аргументировать. Иначе говоря, если аргументировать использование Scala вместо Java достаточно просто (в силу “мощности” языка), то аргументировать использование F# вместо C# – значит напирать на “функциональность”, немутабельность, async workflows и т.п. Иначе говоря, на те вещи которые реализуются на C# без каких-то громадных трудозатрат. Например, на C# проще простого сделать immutable структуру, да еще и тест написать который проверяет ее “немутабельность”.

В заключение о языках хочу добавить что единственная фича, которая нужна в C# – это статическое метапрограммирование. И оно у нас будет. А все кто считает что Ruby лучше как раз из-за возможностей метапрограммирования которые “я получу уже сегодня” занимаются сравнением яблок и апельсинов, т.к. метапрограммирование в Ruby динамическое. Нечестное, как мне кажется, сравнение.

Незрелость библиотек и MVC vs. Rails

Окей. Да, в каком-то смысле .Net играет в догонялки с той же Java в тех областях где эти платформы имеют общие требования. Люди очень любят приводить пример с “рельсами” которые якобы копируют авторы Asp.Net MVC. Меня всегда итересовало – что мотивирует людей делать такие обзоры и сравнения когда мы живем, собственно, в эпоху свободы выбора, когда вместо того чтобы тупо читать что А лучше B я скорее скачаю и сам попробую и А и В.

Вообще сравнивать библиотеки – это дело неблагодарное. Сравнивать фреймворки – это да, это уже как-то актуальнее. Но кто хочет, например, сравнить Swing и WinForms/WPF? Нет желающих? Опять же, очень глупо катить бочку против Microsoft когда в плане презентационных фреймворков для десктоп-приложений не так уж и многа выбора. Я конечно все понимаю, и как сказал Ринат Абдуллин “Россия это страна где еще на Delphi пишут”, но серьезно… какие варианты быстрого (да-да, быстрого и качественного) построения интерфейсов thick-client знаете вы?

Вот другое дело web – тут как бы технология общая (HTML), и бороться за нее не надо, т.к. она не проприетарная. Тем самым можно сказать что используете вы Rails или MVC или PHP – это не так критично т.к. и там и там можно получить идентичный результат. Мне кажется что сам спор веб-фреймворков также бессмысленнен в связи с тем, что вне зависимости от ваших предпочтений уже есть хорошие платформы для построения решений, ничего не надо писать “с нуля”, можно просто кастомизировать. Сказать что А лучше В тут сложно – да, есть разница в зрелости фреймворков, но посмотрите вокруг – люди поставляют решения даже на сырых платформах. И что – работает!

Про стоимость лицензий

Вообще меня удручает подход разработчиков которые считают что все должно быть FOSS (бесплатно и open-source). Это абсолютно ущербный подход, т.к. если мне, например, перестанут платить за производство решений, то… я тупо перестану что-либо производить и уйду в другую область. Идея о том что можно получать бесплатно все что нужно для разработки породило такие решения как NHibernate (действительно the linux way – если что нужно, берите лобзик и допиливайте) или, например, тот же SharpDevelop. Я не имею ничего против, но когда у вас есть IDE без вменяемой отладки – это не IDE. Поэтому коммерческие решения нам нужны как воздух.

Очень много разговоров идет про стоимость лицензирования, про то что BizSpark это маркетинговая уловка, про то что сложно оплатить N лицензий, там, Windows или SQL Server. Если честно, эта дискуссия тоже уже устарела. Например, корпоративный сектор, который очень хорошо умеет считать деньги, с удовольствием использует ПО от Microsoft, и оно входит в его бюджеты. То есть сказать, что Windows – дорого, значит ничего не сказать.

Да, конечно, хорошо когда все бесплатно. И с моей стороны достаточно лицемерно говорить про стоимость лицензий когда я использую ПО по программам MVP и BizSpark. Но несмотря на это, те заказчики с которыми мы работаем с удовольствием приобретают ПО от Microsoft – с другой стороны, у многих из них стоит и Linux/Java. И вот что я вам скажу – они довольны и тем и тем. Поэтому говорить что что-то кардинально лучше – некорректно. И я не буду тут писать про то, насколько стоимость ПО ничтожна по сравнению со стоимостью разработки кастомных решений, ибо вы все итак уже знаете.

Инновации, смерть SQL, и т.п.

Для многих, Microsoft, ‘enterprise и консерватизм – это слова из одной ипостаси (люблю это слово). Поэтому многим видится консервативная компания которая по-тихоньку удовлетворяет и пьет кровь большого бизнеса, не очень-то обращая внимание на малый. Тем самым, сравнивая деательность Apple и Microsoft, например, обыватель может достаточно справедливо сказать что у Apple все как-то поинтересней – по крайней мере с точки зрения продуктов.

Увы, в плане разработки под различные платформы ситуация действительно не очень внушающая – посудите сами, что сейчас выгодней – разработывать для iOS или WinMobile? (или Android?) Ну а desktop-приложения для Windows сейчас создавать бессмысленно т.к. рынок перенасыщен уже давно, да и нет какого-то “уютного магазинчика” для всего этого добра.

Впрочем, в плане веба инноваций тоже как-то маловато. Да, Asp.Net MVC это небольшой шажок вперед, но если посмотреть на другие новые проекты (например Node.js), начинаешь понимать что речь идет о разных уровнях инноваций. В одном случае, это действительно свежии, новаторские идеи. В другом, эволюция существующих идей (например WebFormsViewEngine --> Razor), которая является чем-то ожидаемо-предсказуемым. Совершенно разные вещи. Так что в этом плане я с критиками согласен – инновационность, по крайней мере для разработки в стеке .Net определенно страдает. Есть конечно интересные вещи (Rx, StreamInsight) но их мало и кардинально они мозг не выносят.

Насчет NoSQL и SQL Server

В принципе, таким заголовком можно открыть флейм на тему SQL Server vs. NoSQL, где одни будут предрекать падение платформы SQL Server а другие указывать на то, что понадобятся годы чтобы реализовать SSxS на MongoDB или аналогичных системах.

Очень сложно спорить с тем, что при всех наработках платформы, SQL Server капитально проигрывает в производительности, масштабируемости, а также платформной зависимости. И еще, вы уж извините, но в стоимости он проигрывает тоже – да, я знаю что ранее я написал что стоимость некритична в общем случае, но так уж получилось, что суть хранилищ данных – это большие объемы а следовательно большое количество ядер. Лицензирование SQL Server в этом плане оставляет желать лучшего. Не знаю, может есть скидки когда инстансов много?

Тема NoSQL и то как она повлияет на стек .Net очень интересна. В принципе, уже понятно что binding’и на NoSQL базы есть и будут, поэтому существенные причины уходить с .Net неактуальны пока вы не решите уйти с Windows. Могу по себе сказать, что мои личные проекты связанные с web mining медленно перекачивают на MongoDB. Что касаеться “продакшн”, то тут я как и все буду осторожничать. Так или иначе, лично мне занятие MongoDB кажется актуальной стратегией для развития – даже более актуальной чем наращивание компетенций в Windows Azure.

Comments welcome.

Written by Dmitri

21 июля 2010 at 22:42

Опубликовано в .NET, Development, Engineering, Internet, Programming