Author Archives: Scott

ORMs are not just about replacing SQL

It’s Time To Get Over That Stored Procedure Aversion You Have – Rob Conery

Rob’s advice would be great if people wrote stored procedures the same way they wrote normal statically typed code using C# or Java. But they don’t, they tend to cram every possible path for the business logic can take into a single stored procedure, making it hard to understand, hard to maintain, and fragile.

Everyone has heard or had to deal with that kind of stored procedure. Written years ago, the authors have moved on to another job, everyone shudders at the thought of having to modify it. Then one day, it stops working, maybe it’s due to a change in the underlying table, maybe a new business requirement came up that requires a new kind of data to be passed to the procedure.

ORM’s were originally created so that:

a) We could stop writing 4 different stored procedures for every object in our programs.
b) So that we could normalize our data in the database and then create object models in our application code that represented business concerns rather than the most efficient way to store data.

People are productive in different ways

Don’t Check Your Email in the Morning

An interesting idea from Scott Hanselman.

DON’T CHECK YOUR EMAIL IN THE MORNING.

Insane right? I believe that checking your email in the morning is the best way to time-travel to after lunch.

Why DO we check email first thing in the morning? Well, because something crucial might have happened overnight.

There’s a few things wrong with that sentence, in my opinion. Words like “something” and “might” stick out. We check our email because of fear, a sense of disconnectedness, and (in some cases) a feeling of urgency addiction.

I think this is worth trying at least once, if you aren’t me. Me, I’ve tried this before. I find that I am WAY more productive in the afternoon and evening than I am in the morning. I’ve always hated the “9-5” workday. I find that I can’t get started and focused on a project before lunch regardless of whether I’m on IM or checking emails. There’s just something about my brain that doesn’t start working until the afternoon.

My general workflow is to check email first thing, respond if necessary, filter out the worthless emails, accept meeting requests, etc… Then I CLOSE my email client and don’t open it back up until just before I leave. Sometimes I’ll check email just before lunch if I’m waiting for a reply from someone. I do agree with Scott’s general point, don’t get so caught up in your inbox that you lose focus on the actual reason you are at work. And, as always, postpone meetings with time wasting morons.

Modern Javascript Development:The arguments object, overloads and optional parameters

Reassign JavaScript Function Parameters In Reverse Order, Or Lose Your Params – In which Derek discovers that arguments object is a data structure with an identity crisis. 😉

That’s just bad, and it’s not specific to node.js. You should use the short circuit in the || operator to assign default values to your parameters instead of relying on ordinal indexes in the args pseudo-array in my opinion.

Modern Javascript Development: constructors and objects

The premise that someone would pass in b and c but not a is also weird. But, whatever. It does cause a problem due to the weird nature of the arguments object The big gotcha here is that JavaScript doesn’t support overloads.

In most languages that do support overloads, you would just define two different functions. One that takes three arguments and one that takes two arguments. But that won’t work since JavaScript is interpreted top-down. The last function definition clobbers the previous definition. So in the Fiddle posted above, the two argument function is the only one that exists.

Derek is correct that the arguments object is funky. It’s an array, but not really an array. It only has a “length” property. But it doesn’t have any really useful methods like pop or push. So assigning the variables in reverse order does work, for the reason you would expect knowing that JavaScript is interpreted top-down. I think a better way would be to convert the arguments objec to a REAL LIVE BOY ARRAY and access the values from that.

It has the same effect, but in my opinion it’s a little easier to understand.

Agile is dead? What’s next?

When I first saw these words written on Twitter I thought, “No way, Agile can’t be dead. There is too much money invested. Too many groups, conferences, books, and tools to be sold.” Turns out, I was right. People weren’t saying that “Agile” is dead, but that the term has been diluted so much as to be meaningless.

I have been thinking about that idea for some time, I actually thought that “Lean” bit the dust long before “Agile” did. Lean was dead as a meaningful term once “Lean startups” started to spring up. So do I really care that “Agile” as a term referring to the Agile Manifesto is dead? Not really.

So what next? Does the over-abundance of money-changers in the Agile temple mean that we give up on Scrum? Lean? Kanban? That we don’t value “Individuals and interactions over processes and tools”? No, we can continue to use these tools if they provide value. I hope that this discussion around the word “Agile” causes teams and individuals to reflect and evaluate what kind of return they are getting based on where most of their energy is spent. I’ve found that most Agile tools are centered around providing feedback and reports to managers (Who, in the Chicken & Pigs store are often Chickens. Often they are just farmhands to really bury the metaphor).

“Why do we need to point all of our stories in Super Frumpy Agile Tool 2.3?”
“So we can measure your velocity.”
“Why do we need to measure our velocity?”
“So we can estimate how long it will take you do finish”
“But velocity doesn’t really tell you when we will finish, only how many points we can get done, on average, in a sprint?”
“blurrggghhhh bar charts!”