Listen Now

Yesterday I attended a presentation at the Dallas .NET User's Group. Norm Headlam presented the Microsoft Patterns and Practices Web Service Software Factory (or Service Factory for short). You can download this tool from http://msdn2.microsoft.com/practices. Follow the "Web Service Software Factory" link.

Norm demonstrated how the Service Factory generates a solution with a set of well-organized projects. It generates a service layer, a data contract, a business layer, and a data access layer. Each of these assemblies has one and only one role. The service layer defines the web service. The data contract defines the data types that are exchanged between the client and the server. The business layer contains all of your business rules. And the data access layer interfaces with the database.

No longer will you return a dataset from a web service. These layers are separated according to best practices.

Norm showed how the Service Factory offers ongoing guideance. It doesn't just generate this skeleton and leave you to fill it in. Instead, you right-click on your projects to add data objects, data containers, and service endpoints. As you work, the Service Layer keeps a log of your changes. And it gives you links to your most likely next step.

Web services are no longer generated from your code. Instead, your code is generated from your contracts. You can import a database schema as a data object in the data access layer. Or you can import an XML schema to generate an object in the data contract. This is not like NHibernate, where the data layer is generated at runtime from business objects. This actually does it the right way, where the stored procedures that your DBA authors are honored, and all code is generated at design time.

The only problem I have with Microsoft's Web Service Software Factory is the name. This is not a Software Factory.

According to the book (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools), a software factory is a set of tools that generate several products within a software product line. All products in a product line serve the same vertical domain. They are described using domain specific languages.

"Web services" is not a product line. It is a horizontal slice of software technology, not a vertical problem domain. And these tools, useful as they are, are not a domain specific language. I look forward to using Service Factory on a real project in the near future, but I will also continue to create software factories in the real sense of the term.

Listen Now

Colorful language is not terribly helpful in a bug report. The best quality assurance professionals document what they were doing, the expected behavior, and the actual behavior. The outstanding quality assurance engineers probe deeper to find patterns. Let me tell you about one such individual: Chris Sachnik.

Listen Now

If you're new to the show, then welcome. If not, then you probably know that I am a Java programmer by day, and .NET by night. So it may come as a surprise to you that I have purchased a Mac. I got a 15 inch MacBook Pro. The "entry-level" version with a 2.2 GHz processor, not the 2.4. And certainly not the 17 inch boat that frankly should come with a set of trucks so you can ollie and rail slide your way to work.

If you are not new to the show, then you probably know that I am passionate about quality. I'm on a constant quest for quality in my own software and in the software that I use. I've heard it said that people who love software want to build their own hardware, but I didn't really understand that until I used my new Mac. This thing was built to run quality software.

For one thing, you have the specs. This, like I said, is a 2.2 GHz laptop. It comes with 2 Gig of memory and a 5400 RPM hard drive standard. You can't choose anything less and still have a MacBook Pro. Apple just won't let you. Other manufacturers sell similar specs for the money, but their stuff appears less expensive because you can buy less machine.

For another thing, you have the screen. This 15.4 inch monitor has a 1440x900 resolution. That's the same as the 22 inch panel on my desktop. Do the math ... the not new among you know that I love to do the math ... and you see that this screen is twice as dense! Apple won't let you see a pixely picture. There's a reason that Safari looks bad on Windows ... it was designed for a Mac!

So this is hardware worthy of quality software. It begs for quality software. In fact, if you write crappy software for the Mac, nobody will use it. The Apple community has come to expect a certain level of polish on their apps. Sure, some of them only go skin deep, but at least the effort is visible. I use an open-source instant messenger called Adium, and even this little app has the clean simple look of OS X. It even has a gorgeous little green duck icon that looks great sitting in the dock next to the Garage Band guitar. I'm a Java developer, so I know. You're lucky if we replace the coffee cup. And when I'm writing a Windows app, 16 colors and a copy of Paint is good enough.

But you know that I can't live without my .NET. Having written in C#, I never want to go back to C++. The Mono Project isn't keeping up, so I, of course, installed Boot Camp and Vista on this baby. And let me tell you, it runs Vista like a dream. I can't imagine the heat that the Boot Camp team gets in Cupertino for writing Windows drivers, but they did an excellent job.

Anyway, it's not my intent to become a Mac bigot or to convince you to switch. I just know quality when I see it, and the not new know that I'm all about the user experience.

My name is Michael L Perry, and I run Windows on the Mac.

Listen Now

Charles Martin of Before You Are Gone shares some of his time-tested web development techniques. And we even make some up on the spot.

First, consider creating separate servers. You need at least four. Start with a development server where the team can first integrate their code and see if it works. Then deploy to a test server where your QA team can exercise it. Practice your deployment on a staging area separate from the others so that you can be certain that you can upgrade the current production release to the next one. Finally, of course, you have the production environment, far removed from the others.

For the love, don't develop in production!

Second, the separation of style from content is essential to modern web development. Always create a CSS file rather than embedding style within the page. Understand how specificity determines how styles are applied to elements of a document. And to test your CSS file, consider creating a single template page that includes examples of all elements that you use in the entire site. This gives you one place to look to see if your CSS change affects anyone else.

And third, configure your environment to report all Javascript errors. Web browsers are very forgiving by default. They have to be because of all the legacy code that is out there on useful sites today. Since you don't have a compiler to check for errors, you have to rely on the browser to perform that function. Let it tell you about all the errors on your pages, and test each page on all major platforms. Now that we have Safari for Windows, the Mac - and the iPhone - cannot be ignored.

Listen Now

Several recent events are converging on a common theme.

Windows Presentation Foundation brings new user interface possibilities to Vista. Silverlight delivers WPF to the browser. Microsoft’s surface computer let’s us interact with the computer on a near-tactile level. Steve Jobs announced that the programming model for the iPhone is Ajax in Safari. Apple ported Safari to Windows. And Google Gears allows you to run a web application while not on the web.

All of these events demonstrate that the new programming model is markup and script. This has been the programming model for Web 2.0, but it is now it is breaking out of the browser.

This programming model has some promise, but there is a dark side. This moves us away from computer science based in proof. The tools that we have chosen to use for the new programming model are usually dynamically typed. With the exception of C# in WPF, the scripting languages that we bolt on to the markup are neither compiled nor statically typed.

Static typing is not just a way to give us intellisense, but it is a way to express intent in the form of a contact. Type checking is one simple way for the compiler to check a contract. But wouldn’t it be great if the compiler could do even more for us? Current research languages can prove that null pointers are not derefferenced. And with existing theorem provers, it is feasible to verify preconditions and post conditions at compile time. Despite the apparent evidence to the contrary, the web model is leading away from a path of increased productivity.

In addition, the web model does not support real-time collaboration. The best we can achieve with a request/response protocol like HTTP is rapid refresh. That solution is not scalable, and not feasible for many kinds of highly collaborative applications. And even when it works, the programming model forces developers to be aware of the fact that they are checking for updates. They can’t just express the relationships among objects and leave it at that.

I see a new programming model on the horizon after the markup/script wave has passed. In this programming model, the code represents the relationships between objects, not the triggers that cause the next domino to fall in a Rube Goldberg machine made of script. The compiler and the runtime can work together to make inter-related objects behave in a provably consistent way.

Update Controls is the first step along this path. With this library, you express the relationships between your user interface components and your data. You say what is to be displayed; the runtime takes care of when. If the data is changed in one window, the library pushes that change to the others automatically.

The next step is a collaborative object model that pushes those changes across the wire. When that step is ready, data can be changed on one computer, and the effect will automatically appear on another. Best of all, application developers won’t need to code that behavior. They simply express the relationships among objects and the runtime makes it happen.

I hope you will be with me for the next few steps in our evolution. The future is rapidly approaching in which we bring great value to our clients. It’s closer than you think.

Links:
WPF
Microsoft Surface
iPhone programming model
Safari for Windows
Google Gears
Update Controls

Listen Now

A recent article in MSDN magazine introduces several new features of C# 3.0. The goal of these changes was to add query capabilities to the language. Lambda expressions were added so that the where clause could be written. Lambda expressions required type inference. Type inference allows for anonymous types. But anonymous types could not be stored without implicitly typed variables.

These features could not be added individually. Each feature brings capabilities to the language that are incomplete without the others. This is an excellent example of closure.

The idea of closure appears often in mathematics. The set of integers, for example, is closed under the operations of addition, subtraction, and multiplication. If you add, subtract, or multiply two integers, the result will be an integer. Introduce the concept of division, however, and the system is no longer closed. Now you need a larger set to express the possible outcomes. You need rational numbers. Introduce exponentiation, and now you need the reals.

In software, closure is often a consideration in language design. But it can also be applied to applications. The set of states that can be represented should be closed under the set of operations that the user can perform. If the user can perform an operation on the system that would put it in an invalid state, then that operation is a design flaw.

Join the panel as we discuss several issues from past experience that were solved or could have been avoided by applying the concept of closure.

Listen Now

On the SSG oven software project, Raymond and I used several mathematical truths to prove that the design met the stated requirements. Three of those truths are mapping, scope, and partial order.

A mapping is a function from one set, called the domain, to another set, called the range. The range is not larger than the domain. If the mapping is one-to-one, then a reverse mapping exists and the range is exactly the same size as the domain. A hash is a many-to-one mapping, so the range is smaller than the domain. Therefore, no reverse mapping exists.

A scope is a context in which simpler objects reside. You can abstract the relationships among the enclosed objects as relationships among the scopes in which they live.

A partial order is a transitive relationship between objects in a set. It is not as restrictive as a full order, but allows for some independence. A partial order, because it is transitive, must be acyclic. Replacing a full order with a partial order can relax the constraints on a design, and give you room for optimization.

Your homework is to design an Integrated Circuit designer. Allow the user to build a component out of other components. Prove that your design does not allow the user to create a recursive cycle.

http://www.beforeyouaregone.com/
http://www.clipperz.com/

Listen Now

If you’ve taken a course in analysis of algorithms, then you’ve learned how to prove that an algorithm will have a certain result. You’ve proven that quicksort will terminate, that it will actually sort the list, and that it will complete in n log n time. But in the real world, all of the sorting and searching algorithms are already written. We no longer need to prove algorithms. Now we need to prove designs.

Cycle of discovery
Programmers tend to work in a code-test cycle. We’ll write some code, then we’ll see if it does what it should. Then we’ll go back and change the code and test again. The cycle continues until the feature is complete. This is a cycle of discovery. This is how we explore new things. This is the scientific process. This is not how other engineering professions work. Sure, it gets the job done, but it’s not the most efficient way to do it.

Agile development techniques put new labels on the cycle of discovery. Now instead of code-test we have red-green-refactor. But it’s still the same cycle. We don’t know ahead of time that the code we are about to write is correct. We just keep typing until it works. In this world you don’t know how close you are to the finish line until you cross it. How are we ever to estimate our work? Or mitigate risk?

Would you buy a house from someone who says, “let’s just keep nailing boards together until it looks like a building”? Of course not. But most software is more complex than a house. It takes longer to build. It has more moving parts. It’s more expensive. We should be doing at least as much as a home builder to ensure that we will deliver the right product, at high quality, on time, and on budget.

We can do that by proving our design.

Cycle of proof
In my day-to-day work, I follow a different cycle. I’ll learn the requirements of a feature, design the feature, code it once, and then fix bugs. I don’t spin in a tight code-test cycle. Once I know what the design should be, I just sit down and write it all out. Sure, I may have bugs and typos, but they tend to be easy to fix. I may go days between compiles, but in the end I know that it will work. I know because I’ve proven it.

Listen Now

Raymond and I have been working on a time crunch project for the past week. We take a break from our design work to discuss the project so far. We've been fortunate to work with an experienced team of professionals -- SSG -- who understand how to make a softawre project succeed.

SSG pulled together an exhaustive requirements document. This document is an outline-numbered list of line items, each one describing one functional aspect of the system. The requirements document gives the team a common set of goals from which to work. It doesn't explain exactly how each of these functional requirements are met. That job is left to the user experience designers.

SSG hired a user experience design team to construct a conceptual model of the system and translate that into a series of wire frame designs. A wire frame shows the visual components that comprise a system, but don't attempt to make those components attactive. For that, SSG has hired user interface designers.

The user interface design team is skilled in graphic design. They provide the artistic talent to make the user experience look good. That leaves Raymond and myself on product development. We are primarily responsible for making the system work.

SSG was seeking a parallel workflow between user interface design and product development. They chose to use Windows Presentation Foundation to separate those two processes. However, Raymond and I decided that the introduction of such a new technology to such an urgent project would add too much complexity. So we advised that we use Update Controls instead.

Fortunately, we may be able to bring WPF back into the project after the demo. It seems entirely reasonable that a XAML document could lay out Update Controls in addition to the more typical components. This should give us the best of both worlds: parallel development tracks and isolation of user interface components.

One other developer is involved in the project. While Raymond and I are creating the user facing parts of the system, an employee of SSG is working on integration with custom hardware. To mitigate risk on this integration, we designed an interface ahead of time. The interface accepts memento objects instead of business objects to further mitigate the risk of changes to the interface. Whereas business objects are likely to change, mementos tend to be more stable.

The design and techonogy decisions that we've made are driven by not only the requirements of the system, but also the structure of the team that is building it, and the time table in which it must be delivered. In future episodes we'll delve into some of the detail of design and implementation, and let you know how the project is progressing.

Listen Now

Refactoring is the process of changing the structure of code without changing its behavior. Martin Fowler coined the term when he wrote the book on the subject. Not only does the book define refactoring and describe when to use it, but it also provides a catalog of recipes for refactoring code. By iteratively applying these transformations to a system, Fowler says that you can evolve the design of existing code.

I use refactoring in my day-to-day coding, but not in the way that Fowler recommends. I design my software systems up front. I don't expect the design to evolve into a good solution. However, I will often use the automated refactoring built into tools like Eclipse as a way to edit code. The tool is a faster typist than I am, and it won't make a mistake due to a copy/paste fumble.

Refactoring, as most agile development techniques, works best when you have a small team of talented developers working in uncharted territory. Agile techniques move the methodology out of their way and allow them to be talented. However, if you know where you are going, it is much better to draw up a plan to get there.

http://www.refactoring.com/
http://www.eclipse.org/
http://www.jetbrains.com/resharper/