Доклад на DevPro-2014

Сегодня прошла вторая конференция DevPro, организованная компанией Rubius.

На ней я выступил с докладом «Кроссплатформенное приложение за 15 минут или Беды и победы мобильной разработки».
Посмотреть презентацию можно на СлайдШаре:

Исходные коды демо-приложения (вместе с iOS версией).

Лучи благодарности организаторам и всем слушателям — очень приятно было находиться в атмосфере мотивированных и заинтересованных профессиональных коллег :)

Жутко обрезаная видео-версия доступна на youtube:

P.S. Желающим посмотреть мой доклад 2013 года — добро пожаловать по ссылке.

Ревью на книгу «Идеальная IT-компания. Как из гиков собрать команду»

Как и многие «управленческие» книги, «Идеальная IT-компания» почти не затрагивает тему технологий, а акцентирует внимание на важности soft-skills и командной работе. Но если большинство «управленческих» книг считают своим читателем прежде всего менеджеров, то авторы «Team Geek» ориентируются на участников команд — программистов — и формирование командной культуры и атмосферы изнутри (впрочем, не исключая и роста карьеры потенциального читателя :))

Несмотря на то, что книга очень молодая — оригинал вышел в 2012 году — в ней практически нет отсылок к Agile. Тем не менее, очень многое в книге перекликается с манифестами гибких методологий: это и принцип доверия команде, и важность технически сильной и мотивированной команды, и роль руководителя как «слуги команды» (скрам-мастер?), и многое другое.

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

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

Критика направлена не на человека (а на код), да и проблема вовсе не в «плохом коде» как таковом (код работает!), а в понимании этого кода в будущем.

Реакция команды на внешнюю критику также очень важна, и здесь авторы призывают также следовать принципу «скромности и уважения» и даже из откровенно аггресивных сообщений о дефектах извлекать факты и вежливо реагировать именно на них. Несколько очень любопытных примеров подобных диалогов вы обязательно найдете на страницах книги :)
О конструктивности критики сейчас говорят очень много, и такие небольшие разборы стандартных ситуаций могут внести свою лепту во внедрение этой практики в нашей отрасли.

Также любопытным мне показалась тема технического долга.

Команда никогда не должна тратить больше трети (максимум — половины) своего времени и энергии на «оборонительную» работу независимо от размера технического долга. Вложение большего количества времени в «оборонительную» работу — путь к политическому самоубийству.

Это, безусловно, связано с важностью создания правильного «visibility» — если команда перестает стабильно выдавать заказчику business-value (а исправление технического долга, в большинстве случаев, заказчиком не воспринимается, каким бы технически-продвинутым он ни был), то доверие команде будет резко падать.

В целом авторы не открыли Америки, но, на мой взгляд, подчеркнули очень важные детали, привели множество полезных практических примеров и, возможно, привлекут этой книгой новую аудиторию (кроме менеджеров, которые подобными книгами, конечно, уже зачитались :))

P.S. Купить книгу можно в издательстве «Питер».

Инъекция зависимостей и меняющиеся параметры в конструкторе

При использовании инъекции зависимостей у меня частенько возникают проблемы с конструкторами.
Посмотрим на простой пример класса — сервиса почтовой рассылки:

public class EmailSender
{
	public EmailSender(ISmtpClient smtpClient, string serverAddress)
	{
	}

	public void Send(string from, string to, string text)
	{
		
	}
}

Какие у класса есть зависимости? Ему нужен SMTP-клиент, чтобы осуществлять отправку писем, а также необходим адрес смтп-сервера, который будет отправлять корреспонденцию.

Допустим, что у меня в проекте полная Инверсия Зависимостей и активно используются IoC-контейнеры. Какая возникает проблема?
ISmtpClient зарегистрирован в моем контейнере с ним проблем нет, но как сконфигурировать EmailSender адресом сервера? Непонятно.
Continue reading

Только React.js, только хардкор (aka долой Angular и Knockout)!

Последние годы только ленивый не писал о javascript-фреймворках. AngularJS/KnockoutJS/Backbone/Ember — выбирай на вкус :) Но, озадачившись выбором фреймворка для небольшого веб-приложения с год назад, оказалось, что серебряной пули в мире js все еще не придумали.
Backbone и Ember слишком низкоуровневы и многословны, Knockout расстраивает постоянными конвертациями данных в observable, AngularJS.. да, почему бы не попробовать Angular, подумал я тогда. Энгуляр обладал приятным синтаксисом, структура Контроллеров была более менее близка и понятна и всё шло хорошо, пока.. пока мы не уперлись в довольно стандартную для Angular проблему произодительности.
Continue reading

Xamarin и Garbage Collector на Андроид

При тестировании Андроид-версии нашего мобильного приложения, мы неожиданно начали замечать ощутимые проблемы в производительности — время от времени (достаточно регулярно) приложение «подвисало» на несколько секунд, а в некоторых случаях и вовсе вызывало ANR (Application Not Responding — такое замечательное окошечко, которое говорит, что приложение не отвечает и предлагает его закрыть).

Гугл подобных ситуаций дает подробные рассказы о проблемах с Garbage Collector’ами, и даже о том, что все языки с GC прокляты :) А сама проблема, обсуждать которую мы начали на форуме Xamarin’a, проявлялась в довольно странном факте:
Continue reading

Xamarin и проблемы с камерой в iOS 7

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

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

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

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

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

Видеозапись внутреннего семинара Rubius о тестировании

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

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

Строготипизированный доступ к UI-элементам в Xamarin.Android

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

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

Все еще пишете это руками? Используете FindViewById? Если при этом вы еще и используете Xamarin — то у меня есть решение! :)
Continue reading

Эволюция Team Foundation Server

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

WCF, Silverlight, асинхронные вызовы и Task Parallel Library

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

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

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

С моего последнего появления в Сильверлайте прошло достаточно много времени, и я надеялся, что взаимодействие с WCF там значительно улучшилось. Оказалось же, что все в общем-то по-прежнему Continue reading