# Wednesday, 05 May 2010

Episode 85

In this show, David Isbitski and Matt Van Horn describe Behaviors, a feature that allows you to easily enhance the user interface of your Silverlight applications.

Wednesday, 05 May 2010 12:09:02 (GMT Daylight Time, UTC+01:00)

Microsoft Product Unit Manager Cameron Skinner came to the midwest to show off the Architecture features of Visual Studio 2010. He began his tour in the Detroit area, speaking at local companies in the afternoon and at the Great Lakes Area .Net User Group (GANG) in the evening. I recorded two of his presentations, which are available here.

Here is the presentation at GANG

Part 1:

Part 2:

Part 3:

Part 4:

Part 5:

Here is the presentation at a Detroit-area company.

Part 1:

Part 2:

Part 3:

Part 4:

Wednesday, 05 May 2010 03:04:35 (GMT Daylight Time, UTC+01:00)
# Monday, 03 May 2010

Episode 84

In this interview, John Petersen describes how to use jQuery, JSON and Ajax to enhance an ASP.Net MVC application.

Monday, 03 May 2010 11:28:46 (GMT Daylight Time, UTC+01:00)
# Friday, 30 April 2010

I began reading Agile Principles, Patterns and Practices in C# by Robert C Martin and Micah Martin after a friend recommended the chapters on pair programming.  My friend was right, of course. The Martins not only decribed pair programming but included an entertaining script of two developers pairing on a programming problem.

But, as I dove deeper into this book, I found a wealth of other information.

The book begins with a section on agile development, defining some basic terms and concepts recommended practices. It follows with a detailed section on good design practice. This second section is the most interesting, as it describes the famous SOLID principles. SOLID is an acronym for a set of good design practices:

S=Single Responsibility Principle: Each class should serve only one purpose and have only one reason to change.
O=Open-Close Principle: Classes should be open for extension but closed for modification
L=Liskov Substitution Principle: It should always be possible to substitute a derived class with its base class
I=Interface Segregation Principle: Interfaces implemented by a class are defined by the client objects that use that class; a class should implement a separate interface for each client that calls it.
D=Dependency Inversion Principle: To maintain flexibility, you should write code that depends on abstractions, such as interfaces.

Next, the authors present an overview of Unified Markup Language (UML), a graphical language used to describe software designs and requirements. Common UML diagrams and shapes are described and the author offers opinions of which ones are most useful and when to best use them.

The last half of the book is a case study of a Payroll System in which the authors use examples to illustrate the concepts introduced in the first half of the book.

Although C# is included in the title, the book does not focus on C# and almost none of the concepts are specific to any particular language. All the code examples are in C#, which makes it a bit more accessible if that is your strongest language.

The book is filled with lots of information and good advice. For example, the authors recommend an iterative approach to writing software, a test-first approach to development and encourage developers to refactoring their code frequently.

Whether you read all of Agile Principles, Patterns and Practices in C# or pick through the sections of interest, you will benefit from this book.

Friday, 30 April 2010 19:41:42 (GMT Daylight Time, UTC+01:00)
# Monday, 26 April 2010

Episode 83

In this interview, Eric Greene describes the advantages of using a Content Management System to rapidly build a flexible web site

Monday, 26 April 2010 16:02:50 (GMT Daylight Time, UTC+01:00)
# Monday, 19 April 2010

Episode 82

Monday, 19 April 2010 13:28:26 (GMT Daylight Time, UTC+01:00)
# Wednesday, 14 April 2010
  • Saturday April 17, I will be presenting "Building Your First ASP.Net MVC Application" at the Pittsburgh Code Camp at The University of Pittsburgh. More information is available at http://codecamppgh.com/codecamp.aspx

  • Saturday May 1, I will be presenting "Extending your Application with the Managed Extensibility Framework" at the Ann Arbor Day of .Net at Washtenaw Community College. More information is available at http://www.dayofdotnet.org/AnnArbor/Spring2010.

  • Friday August 7, I will be presenting "Effective Communication" at DevLink in Nashville, TN. More information is available at http://devlink.net.

Wednesday, 14 April 2010 11:57:00 (GMT Daylight Time, UTC+01:00)
# Monday, 12 April 2010

Episode 81

In this interview, Jennifer Marsman describes some of the new features of Windows 7 and how a developer can use those features to build more powerful applications.

Monday, 12 April 2010 05:27:31 (GMT Daylight Time, UTC+01:00)
# Sunday, 11 April 2010

Yesterday, I attended the second Kalamazoo X conference. This year's event featured a great list of speakers, presenting many thought-provoking topics. Ideas came at me so fast, it was tough to keep up. Here are some highlights of the presentations I saw.

"Treating the community like a pile of crap makes it stronger" by Brian Prince

The title of this talk comes from Brian's experience growing up in rural Maine and shoveling manure in the summer months. Manure works better as a fertilizer if you periodically mix it, moving the bottom to the top. The same can be said for user group leadership.
If you are a community leader, plan for a peaceful transition. Identify others who can take over and groom them to do so. Take some time off from the lead role in order to re-energize before coming back.

"Agile+UX: The Great Convergence of User Centered Design and Iterative Development" by John Hwang

John is a web designer and his company is applying agile methodologies to its project. He discussed the challenges of using Agile to manage User Centered Design (UCD) AND User Experience (UX).  The big challenge is that Agile is geared toward making developers more efficient, yet designers are a key part of any web development project. John avoids responding to amy Request for Proposal (RFP) because an RFP forceS you to estimate many tasks that you don't yet know and that are almost certain to change. He emphasized that development and design should be done in parallel and that the feedback loops and iterations of agile should apply to both. Developers and designers should work cooperatively, rather than in conflict.

"How to Work Effectively with a Designer/ How to Work Effectively with a Developer" by Jeff McWherter and Amelia Marschall

Jeff is a developer and Amelia is a designer and the two recently went into business together. They have worked together in the past and they related some of the challenges and lessons learned from their previous collaborations.

"Communication is the key" was a message they reiterated several times during this talk: Ensure that your partner knows what you are doing; verify that it is consistent with what they are doing and that the technology supports it. Developers and designers should strive to learn about the tools and skills of the others. It will help them figure out what they can accomplish.

Mock-ups are a key means for designers to convey information. Jeff said that he often writes business rules in the margins of Amelia's mock-up drawings.

"Does Your Code Tell a Story?" by Alan Stevens

Alan told us we should not bury the lead, so I will tell you his main point now: Beauty is the ultimate defense against complexity.

Alan took the advice of successful novelists and applied their principles to the art of writing code. "The code in our industry is crap", he asserted; then he explained how to make it better: Take chances; write shitty code in your first draft; refactor it several times; and make it clear, simple and obvious before releasing it.

"Unwritten Rules of Resumes" by Jeff Blankenburg

Jeff's major point was that your resume should stand out and distinguish you from other candidates. He advised ncluding a strong first paragraph in a personal letter, accompanied by a self-addressed, stamped return post card with your resume. This will help to establish you in the minds of the hiring personnel. Establish a strong professional network and avoid the temptation to burn bridges when you leave a company.

"Have you hugged your brand today?" by Clovis Bordeaux

Per Clovis, building a brand begins with a mission statement. A critical part of building your brand is getting every employee involved and on the same page, regarding the message you are sending about your company. 

Kalamazoo X home page



Sunday, 11 April 2010 17:31:03 (GMT Daylight Time, UTC+01:00)
# Tuesday, 06 April 2010

There is a reason why computer languages are called "languages". These languages share many common characteristics with the languages that humans use to communicate.

Humans use languages like English, French, Mandarin Chinese, and Farsi to communicate with one another. Programmers use languages like Java, C# and Visual Basic to communicate with computers.

Human languages contain words and each word has one or more correct spelling and one or more meanings; Computer languages have keywords that have a single correct spelling and one or more correct meanings.

Human languages have a grammar to which writers and speakers are expected to adhere. Deviating from this grammar makes it more difficult to understand the message. Computer languages also have a grammar that we call "syntax". It is not sufficient to throw together correctly-spelled keywords: They must be structured properly. Some languages have stricter grammar rules than others, such as a requirement that we declare each variable before using it.

Writing quality software in a computer language is similar to writing a good book or article in a human language. It is possible to write a poorly-written book in English that has perfect spelling and grammar. Microsoft Word will report no errors when you press F7 when editing such an article, but that tells us nothing about the quality of the writing, which may still be confusing or boring. Similarly, it is possible to write slow, non-scalable, difficult-to-maintain software that violates no rules of spelling or syntax. This software will compile but will not perform well.

The main difference between human languages and computer languages is the precision required by each. We can communicate reasonably well in a human language, even if we use poor grammar and poor spelling. This is because we have other communication mechanisms to use, such as expression, tone, gestures and a shared context with others. Computers are generally not smart enough to understand us unless we are very specific in the words we use and in the way we structure those words. We must be more careful what we type and how we compose our words when communicating with a computer.

This is why I believe that writing software has improved my communication skills in general. By forcing me to choose carefully my words and grammar, I get in the habit of communicating with greater clarity.

Tuesday, 06 April 2010 17:53:25 (GMT Daylight Time, UTC+01:00)