What is TDD and BDD and How Do They Relate to One Another?

In this post I will attempt to define TDD and BDD and show how they are similar. I’ll also describe the way that each apply to software development and where I’ve seen shortcomings with how TDD is often applied.

TDD - Test Driven Development/Design

It depends on the age of the information you’re looking at which of the two terms you’ll see used – Development vs. Design. Newer literature will refer to it as Design more often than not. The reason for the change is to emphasize the important software engineering practice that is primarily benefited from its practice.

Can you describe TDD in a sentence?

TDD is the practice of using automated unit tests to drive the creation of classes and methods that satisfy a set of requirements for a software application.

On a team, who does TDD?

TDD is performed by the software developers that are responsible for the delivery of the code that satisfies the requirements of the application. It is not performed by QA or others responsible for quality control of an application.

Why are developers writing these tests? Shouldn’t testers write tests?

Because the primary purpose for TDD isn’t testing per se. It’s strange that it’s called Test Driven Design when its primary purpose isn’t testing. Perhaps it’s a matter of semantics, but in my opinion, the simple unit tests that are created as a part of this process are a byproduct of the effort. The real output from this process is a design that embodies two very important traits: cohesiveness and loose coupling. For information on SOLID design principles, please see: http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod. This book has an excellent coverage of these principles.

Cohesiveness refers to the degree to which a class’s interface is well organized into single set of related responsibilities. This refers to the ‘S’ and the ‘I’ in the SOLID principles that are widely accepted as good Object-Oriented design principles.

Loosely coupled refers to the degree to which classes that work together to solve a problem are concretely knowledgeable of each other. In other words, how abstract are the relationships. More loosely coupled is desirable. This refers to the ‘L’ and ‘D’ and a bit of ‘O’ of the SOLID principles.

How does TDD fit into a SDLC?

In my opinion, before writing the first TDD test and subsequently any code, developers come together and through a general understanding of the high-level functional and non-functional requirements make a determination of the high-level architecture. They should be able to do this based on past experience with applications that are similar in nature. This decision process includes deciding what technologies will be used (WinForms vs. WPF vs. Mobile; SQL Server; etc.) and what high-level layers exist in the application (UI, Business Logic, Data Access). They should also generally have some ideas about how these layers will interact. For instance, you might determine that because you must support desktop clients, web clients, and automated processing that you wish to separate business logic into a separate layer and make it accessible via a web service. The latter might be skipped to begin with, but I think it’s helpful to form these mental maps early on.

Once the developers have this high-level roadmap, it becomes easier to proceed with work in specific areas, but the next part can be somewhat tricky. It is at this point that the team needs to figure out where to start working. Most TDD examples are very simplistic and in my opinion don’t help much in making this decision. Often, a developer will decide, “I know how I want the database to look so I’ll do the data model and procs and then code up my data access objects.” If that’s where they wish to start, they would create a test fixture for the DAO and then create tests that would drive the new methods that the DAO must provide to satisfy the test. As each test is written, the DAO has logic added to it to satisfy the new test. These tests are often very, very small and simple (that’s a good thing). The developer may try to “guess” all the corner cases that a consumer would hit against the DAO and would create a lot of tests to validate those and subsequently put code into the DAO to handle the cases. As you can imagine, the number of these small unit tests will be many. That’s OK since unit tests are supposed to be fast, atomic, and repeatable. It’s not painful to rerun them many, many times. The end result is that you have a DAO that has a well-defined public API for getting your data and you have a unit test fixture that exercises that logic based on “rules” that the developer established that the DAO was supposed to adhere to.

The above pattern would then repeat itself at the web service layer, the business logic layer, and potentially up into the UI layer. All during this time, you make numerous “assumptions” about how the code will be used by a consumer. As you move higher and higher through the layers of your application, you may be required to tweak classes in lower layers, but that’s OK. You have the benefit of unit tests to help you if your assumptions are wrong and you have to go back and refactor. Each change is supported by a compilation and execution of tests to ensure you didn’t break something along the way. This entire process should be iterative, fast, and focused on small sets of functionality.

However, the above scenario is where I’ve seen TDD fail. Why? Because the view is that the reiteration of changes as you move up the layers is seen to be expensive. It can be costly to go back and touch several layers lower down in the design. You often have to: 1) Identify a missing or incorrect assumption; 2) Identify where to make the change; 3) Change the test(s); 4) Change the code; 5) Recompile; 6) Rerun the tests. If your requirements are constantly in flux or you make lots of assumptions that are wrong, this cycle can be expensive.

Enter BDD…

BDD

Behavior Driven Development/Design

Similar to TDD, the emphasis in this practice is on Design not development. In contrast to TDD, where you often see examples or real-world projects that begin at the bottom of the logical application stack, BDD focuses on “Behavior” aka what the user experiences and sees from the application at the logical “top” of the stack. That’s why I refer to it as a top-down approach while I refer to TDD as a bottom-up approach.

Not surprisingly, it shares a TDD principles: 1) use tests to drive design; 2) use small, fast iterations to identify a requirement, codify that in a test, implement code to make the test pass, repeat. Why is it similar? Because BDD evolved from TDD. I believe many practitioners of TDD realized that the most important aspect of the apps we write is what the user experiences. As a result, the emphasis shifted from the bottom of the stack to the top and BDD was born.

So rather than starting with writing tests for a DAO, you would start with writing tests for a UI-related class that defines the behavior the user wishes to have. Depending on some of the prevalent design patterns for the UI technology you chose, you may have in mind various design patterns that are popular to use with that technology. For instance, Model-View-Controller (MVC) is very popular with web technologies, Model-View-View-Model (MVVM) is popular with WPF, and Model-View-Presenter is often applied for WinForms. Strictly speaking, when you first begin writing your UI tests and supporting code, it’s too early to choose one design pattern over another, but I believe it’s useful to have them in mind as you
code to see where the design is leading you. But most importantly, let the tests and the resulting behavior drive which pattern is the winner.

So why is BDD better than TDD?

Well, I believe that they are very closely related and in reality BDD is nothing more than a refinement in how to approach TDD. In my opinion, BDD is superior because it focuses on the most important aspects of the system you’re building – the thing the user experiences. Secondly, while I don’t have empirical evidence at hand to prove this, I believe it reduces the churn that is often experienced when you build systems from the bottom up. As long as you design and code in small chunks and focus on YAGNI (you ain’t gonna need it) and let the top-level classes drive the requirements for the lower-level classes then the amount of churn is less. Most importantly, you don’t need to make ASSUMPTIONS about what is needed. Your top-level classes as consumers TELL the lower-level classes what is needed and you code that and nothing else. YAGNI wins.

Where do Business Analysts fit into this process?

The emergence of DSL (Domain Specific Language) and tooling to support them have opened a number of possibilities. It allows the Business Analyst (or subject matter expert SME) to define the specifications for how an application should behave in a language they are familiar with. The tooling then “translates” that to executable code and with the help of the developer the required BDD unit tests are born thus driving the development of the app. This is often referred to as “executable specifications”.

One example of a tool like this is SpecFlow. This tool is a .NET tool that supports creating executable specs by integrating with numerous supported unit test frameworks like NUnit, xUnit, etc. The SME can write specifications in English sentences that conform to a predetermined structure that outlines pre- and post-conditions for each “test” and the tool converts those into actual unit tests, which the developer then implements.

@bradwilson of Microsoft did a demo of this tool at #agile2010 and showed how he was able to integrate the resulting test fixtures with a web-automation tool to drive the web UI of a project. The end result was a set of specifications written in English backed by executable tests written in the developers language that drove the creation of the web UI the end user wanted.

I hope this has helped to clarify the differences between TDD, BDD, and how it might apply to your development initiatives.

/imapcgeek

Agile 2010 - Day 1 - Evolutionary Web Development with ASP.NET MVC (Part 1)

Presented by Brad Wilson, Senior Developer Microsoft ASP.NET MVC Team

Part 1 – TDD

The first session for me of the Agile 2010 Conference in Orlando was the “Evolutionary Web Development with ASP.NET MVC” given by Brad Wilson (@bradwilson). The first 90 minutes of the three-hour session was dedicated to Test Driven Development (TDD) basics. Brad and his sidekick Scott not only demonstrated the fundamentals of how testing drives design, but gave a good example of how paired programming works. For me, the jury is still out on the effectiveness of pairing, but then I’ve never been in a team that it was encouraged or embraced so that it could sway me.

Although TDD isn’t practiced at my current company, I do use TDD in my personal programming projects and it was a good reminder for me of the fundamentals. Repetition is what helps to keep our skills fresh

A few key points from the first half that resonated with me were:

1) When developing, think in terms of component development that facilitates isolation making it possible to test your units in isolation

2) Use your tests to drive public API’s – tests should also only exercise publicly visible behavior

3) Your tests should be small, simple, and fast – makes it easier to run them over and over again. If anything, I’d add that the tests should also be repeatable though that wasn’t discussed (maybe it was just that obvious).

4) The basic workflow in TDD is – Green –> Red –> Green. Although, I’ve often seen the workflow start with Red where my tests initially fail until I provide the requisite implementation to make them pass. In fact, re-reading James Newkirk’s book on TDD starts off with the Red->Green->Refactor workflow.

5) Refactor, refactor, refactor – if you aren’t regularly refactoring, your code probably (almost surely) has a lot of smells. The beauty of the unit tests is that it provides the safety net and gives confidence that while refactoring you aren’t breaking the contract that you promised to provide in your implementation.

6) Replace your dependencies with “test doubles” (mock objects) – Brad’s demo touched lightly on Moq (http://code.google.com/p/moq/), which I hadn’t used before. It looks like a good framework and I’ll have to experiment with it myself to see, but having used NMock, and others, it appears to address some of their shortcomings (like mocking classes not just interfaces).

7) TDD is more about design than it is about testing. The conscious act of creating tests that define the specifications for the public API is a radical departure for anyone that has never tried TDD. It can represent quite a leap in style and thought process, but one that can yield excellent results. Most people that aren’t practicing TDD say they believe that the process would slow them down. I believe (though I have no hard evidence to support my argument) that it’s quite the opposite. If nothing else, it certainly yields a cleaner design that makes maintainability higher reducing time over the long haul.

8) A side effect of #7 is that the unit tests aren’t the goal; they’re an artifact of the process. This can be a distraction for some – myself included. Until you realize that the unit tests are a means to an end, you may lose focus on what they are supposed to be doing for you: a.) driving your design and b.) providing a safety net for when you refactor (you want to refactor don’t you?).

9) Refactoring should focus on small, incremental changes. In my second session of the day (which I’ll cover in another post), Joshua Kerievsky (pretty sure it was him) spoke up about the importance of refactoring to patterns to improve overall design.

I came away with a few little catchy tidbits as well.

1) xUnit – uses the word “fact” to avoid the stigma that developers have against testing. I began experimenting with xUnit after the conference and find it equally usable to NUnit, but it also emphasizes some best practices that NUnit missed (as James Newkirk’s blog pointed out, xUnit was developed after some experience with “programmer testing”).

2) “Do the simplest thing that can make it work.”

3) TDD drives a very small incremental development style. Add test, watch it fail, add code, watch it pass.

4) In the real world you would write the acceptance tests first – BDD then TDD. The acceptance tests will fail for quite some time.

5) TDD tests are the documentation for other developers. BDD tests are the documentation for the business.

6) @bradwilson, “TDD is like the scientific method.” You form a hypothesis, write a test to represent it, and then see if your assumption is correct.

7) The basic test structure should be similar to this:

// Arrange
Set up the conditions for the test

// Act
DO whatever work is required

// Assert
Validate that the results are what you expected

See (http://c2.com/cgi/wiki?ArrangeActAssert)

That pretty much sums up the first part of that session. In closing, the important takeaways were using TDD and refactoring to drive your designs and improve code readability and overall health. Though this session talked about using mock objects as a means to loose coupling, a later session with Arlo Belshee discussed other design patterns that can also help to achieve loose coupling, but that don’t necessarily have the same overhead that mocks bring. I’ll cover more on that in a future post.

Troubleshooting a Failed Deployment of WCF Services on IIS7

In this blog post I will describe a problem that I recently experienced while developing a new WCF service and deploying it to a local IIS installation on Windows 7. The details of the service itself are unimportant; rather, the specific problems are related to the deployment of the service and with the setup and installation of IIS.

When attempting to browse to the newly deployed service (which was nothing more than a stub at this point), I experienced two problems. First, there was no handler mapping for the .svc extension. After I rectified that, I received the following error:

HTTP Error 500.21 – Internal Server Error
Handler “svc-Integrated” has a bad module “ManagedPipelineHandler” in its module list

According to the error page that was presented, the most likely causes were:

1. Managed handler is used; however, ASP.NET is not installed or is not installed completely.
2. There is a typographical error in the configuration for the handler module list.

How I got here:

1. I installed the Internet Information Services through the Control Panel \ Windows Features dialog.
   
   
2. I then manually created a new Application Pool to host the new services web site.
   
   
3. From there I created a new Web Site to host the service.
   
   
4. Last, I set my publication settings in Visual Studio to push the service and its implementation to the newly created website. Executing the publish from the IDE all things went well.

 

When I browsed to the service in the IIS Manager, I received the dreaded error above.

The root cause of this is mainly a timing issue. Depending on the order in which you install .NET and IIS, then the WCF and ASP.NET handlers and related modules will not be properly configured. Fortunately, resolving the issue is fairly straightforward.

1. To resolve the problem with a lack of a .svc handler mapping, run the following:
   “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe –i”
   
   or if you are running with .NET 4, then the path is:
   “%windir%\Microsoft.NET\Framework\v4.0.30319\ServiceModelReg.exe –i”
   
   * Note that if you’re running on a 64-bit O/S you will need to change the path to use “Framework64” instead of “Framework”
   
2. Lastly, to resolve the error above, you need to re-run the ASP.NET registration using this command:
   “%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe –i”

Once you’ve done that, you should be able to then access your WCF service. Hope this helps resolve this for you if you run into a similar situation.

del.icio.us Tags: wcf,iis,iis7,aspnet

Expression Blend 4

I’m not sure where I missed it, but Expression Blend 4 is now out. I recently went back to create a SketchFlow project to model some stories I’m working on for a proof of concept application and found that Expression Blend 3 does *not* integrate with Visual Studio 2010. I posted a #fail message on Twitter and low and behold @mfcollins3 and @unnir were nice enough to point out that Blend 4 was not only out but *did* work with Visual Studio 2010.

Thanks for the info. I’m downloading and installing Blend 4 as I write this and will hopefully be back to sketching and designing again very soon.

del.icio.us Tags: expressionblend,sketchflow,vs2010

Lessons Learned from a Failed Vendor Engagement

We just terminated a POC engagement with a software vendor (to remain unnamed to protect the innocent :)) because of their inability to deliver a workable solution for our needs. From the beginning, the relationship between the two companies was somewhat iffy. I thought I’d share with everyone some insight into what we experienced as well as see if there were some key takeaways that might prove to be useful for the future.

The Problem

Our company does a tremendous amount of custom application development in support of our primary line of business. One area that we have identified that has room for improvement is the monitoring of the runtime health of our applications. We were seeking an enterprise scale solution that would allow us to instrument and monitor our applications and to be preemptive in identifying problems in production environments before they become outages affecting our end users.

The Process

Beginning with a failed LiveMeeting where the vendor completely missed the mark on what we were looking for, we finally got a high-level demo of the “product” that they felt would serve our needs. A number of hour-long telephone conversations were held and lengthy email discussions and questionnaires were completed all in a fact-finding and discovery mission to ensure that the vendor thoroughly understood our problem, our environment including network and hardware infrastructure, application architecture, etc. The conclusion of this was an agreement by the vendor to be on-site to assist with standing up a POC test environment with their components monitoring our applications. Our goal was to spend 2 days installing and configuring the system, wrapping up with a lunchtime demo of the installed environment, and a plan to spend the remainder of a week exercising our applications in that context to understand how the solution would help us. We never got there.

The Failure

Arriving as scheduled on Monday morning, the reps from the vendor arrived and began the process of installation and configuration. After a couple of hours, it became clear that there was confusion on their part about our environment. It forced me to walk through additional whiteboard discussions of what the environment was and how things were organized (reiterating many points that were made through the countless phone calls preceding the POC). To be clear, our environment is not complicated and when compared to many larger enterprises must be considered quite simple actually. So for a vendor that is positioned to address enterprises that are significantly larger, this already presented some concerns for us. Then came the confusion about which of their products we wanted to demo. Again, the details for all of that had been previously discussed, but confusion and lack of clarity reigned when trying to nail down which of their products would really solve the problems we had.

As the second day was winding down we found that they had completely forgotten an entire tier of our architecture and didn’t understand how it played into the big picture. It left us with a 1/2 complete install and they were scheduled to fly out. The best they could offer was to demo what they had and promise to call back in and via a remote session try to configure the last pieces – at the end of the week with teams of people left twiddling their thumbs unable to test what we planned.

The demo was the most frustrating of all. It was fragmented, bouncing between screens and products to try to get the “big picture” of system health. When trying to drill into specific areas, we would get “well this is how it should have worked – you get the idea” rather than really nailing the working example. Under the gun and with time running out before their flights, they packed up and headed out.

Lessons Learned

Some key takeaways for me in the aftermath of this process are enumerated below (in no particular order)

1. If you supply a product, it is a MUST that you understand your own product. If you can’t install, configure, or use the product to its fullest don’t bother showing up.
2. You MUST listen to your customer. Remember the old adage “The customer is always right.” Take the time to thoroughly understand the needs.
3. Do your homework before committing not only your time and money into something, but more importantly the time and money of your customer.
4. Don’t be afraid to say, “I don’t know the answer to that. I’ll get back to you.” Honesty is always the best policy.
5. Be honest when you know your product has gaps or is imperfect. Knowing the limitations helps make a more informed decision.
6. Technology is not a silver bullet; it will not solve all of your problems. It can help you make better informed decisions, but still needs a personal touch to make it work. Having competent people that understand not only your product but your customers and their environments is a MUST.
7. As a consumer, especially when dealing with products that are this large and complex, get recommendations BEFORE engaging the vendor in a POC

Some of these thoughts are pretty common sense and at least the last one would have saved us the headache and cost of this endeavor had I done that. I hope that others benefit from this experience and the feedback.

Good luck!

How Do You Manage Multiple Dev Environments?

I often am required to work on multiple versions of a product, some of which may span different versions of .NET, require different versions of Visual Studio, 3rd party controls, etc. Other times, I need a different version of the O/S for development or testing. What’s the best way to manage all those differences and keep from stepping on one environment or another?

My preferred way of doing this juggle is to use Virtual PC. The beauty with using Virtual PC for this is that I can configured a completely self-contained environment that has everything I need to represent the project I’m working on. I can quickly replicate it for the next project, change what is unique and be up and running with an environment that is customized specifically for my needs without breaking the first one, which allows me to return to it when needed.

One caveat with using Virtual PC for this: you need a pretty well configured machine to run it on especially if you want to load up resource intensive tools like VSNET, Resharper, etc. I highly recommend a minimum of 8GB of RAM – more if you can get it. In some cases, I’ll have more than one virtual spun up at a time and having LOTS of RAM is essential.

Perhaps the other tip I can offer here is to take the time to organize your virtual images based on O/S and tool sets installed. It will help you to duplicate an environment quickly and customize it to your needs.

How Does VSTS Recognize Which Projects Have Test Classes?

I recently ran into an interesting gotcha with VSTS 2010. I added a Library project to my solution that I intended to populate with integration tests. When I created the project, I chose the Class Library template. I then added a class to the project that would represent my test fixture. Expecting VSTS to leverage the [TestClass] attribute that I applied to the class, I went about adding test cases and attributed them with [TestMethod].

When I went to my Test View, the methods that I’d added didn’t show up :(  The problem was that I expected VSTS to behave similarly to NUnit, which reflects over the classes looking for the [TestFixture] attribute to figure out which classes contain tests. VSTS does not do it that way; rather, you have to modify the .csproj file to include a new element

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Once I added that element to the project, the Test View happily found my new tests.

Hope this helps you if you run into a similar problem.

del.icio.us Tags: unittest vsts

Free eBook: Programming Windows Phone 7 Series (DRAFT Preview)

While we were at MIX, we were given an opportunity to peek into the upcoming book from Charles Petzold on Windows Phone development. He has released a preview of the book that you can download now.

Check it out here:

http://blogs.msdn.com/microsoft_press/archive/2010/03/15/free-ebook-programming-windows-phone-7-series-draft-preview.aspx

Enjoy!

del.icio.us Tags: windowsmobile,phone,petzold,mix2010

Key Takeaways from MIX 2010

I had an opportunity to attend MIX this year in Las Vegas. I hadn’t been before, so I really didn’t know what to expect. Marketed as a conference for the web doesn’t do it justice – or maybe it’s just because the technologies that Microsoft now brings to the table to satisfy web development is so rich and diverse – but there is a LOT of information there for folks even if they’re not doing web development.

So what were the big takeaways? The message that I came away with was that there were four big areas of focus:

Silverlight

Impressive stuff here. Silverlight 4 really has stepped up to be a 1st Class desktop citizen. It’s ability to run as an out-of-browser application with elevated privileges really bridges the gap between older versions and WPF. I am honestly asking myself if we are seeing Microsoft make WPF irrelevant? While at MIX they demoed Silverlight running on the Windows Phone 7 platform and the Xbox. All with the ability to leverage the Expression Blend designer tool, which is an extremely powerful tool in it’s own right – probably unparalleled for XAML layout.

A big announcement from Microsoft was that they were making the development tools for Windows Phone development FREEEE. You can download them from here.

Cloud Computing

While I didn’t get the opportunity to attend but one session on Windows Azure, it was enough to convince me that it will make a big impact on design decisions for companies that want a fast low cost entry into a secure, reliable, and scalable environment in which to host their apps. This is a very new area, particularly for me, but the advantages are immediately obvious when you look at them – reliable, secure, scalable, open standards-based.

One new service called AppFabric that will really make this shine allows for Azure to integrate with on-premise applications. Imagine being able to run your LOB applications in the Cloud and take advantage of it’s capabilities, but also allow them to reach back into your network for secure data or other internal resources. Very powerful.

Open Data Protocol

While the last thing we want (or need) is another data access acronym to go along with ADO and all of its predecessors, OData (short for Open Data Protocol) is Microsoft’s commitment to data integration and interoperability. Many of the MIX sessions demonstrated consuming data using OData syntax through the browser, through RESTful web services. I expect this will be a game changer when it comes to how we write data services.

During the conference, numerous demos gave the same message – OData will make it possible to mash together data from numerous disparate sources and provide a seamless and compelling user experience. Imagine pulling data from Netflix, the local movie theaters in your area, and your own personal movie database to provide a single application on your phone to search movies. Now imagine doing that using a standards-based syntax that makes it equally easy to consume any/all of those data sources. Now imagine that you want to serve up your data using OData and being able to do it completely from within your web browser! All demoed this week!

IE9

The sessions didn’t have anything to do with the vNext version of Internet Explorer; however, the Day 2 keynote gave us some peeks into what’s in store for IE9. First – it’s FAST. Second – it’s standards based. Third – Did I mention it was fast? It was amazingly fast for developer code. It features a completely redesigned rendering engine that will leverage the power of multi-core CPUs. The demonstration of some of its polygon rendering capabilities and performance were quite compelling.

Its support for HTML5 and video were amazing. The other browsers will finally have something to catch up to. Watching streaming HD video at full frame rates with 50% of the CPU utilization of competitors was impressive – especially since the others were dropping frames like hot rocks.

That said, I’m still leery of the security issues that have plagued IE in the past. Let’s hope they’ve (or will) resolved those.

Summary

Collectively, these technologies come together to provide a rich development, deployment, and support environment. I expect them to go WAY beyond the development of just web applications.

I plan on writing more about each of these as I get the opportunity to explore them and employ them in my projects.

Starting Down the Path of Android Development

Awhile back I decided to begin doing some Windows Mobile development. Overall, it’s been a good experience and the tool support from VS2008 is excellent. The ability to debug your mobile app in a virtual device emulator is extremely helpful to visualize how your app will run on the target device platform.

However, now that I’ve had the chance to begin using the Motorola Droid and seeing their marketplace application, which gives access to scores of free and pay apps, it has convinced me that I need to begin looking at developing for this platform as well. In the short time that I’ve used this new phone, it’s clear that the user experience is far superior to WM6. Not having seen the new Windows Mobile 7 platform more than a couple of screenshots, it does look like it WM7 could be a strong competitor though.

My next posts will be about ramping up and getting started with a basic application for this platform. It should be exciting and hopefully I can help share some of the stumbling blocks that I run across to save you a bit of your own frustration.

del.icio.us Tags: windowsmobile,motorola,android