.NET *

Отлаживая WPF-ный редактор для таблицы БД, столкнулся с Exception-ом при переходе между соседними ячейками с помощью клавиатуры.
Казалось бы, обычное дело — кто из нас эксепшенов не нюхал? Да и компонент DataGrid из WPF Toolkit весьма экспериментальный, так что удивляться нечему. Однако, кое-что меня насторожило.

Введение

Как известно размер .NET фреймворка увеличивается от релиза к релизу. Но, к сожалению, не у всех потенциальных пользователей широкий безлимитный канал.
Стояла задача — определить какой .NET Framework, поддерживающий WPF, оптимален с точки зрения простоты распространения. Ведь не хочется терять пользователей из-за лишних мегабайт в установщике.
Т.е. надо было принять решение какой .NET Framework использовать: .NET 3.0 или .NET 3.5.

Собственно все довольно просто:

1. Качаем и ставим Google API [Google.GData.Client.dll, Google.GData.Extensions.dll, Google.GData.Photos.dll]

2. Создаем новый проект на C# (я использую WinForms)
3. Заведем класс основной логики:

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

Итак, имеется приложение, написанное на C#, которое использует .net framework 1.1 (да-да). Приложение после некоторых внесенных изменений начало выбрасывать такое малоинформативное исключение:

В этой статье будет рассмотрен один из вариантов реализации паттерна репозиторий на базе LINQ to SQL.

Сегодня LINQ to SQL – это одна из технологий Microsoft, предназначенная для решения проблемы объектно-реляционного отображения (object-relational mapping). Альтернативная технология Entity Framework является более мощным инструментом, однако у LINQ to SQL есть свои преимущества – относительная простота и низкоуровневость.

Данная статья — это попытка продемонстрировать сильные стороны LINQ to SQL. Паттерн репозиторий отлично ложится на парадигму LINQ to SQL.

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

foreach(var element in collection)
{
  // Do something
}
* This source code was highlighted with Source Code Highlighter.

Поэтому образовалась вот такая обёртка.

Некоторое время назад я узнал о лямбдах, но не совсем понимал принципов построения выражений с лямбдой. Но сегодня наткнулся на пост Charlie Calvert'а и всё для себя прояснил.

В любых программных продуктах, будь то 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.