Не стреляйте в программиста

Записали с Лёшей Абрамовым наш первый подкаст. Всё получилось очень спонтанно. Творчество можно заценить на rpod, podfm и на хабре.

Ну, или прямо тут:)

Game Center + iOS 5

Если вы тестируете GC и не видете ни одной записи о заработанных очках в LeaderBoard, хоть и отправляли их,- попробуйте завести еще один тестовый аккаунт и отправить очки из под него. Особенность работы GC с iOS 5 - не показывает таблицу, если только один участник отправлял данные. С какого-то бока логично, с остальных - глупо.

Импортировать/экспортировать конфигурацию сайта в IIS7

Экспорт:
appcmd list site /name:siteName /config /xml > d:\siteName.xml

Импорт:
appcmd add sites /in < c:\siteName.xml

Не забываем создавать, если нужно, соответствующий application pool.
При импоте может быть ошибка, вызванная дублированием ID сайта. В этом случае просто меняем ID в xml-файле.

CCRepeatForever + CCSequence

id yourDelaying = [CCDelayTime actionWithDuration:5.0f];
id yourSequence = [CCSequence actions:[CCAnimate actionWithAnimation:yourAnimation], yourDelaying, nil];
CCRepeatForever *repeatAction = [CCRepeatForever actionWithAction:yourSequence];
[yourSprite runAction:repeatAction];

TDD - это как сноубординг

Перевод статьи TDD is like snowboarding

Я только что получил следующее письмо, которым хочу поделиться и ответить на него публично.

"Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD - уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют."

Первая и самая важная вещь, на которую я хотел бы обратить внимание, - ошибочное представление о TDD как об инструменте для уменьшения количества багов. Хотя это и является одним из "побочных эффектов" TDD, это не основной мотив для его использования. Главный довод в пользу TDD - последовательная разработка дизайна каждого компонента вашей системы посредством написания теста для него.

Что касается следующего вопроса:

"Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD - уменьшается, увеличивается или остается неизменным."

Когда вы впервые решаетесь забраться на гору и рискнуть прокатиться на сноуборде, вы забираетесь туда с мечтой в голове о том как будете рассекать несколько минут и выделывать трюки круче, чем в SSX Tricky. Но после пары падений вы чувствуете увесистый пинок реальности и осознаете, что, похоже, это займет немного больше времени, прежде чем вы научитесь хотя бы просто съезжать с горы без всякого блеска и очарования. Если вы благоразумны, то потратите время на занятия с квалифицированным инструктором, который за день обучит вас основам и поставит технику. На базе занятий с интруктором вы сможете расти как сноубордист следующие пару месяцев, и, скорее всего, не нахватаетесь вредных привычек, которыми могли бы обзавестись, попытайтесь вы научиться самостоятельно.

Как в сноубординге (да и в любом другом новом деле, которое вы решили освоить), в начале нужно потратить время на обучение. Большинство людей, решивших окунуться в TDD, осознают, что в их знаниях много пробелов, которые могут создать проблемы в этом новом мире. Даже если со знаниями у вас все в порядке, вы должны осознавать, что в любом случае первое время вы будете тренировать свой мозг решать программные проблемы непривычным способом. На самом деле, это одно из самых больших препятствий при переходе на TDD - выработка нового стиля программирования, который заставляет вас думать о маленьких шагах и разрабатывать API, как будто он уже написан. Хороший способ начать практиковать TDD - использовать state-based тестирование (от перев. - подход, при котором проверяется состояние объекта после прохождения теста). Как только вы набьете руку на state-based тестировании, вы сможете сочетать его с interaction-based тестированием (от перев. - подход, при котором тестируется взаимодействие объектов, поведение методов, последовательность их вызовов и т.д.).

Начав использовать TDD, вы можете обнаружить, что работаете медленнее, чем обычно, - это в основном из-за того, что вы будете работать вне "зоны комфорта", чувствуя себя неестественно. После того как вы ощутите, что написание тестов стало естественной частью рабочего процесса, что вам больше не нужно думать об использовании TDD при работе над проектом, так как TDD влилось в вашу работу, вы поймаете ваш "АГА!" момент с TDD.

Я был свидетелем работы двух команд (одна из которых была agile) с разработчиками примерно одного уровня, которых попросили реализовать одну функциональность в проекте. Команда, практикующая TDD, подстраивалась под поставленные задачи и меняющиеся требования гораздо лучше, чем та, которая не использовала TDD. Я много раз наблюдал эффект TDD на самых разных проектах - от небольших до огромных проектов уровня предприятия. Я бы не говорил о преимуществах TDD, если бы не чувствовал, что оно действительно заслуживает внимания. Что касается меня, то этот подход полностью изменил мой взгляд на решение проблем в программировании.

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

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


Для тех из вас, кто всерьез рассматривает использование TDD, но еще не начал, - возможно, сейчас хороший сезон, чтобы попробовать взобраться на холм!

Из чего готовят Google Analytics Cookies

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

Всю эту информацию мы получили из Google Analytics Cookies.

Что же из себя представляют печеньки от Google?


Если кто-то вдруг не знает, что такое cookie, то можно почитать, например, в википедии.

Google Analitics пользуется в основном четырьмя сортами печенья: __utma, __utmb, __utmc, __utmz (изредка встречаются __utmv и __utmx, но в кризис их не достать необходимости в них я не почувствовал).
Разберем каждый отдельно на примере.

__utma

Это основные пользовательские cookie, которые уникально идентифицируют посетителя сайта и содержат много полезной информации о нем.
Срок жизни у этих cookies два года (если пользователь их не почистит), то есть можно получать информацию за достаточно большой период времени.

Формат: XXXX.DDDD.FFFF.PPPP.CCCC.N
Пример: 126394024.179004532335319200.1247654493.1260769004.1260878051.7

Значения:

• XXXX - hash домена, полезной информации не содержит.


• DDDD - уникальный ID пользователя в системе Google Analytics.


• FFFF - дата первого посещения пользователем сайта в Unix формате (количество секунд, прошедших с первого января 1970-ого года).


• PPPP - дата предыдущего посещения пользователем сайта в Unix формате.


• CCCC - время начала текущего посещения (начало сессии) в Unix формате.


• N - количество посещений сайта данным пользователем.
• 
  

__utmb

Эти cookies несут в себе информацию о текущей сессии пользователя, время жизни - 30 минут после загрузки последней просмотренной страницы.

Формат: XXXX.P.10.CCCC
Пример: 126394024.1.10.1260878051

Значения:

• XXXX - hash домена.


• P - количество страниц, просмотренных пользователям в течение текущей сессии.


• 10 - магическое число Google одинаковый на всех сайтах параметр, не меняющийся с течением времени. думаю, полезной информации не несет.


• CCCC - время начала текущего посещения (начало сессии) в Unix формате (аналогично CCCC параметру _utma).

__utmc

Время жизни этих cookies - текущая сессия. Содержат только hash домена.

__utmz

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

Формат: XXXX.TTTT.V.S.utmcsr{source}|utmccn{campaign}|utmcmd{medium}|utmctr{keyword}
Пример: 126394024.1260524913.5.5.utmcsr=yandex|utmccn=(organic)|utmcmd=organic|utmctr=best

Значения:

• XXXX - hash домена.


• TTTT - дата последнего обновления cookies в unix формате.


• V - количество посещений пользователем сайта, совершенных по ссылкам с других ресурсов.


• S - количество различных ресурсов, с которых пользователь попадал на сайт.


• utmcsr - ресурс-поисковик, с которого пользователь попал на сайт.


• utmccn - содержит информацию о компании из AdWords (или значение utm_campaign в запросе) или же сообщает, что пользователь попал к вам посредством organic search.


• utmcmd - содержит название компании (или значение utm_medium в запросе) или сообщает об organic search.


• utmctr - ключевые слова, по которым велся поиск.

Как видите, эти печенья содержат очень много полезной информации и в следующей статье я расскажу как мы их ели с ними работали.
Дополнительно о Google Analytics Cookies можно почитать в официальной документации.