Пишем код

7-я версия iOS принесла ряд разнообразных проблем при работе с камерой в наше iPad приложение.

Среди достаточно простых вещей вроде отображения камеры в Popover’е, самым правильным решением которого стало отображение камеры в фулскрине, была и другая презабавнейшая вещь.

При первом кадре съемка работала отлично. Но если мы сделали снимок, закрыли камеру, а потом решили снять еще один кадр — в «видоискателе» камеры показывался статичный предыдущий снимок. Никакие повороты или перемещения iPad’a не могли заставить камеру «показать» то, на что она направлена сейчас, на экране был лишь «замороженный» предыдущий снимок.
К слову, если таки сделать снимок «наугад», то он обновлялся без особых проблем «реальной» на тот момент картинкой, но такое поведение — это явно не то, к чему привыкли пользователи :)

Как часто и бывает в таких случаях, на stackoverflow казалось бы нашелся вопрос с точно такой же проблемой, но.. ответов на вопрос почему-то не было :)

Решение проблемы оказалось довольно простым — GC.Collect() в очередной раз нас спас :) А именно, после получения и обработки изображения с камеры, необходимо было «освободить» память, отвечавшую за сделанный снимок.
Cделано ли это ограничение в iOS 7 просто чтобы «заставить» программистов освобождать достаточно «тяжелые» Bitmap-объекты, или это объективная картина, которая случается при нехватке памяти в iOS сказать cложно. Но поиск и исправление подобных тонкостей работы безусловно доставит каждому столкнувшемуся немало приятных минут. Особенно, как в нашем случае, при обнаружении этого за пару дней до релиза :).

Где-то в августе мы провели небольшой внутрикорпоративный семинар посвященный автоматизированному тестированию.

В итоге получилась очень большая дискуссия и очень мало конкретики, фактического материала, выводов и конкретных решений :) Но если кому-то интересно послушать галдеж на айти тематику — welcome :)

Всем Андроид-разработчикам должен быть очень знаком код вроде:

private Button _myButton;
public Button MyButton { get { return _myButton ?? (_myButton =  this.FindViewById<button>(Resource.Id.MyButton)); } }

Все еще пишете это руками? Используете FindViewById? Если при этом вы еще и используете Xamarin — то у меня есть решение! :)
Read the rest of this entry »

Вообще говоря, мое отношение к Team Foundation Server всегда было довольно негативным. Это подтверждал и мой собственный опыт, и бытующие легенды, что в ТФС взяли самые худшие составляющие (худший баг трекер, систему контроля версий, билд сервер) и с трудом слепили их в нечто единое :) Эти суждения были весьма небезоснавательны, и когда очередной проект мы начали вести в TFS, мой настрой к этой системе был весьма и весьма скептическим.
Read the rest of this entry »

Уж сколько раз хоронили Silverlight, а в некоторых, особенно, внутрикорпоративных проектах он всё еще живет и здравствует, и даже активно развивается.

В один из подобных проектов и ступила недавно нога человека (моя, то есть :)).
Типичной задачей в Silverlight апплетах является, конечно, взаимодействие с сервером.

Использование технологии RIA Services (aka Domain Services), некоторое время активно пиарившейся Майкрософтом, лично у меня оставило весьма двойственные впечатления — в первую очередь из-за неочевидности происходящего «под капотом» и ощущения некоей магии происходящего. Поэтому старые добрые WCF-сервисы для взаимодействия с Сильверлайтом остаются для меня приоритетом.

С моего последнего появления в Сильверлайте прошло достаточно много времени, и я надеялся, что взаимодействие с WCF там значительно улучшилось. Оказалось же, что все в общем-то по-прежнему Read the rest of this entry »

Наконец-то стали появляться первые видеозаписи с прошедшего 16 марта семинара DevPRO.

На семинаре я выступал с докладом о разработке мобильных приложений с использованием c#.

Как известно, в ASP.Net MVC4 одной из главных появившихся фишек стал WebAPI.

Вместе с обновлением Web Tools 2012.2, вышедшем, как ни странно, в 2013, Майкрософт добавил к WebAPI интересную функцию — генерацию страницы помощи (help-page) с описанием вашего API в человеко-читаемом виде, и даже с примерами в виде xml и json. Большой плюс этой страницы в том, что информацию и описание API можно брать прямо из xml-комментариев к методам API-контроллера

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

    /// <summary>
    /// description
    /// </summary>
    [HttpGet]
    public string Tst([FromUri] TstModel filter)
    {
        return null;
    }

Проблема, как оказалось, была в том, что TstModel я, как водится, объявил вложенным классом (nested class) в самом контроллере. Из-за этого help page слегка потерял голову и необходимой документации не увидел :)

Для интересующихся и/или столкнувшихся с той же самой проблемой, фикс прост:
XmlDocumentationProvider.GetTypeName

line 109: return type.FullName.Replace("+", "."); //was: return type.FullName
line 101: string typeName = genericType.FullName.Replace("+", "."); //was: string typeName = genericType.FullName

Может, кто подскажет, куда можно послать по этому поводу bug-report? :)
Кроме как через nuget письмом автору Microsoft.AspNet.WebApi.HelpPage — других вариантов не найдено :)

Сделал перевод ответа Роба Эштона на заметку Роберта Мартина «О стартапе-ловушке».

После появления перевода оригинальной статьи дяди Боба не мог не ответить переводом зацепившего ответа :) Тема моя любимая — про тесты.

Не стесняйтесь плюсануть на хабре (http://habrahabr.ru/post/172039/), если понравится :)

I love this feature!
И это реально то, чего не хватает в VS/Resharper :)

Попробуем добавить xml-комментарий к свойству:

    public UIViewController CurrentViewController {

Набираем традиционные «///» и получаем…

    /// <summary>
    /// Gets the current view controller.
    /// </summary>
    public UIViewController CurrentViewController {

Ну, я даже не знаю, что добавить :) Правда, иногда всё-таки приходится дописывать еще пару фраз :)

P.S. Может, кто-нибудь знает, как это сделать в VS?