На днях вышли в свет несколько новых продуктов от Microsoft, среди которых были IIS Express 7.5, WebMatrix и SQL Server CE 4, я так нашел применение уже для них всех.

Может я как-то не правильно подошел к DataPager, но, как оказалось, заставить его нормально работать без DomainDataService не так уж и просто. Идея у меня была простая, думал найти свойство, вроде ItemCount (оно есть, но только для чтения), туда поставить то количество элементов, которое у меня есть, сделать байдинги на PageSize и PageIndex и все должно быть готово. Но пришлось делать все совершенно по-другому.

Вообще, мне кажется, что такая проблема, наверняка, была не только у меня, ну не всегда и не везде же используется WCF RIA, а использовать пейджинг в списках это уже правило хорошего тона, если знаешь, что список будет расти. Интересно, кто как борется с этой проблемой. А я пока расскажу про свой велосипед.

Silverlight 4 in Action (Manning, Pete Brown) – это вторая книга про Silverlight, которую я прочел. Первая была Pro Silverlight 3 in C# (Apress, Matthew MacDonald), которая в свое время мне очень хорошо помогла быстро освоиться с Silverlight после WPF. Но все же после прочтения SL4 in Action для меня фаворитом стала именно она, и на это есть доводы. Правда, сравнивать было бы правильно SL4 in Action, наверное, с Pro Business Applications with Silverlight.

Блог автора книги SL4 in Action Пита Брауна, думаю, знаком большинству Silverlight и WPF разработчиков. C 2009 года он сотрудник Microsoft, с 2007 года Silverlight стал для него приоритетной для разработки технологией. Вообще, можно подумать, что книга Silverlight 4 in Action – это уже вторая редакция, ведь есть книга Silverlight 2 in Action, с которой я к сожалению не знаком. Так вот, если присмотреться, то окажется, что SL2 in Action написана совершенно другими авторами. Так что, приводить информацию чем SL4 in Action отличается от своего предшественника не разумно – это совершенно другая книга. И, как я понимаю, это первая книга написанная Питом Брауном, и написана, я должен сказать, очень хорошо.

Такой вопрос “Почему тормозит Silverlight?” достаточно часто можно услышать, особенно если вы разрабатываете решения при помощи технологии Silverlight. Часто вы не можете выиграть тендер, или уговорить заказчика на использование технологии Silverlight в вашем приложении, только потому что за ним уже закрепилась эта популярность мышления, что все приложения на Silverlight тормозят. Давайте попробуем обсудить этот вопрос.

Неделю назад напоролся на баг в Silverlight, точнее в DataGrid контроле, а он пришел, вроде, с Toolkit. Потребовалось больше часа, чтобы понять в чем проблема.

Мы в приложении для части администрирования используем свои контролы, которые могут по схемы таблицы базы данных построить контролы списка объектов и форму для редактирования объектов. Более того, даже строятся join’ы. Сделано это для того, чтобы быстро в административную часть нашего решения быстро добавлять настройки только поменяв метаданные на интерфейсе, не трогая сервисы, и любые другие слои нашего приложения. Пользователям мы эти интерфейсы не показываем, а работаем чаще всего с ними только мы-разработчики и немного наши консультанты и менеджеры, так что внешний вид там не важен.

Как-то я поднимал уже тему про то, стоит ли покупать компоненты или может имеет смысл писать их самому. Хочется пожаловаться, просто накипело. Syncfusion меня очень сильно удивил. Есть у них библиотеки, включающие имя Web, ну, наверняка же, должно подразумеваться, что все классы, контролы должны уметь жить в многопоточной среде. А оказывается нет. В общем, хочу провести антирекламу Syncfusion. Я могу точно сказать – эти библиотеки покупать не стоит. Берут они, наверное, свое, только обилием количества решений, контролов, сред. Но, не стоит это тех денег, а особенно сил, которые нужно будет тратить на решения проблем.

Недавно внедрил в проект Entity Framework 4. Надоело писать все на хранимых процедурах. Конечно, что-то можно и нужно делать на хранимых процедурах, но что-то быстрее и проще можно сделать с помощью ORM. Может встать вопрос, почему не nHibernate? Очень просто. nHibernate велик и всемогущ, но у него нет дизайнера. У нас очень простая бизнес логика, потому все прелести такого ORM нам не нужны. Честно, хватило бы и LINQ to SQL, но остановились на Entity Framework потому что: “а мало ли?”. Начал использовать я дизайнер, и первое с чем столкнулся – дизайнер, генерируя по базе, по связи многие-ко-многим (через таблицу связи) так и связывает сущности в дизайнере связью многие-ко-многим, а мне бы хотелось все-таки оставить промежуточный объект (вроде одно из отличий EF от LINQ to SQL, что есть поддержка связи многие-ко-многим, а мне не нравится). Полазил в интернете и единственное решение, которое нашел, было – добавить в промежуточную таблицу еще какое-нибудь поле, тогда все будет хорошо. Такое решение мне не подходило, и, конечно же, не хотелось мне лезть в XML файлы маппинга и править там все руками.

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

Несколько дней назад написал в твиттере, что приобрел себе Kindle 3, точнее о том, что его мне уже доставили. После этого мне было задано достаточно много вопросов в твиттере, и народ посоветовал написать небольшой обзор. Хоть обзоры уже и были до моего (на хабре около 3х точно видел), но раз вопросы есть, то почему бы и нет, напишу.

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