# Tuesday, April 30, 2013
Tuesday, April 30, 2013 7:10:00 AM (GMT Daylight Time, UTC+01:00)
# Thursday, April 25, 2013


I first heard about the Global Windows Azure Boot Camp in February, while attending the Microsoft MVP Summit. Azure MVP Magnus Mårtensson told me about a day that he and his cohorts were planning when cities all over the world would simultaneously host an event designed to teach people about cloud computing and Windows Azure. Students, instructors, and organizers in each city would be able to collaborate and order to learn more about this exciting technology.

It's two months later and I find myself preparing to host one of these boot camps - this one in Southfield, MI. My friend Mike Wood is helping to organize the event, both globally and in Columbus, OH and he forwarded to me some people in Michigan who had heard about the event and were prepared to drive to Columbus to attend.

So I began planning and it is now rolling forward at full speed. 65 people have already registered for the Detroit Azure Boot Camp. I've enlisted the help of Victor Szalma and Susan Yount to help present some material; and Brian Korzynski and Ed Hanlon will be assisting with the logistics. Sogeti and Microsoft agreed to sponsor the event, which means we can keep it free and provide lunch for everyone.

Each attendee should bring a laptop with Windows 7 or 8; Visual Studio; and the Windows Azure Training Kit installed. In addition, they should sign up for a Windows Azure account prior to arriving at the event.

The format will be a combination of classroom-style presentations and hands-on labs and the goal is to give each student a basic understanding of Azure, some hands-on experience and a chance to dive as deeply as they can.

If you would like to attend the Detroit Azure Boot Camp, you may register at http://detroitazurebc.eventbrite.com/. If you are looking for a Boot Camp closer to your home, you can find a list of all 96 locations at http://globalwindowsazure.azurewebsites.net/?page_id=151

Thursday, April 25, 2013 1:55:42 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, April 23, 2013
Tuesday, April 23, 2013 7:06:00 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, April 16, 2013
Tuesday, April 16, 2013 6:53:00 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, April 9, 2013
Tuesday, April 9, 2013 6:50:00 AM (GMT Daylight Time, UTC+01:00)
# Tuesday, April 2, 2013
Tuesday, April 2, 2013 6:44:00 AM (GMT Daylight Time, UTC+01:00)
# Saturday, March 30, 2013

My youngest son recently completed his senior season of high school basketball, ending my 8 consecutive years as a high school basketball parent.

To commemorate the occasion, I created a highlight video of his team's season.

Saturday, March 30, 2013 2:25:07 PM (GMT Standard Time, UTC+00:00)
# Monday, March 25, 2013
Monday, March 25, 2013 2:28:00 PM (GMT Standard Time, UTC+00:00)
# Tuesday, March 19, 2013

When building a new application, you can start coding at the front, you can start coding at the back, or you can approach development randomly and just start wherever. I encourage you to start at the front-end of your application.

I came to this approach a few years ago while working on a new feature of an existing application. In the past, I had always started with the database (probably because my first language was the data-centric FoxPro language).

The new feature required a new database table and several new web pages. My partner and I split up the work:  He would write the forms and business logic; while I would create the new table, stored procedures, and data access layer. I immediately jumped to work, creating stored procedures and C# methods. I created procedures and methods to add a row, update a row, delete a row, return a single row by its ID, and return all rows in the table. After a few hours, my colleague was ready to integrate his code with mine.  “Where is the method to return all rows matched by last name?” he asked me. This method did not yet exist, so I wrote a function to search by last name and return matching rows. A few minutes later, he asked me for another method I had not yet written, so I wrote that one. After a few hours, I realized I had written almost none of the methods my partner needed and he used very few of the methods I had written in advance.

A light went on in my head: My approach was very inefficient.

The next feature we added, we took a different approach. We didn’t write any stored procedures or data layer methods until we had written code that called these methods. We started with the user interface, which told us which business objects and business logic we need; then wrote those business object classes and business layer code. The business layer in turn taught us what data layer methods and stored procedures we needed to write.

This is the approach I have taken ever since that project. I start with the part of the application closest to the front for which I know the requirements. I use each application layer to define the interface of the layer that it calls. This leads me to write only the methods that I need and ensures that each component has an interface that makes sense to those calling it.

This is the same philosophy used by proponents of Test-Drive Development (TDD), who advocate writing a failing test as the first test.

Starting with the front of my application and working my way back to the database has helped to keep my application interfaces, clean, lean, and logical. It took me a few years to learn this, but my code has improved since I did.

Tuesday, March 19, 2013 2:03:00 PM (GMT Standard Time, UTC+00:00)
# Monday, March 18, 2013