Jeremy D. Miller -- The Shade Tree Developer - All Comments

business income opportunity xango

business income opportunity xango — Thu, 03 Jul 2008 23:41:58 GMT

June 2007 M T W T F S S« May Jul» 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Favorite Sites A Million Monkeys Typing Ace of Spades Acute Politics Alarming News Anwyn’ s Notes in the Margin Badgers Forward Beldar Blog

re: Why do we Refactor?

tree removal California — Thu, 03 Jul 2008 22:36:15 GMT

please do care for our trees.

re: Why do we Refactor?

tree removal service — Thu, 03 Jul 2008 22:35:08 GMT

salute for trees!

re: Unit Testing Business Logic without Tripping Over the Database

Jeremy D. Miller — Thu, 03 Jul 2008 13:23:00 GMT

@ejames,

"you can unit test business logic" is different from "it's easy to unit test the business logic." I shouldn't have to mock out data access methods and all that data portal jazz just to unit test business logic at all. It's work that I wouldn't have to do with other architectures.

re: Unit Testing Business Logic without Tripping Over the Database

ejames — Thu, 03 Jul 2008 10:26:53 GMT

Using TDD for CSLA objects is no different from TDD using using plain ordinary C# objects. Just because CSLA uses the Active Record pattern doesn't mean you cannot use dependency injection to inject the data access code.

CSLA defines four (give or take some) Methods to be overridden for data access: Create, Fetch, Update and Delete. The implementation of such methods is left for the business object developer, leaving the door wide open for use of data-access interfaces, dependency injection, and database isolation.

re: First Causes in Software Development: How do I decide what is good?

FransBouma — Thu, 03 Jul 2008 08:03:28 GMT

@Fregas:

Hehe :) sorry but after reading your post, I can only conclude here that it's not me, but... you who's attacking someone as it's you who wrote "In fact almost every time i see a post or comment from Frans, he is coming across as aggressive, egotistical, accusatory, victimized, pushy, defensive or attacking.",

No offence, but I think you should look in the mirror as well, if you're going out to bash someone in public with a post like you did above.

I know we did everything we could to help you out, and you know that. I'm sorry you still feel a lot of hate after all these years that you have to post a piece of text on a public blog like you did above.

re: Classic Technical Lead Blunder

Bil Simser — Thu, 03 Jul 2008 03:48:54 GMT

@Jeremy: I'm torn on the code review comment. I frankly don't like sitting in a meeting for more than 15 minutes (our Scrum limit) and an hour (or longer) wallowing through code doesn't seem to be condusive to a healthy collaborative environment. Most of the time it's "this is bad", "this needs work", "why didn't you try this". All good suggestions, but sometimes never even implemented due to cost concerns (another issue). However, with peer reviews you run the problem of the team. On a small Agile team of say 4 devs (2 senior, 2 junior paired) your gene pool quickly empties out as the senior guys are always reviewing the junior guys and you're left with 2 peoples opinion (or sometimes 1). Not sure how to resolve that and pitch the code review free zone to my client as a result of that (situation I"m in right now). A good discussion to have (psst, come up to Canada in August for some good ALT.NET'ing)

re: Let's see, if I...

Jeremy D. Miller — Wed, 02 Jul 2008 14:46:37 GMT

@John,

Nice comment. However, if you aren't smart/experienced enough to cut through the garbage on Google, you certainly aren't going to do any better writing your own stuff.

@Kent,

"I think what Jeremy's getting at (and I apologize for putting words in your mouth, Jeremy) is that if there is a business problem to be solved, we should be *avoiding* solving technical problems, especially when they've already been solved well."

Ditto from me, with the proviso that yes, sometimes you can come with an innovative way to do it better.

@Kyle,

Welcome to the world of a professional software developer.

re: Working faster and fewer mapping errors with NHibernate

Colin Jack — Wed, 02 Jul 2008 14:24:32 GMT

@Sheraz

We do that too, sometimes they are also overkill (also coveed in the book). Even if you do use a factory its quite nice to see absolutely required (and unchanging) dependencies on the constructor.

For example an Account may need to be told what kind of Account it is by being passed an AccountKind (assuming thats the design we have). We could use a factory, but we may choose to pass that value to the constructor as its not ever valid for it to be null or for it to change.

Also one question mark does the job :)

@Jeremy

Tried using ObjectFactory.AssertConfigurationIsValid() when I knew I had invalid mappings. It did indeed cause an exception to be thrown:

"No Default Instance defined for PluginFamily..."

Unfortunatley after travelling through 3 other catch blocks it got to a catch blow ValidationBuildSession which appeared to swallow the exception, the code carried on and in the next iteration of a foreach in PipelineGraph.Visits you get an InvalidOperationException because "Collection was modified; enumeration operation may not execute."

We're using 2.5 (downloaded from SVN this morning) and although this doesn't really matter I thought I should report it.

re: Let's see, if I...

Kyle Szklenski — Wed, 02 Jul 2008 13:46:31 GMT

What bothers me is when someone writes an application and starts it off as godawful complex, without even trying to do something simpler.

An example would be a co-irker of mine wrote an application for which there are multiple different hardware types to be abstracted. He wrote a single base class, to which he adds all the functionality of a new piece of hardware to whenever that hardware is added. In most cases, 50-90% of the interface is dead code/degenerate functions. What I realized is that, the way it's set up, it's much simpler to use the command pattern and that's that. How is it that a relative nublet programmer (me - 1.5 years experience) came up with this significantly simplified version of the base class interface (no specific functions, just the one called Send(ICommand command)!), when a person with 15+ years of experience was completely blind to it? As a friend of mine said, "Welcome to the real world."

The fact is, the author of said class didn't look for anything simpler. He made it ridiculously complex from the start, and now when someone else has to add a new piece of hardware to the top, that person is left in a coma - because their brain shut down when they saw how it was "designed"!

re: Let's see, if I...

Bil Simser — Wed, 02 Jul 2008 13:16:40 GMT

Heh. "co-irkers". A typo or...

And just ask Oren, he would have written the solution for you in 8 lines.

re: Let's see, if I...

Kent Boogaart — Wed, 02 Jul 2008 12:07:30 GMT

@Josh

I, too, have side projects that are aimed more at providing framework/utility code. I don't see a problem with this: it's a project dedicated to solve a particular problem, and that problem just happens to be technical rather than a business problem.

I think what Jeremy's getting at (and I apologize for putting words in your mouth, Jeremy) is that if there is a business problem to be solved, we should be *avoiding* solving technical problems, especially when they've already been solved well.

re: Let's see, if I...

Kent Boogaart — Wed, 02 Jul 2008 12:03:12 GMT

I think you're touching on a bigger problem: developers *want* to develop technical solutions, not business ones. They'll often jump at the half-chance to develop a new logging infrastructure or utility layer of some sort to the detriment of actually producing something with business value.

I'm not so sure it's entirely out of ignorance of what's out there, it's often more a case of 'I can do better' and 'working on X utility code is more interesting than working on Y business code'.

re: Let's see, if I...

John O'Brien — Wed, 02 Jul 2008 01:50:17 GMT

Warning.... using google can be like looking through a garbage heap for something edible. There are a lot of experienced people out there share good things.

But there are lot more people who spend more time blogging than actually "eating their own dogfood".

Another warning... Don't be a CoPaster

www.obrienjd.com/.../The-copypaste-generation-(CoPasters).aspx

re: Before you use an IoC tool, some concepts to know first

Frank — Tue, 01 Jul 2008 23:36:59 GMT

@Jeremy:

I was just attempting to make the point that cohesion and interclass dependency are orthogonal concepts. A cohesive class may or may not have dependencies on other classes. The same is true for a noncohesive class.

Cheers,

Frank