переход был с web-приложений (ASP.NET) на мобильные (iPhone) (хотя и десктопными я занимался, но это было уже почти два года назад). да и не переход это был, а скорее еще одно начинание — работать с .NET платформой продолжаю.
причина простая — увидели перспективу в этом рынке.
нет, не смотрел на MonoTouch. во-первых, я всегда считал и продолжаю считать, что всегда лучше пользоваться нативными средствами разработками. во-вторых, было как раз время запрета Apple на разработку приложений ненативными средствами.
на MonoTouch смотрю сейчас, но вовсе не из-за того, что я .Net разработчик:) меня привлекает идея писать приложения сразу под несколько устройств (или очень быстро переносить написанный код с одной платформы на другую) — iPhone, Windows Phone 7 (в будущем, думаю, и Android).
конечно, основной «хлеб» TDD — это бизнес-логика. очевидно, что она должна быть максимально покрыта тестами. TDD гарантирует это покрытие. другими словами, исключаются ситуации, когда разработчик, реализовав некоторую функциональность, решает ее не тестировать, оправдывая себя нехваткой времени, или откладывает написание теста на «когда-нибудь».
только при использовании API вы сможете ощутить всю прелесть, написанного вами кода, или увидеть его недостатки. TDD позволяет исправить ошибки API на самой ранней стадии.
ниже уже замечено, что хорошие тесты — это лучшая документация вашего кода. TDD — это гарантированное написание «документации» к вашей логике. а значит и более легкое сопровождение и поддержка в будущем.
так получилось, что TDD и сноуборд я осваивал одновременно. и там, и там делал это без инструктора — по книгам и видео-туториалам. и в TDD шишек набил, и на сноуборде плечо выбил… так что когда наткнулся на эту статью — как свои мысли прочитал:) потому, наверное, и решил сделать свой первый перевод. рад, что не мне одному она понравилась.
ничем, xml нужен только на этапе заполнения базы. вообще, xml-файл здесь дан просто для примера источника данных. главное: заполнить базу с нужной схемой из вашего изначального хранилища данных и использовать ее в приложение. а как вы ее будете заполнять — это уже дело десятое.
про то как парсить XML тут буквально полслова:) если уже есть какое-то хранилище данных, где есть вся необходимая приложению информация, то лучше потратить час-полтора времени и автоматизировать процесс, чем нагружать клиента дополнительной работой. зависит, конечно, от клиента, но наши клиенты, как правило, предпочитают заплатить за дополнительную работу по автоматизации, а не тратить свое время на рутинную работу.
спасибо за комментарий
описанный вами способ эффективно можно использовать лишь при небольшом количестве данных — не будете ведь забивать руками тысячи сущностей.
хотя посмотреть в этом направлении стоит — если сделать десктоп приложение с загрузкой данных из внешнего источника. но тут я не уверен какой вариант будет быстрее написать:) нужно будет смотреть по задаче.
может пост-отчет напишите?
небольшой фидбэк:
— онлайн трансляции — было бы здорово слайды видеть.
— Денису Марголину — посмотреть фильм «Welcome to Mac» — незнание некоторых моментов в истории Apple у человека, выступающего по ней с докладом, огорчает.
рассказывал сегодня коллеге про эту встречу и получил вопрос: «зачем разработчикам рассказывать историю Apple?» переадресую его вам:)
— Эльдару Маркову — увереннее и больше тех деталей, иначе довольно поверхностно получается. а в целом неплохо.
радует, что вы это начали. буду ждать следующих трансляций.
действительно отличная книга, помогла окончательно перестроиться на путь истинный:) очень благодарен человеку, который в свое время мне ее рекомендовал.
причина простая — увидели перспективу в этом рынке.
на MonoTouch смотрю сейчас, но вовсе не из-за того, что я .Net разработчик:) меня привлекает идея писать приложения сразу под несколько устройств (или очень быстро переносить написанный код с одной платформы на другую) — iPhone, Windows Phone 7 (в будущем, думаю, и Android).
только при использовании API вы сможете ощутить всю прелесть, написанного вами кода, или увидеть его недостатки. TDD позволяет исправить ошибки API на самой ранней стадии.
ниже уже замечено, что хорошие тесты — это лучшая документация вашего кода. TDD — это гарантированное написание «документации» к вашей логике. а значит и более легкое сопровождение и поддержка в будущем.
также порекомендую «Эффективная работа с унаследованным кодом» Майкла Физерса
описанный вами способ эффективно можно использовать лишь при небольшом количестве данных — не будете ведь забивать руками тысячи сущностей.
хотя посмотреть в этом направлении стоит — если сделать десктоп приложение с загрузкой данных из внешнего источника. но тут я не уверен какой вариант будет быстрее написать:) нужно будет смотреть по задаче.
небольшой фидбэк:
— онлайн трансляции — было бы здорово слайды видеть.
— Денису Марголину — посмотреть фильм «Welcome to Mac» — незнание некоторых моментов в истории Apple у человека, выступающего по ней с докладом, огорчает.
рассказывал сегодня коллеге про эту встречу и получил вопрос: «зачем разработчикам рассказывать историю Apple?» переадресую его вам:)
— Эльдару Маркову — увереннее и больше тех деталей, иначе довольно поверхностно получается. а в целом неплохо.
радует, что вы это начали. буду ждать следующих трансляций.