jmcd's Stuff -> Now at http://jmcd.nu/blog

Movin'

Mon, 11 Feb 2008 00:52:20 +0000

I tried Tumblr. It’s real nice, but is a bit limited in terms of tagging and commenting, so I’m moving the blog.

Microsoft and Developer Duality

Sun, 10 Feb 2008 11:22:00 +0000

There are two different Microsofts. On the one hand there is the Microsoft that everyone knows. They make Office, try to lock people into proprietary formats, butterfly around technologies that other companies are already successful in (MSN Search, Zune) and twice a decade release a new version of the leviathan that is Windows. This is the Microsoft that everyone knows. They are a fact of life that office workers, school kids and parents endure everyday. An office worker puts up with this Microsoft in the same way that she endures a crowded bus ride to work. This Microsoft is unnoticed and unloved.

There is another Microsoft. Only developers get to see this Microsoft.

Ten years ago Borland ruled IDE land, and Java was the language with momentum. Microsoft had the restrictive Visual Basic and the eccentric Visual C++. A decade of massive investment and hiring smart guys changed things. From the outside looking in, it feels like Microsoft removed a layer of PR from their development division, poured a bunch of money in and said “go nuts”. The result is a company that does actually produce some pretty good tools and has research that is more visible and quick to change. Visual Studio is king of the IDEs again, and C# is the language with widespread acceptance. Microsoft still follow others (Monorail/Rails -> MVC, DLR -> Ruby engine), either copying or “embracing and extending”, but they seem to do it in a much more cooperative way. In development tools land, the goal is not for Microsoft to kill the competition, just to make sure that developers have good tools that encourage developers and users to stay on their platform (and thus kill the platform competition). They sill produce a ton of crap (still waiting for good source control), and the high rate at which new (sometimes competing) technologies are unveiled can make it hard to wheat from the chaff.

There are two types of Microsoft developer. There is the disciple and the real developer.

The disciple hangs on every word Microsoft says, every product they produce. They likely have a bunch of MSDN qualifications that they use to bash you over the head to win arguments (they tell you “This is the official Microsoft way”). They know about the minutia of the tools, but don’t know how it fits together. They didn’t know unit tests existed until they were built into Visual Studio. They thought Java was stupid until C# came along (no wait, they still think it’s stupid). If they have heard of Ruby they think that’s dumb too, well they will until they notice DLR languages.

The real developer likes to know about fitting technologies together. They understand that software development is not about for loops, it’s about what drives your development and how you architect a solution. This developer might use Microsoft tools, they might use other tools. They use whatever is best and can fit into their environment (typified by the ALT.NET so-called “movement”). This type of developer fits well with the new, cooler Microsoft. Solutions are built from the most appropriate technologies, be they Microsoft, open source or other.

New Project --> Choosing Tools

Thu, 31 Jan 2008 05:39:44 +0000

I have a project I’d like to try for fun and learning. It’s been rattling round in my head for quite a while, and I think I’m finally ready to get going on it. It’s going to be a web application, and its green-field.

I have a rough idea of the domain, and some idea of bits of the UI. I’m pretty much free to choose whatever I like technology-wise.

I used to be a pure Java kind of guy, but in the last few years I have mostly been a user of Microsoft tools. I feel at this moment that the .NET platform is stronger that Java in terms of language implantation/features and in terms of developer tools. An added incentive to choose .NET is the new language features in c#, which I am pretty keen to try.

Choosing .NET for the domain doesn’t necessarily tie me to a Microsoft UI and/or database, but choosing SQL Server and ASP.NET does make things simpler.

Not a fan of traditional ASPX applications. Most of the time spent on an ASPX application seems to be developers struggling to fit in with the framework. The ASPX model is a mess; Microsoft tried to make it easy for developers to write applications by squeezing the Windows forms model of events and controls into a place where it only kinda’ fits via heavy ViewState and developer abstraction from the “metal”. Writing unit tests for ASPX code behind is pretty awful; you struggle to test the interaction of the user without using or implementing some MVP/MVC solution. So I was pretty stoked when I heard about the MVC framework that Microsoft is producing to address these issues, so I’m going to give that a try. If there were no MVC solution forthcoming from Microsoft I’d be going for Monorail, but there are extensions for the MVC framework that make writing RESTful applications easier that I want to try.

I’m going to pick a bit of Domain Driven Design that I like and have domain entities that are ignorant of persistence, and have repositories handle the interaction with the database. No one rolls their own DAL any more (unless they really have to), so I reckon I’m going to use Linq to SQL (I want to know about the Lambdas). I think this solution is appropriate when you are in a position to make the domain match the database schemata, but might not work if you have to interact with a legacy database.

Another choice which seems to provide a lot of Free Good Stuff is Rob Conery’s SubSonic. I don’t really know much about SubSonic, so I’ll investigate.

Process Driven Vs. Entity Driven UI Design

Wed, 23 Jan 2008 12:47:00 +0000

I used to enjoy writing HTML UIs, but then I had traumatic experiences with nested tables, CSS and cross browser compatibility and went cold on the whole experience. For a good five years or so I avoided the UI like the plague.

Since moving to a new job last year I’ve been much more involved with the “front-end” of the ASP.NET product that I work on. Things are much better than they were before. CSS support is good, and we are in the enviable position of having an internal product that we can define the requirements for (IE7). Now I find myself frustrated not by the tools so much as the approach to UI.

Our application has a UI which is notionally split into functional areas. Each area takes the form of a wizard type process, split into tabs. Each tab deals with populating data on a Domain Aggregate. The problem I find is that populating instances of classes collected by the Aggregate necessitates that each tab be further spilt into more components (sub-tabs or otherwise). This solution doesn’t really scale beyond Aggregates containing Entities more than a few layers deep, because no one wants pages with lots of levels of tabs.

These process type UIs work well when the data is simple and flat; for example at a previous job I worked on a project that had this style of UI. The goal of each stage of the UI was to collect data which would be used to perform a query whose results were displayed as the last stage.

I think the crux of the problem is that people try to cram edits of complex Aggregates into linear wizard type processes.

My current thinking is that when you are performing edits on complex Aggregates you have to forget the linear process and go to for more entity based approach. I’ve not implemented anything yet, but I’m thinking that instead of breaking down your UI into bloated processes you have a page (or pages) that allow you to search for entities, then navigate to a particular entity’s “edit” page. The edit page would just be a user friendly view of the Aggregate, exposing root entity fields, and providing navigation to sub entities and value objects own edit pages. Instead of providing context through the wizard’s tabs, a history type bread-crumb trail could keep a record of entities recently visited.

Anyway, just an idea at the moment. If I get some time to implement some of this I’ll update.

UPDATE

Here is an example. A simple customer order scenario. System contains customers, customers contain basic details and orders, orders contain items and oacking instructions. The traditional tabbed UI might look like this (but with straight lines)

So, the alternative might start like this:

I think a search page/results can be core to a lot of systems. It’s a paradigm that almost all users understand now. A unified search page that lets you search for multiple entity types from one location might be a good idea. Even combined results might be possible or desireable if you have cross-entity indices.

So, once we have search results we move onto viewing an entity, in this case the customer. All entity details pages could follow the same kind of pattern, maybe a summary, links to sub-entities and value-objects, and buttons to actuate operations on the entity.

The user has viewed the customer, and clicked on the orders link, this takes them to another page which renders a collection of the orders held within the customer. Clicking on a specific order might give us:

This seems like a lot more screens than the initial tabbed example, and it is. There are a number of key advantages though.

Each screen is significantly simpler. There is no real design as such, just a visual representation of the entity.
There is no navigation to worry about.
As we are not constrained by navigation, and are not bounded by tabs we can navigate beyond the cul-de-sac presented in the tabbed example.

Expanding on the third point; when we are looking at an order, we can now click on the order to present generic information regarding that product. This presents a level of detail that would be practically impossible within the confines of a tabbed UI.

Blog thing

Wed, 23 Jan 2008 12:44:59 +0000

I have it. First post etc.