This week’s blog battle has begun!

We, those of us who fancy ourselves serious developers, like to disparage the enterprise developer who specializes in a class of application called Forms Over Data. The Business needs to save some data, so they have the DBA lay out a table. The developer then points their IDE at the table and drags input element on to the form and bind columns to text boxes and BAM!, they are done. System.DraggyDroppy. It doesn’t scale to Real Development. Not when I have a rich set of domain objects.

When I started full-on professional development, the summer before my senior year, I wrote web pages. Each page was a thin veneer over the database. Until I had to add more logic and added a bunch of ifs and elses in to the page. The fact remains, the data I was manipulating was pretty anemic. I’ll call this Pages Over Data. The difference is I have an implicit Fat Controller in my CGI script that the forms over data didn’t.

As I’ve done more desktop and mobile development, I’m starting to see that I’ve just done the same damn thing. Over and Over. It’s how I’ve always done it.

Recently, I have heard several people talk about software architecture. James Coplein has been promoting DCI. At work a few of us have been thinking about rereading Eric Evan’s Domain Driven Design. Despite none of these texts exploring a new idea, despite none of these ideas being things I heartily agree with, despite having evangelized and touted these ideas; I’m not very good at it. I keep finding myself doing pages over data.

What am I seeing? In one case, we had to stand up a bunch of screens for a user study so we’ve stuck a bunch of logic in Android Activity classes. While we’ve been refactoring this out, the odds are good we will always have some of that sticking around. In another case, we had a “business layer” that another team managed and UI designed a screen at a time. Our ViewModels had a lot of logic that we decided didn’t belong in the BL as that was a representation of only the data to be saved in the file and enough logic to ensure consistency and validity and undoing edits.

I can’t put my finger on WHY I don’t like these things, but I don’t. I’m on a quest to overcome the architectural momentum I’ve developed. Here’s what I’m going to do about it. I’m reading a bunch of architecture stuff. Reading along is only so good, so I’m writing a pet project a few times to explore each architectural style I’m working with. Hopefully, this will give me a better understanding of what I’m feeling and how well these styles work for me. So the next time I’m done with a project I don’t look back and say, “it’s just Pages over Data.”

This weeks Blog Battle was a song title. Just to make a point, here’s a video!

When I has a young software engineer, I was a Perl hacker. I could do amazing things because I spent so much time learning the ins and outs of the language. I blame, in part, Dave Mott for showing me what was possible. But also people like Damian Conway for things like Lingua::Romana::Perligata, a library that allowed you to write code with Latin grammar rules, because they showed me how to make the world a slightly crazy place with their code. And to enjoy code for its own sake.

I used Perl, not only in direct project work, but to slice and manipulate any data I had to deal with. I didn’t have a machine without it installed. At least is was not long until it was installed. When I did use it, odds were I would write code that others would call messy and dangerous. Calling methods that don’t exist. Rewriting the symbol table for just a little while. Writing code that changes file without opening them. It was there I learned that it can be easy to solve problems with a dash of black magic.

I started learning Ruby because all the cool kids were doing it. I’d heard about Rails, and I had seen it mentioned in both the Pragmatic Programmer and Extreme Programming Adventures in C#. I stayed for a while because of things like Rake, rSpec, and people like Why the Lucky Stiff, who, like Damian Conway, made the world a little stranger and a little nicer.

I explored “block” and finally understood what all that crap I was doing in Perl was now that “metaprogramming” had a name. Wrote my first internal DSL because I hated the language I was targeting. I learned that code needs to be ‘ergonomic’ and easy to understand. I still used magic, but I kept it in a corner of the code.

The weapons I’ve been looking at recently are mot because they are inherently useful to me, but because they make me think differently. Haskell, Erlang, Clojure, and F# are not things I can as immediately push in to a project, but they teach me about the form and movement of their usage. You see, C# is no longer as pure an OO language as version one was. You can make an argument that it never was pure, but it is taking so much more from other language paradigms because of people like Erik Meijer. And they have helped me write very different C# that is more expressive and succinct than anything I would have been able four years ago.

But what serves me best? In each case, I try to understand the language for what it is, not for what is is expected to be. Each feature should be approached with the beginners mind and explored from several angles. Each is different and can be used in a variety of ways. A master swordsman can strike with any part of the sword.

As I get older I realize my weapon of choice is not any specific language. I have favorites and some I understand better than others. Those are matters of fashion and taste. A master swordsman understand the sword so well, he can turn any object in his hand in to a weapon.

That’s my weapon of choice; what ever is close at hand.

A colleague bemoaned how Project Euler was far too mathy and not at all practical. He felt there needed to be a more useful version, like display a number of items on a web page. I mentioned that this sounded like a koan.

Koans? What are They?

Koans were first put together by EdgeCase as a series of exercises that used a test framework and heavily commented code to teach Ruby. They cover several topics; array manipulation, functions, exceptions, classes, etc. Many other language evangelists have attempted to use the Koan format to teach there favorite language. And for this, they are very well suited.

I loved the Ruby Koans. I enjoyed the Haskell Koans. However as far as they go teaching you how to use a real framework to do real work, they were anemic. But I still think there are some great things to learn from them. Especially if I want to teach some frameworks.

So, what are the principles if Koans and how can they be used to teach long-form ideas? And can I pick on an existing set of koans as either good or bad examples? Can I back up what I was talking about with real code?

Principles of Koans

Koans run quickly. They run until they find the next lesson, usually a broken test. There test errors should give you a file name and a line number. The lines near the error are filled with comments explaining what you need to know to make the next test pass.

Koans lead you down the path. Each step builds on what you’ve learned and adds a new twist. While they break in to larger topics in each file, then slowly build out the knowledge of that test.

Koans I’ve run, the good and the bad.

Speedy turn around is where the Haskell koans fell flat for me. First off, I had to compile several files before I found out if my solutions were correct. They weren’t, but I had to use the number of trues an falses output and the number of assertions made to figure out where I had made my mistake. I got it wrong, and you’re not helping! I would drop the Literate Haskell file type and just use the runhaskell command to fail the first file before the next even gets compiled.

One of the things I liked about the ruby koans was their simulation of TDD to guide the completion of a project. Yeah, it was a simple project, but still. It was me writing actual code to do actual work. It spiced up the exercise and was a nice island of diversion on the ‘path to enlightenment.’

Halfway There

I taught WPF for a company class. The project I had them work on was an iTunes clone. Each week I’d ask for them to get a little bit more done. Each week, I’d put a little more business logic up for them to use in their app. But I don’t scale. Don’t get me wrong, I’m not the best WPF guy in the world. I might even be average. But I want to share what I know.

What keeps my project from being a Koan is a lack if automated tests. If I had some test failures mixed in that would guide them to success, then we’d have a winner. But I couldn’t use plain old NUnit to handle it. I’d need to deal with leading them in steps to writing code that I can eventually compile against. It is possible that the C# 5 compiler as a service will help smooth this out some for my WPF example, but reflection can help. As for Matt’s world, odds are he will get this for free by using a dynamic language like Python or JavaScript.

A successful take on this was the Rails for Zombies project. So what Matt Swanson and I are proposing isn’t anything new. It just takes time and planning, trying to make everything build out in an order that allows learning and several small projects to actually live and breath.