Kirsty Busfield

Unleashing the Geek

MVP: One step forward, 1 billion left to go.

So, Mix has started. I must say I’m very jealous. I even found myself looking enviously at a picture of the contents of the goody bag earlier....I must get a life.

 Anyway... Work has started on our MVP migration. Even I was struggling to keep a smile on my face. It’s not the passive view per se that’s caused me pain today, it’s the unit and spec tests that go alongside it. As we’re not doing the whole enterprise app straight away, there’s still lots left structured the ‘old way’. So much pain was caused trying to get the ‘new’ and the ‘old’ to sit alongside easily.

The way we have decided to do it, is to start with the new pages first. Any new screens will use passive view. We will ‘upgrade’ the others as we go. With the addition of a new project to our solution, I set-to with enthusiasm. I’m still really nervous that the folder structure we’ve added in there won’t be extendable easily and a couple of years down the line our ‘successors’ will be moaning that it wasn’t properly thought through. But it really was, I promise. It’s just really difficult to predict the future. And when you’ve not got the experience of doing this with another enterprise app before you don’t even have hindsight to fall back on.

If anyone has a suggestion for a good set of folder names to structure the mvp project, I’d really appreciate that. Eg ‘presenters’, ‘views’, ‘models’ sub folders; ‘interfaces’, etc etc. I know it sounds really lame to be worrying about folder names in the grand scheme of things. But when it comes down to it, the folder structure is the first thing new developers to the application will see, and in an enterprise app making things as transparent as possible is key. It's not always about starting with the complicated things first!

On a lighter note, I have a bit of geek rivalry going on between me and a friend and a couple of people we know. Infact it was mentioned today that the ‘geek-gauntlet’ has been thrown down. :-)  So what I want to know is how do you measure ‘geekness’, how can we know when we’ve won (as I’m sure we will). Do any of you out there think you are more geek than anyone else you know, and if so how have you achieved it? Lol. Any comments gratefully received. ;-)

Posted: Mar 05 2008, 08:56 PM by kirstybusfield | with 6 comment(s) |
Filed under: , , , , ,

Comments

rrobbins said:

The main factor by which I measure geekness is the quirky nature of the technology you use. For example, I bought the Linux kit for the Playstation 2. That is terribly geeky because most people don't run Linux on their game consoles. I also run a mainframe emulator, BABY/400, on Windows to study RPG II programming. That is uber geeky. You score extra points for anything involving mainframes.

# March 5, 2008 4:54 PM

kirstybusfield said:

...mainframes... thanks for that one, will note it down. ;-)

# March 6, 2008 3:07 AM

Jeff Brown said:

Hmm...  Do TI-99's and cassette tapes count?  Sorry no punch card experience.

Anyways, folder names should reflect how you think about your application.  Consequently you can (and should) change them as your perspective shifts.

Personally I avoid catchall names like "Interfaces".  What kinds of interfaces are in there?  How are they related?  So I'll choose names like "Model", "Core", "Framework", or "Runtime" to group infrastructure concerns.  Then I'll break them further down into modules.  "Core.Logging", "Core.Collections", etc...

If we're just talking about interfaces for Presenters or Views, then why not just colocate them with their concrete implementations?  Client code can just promise to use the IoC to resolve the dependency even though the implementation is plainly accessible.  This approach works quite well and enables you to focus on more important divisions of labour.

Separation by tier can be useful but it also creates its own problems.  If you have a folder with 100 views in it and another one with 100 presenters then maintaining the parallel structure can become tedious.

At that point you might choose to decompose by functional unit (module) and then by tier.  So Registration/Views/MyView.cs instead of Views/Registration/MyView.cs.  YMMV.

At a certain point the decomposition will transcend folders within a project and you will consider using multiple projects.  For example, you could end up with a project consisting only of interfaces.  Arguments in favour may include enforcing separation of concerns across horizontal tiers.  Arguments against may talk about separation of concerns across vertical applications.

Anyways, just see what works.

# March 8, 2008 2:20 AM

kirstybusfield said:

Jeff, thanks so much for taking the time to share that. It's really helped!!

Kirsty

# March 9, 2008 2:21 PM

Jeff Brown said:

So how is it going?

You should post more often.

I've been looking forward to more infectious enthusiasm...  ;-)

# April 8, 2008 7:42 PM

Roman said:

It sounds like you are hitting similar anxiety that I experienced when I just started with MVP.  Just to note, the software design is an iterative process. I stopped worrying about what happens years from now but just concentrate on how to create a maintainable code and structure right now based on current requirements.  Evolving requirements always a have a knack to throw a curve ball in whatever design you have just finished.

On the folder naming, Jeff has a good starting point to think of layers and avoid ambiguous irrelevant names.

I come from java world, so I prefer to keep the namespaces and folder structures closely matched up, even between the projects.  

For Huber geekiness, I have not had those contests since college. Now, I think a tougher contest is to show well-roundedness in other non-technical areas in life.

# June 17, 2008 5:50 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)