Comments for mookid on code

Comment on New job!! by mookid

mookid — Tue, 20 Dec 2011 13:44:04 +0000

Thanks, dude

Comment on New job!! by Thomas Ardal

Thomas Ardal — Mon, 19 Dec 2011 15:24:31 +0000

Congrats on your new job!

Comment on How Windsor’s decorators can save your life (almost) by mookid

mookid — Sun, 04 Dec 2011 18:43:20 +0000

Yeah, I understand why you think that “Castle’s smartness” is rather error-prone… as always, when you have the option of either being explicit about stuff, or letting stuff happen by convention, it’s important to take into account whether the chosen solution will violate POLA… and whether a given solution is a violation, depends very much on whether this style of convention-based programming is a well-understood and accepted among your team members.

Thanks for the comment, what the heck… great name, btw

Comment on How Windsor’s decorators can save your life (almost) by what the heck

what the heck — Sun, 04 Dec 2011 17:43:02 +0000

There’s good reason against mixing component registration and decorator configuration. Service overrides define which imlementation is used by a component that needs it. Registration order defines a default implementation for a service, which is a rather different concern. So, Castle’s smartness “to resolve the ExternalStuffWithMasterSwitch supplying the next available implementation” is rather error-prone.

Comment on Getting my Mongo on by James Jeffers

James Jeffers — Sun, 20 Nov 2011 15:22:40 +0000

This is exactly what I was looking for. Thanks!

Comment on If you can draw it like that, then just f*n code it like that! by mookid

mookid — Sat, 12 Nov 2011 09:42:56 +0000

I think it was caused by the fact that our product owners know both too much and too little about software development… you know, when story owners enter solution mode already during the specification of the story. And even though I was a little bit reluctant to implement things like that, I guess I didn’t have the confidence at the time to challenge their proposed solution.

Seen from an agile point of view – or any kind of view, really – we could have salvaged the situation by either 1) been much much more refactoring-eager and much more aware of the pain and friction that we started experiencing after a short while, or 2) we could have refused to accept features in the form of proposed solutions and insisted that features capture intent.

I definitely prefer solution 2. I guess the application of a technique like 5 whys could have helped focus on the right things during specification of each feature. And then, the modeling and implementation could have been carried out by us as the fairly experienced object-oriented programmers we are.

Comment on If you can draw it like that, then just f*n code it like that! by Simon Hem Pedersen

Simon Hem Pedersen — Sat, 12 Nov 2011 07:11:36 +0000

Nice post!

A few questions:

* How come you got misleaded by the second bunch of models presented to you?
* Seen from Process/Kanban/Agile point of view, what could have saved you ending up in this “huge-ball-of-mud-model-with-limited-expressive-power” ?

And a comment:

* I love the term seasoned developer

Comment on Tinkering with MongoDB and sharding by mookid

mookid — Wed, 05 Oct 2011 21:59:08 +0000

Awesome

Comment on Tinkering with MongoDB and sharding by Vikas Kumar

Vikas Kumar — Wed, 05 Oct 2011 21:53:16 +0000

Excellent Post!!! I just ran step by step, and it works like a charm. 10 million records and I did a search on one particular record, and the speed of MongoDB is just amazing.

Thanks,
Vikas

Comment on How to avoid (unnecessarily) touching the container by mookid

mookid — Mon, 03 Oct 2011 10:25:55 +0000

That might be the case most of the time, yeah – but the way I made it, a controller could get any number of views injected.

I’m not sure if I’m being strictly MVC true to the 1979 Reenskaug-way, but the point of separating view concerns from model concerns, and binding everything together with controllers remains intact.

You can see my example source code on my GitHub.