.NET *

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

Конечно же, нельзя быть абсолютно уверенным, что пользователь введёт именно то, что нужно, поэтому все данные необходимо тщательно проверить.

Как правило, алгоритм проверки этих данных один и тот же: «Если значение поля удовлетворяет требованию, то проверить следующее требование, иначе вывести сообщение об ошибке. Перейти к проверке значения следующего поля».

На практике это выливается с довольно длинные последовательности «if-else». Лично мне это жутко не нравилось, так как сложно с первого взгляда определить, какие поля как проверяются и какие сообщения выдаются в случае ошибок. А ведь полей в форме может быть и десять, тогда код проверки вообще затягивается. Вобщем, я задумался над тем, как можно минимизировать объём работ и вот что из этого получилось.

Введение

Если Вы когда-нибудь слышали такие слова, как IoC, DI, AoP, но не имеете четкого понимания этих терминов, надеюсь, эта статья поможет в них разораться на примере работы с Microsoft Unity контейнером.

Mono, open-source реализация платформы .NET была использована для разработки игр для iPhone и Wii. Посмотрим, как статическая компиляция сделала возможным, чтобы приложения на Mono удовлетворили требованиям Apple к приложениям, размещаемым в App Store.

Собираюсь начинать новый проект и постепенно приближаюсь к стадии написания некоторых базовых вещей. Решил собрать и систематизировать свои знания об некоторых аспектах разработки ПО на платформе ASP.Net, полученные за более чем год коммерческой разработки. В результате получилась вот такая статья. Она не претендует на принципиально новые вещи, это все давно знают, в определенном смысле это своеобразные best practices. Все, что написано ниже, скорее всего пригодится новичкам, но и опытные разработчики смогут почерпнуть для себя что-нибуть интересное.

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

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

Необходимое отступление: не так давно я разместил статью предназначавшуюся для печатного издания. Приведенная ниже статья имеет ту же самую судьбу: она не попала в печать в связи с тяжелым положением журнала. Как и в прошлый раз, я решил опубликовать статью на Хабре, благо тематика попадает под формат. Необходимо заметить, что статья оформлена и содержит текст для журнала, если бы она готовилась для Хабра, то некоторые часть могли бы быть изменены. Надеюсь, статья вам понравится.

В последнее время заметно, что компания Microsoft уделяет повышенное внимание развитию своих средств разработки, новым инструментам и механизмам разработки программ на своей платформе .net. Быстро развивается язык C#, четвертая версия которого не за горами. Представлен и активно продвигается новый язык F#. Для разработчиков баз данных разработан Entity Framework, который уже доступен в виде финальной версии в первом сервиспаке к .Net Framework 3.5 и Visual Studio 2008. Microsoft активно занялась и клиентской частью разработки web-проектов. Для нашего внимания предложен путь развития Ajax.Net 4.0. Internet Explorer 8 все больше соответствует стандартам и становится привлекательным инструментом для web-программистов, так например, его вкладка Developer Tools включает в себя профайлер JavaScript. Очень хорошей новостью стало недавно объявление о полной поддержке и включении JavaScript-библиотеки jQuery в следующее обновление Visual Studio. В этом свете возникает вопрос, что же предложено разработчикам ASP.NET? Ответ — MVC Framework. Целью данной статьи рассмотреть некоторые общие проблемы, с которыми могут столкнуться программисты, решившие использовать MVC Framework для своих web-проектов, и их решения.

Хочу рассказать вам о фреймворке, который был создан для разработки «богатых» веб-приложений на ASP.NET. Фреймворк был создан в компании, в которой я работаю, и использован в нескольких боевых проектах.

Из ключевых особенностей фремворка:

• хороший JSON-форматтер (теперь на клиент можно передавать почти любые .NET-типы);
• мастерстраницы/страницы/контролы на клиенте представлены как объекты JavaScript (в JavaScript построить взаимодействие между ними теперь совсем просто);
• мастерстраницы/страницы/контролы можно наследовать, причем можно наследовать как серверный код, так и клиентский (да, даже разметку);
• можно использовать совместно с jQuery или (как делаем мы) с ExtJS;
• много всего приятного :)

Инициатор создания фремворка и его главный разработчик не я, а мой коллега. Я же просто разместил объяву хотел рассказать вам о замечательном продукте :)

Читать статью

P.S. — В топик-ссылку не поместилось описание, сделал как топик.

Хватит мне уже гнать про теорию, вы мне практику давайте, практику!

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

Споры насчёт того, какой же подход лучше, утихают редко. Сейчас я покажу, как можно скрестить ежа с ужом. У нас есть .NET, которым можно быстро делать и есть Native, который может быстро делать.

В образовательных целях мы будем скрещивать эти два направления. У статьи есть ещё одна цель. В её основе лежит написанная мною и Arwyl'ом программа под названием DuSter. Эта программа представляет собой сервер-пустышку, который позволяет тестировать сетевые программы. Сервер очень прост в использовании, достаточно гибко настраивается, поддерживает файлы описания протоколов, которые позволяют более-менее автоматизировать тестирования работы любых протоколов. Я занимался разработкой сетевого уровня, мой друг — бизнес-логикой и парсингом протоколов. Получилось что-то неимоверно хорошо вылизанное и приятное. Мы гордимся своей программой, и хотим предоставить её сорцы миру, для некоммерческого использования.

Всем привет! Хабраюзер shai_xylyd написал статью про аспекты тестирования, где им были рассмотрены некоторые понятия и ценности TDD. В частности, он упомянул очень интересный способ создания первичных юнит-тестов — когда функциональный код пишется совместно с кодом юнит-теста, чем меня очень заинтриговал.

Дело в том, что я (как программист), нахожусь в состоянии переходного процесса между «классической» разработкой и разработкой test-driven, поэтому всякими способами ищу возможности упростить и сделать более естественной последнюю. После пары приседаний, сразу включиться в методику shai_xylyd не сумел. Начал переписку с автором статьи, где он натолкнул меня на мысль подойти к решению с математической точки зрения. Идея в том, чтобы воспользоваться функциональным пространством среды программирования и «разложить» написание юнит-теста на составляющие. После чего сделать выводы.

Не судите строго, это моя первая статья

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

Начиная с версии 2008 (и пока что заканчивая ей) MS SQL Server имеет встроенную поддержку пространственных данных. Прекрасно!

На данный момент времени уже существует несколько СУБД, предлагающих индексированное хранение пространственных данных. Наверное, самые популярные из них, это: «народная» MySql и PostGIS.

Программируя на c#, естественно, в очень многих случаях, отдаёшь предпочтение продуктам и решениям Microsoft. Причины просты: полнее поддержка одних технологий другими, хорошая документация, более полная реализация, например провайдеров данных, и гораздо меньшая глючность. Я выбрал SQL Server. Заодно захотелось освоить LINQ в общем и LINQ to SQL в. частности.

Поначалу всё было хорошо. Для меня хороший старт сделала, обнаруженная на msdn, статья «LINQ to SQL: .NET Language-Integrated Query for Relational Data».
Но я не сильно удивился, когда «всё хорошо» закончилось.

Для хранения геометрических данных в SQL Server были введены два дополнительных типа: geometry и geography. Первый используется для хранения геометрических объектов, описанных в декартовой системе координат, а второй — для геометрических объектов заданных географическими координатами (широта/долгота).
Такое разделение, по всей видимости, пришлось сделать из-за того, что пространственный индекс реализован в SQL Server на основе B-деревьев. При использовании этого индекса пространство шаблонно разбивается сеткой несколько раз и в «ячейки» этой сетки сохраняются ссылки на геометрические объекты. И оказалось невозможно строить универсальное разбиение и для прямоугольной системы координат и для эллипсоидальной. В MySql, например, выбран другой алгоритм индексирования, основанный на R-деревьях, работающий на совершенно другом принципе, и используется один тип данных. Какой способ индексирования лучше, а какой хуже — не очевидно, так что пока не понятно на кого ругаться и стоит ли.

Оказалось, что LINQ to SQL не понимает этих типов данных и работать с ними, а также со встроенными геометрическими функциями, отказывается. Хотя, наверное, правильнее сказать, что их не понимает провайдер. В любом случае, уверен, что поддерживаться эти данные будут, но сейчас такой поддержки нет.

Я не смог найти в интернет решения, обходящего эту проблему, поэтому пришлось изобрести его самому. Здесь нет никаких удивительных ходов, но есть детали, которые, думаю, будут интересны. Также в этой большой заметке, для вашего интереса, я чуть-чуть опишу работу с LINQ to SQL.

Вчера наткнулся на такую библиотеку — tweetsharp. Она маленькая, умная и быстрая.
Так что вполне можно строить свои клиентики и например даже боты для особо больших извращенцев :)

Подозреваю, многие из вас задумывались — как можно в .NET приложение добавить поддержку макросов — чтобы можно было расширять возможности программы без ее перекомпиляции и предоставить сторонним разработчикам возможность легко и просто получить доступ к API вашего приложения? В статье рассмотрено, как в качестве основы для выполнения макросов использовать IronPython — реализацию языка Python на платформе .NET.

Этот топик является ответом на это заявление в хабраюзера wizard о том, что проекты для работы с БД на .Net занимают очень много места на диске и вообще, двадцать лет назад трава была зеленее, а деревья выше.
Как высказался один из комментаторов вышеупомянутого топика (neuotq):

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

Важно понимать, что современные фреймворки дают программисту множество инструментов для решения задач. И если вам нужно, цитирую, «получить пару строк данных» из БД, не нужно для этого применять «комбайны с лазерным прицелом» а-ля ADO.Net Entity Framework или NHibernate. Важно понимать, что такие инструменты созданы для больших проектов. Под большим проектом я понимаю не курсовую или дипломную работу, а крупномасштабные коммерческие системы, которые стоят очень больших денег и лишний «1 день(неделя, месяц)» (опять цитата), затраченный на написание собственных велосипедов, обходится заказчику в сотни(тысячи, миллионы) отнюдь не русских денег. Хороший разработчик отличается от плохого тем, что знает, когда нужно писать велосипед, а когда достаточно взять готовый. Плохой, соответственно, либо пихает кругом фреймворки, либо же наоборот везде пишет велосипеды. И виноваты в этом не инструменты разработчика, а он сам.
Все, не буду утомлять своей философией. Под хабракатом можно почитать о том, как можно взаимодействовать с базой данных в .Net без привлечения экскаваторов.

Несколько дней назад написал пост про то, как количество нитей влияет на скорость вычислений. В комментариях, меня неоднократно обвинили в том, что при использовании нитей используется только одно ядро (или один процессор), а для просветленного многоядерного программирования надо использовать Parallel Extensions. Подобные утверждения меня, мягко сказать, удивили, потому решил разобраться более детально в вопросе.

Вступление

Одним из нововведений в четвертой версии ASP.NET стала возможность контролировать формирование идентификаторов элементов разметки на клиенте. Ранее фреймворк задавал уникальный идентификатор для каждого элемента. Это приводило к тому, что определяемые вами идентификаторы преображались во что-то похожее на это: ctl00_MasterPageBody_ctl01_Textbox1.

Проблема

Модификация идентификаторов на клиентской стороне отлично работает, когда требуется обеспечить уникальность идентификаторов для каждого элемента, но работа с такими идентификаторами могла расстроить любого, кому приходилось работать с клиентскими скриптами. И если вы работали с ASP.NET, то скорее всего сталкивались с этими трудностями. Проблема состоит в том, что во время исполнения скрипта вы не можете точно знать каким может быть идентификатор, что затрудняет написание клиентских скриптов. Кроме того, любые модификации на странице, добавление или удаление элементов управления, могут привести к генерации других идентификаторов.

Совсем недавно группа разработчиков с ресурса Mix Online (часть Microsoft) анонсировала проект Oxite — CMS для создания блогов на базе MVC Framework. Проект находится в состоянии alpha-версии и самими разработчиками позиционируется как эксперимент, целью которого ставится показать разработчикам то, как можно писать на MVC Framework.

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

Приблизительно через год нас ждет очередной релиз Microsoft Visual Studio и едва ли не самой вкусной новинкой обещает стать F# — функциональный язык глазами ребят из Кембриджской лаборатории Microsoft Research. Этот язык совсем новый и сейчас находится на стадии вылизывания в лабораториях Microsoft Research. Microsoft позиционирует F# как один из основных языков для .Net наряду с C# и VB.Net что скорее всего значит, что рано или поздно с ним придется столкнутся очень многим програмистам под .Net. Я, как и многие разработчики, никогда не сталкивался с чисто функциональными языками, но принцип «Готовь сани летом» еще не отменяли. Эта статья — мой личный маленький «Привет F#».

Всего несколько дней назад вышла вторая версия гайдлайна Application Architecture Guide 2.0.

Брошюра включает четыре раздела:

• Основы — раздел в котором описаны основные стратегии и техники проектирования
• Проектирование — содержит паттерны и примеры проектирования различных приложений, включая примеры проектирования сервисов
• Слои — в котором описаны подходы к архитектуре и проектированию слоев приложений, включая уровень представления, бизнес логики, сервисов и доступа к данным
• Архетипы — в котором паттерны классифицированны на основе архетипов, таких как RIA, Rich-client приложения, сервисы, мобильные приложения и т д

Авторы ребята из Microsoft, продвигающие инициативу Patterns & Practice

О чём вы, Морфеус?

Приветствую всех!
Моя первая статья на хабре была оценена хабраюзерами достаточно высоко. Что же, спасибо всем кто оставил своё мнение о статье, мне было приятно вас почитать, я продолжаю.

В новой статье хотелось бы поговорить о наследовании. Признаться честно, до изучения ADO.NET Entity Framework я вообще даже не задумывался о том, чтобы вводить в свои проекты наследование сущностей в объектно-ориентированных обёртках для БД. Обычно базу строили так, чтобы максимально избегать наследования. Хотя, порой оно и маячило на горизонте, но обходилось. Сейчас я опишу, как я добавил в свой проект два очень простых класса, которые были отнаследованны от уже имеющихся таблиц.

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

И так,