What's it all about, Alfie?

This afternoon I wanted to do a little refactoring on the codebase for the project I'm working on. Right now, one of the two main classes we're using in the code is real just a ruby Hashes, and while that's great for loading and persistence, it's not really where we would like to be, and there's a decent Open Source gem called Hashie. This guy is really just methods on top of Hash that allow you to use the "dotted notation" as opposed to the "bracket notation":

  # the old way:
  a = merchant["name"]
  # the Hashie::Mash way:
  a = merchant.name

This makes the code look a lot simpler - though it doesn't really make it any better. However, it adds nice convenience methods as well:

  a.name = nil
  a.name?   # => false

The real goal is to move a lot of the methods that take a single argument - the Demand, and looks into it for some bit of information, and make them methods on the Demand so that it's a lot clearer where the business logic is being held.

There were a lot of little complications - primarily because of the fact that Ruby devs hate writing comments, and so the code is the comments, and I had to do quite a bit of digging to know how to handle an initialize method on a subclass of Hashie::Mash. Ugh… I do wish they'd learn to comment things.

I got a lot of work done, but not enough to call it a day, so I moved it all into a branch and I'll work on it more tomorrow.

This wonderful Monday morning has been trashed by a particularly careless Code Monkey I work with. I know he probably meant well, but he checked in code - to master, that was then deployed to production, that broke production. Why? Simply because he didn't check.

I'm not perfect. I make a lot of mistakes. But this was one that I really got a little steamed about. I don't make mistakes like this - and even if I did, I'm here in the morning to clear them up! This is my real gripe.

It's one thing to be careless if you're the one cleaning up the mess. As I've said to my kids over and over again, I'll eat in the living room because I'm the one that cleans it up. They can't because they simply don't.

I want to just shame these Code Monkeys into taking a little more personal interest in their work. Take a little more time - check. Make sure. Don't just assume that because it's checked in and the CI build worked that everything is going to be OK. It might, but it might not. And it's those "might not" cases that really make or break your reputation.

The particular Code Monkey that broke production today is a nice guy. He's personable, likable, nice to talk to, and just a plain "good guy". But he's careless. He isn't a details person. He can write code, but it's a mess and it takes a lot longer than I'm used to - for a guy that's clearly well beyond the "junior" phase of his career. I don't want to yell at him, so I don't. But it's hard not to. He should know better, but I know this isn't going to be a lesson he learns this time - if ever.

He's just careless.

Today I was finally able to finish up the performance testing for the Amazon EC2 instances and the SCN1 datacenter machines. There's no question that our datacenter machines are better, but the question is by how much? And how do they handle the load? Well… now we're ready to answer at least a few of these questions.

It's nice to see the parallel processes on the A64 box flatline over 6 processes - but that's because there are 24 cores on that box, and that leaves 4 per process - still a lot.

I've decided to cap the processes on the EC2 machines at 3, and give the SNC1 machines at least 6 - maybe more. We'll have to see how it works out when we get things in house and I can start to migrate things to the new boxes.

This morning there were some problems with the UAT runs from last night. FIrst off, it took 10 hours to run, and there were a lot of problems because a change wasn't put into the newly refreshed Salesforce sandbox that we are using - so I got the Crack Monkey-like request from Jerry asking why they didn't run. I looked into it knowing that because of the Salesforce problem it didn't really matter - it'd be fixed and it'd run Sunday night just fine.

Not good enough for Jerry.

So he wanted me to re-run them, and at 10 hours, I was a touch reluctant. Still, I remembered the other exchange, so I simply said: "Sure. Love to."

Jerry was a little taken aback. Clearly he could tell I was shutting down.

Don't care. It's not going to get me in trouble, and he's clearly not going to listen to me anyway, so what difference does it make?

None.

This afternoon my patience has severely been tested by a co-worker. The exchange was pretty simple: He wanted to make sure that he knew what was going to run in UAT this evening, as he wants to push the rollout of the application to more people. He specifically asked me if a series of cities were going to be included in the run.

"Yup" I responded.

Not 60 seconds later he asked the exact same question again!

I'm going to pause the story for a moment to reflect on this behavior in general. Skipping medical conditions, there's no good reason for this kind of behavior. I can't think of a one.

• If I'm wrong well… I won't check again in such a quick time - I just looked.
• If I'm lying I'm not about to be that stupid to confess so soon
• If I didn't read it right I'm not going to think this time is any different. After all, it's not that hard a question.

Yeah, I can't see a good reason to ask again. One thing does pop to mind:

Insanity: doing the same thing over and over again and expecting different results. - Albert Einstein

Back to our story...

I wrote back:

Remember when we had that talk about communicating effectively? When you asked me something, and I pointed out that I'd just used those exact words? Well… I can point you to the code, or you can trust me that: "Yes, those are in the Original Six and Top 40"

I realize it was a little snippy, but I wanted to try and re-enforce the point that we had talked about this behavior in the past, and that indeed, this was one of those times that I had told him exactly what he wanted to know, and it wasn't likely to change with the second request.

I think it's just hard to be nice all the time.

This morning I was finally able to get back to the performance testing that I was hoping to finish yesterday. The problem with today's data is that it's significantly slower than before the Salesforce refresh - meaning they clearly put us on less powerful hardware or bandwidth because we're seeing a three to five times increase in the access times for the data and writes. It's really slow. However, that's got it's upsides as well - we won't likely see much slower, and we'll see how the data stacks up.

Additionally, today I compared the EC2 instance with a physical box in the datacenter that will be the ultimate host for the app. This will again be the comparison of serial running versus a number of parallel processes. All in hope of finding what impact the runs have, and how the time grows with workload.

Hope things all work out.

For the last several hours I've been really dragging… feeling like what I'm doing is just a waste of time - no on cares, etc. Really getting bummed out.

Then I got sick and tired of listening to a guy near me yammer on about something that had nothing to do with work, and picked up the ear buds for some tunes. Amazing what a great song will do.

It's really almost magic.

Gotta remember this.

I'm sitting here trying to get all my tests restarted, and I realize a simple fact:

Nothin's ever easy.

Nope. It just isn't.

I can say that the Best things in life are free - and to a point, in a way, they are. But then again, the best relationships may be free, but they take work. Again, not easy.

Getting these tests going… should not have even been an issue… and it's turned into a complete and horrible diversion. Not easy.

Ugh.

I knew as soon as it happened, it was going to eat up hours of my time. I first noticed it as a failure of one of the tests I was running this morning. Nothing back from Salesforce, and when I looked at the log files, everything was failing. I had heard that they would be refreshing the staging sandbox from production, but I had no idea it'd be this morning.

So first things first… Wait.

Let them finish the refresh and then try to get the Remote Access going again, given that I've never really gotten it going in the first place. You have to create an application in Salesforce, and then make sure that's all OK to get the first two pieces of the authentication tokens. Then you have to have the new user send it's security token back to you, and now you just need to battle with the uncompiled, or mis-permissioned classes.

It's enough to make you want to drink. Heavily.

I had some help, and that's nice, but it was still an amazing waste of time to get things back to where they were. But hey… I'm sure someone had a good reason for this. I just can't possibly imagine what it is.

This afternoon I needed to fix up a huge merge that a co-worker did right before leaving for a two week vacation. He did all he could with Git, and he tried, to be sure, but his codebase had a lot of problems in it, and they needed to be fixed up before I released it to UAT and production this evening. While I can certainly understand misnamed methods, I was more than a little miffed at the API changes that I got as well.

Specifically, because of the code paths, an API change that only happened in development, and only when retrying saves. The code used to require an array of merchants - even if it's just one, and the new method worked without the array on a single merchant. Since this was really an API, the normal code worked when passing it the array - but not when in development. Then again, it was only hit on the retries.

It was a really frustrating time because I've been on the "business end" of a lot of folks leaving systems to me, and the carnage that ensues. It's not pretty. And in this codebase, where comments are seen as a weakness, it's orders of magnitude worse.

But in the end, I got it all squared away and deployed. I just wish it weren't so much effort a lot of the time.