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.
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.
Somewhere in the bowels of the code base for sites like Facebook and Twitter and flickr and Azure and Heroku, there is code, I bet, to specifically deal with IP addresses.
And that code will lose it’s SHIT completely if we switch to IPv6.
If we throw an argument about how to and how not to design a framework into the mix this
thread will probably gain sentience and destroy us all.
via @paulbatum from this thread.
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.
It has the same effect, but in my opinion it’s a little easier to understand.
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!”