Archive for the ‘Programming’ Category
Getting It Out of Our System
On the main Infovark blog — the “business” blog — I talked about how we threw the first version of Infovark away. Not the core idea, of course, but we dumped our initial database schema and restructured most of the code. Here’s the technical story behind that tough call.
Fighting the last war
We’d originally intended to build Infovark on top of an existing Enterprise Content Management platform. At the time, Gordon and I thought of Infovark mostly as an alternative ECM interface targeted at knowledge workers.
When we decided to strike out on our own, we realized that we couldn’t take the underlying ECM services for granted anymore. We’d have to build things like object storage and version control ourselves. And if we were going to create a mini-platform for our own use, we were going to do it right, by golly.
Drawing on my background with real estate MLS systems, database reporting tools, and electronic records management, I began to work on an amazingly flexible data storage tier. Gordon dove into the data access classes. We began creating the sort of system we’d always wanted to use as highfalutin IT consultants.
The system allowed us to do neat things like define metadata for an object on the fly and roundtrip it to the database. We could access those objects in code, or via XML or JSON web services. We could define multiple views for each object. Every object was searchable using a full text index or via SQL. We were quite proud of ourselves.
It was an utter waste of time.
Deep magic
Technically, what we’d done was construct an entity-attribute-value database model. EAV systems are technically complex beasts designed to solve one tricky problem: client domains that don’t have well-defined metadata.
The EAV model was initially developed for clinical records systems. These needed to accommodate a huge array of possible symptoms, complaints, effects, diagnoses, and interactions. A particular patient is unlikely to have more than a handful of issues at a time, however. It’s a rich set of metadata with a sparse array of values.
Think of those questionnaires you get at your doctor’s office. They normally give you a long form with lots of checkboxes on it. You tick a few boxes here and there to record your or your family’s medical history.
An EAV model is designed to store that type of information efficiently in a standard relational database, at the cost of doing some major code gymnastics.
Except in very limited circumstances, an EAV design is considered a database smell. Some go so far as to list it as a SQL design error. Joe Celko, author of several books on SQL, has an article on how to avoid the EAV of destruction.
EAV remains popular though, perhaps because of its close ties to Steve Yegge’s universal Properties pattern.
In fact, there’s a whole slew of alternative databases designed specifically to help with EAV problems: Column-based databases like Vertica, meant for data warehousing; XML databases like Mark Logic, for structured documents; CouchDB for unstructured content; and key-value stores like MongoDB. But I digress.
All of the hoops we jumped through to help store arbitrary data was overkill. We were making the problem harder than it needed to be.
The only positive thing I can say about the effort was that it was an itch we had to scratch. We had to get the old stuff from our previous jobs out of our system before we could focus on Infovark.
What we really needed
While the features we built were exactly the sorts of things a consultant or systems integrator might want, end users couldn’t care less about them. We’d unconsciously built a product for ourselves, not for our customers.
Our customers didn’t want to define their own data structures. They don’t want to learn about metadata or record types. They just want a product that helps them remember stuff. Figuring out what data to store or columns to index was our job.
So while the Alpha build was incredibly cool from a techie perspective, it wasn’t easy or fun for the typical knowledge worker to use.
We needed to do our homework. What do our customers need to get out of a personal information wiki? What items will they want to reference later?
How we manage that information under the hood should be completely invisible to them. As far as they’re concerned, Infovark is an actual animal that lives inside their computer that helps them find interesting things.
Back to the drawing board
Once we started looking at the problem from the user’s perspective, things got much simpler. We threw out the EAV approach and went with a much simpler data model. We gathered requirements to figure out what were the bare minimum number of data types that a typical knowledge worker would need. Then we began defining templates that gave users the ability to interact with these types in (what we hope) will be natural ways.
I guess it’s another example of the write big to write small principle. We built a general framework at first, capable of handling nearly any sort of object we threw at it, then drastically edited it back to hold the bare minimum needed.
Conclusion
It wasn’t that the EAV approach was wrong. It worked. We could have built on it. But it was a huge framework and it consumed a lot of our engineering effort. That’s time much better spent on things that our customers actually care about.
I wish we’d started with the simple solution. But I’m not sure we would have understood or appreciated it without trying the EAV approach first. We needed to get it out of our system.
And then we needed to get it out of our system.
Getting Up to Speed on Windows Installer
In our past jobs, Gordon and I worked as part of larger technical teams. As developers, we never had to worry about the installation routine. It’s a highly specialized area of software development. We had people to do that job for us.
Fortunately I’d had a little experience working with InstallShield but that mainly involved stepped through the wizard and trying not to adjust settings that I didn’t understand. (Which meant most of the settings.)
Working on Infovark, we’ve had to absorb a crash course on Windows Installer. Windows Installer is the official Microsoft sanctioned technology for deploying applications to Windows. If you want to get the compatibility logo on your product, you must use Windows Installer or a tool that generates Windows Installer compatible .MSI files.
Windows Installer has been around for a long time, going back to at least 1998. Version 1.0 shipped with Office 2000. In the time since, it’s gone through many changes and revisions. If you didn’t “grow up” with the technology over the years, it’s a daunting challenge to get up to speed.
We figured our best bet was to pick a software package to help us build our MSI files. But since we didn’t know Windows Installer very well, it was hard to evaluate which one to use.
The best place I found for information about Windows Installer and setup and deployment tools is InstallSite. Finding my way around was a bit tricky, but there’s lots of good information there.
I also found an awesome series of articles written by Robert Flaming about UAC and Windows Installer. There are a few stray articles not included in his table of contents: UAC in MSI.
The series describes the slow evolution of User Account Control and per-user settings from Windows 95 to the present. This helps put all the hacks and kludges in context.
This long history is what makes creating good software installation routines on Windows difficult, especially if you want to support multiple versions of the operating system. The differences between Windows XP and Windows Vista are particularly large.
So if you’re planning to deploy your software to the desktop, make sure to include a lot of time in your development budget for research, testing and troubleshooting. It’s harder than you think.
Software Craftsmanship
I’ve been a bystander in the Software Craftsmanship movement so far. I’m not sure why. I like the idea of software craftsmanship. I’m just not sure what it means in practice.
I’ve read the manifesto and considered signing it. I agree with the aims expressed there. I’ve also read the blogs of those skeptical or confused about the manifesto. I can’t decide what to do about it.
The best overview of the software craftsmanship idea is Mark Levinson’s Call to Arms article on InfoQ. It describes software craftsmanship as a response to the typical coding grind, where just-barely-good-enough software is shoveled out the door as rapidly as possible.
I understand and appreciate the feeling; I’ve been there. I know how much it hurts to release bad products that frustrate customers. But I’m not sure the software craftsmanship community has a solution to that problem yet. It’s early days, though, and over the past few months I’ve discovered some interesting ideas about software craftsmanship.
Glimmerings of hope
Recently I listened to a Hanselminutes podcast where Bob Martin discusses professionalism in programming. Uncle Bob made three points that caught my ear. He said that programming professionals:
- Embrace testing. When making changes to code, software craftsmen hold to the principle first do no harm.
- Refactor always. This ensures flexibility in the codebase by “keeping the gears lubricated.” Be mindful of small improvements you can make to your software. This prepares the way for making bigger changes later.
- Learn continuously. Professionals practice their current skills and attempt to master new ones.
On the subject of continuous learning, I recently watched Mary Poppendieck discuss deliberate practice in a webcast on InfoQ. The summary: To become an expert in any field, you need to seek out coaches that teach the skills you need and spend focused time practicing those skills. Continuous learning is about gathering resources, understanding the material, and gaining experience through repeated effort.
After listening to these two programming mavens, I remembered something I’d read a while back on Coding Horror about code kata. Dave Thomas, of pragmatic programming fame, coined the term code kata for exercises designed to improve programming skills. He has a list of code kata, but other code kata catalogs have appeared as well.
From strategy to tactics to execution
So maybe there’s hope for the software craftsmanship movement after all. We’ve moved from talking about abstract goals to ideas we can put into practice. There’s a slow consensus building as to what a professional looks like and how one becomes a professional. That’s encouraging.
Ultimately, software craftsmanship isn’t about signing a pledge. It’s about delivering quality product.
Writing to the Future Me
Every now and then I find a comment in my code that I’ve completely forgotten about.
When I run across one of these nuggets, I guess I have the same experience as someone who’s kept a journal for months or years. I read the note and think, was that me that wrote that? Did I know that I would come back here again? Was a sending a message to my future self?
// TODO: Improve the quality of these tests. DTHRASHER 6OCT2008
// We need to verify that the filter string is being generated properly.
// We need to add tests to verify sorting behavior.
// We need to separate the ActivityParameters unit tests from the MetaIndex integration tests.
// We need a staff of 10 developers to help us finish this product! ARGH.
These always give me a chuckle.
And then I think, what a jerk that DTHRASHER guy is! I can’t believe he left me all this work to do!
Domain Models in High Performance Systems
I skipped today’s DC Alt.NET meeting on JavaScript. With the other half of the Infovark tech team on vacation, I’m holding down the fort.
Fortunately, I was able to expand my programming knowledge by catching up on my blog reading, and particularly by watching Greg Young of IMIS give a presentation called Unshackle Your Domain at QCon in June.
If you’ve ever had to built a high-performance system or one that has strict auditing and reporting requirements, this presentation is for you. Greg’s company deals with financial systems, and you can tell he’s learned many best practices the hard way.
While I doubt we’ll need an architecture as robust as he describes for Infovark, I recognize many of the the problems and patterns he describes from my old jobs in software companies making records management software (auditing) and real estate systems (transactions and reporting).
The key insight is that for certain software solutions, it’s important to model state transitions as part of the problem domain.
But what I found most interesting was how his example system combined the principles of Domain-Driven Design with the older notion of Command-Query Separation.
I’d explain in more detail, but it’d probably be easier to just watch the presentation yourself.
Laughing in the Face of Errors
To a human, “I once met a man with a wooden leg named Smith” is the start of a old joke. To a computer, it’s a compile error.
Class 'WoodenLeg' has no 'Name' property or the property is not accessible.
If only computers had a sense of humor…
Validation in Domain Driven Design
There’s a great discussion on Jeff Palermo’s blog about entity validation patterns. Jeff takes the position that your domain objects (or entities) should not have validation logic “baked-in” to the class itself. Instead, you should separate the validation routines into separate classes that you can use to validate the object on demand.
There are two advantages to this approach. The first is that you can use different validators for the same object in different circumstances. For example, the validation you might perform prior to storing the domain object in a persistence layer could be different than the validation routine used to validate input from the GUI layer.
The second advantage is that separating the validation logic from the data itself makes it easier to work with ORM or serialization frameworks. Most of these frameworks encourage the use of Plain Old Objects, that is, objects without special attributes or interfaces that help with these mapping and serialization tasks. (See Wikipedia’s article on Plain Old Java Objects, for example.)
Those are powerful arguments, but I’m still not convinced.
Trade-offs
As a practical matter, Jeff’s advice is sound. It’s much easier to move business logic into the helper classes that surround your entity model. You get better tool support and more flexibility. But there’s two things about his approach that bother me. Judging by some of the excellent comments on his article, other programmers are bothered by them as well.
First, stripping away behavior from your domain objects is a recognized anti-pattern in object oriented code. Martin Fowler calls it the Anemic Domain Model. It harkens back to the days of procedural programming, where data and business logic were strictly separated. If you’re an OO purist, this is a red flag.
From an OO perspective, the need to validate the same object in different ways suggests that what you actually need to do is create more objects. Rather than pass a stripped-down data-transfer object (DTO) all the way from your data storage layer up to your GUI, you should have a bunch of intermediate objects to help transition the data and enforce proper behavior.
But I’m not an OO snob. Writing a whole bunch of extra classes to move information between tiers in my application is a hassle. I’ve done it before, and we’re doing it now with Infovark, but for most projects it just isn’t justified. Especially if you have to wrestle with various application frameworks to deal with correctly modeled but more complicated domain objects.
The second objection I have is that if we follow Jeff’s advice, we have to accept that bad data will creep into our domain. Jeff knows that this is a hard sell. It’s why he titled his article “The fallacy of the always-valid entity.”
Whew. That’s rough. That requires a whole different programming mindset. What about the problem of Garbage In, Garbage Out? Can we really create programs robust enough to handle business objects that might, at any moment, contain meaningless gibberish?
I don’t know. For now, as appealing as Jeff’s idea is, I’ll stick to always-valid approach. What do you think?
Review: Framework Design Guidelines
Framework Design Guidelines
I’m almost embarrassed to admit that I really enjoyed Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. I mean, it’s a book about coding standards.
Maybe I ought to get out more… but before I leave the glare of my monitor behind, I’ll type up my review.
Code is literature, not language
Computing languages, just like human languages, have grammar and syntax. There are correct ways to form sentences and paragraphs, with well-defined rules (and exceptions). Just like word processors can check spelling and verify basic sentence structure, most IDEs today can ensure your code will compile and run.
That doesn’t mean that your story or program is an easy or enjoyable read, though. Most newspapers have accumulated extensive guidelines for matters of style and substance, and most software companies have their own guides as well. If you’re writing as part of a team project, or writing programs intended to be used by other programmers, it’s important to make your code consistent, clear, and direct.
Just like many journalists keep a copy of The Associated Press Stylebook or the New York Times Manual of Style and Usage handy — even if they don’t actually work for the New York Times or the AP — lots of programmers keep a copy of Microsoft’s Framework Design Guidelines as reference.
Or they should. That’s probably my roots as a maintenance programmer showing.
Know your genre
Ideally, you’d want any code you write for other Windows programmers’ use to look as if it came from Microsoft itself. That is, you want it to feel like a natural extension of the .NET framework and not some third-party bolt-on with odd stylistic touches. You’d also like your code to use the full power and expressiveness of .NET, and not appear like some watered-down Java-esque port. (Far too many open source projects retain awkward Java-isms after being converted to .NET, in my opinion. NUnit is a notable exception.)
This helps your fellow programmers gain a better understanding of your code in less time. And it can also make your programming tasks easier, too. Just like design patterns can help you lay out your application architecture, programming guidelines can help you structure your code at the class or method level.
About the book
The Framework Design Guidelines covers a lot of ground in its 400 pages. It describes what conventions Microsoft uses when designing types, methods, and exceptions. It also describes the naming and design patterns that Microsoft uses in their public APIs. The topics are grouped by category and heavily cross referenced, making it easy to find your way around. The rationale of each guideline is explained, and the authors indicate the strength of each recommendation by marking it with the terms Do, Consider, Avoid or Do Not.
But the best part of the book is the stories and comments given by members of the Microsoft team. These are sprinkled throughout the book and give insight into why the guideline exists. Some of these discuss lessons Microsoft learned the hard way, places in the .NET Framework where the rules are violated, and how real-world programmers feel about certain guidelines. You can get a flavor of these by checking out the Framework Design Guidelines section of Brad Abrams‘ blog.
If you find his posts interesting or helpful, you’ll feel the same way about the book. Highly recommended.
The Times, They Are A-Changin’
Recently, I made a plea for the adoption of Universal Coordinated Time (UTC) in computer applications. It’s a sensible recommendation, and I stand behind it.
The folks working on HTML 5 are proposing a <time> element for the new standard. This makes sense to me. It will help eliminate some of the objections people have raised to the datetime design pattern proposed by the microformats team.
So, problem solved, right? We use UTC for time, and the usual calendar notation for dates. Neat.
Wait a minute. By “the usual” calendar notation, do we mean the modern Gregorian calendar, or…
There’s always a catch
Peter-Paul Koch, a.k.a. PPK, author of the quirksmode blog, reminds us that calculating historical calendar dates is hard. Really, really hard.
He provides an overview of the major calendar reforms in the Western world and points out that the reforms were adopted by different countries at different times. So forming a consistent timeline requires a knowledge of both time and place.
And many important historical dates float. The rules that determine when Easter occurs in the church calendar are complicated, and Orthodox and Catholic calendars disagreed for many years. In the medieval period, years were often numbered according to the local monarch’s reign. In Roman times, extra days were added to the official calendar by decree to prevent the seasons from drifting too far out of line.
If we want to make the <time> element safe for historical use, programmers would have to deal with this mess.
Leave it to the historians
As useful as having universal, consistent <time> element metadata would be, that’s just too hard. Frankly, I skimmed the last bits of PPK’s article myself, and I’m actually interested in the issue. Most working programmers won’t bother.
While it’d be nice to have trustworthy time data, we’re not likely to get it. The standard should reflect that. I vote for assigning a cutoff date for the <time> element. January 1, 1970 works for me.
REST: How to respond to an HTTP POST
I ran into a problem yesterday. I’d sent a HTTP POST request to a collection of resources on our RESTful web service. Our server responded with an HTTP 201: Created status code and the URI of the new resource in the Location header.
And then… nothing happened.
This was not what I was expecting. I expected my web browser to follow up with a GET request to the URI I’d provided. But Firefox 3 wasn’t biting. A problem with Firefox? I checked in IE8 and Google Chrome and got the same behavior.
Had I misread the HTTP spec? Did I misunderstand the REST pattern? I grabbed for my worn copy of RESTful Web Services. Nope. HTTP 201 seemed to be the right status for this situation.
Had I blundered into some common error? I checked Stefan Tilkov’s useful list of REST Antipatterns. But I couldn’t find anything that quite matched my situation.
I started Googling, but couldn’t find much apart from this question about HTTP Post on Stack Overflow. There were some cryptic responses (to which I’ve added my own answer now).
Eventually, I discovered what I needed to know from Ben Ramsey’s article on HTTP redirection. It’s part of his series discussing RFC 2616, which describes the HTTP/1.1 protocol.
The answer is that while web service clients will often “take the hint” provided by a HTTP 201: Created response, web browsers won’t. If you actually want a web browser to go somewhere else, you need to send a status code in the 3xx series. In this situation, the status code you want is HTTP 303: See Other.
Once I changed the status code returned by the server, all the web browsers followed up the response with a GET to the new URI.
