All posts by erk

I love writing, computers, puns... and can sometimes be spiritual, or mindful.
Computers and Internet

Pointless Arithmetic or Incompetent Communicator?

Leave a comment 
@SuppressWarnings("PointlessArithmeticExpression")

You don’t say? Well, let me counter that with an…

@SuppressFeature("IncompetentCommunicatorErrors")

Let me explain. I’m creating a unit test where I need to do some calculations in order to create an expected value (i.e. do the same computation as the function I’m testing but differently… or usually more manually…)

So this is my test (high lighted was marked as “pointless”):

final MinMaxAverage mma = new MinMaxAverage();
		
mma.add(1d, 1d);
mma.add(2d, 2d);
mma.add(4d, 4d);
		
final double min = mma.min();
final double max = mma.max();
final double sum = mma.sum();
final double average = mma.average();
final int count = mma.count();
		
assertEquals(1d, min);
assertEquals(4d, max);
assertEquals(1d*1d + 2d*2d + 4d*4d, sum);
assertEquals((1d*1d + 2d*2d + 4d*4d) / (1d + 2d + 4d), average);
assertEquals(3, count);

Sure, this test could have used another weight, but I wanted to test with a weight of 1. And regardless… is this pointless arithmetic in a test? Or for that matter in a complex program that might actually benefit from more simple code?

Programming isn’t just coding and numbers… it’s also communicating with other programmers and yourself in a year. Some IDE simplifications aren’t necessarily simplifications at all. Sure, you can make the code look lean and nice, but you probably should think twice about that if it’s a fringe case, something you use very seldom, or in this case the attempt to make the inner workings of a function in a test more transparent.

Ah well, regardless… I fear I’m expecting the IDE to understand my thoughts and feelings… I guess our relationship is in choppy waters then? 😀

Computers and Internet, Humor, Politics and Society

Giraffes don’t have fins

Aside Leave a comment

Why mankind is going to hell via internet:

A: This is a picture of a fish, it clearly have fins!
B: Giraffes don’t have fins!
A: It’s a picture of a fish!
B: What’s fishes got to do with anything?
A: They have fins.
B: Giraffes don’t.
A: We’re talking about fish.
B: Giraffes don’t have fins!
A: Right Giraffes don’t have fins.
B: See, I’m right…
A: Yes with regards to giraffes…
B: …fishes don’t have fins.
A: I give up.
B: I’m so cool! I’m so right! I’m so hot! I’m so bright! I’m so yeah oh yeah!

Productivity and Efficiency

Multitasking your “Plane” into the Ground

Leave a comment

Paraphrased from “Mayday Air Crash Investigation:”

“Oh no, he’s multitasking… no wonder his plane went into the ground…”

Contrary to popular belief, multitasking is not at all guaranteed to make you better or faster. Rather the opposite…

When it comes to airplanes and pilots multitasking is at best prohibited and possible grounds for termination.

Not even computers do much multitasking, as in preforming several things at the same time. For instance the computer I’m writing this on has 6 cores (i.e. the ability to do 6 things at the same time) but looking at the number of threads (think of it as simultaneous tasks) it’s obvious that the computer only seem to be doing several things at the same time. (My computer currently have 3 804 threads going!)

Instead the operating system uses priorities and scheduling to give each thread a certain number of processor seconds per hour during which it can perform its tasks. It also uses interrupts (which pretty much is exactly what the name implies) when something that need immediate attention happens (for instance, the user presses a key on the keyboard, and whatever else is going on, that user will be unhappy if that doesn’t immediately produce a letter on the screen…)

Since a computer memory is widely superior to a human memory, it takes very little time for the CPU to reorient itself to the new task.

Use a priority list

As a human, your best bet is to keep a priority list of tasks to do, and only switch task before task completion if the new task is of a much higher priority.

For instance, in my line of business you might be working on an improvement to a system when the production environment has a critical problem… you drop the improvement and switch over to the critical problem… but if there’s a new improvement order (which usually doesn’t even have an SLA—agreement that stipulate that handling the issue must start within a given time limit) you keep working the current problem until you need some variation to keep your brain alert…

Give extra focus to the critical tasks

Another strategy is to designate certain tasks so important you either finish them or abort them. You never do anything but this task and if something of a higher priority comes in, you abort.

Again, in my business this would be deployments to production… in some cases even to test environments.

You don’t want to miss any critical steps when deploying to production so you make space for the event in your calendar letting everyone know you’re deploying at that time and are otherwise to be considered “out of office.”

Make room for the critical tasks

A third strategy is to finish everything on your list that is dependent on these critical tasks before you perform them.

In my business, we’d never go into production if we haven’t performed acceptance testing first. And we never go into acceptance testing if we haven’t finished the work. Or at least, when the situation is not dire and we’re not in a panic, that’s what we’re supposed to do. (I’d probably quit a project or company where panic deployment of untested functions was a norm… that or go on sick leave due to stress…)

Personally, I create checklists and prepare the deployment by packaging files, even copying them to a staging folder in production well ahead of the actual deployment. In most cases this makes a deployment into me having to stop a few processes (on a checklist) then copy some files, starting/restarting the processes and verifying what has already been thoroughly tested.

That’s it.

Complexity and challenges should never come from performing the critical tasks (e.g. deployment to production) they should come long before that (e.g. programming and testing the function, figuring out how to deploy it as easily as possible).

That way you should hopefully be able to prevent your “plane” from crashing…