How to code....

Make it correct, make it clear, make it concise, make it fast. In that order.

Presenter First Pattern

I've been using MVC patterns for 10+ years and recently have been looking at Fowler's Passive View and Supervising Controller now that he has pulled the MVP pattern.

But the Presenter First pattern really is starting to make a lot of sense when it comes to easy testing and mocking of the model and presenter. I saw someone describe on a blog as "UI as a service". I like the idea of the Model and View being totally ignorant of the view.

I'm still a little fuzzy on the mechanics of wiring MVP triads together at the model levels.

Grab the whitepaper and check it out.

Getting back to Domain Driven Design

I recently started reading Domain Driven Design by Eric Evans and am gaining some insights into many of the DDD design practices I have unknowingly been using over the past 5 years.

It is interesting to see how over time aspects of my companies domain design has been muddled and broken down over time due to the miscommunication of the UBIQUITOUS LANGUAGE we developed in the initial design of the system.

This quote from the FACTORY/REPOSITORY chapters was quite pungent and applicable to our current environment when I read it:

"A client needs a practical means of acquiring reference to pre-existing domain objects. If the infrastructure makes it easy to do so, the developers of the client may add more traversable associations, muddling the model. On the other hand, they may use queries to pull the exact data they need from the database, or to pull a few specific objects rather than navigating the AGGREGATE roots. Domain VALUE OBJECTS become mere data containers. The sheer technical complexity of applying most database access infrastructure quickly swaps the client code, which leads developers to dumb down the domain layer, which makes the model irrelevant."

Also, in discussing the corrosion of the domain model he mentions how making it easy to convert data into objects using mapping layer can lead developers astray. Developers don't think of objects but just think of data containers. Is this the debate between DataSets and Business Objects a wolf in sheep's clothing?

"As a client code uses the database directly, developers tempted to bypass model features such as the AGGREGATES, or even object encapsulation, instead directly taking and manipulating the data they need. More and more domain rules become embedded in query code or simply lost."

I've been heads down in design and coding for so long in an attempt to establish the financial stability. I have been ineffective in the capacity as a System Architect in this regard.

My situation is rather humorous because the majority of Architects tend to spend too much time on Architecture related tasks where as I've been spending the majority of the last 5 years on design, coding, and support.

Also, people will fall back on the argument that any added abstraction is going to impact performance. Pooh to that! Depends on what you are building. If you are building a typical business app, design it correctly for God sake! Unit test it for performance and adjust as required. A good design is agile to change with TDD.

I look forward to reading more of DDD. It's stimulating new ideas and re-enforcing ones I already knew to be correct.

Esoteric and entertaining programming languages

If you ever have some times to waste I encourage you to check out the following programming languages. They are not really of any use but are a cool mental exercise.

Whitespace
BrainFu*k (or BF)

Whitespace is interesting because you embed secret messages through code within white space of your web pages.

Sure, go ahead and print out your white space program and destroy the source file. No one is ever going to figure it out now.

Apparently I had some time to waste this weekend.

My Fizz Buzz interview question

So there has been some "buzz" about the interview question that sets the bar for any entry level programmer. (forgive the pun)

I have my own entry level programming problem I have developed over many years of interviewing:

"Write the code in your favorite language (or pseudo-code) to remove all items from a list that a contained in another list."

I give them concrete lists so we can talk about the implementation:

List 1 = A, B, C, D, E, F
List 2 = C, E, F

Sounds easy enough but candidates almost always start with a loop over List 1 with an inner loop or lookup in list 2. Then, any normal programmer realizes the errors in their ways and say's oh crap, I'll be screwing up my iterator or index over list 1 if I modify list 1. It's interesting to watch as they try to come to a solutions. You would be surprised how many can not make a leap to a solution.

I get statements such as "Oh, man I've done this before" and then they never come to a solution.

Better candidates always ask questions such as what data structures would they be stored in and how large could the sets become? Is performance a factor? Do I memory limitations. The poor developers never make it to a solution. This is the true sign of an experienced developer.

But it's important that they give you a solution that works. I don't take the intelligent discussions around the problem as confirmation that they are a good developer. I want developers on my team that are good thinkers as well as can get things done.

I debated if I should post my version of the "Fizz Buzz" question here but my traffic on my blog is almost non-existent. I guess it's because either I don't have anything interesting to say or I don't blog enough.

Whatever....