Monthly Archives: January 2018

The Streisand Effect

Posted on by
5

I had originally planned on a slightly different topic for this week’s blog, but an email I received from my alma mater last night changed my mind.  First, a little background. I’m a 1990 graduate of RPI in Troy NY, a fact I’m quite proud of. Second, lately there has been a growing controversy over the shape and direction of the school administration, led by Dr. Shirley Jackson.  Let me say that I find Dr. Jackson’s credentials impressive and many of her initiatives have led RPI into the right direction for the 21st Century.

But (and you knew that was coming), all is not rosy in Troy (especially today as I write, it’s a dreary, cloudy day).

So let’s back up a bit though and discuss the Streisand Effect. Originally and mainly the effect refers to bringing unwanted attention to something by trying to suppress access to information in the first place. A similar reaction can be had by telling someone, “Don’t think about a pink elephant.”  Ok, how many of you were thinking of a pink elephant before I told you not to?  Now how many are thinking about one?  But I’m serious, please stop thinking about a pink elephant. There’s no such thing as a pink elephant. Ok, now I’m just being cruel about the whole pink elephant thing.  I’ll stop.

So, back to RPI. As I mentioned not everything is as pink and rosy as it might be.  Generally in cases like this, you have one of three choices. Hire a PR firm that advises you on a course of action, admit the issues and work to solve them, or to shut up and hope things blow over and people stop talking about it.

In this case the Alumni office at RPI decided to take the 4th option. They decided to send a letter to all alumni, including many who probably had no inkling of the ongoing controversies or if they did, didn’t care that it was going on.  The letter was written by an RPI professor in response to a set of well-written and researched articles and a website setup by a bunch of upset alumni. Like good RPI graduates, the alumni backed up their criticisms with research and data.  (For example the website notes how RPI’s credit rating has tanked over the years. An easily verifiable fact.)

The letter unfortunately did not address any of the data (except for one) and instead included highlights such as:

Could it be that the residual racism and sexism (no to mention heightism) that sits in the backs of the minds of the white male majority of our alumni makes it just a bit easier to see Dr Jackson as outside of her league, … out of her place?

Yes, somehow pointing out ongoing critical financial issues results in the Alumni office calling all alumni racists and sexists. Based on the reaction on several social media forums I’m on, after this letter, several alumni who were giving or thinking about giving have changed their minds.  I obviously know only a small subset of the thousands of alumni/ae who must have received this email.  But not a single one I know was convinced by this email to START donating to RPI. And at least one person who wasn’t aware of the majority of the issues said they were made aware as a result of this email and would stop donating.

So effectively, the RPI Alumni office has not only seriously insulted its donor base, it has brought attention to issues that many of the donor base apparently were not even aware of. Streisand Effect is now in full force!

I want to toss in one aside here to be clear: I am not ignorant of the fact, nor do I deny the fact that Dr. Jackson certainly has faced some pushback because of her identity. I’ve see comments about her skin color and gender and have pushed back against such comments. They’re not relevant to the issues at hand.  She has faced and overcome a great deal of discrimination and dislike simply because of who she is.  But, that does not make her or the Board of Trustees immune of criticism based on their actual actions and ones that are backed up by data. The drop in RPI’s credit rating is not due to who she is but rather the actions she and the Board of Trustees have made over the past 18 years.

In closing, as I step off my soapbox here; I realize this blog post is a bit off-topic from my usual fare, but it’s not really. It comes down to how we approach problems.  Trying to ignore them doesn’t necessarily make them go away, but shaming a wider audience doesn’t help either, it only brings more attention to the issue. If in 2003 Barbra Streisand had decided to simply drop the issue of the photographs of her home, the issue would have faded into the woodwork and most people wouldn’t have cared.

In 2018, if the RPI alumni office hadn’t blasted an insulting and condescending email, devoid of facts to its entire alumni base, fewer alumni would know about the issues. But I can guarantee now, many alumni that weren’t aware, or didn’t care, now do.

Think about this when trying to do damage control at your company.

Crane Operators

Posted on by
Reply

Talking online with friends the other day, someone brought up that crane operators in NYC can make $400-$500K a year. Yes, a year. I figured I’d confirm that before writing this post and it appears to be accurate.

At first glance one may think this is outrageous, or perhaps they chose the wrong field. I mean I enjoy being a DBA and a disaster geek, but I can’t say I’ve ever made $400K in one year!  And for what, I mean you lift things up and them down. Right?

Let me come back to that.

So, last night, I got paid quite a tidy bundle (but not nearly that much) for literally logging into a client computer, opening up VisualCron and clicking on a task and saying, “disable task”. On one hand, it seemed ridiculous;  not just because of what they were paying me, but because this process was the result of several meetings, more than one email and a review process.  All to say, “stop copying this file.”

But, this file was part of a key backup process for a core part of the client’s business. I had initially setup an entire process to ensure that a backup was being copied from an AIX server in one datacenter to a local NAS and then to the remote datacenter.  It is a bit more complex than it sounds.  But it worked. And the loss of a timely backup would impact their ability to recover by hours if not days. This could potentially cost them 100s of thousands of dollars if not into the millions.

So the meetings and phonecalls and emails weren’t just “which button should Greg click” but covered questions like, “do we have the backups we think we have?” “Are they getting to the right place(s)?” “Are they getting there in a timely fashion?”  And even, “when we uncheck this, we need to make sure the process for the day is complete and we don’t break it.”

So, me unchecking that button after hours, as much as it cost the company was really the end of a complex chain of events designed to make sure that they didn’t risk losing a LOT of money if things went wrong. Call it an insurance payment if you will.

Those crane operators in NYC? They’re not simply lifting up a beam here and there and randomly placing it someplace. They’re maneuvering complex systems in tight spaces with heavy loads where sudden gusts can set things swaying or spinning and a single mistake can do $1000s in damage or even kill people.

It’s not such much what they’re being paid to do, as much as how much they are being paid to avoid the cost of a mistake. I wasn’t paid just to unclick a button. I was paid (as were the others in the meetings) to make sure it was the right button and at the right time and that it wouldn’t cost even more.

Sometimes we’re not paid for what we do, as much as we’re paid for what we’re not doing.

 

This is secure, right?

Posted on by
1

WP_20180114_001So, over the weekend, while I was waiting for my wife’s hockey game to begin I was exploring the facility. I saw an upper level and I was curious if it was open. But alas no, it was locked. And I mean locked. Above is a photo of the chain and lock used to keep people out.

There’s a saying that locks only keep out honest people. That’s not entirely true, but there’s some truth to that. Security, especially in my field of IT and databases is extremely important. I am often working with data that contains private information about people. I have to take steps to keep it safe. So, as I mentioned in Too Secure, I don’t have a problem with security per se. There I talked about security that prevented me from doing my job.

Here we have the opposite. Making something that look secure, but really isn’t. I mean this has a heavy chain and a lock. I’m not sure who did this or why, but I’m sure they felt the lock was important. It’s not a cheap one either.

 

This is a case where probably a simple sign and string, “Balcony closed” would have sufficed.  The only purpose the lock really had was to make sure the chain wasn’t stolen. The purpose of the chain appeared to be to give something to attach the lock to.

Now, sure, someone could have removed a sign and string and said, “oh we never saw it” but again, what’s the ultimate risk if someone got upstairs? It was simply an observation balcony. They weren’t really securing much.

But I’m sure someone felt good about their security.

So, when you’re making something secure, stop and make sure you’re spending your time wisely. Sometimes not everything needs the most secure system available. Sometimes a “keep out sign” might be enough and easier.

Time, what is it?

Posted on by
Reply

Time is a funny thing. We all experience the passage of it, but, fundamentally it’s arbitrary.  In the SI system of units, the second is defined as “the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom”,

Sure. That’s helpful. To someone. Not to me.

It’s now 2018 AD. Or is that 2018 CE? Or is it 4714, or 1438, or perhaps 5778 or perhaps it’s 2010. Or perhaps it’s year 1?

We can’t agree on what year it is. But we can certainly at least agree on some semblance of the date, correct? Not really. If I’m using Julian dates, my day is going to be 12 hours off of yours.

But, since I’m writing this in the Northeastern US, let’s agree we’ll work with the Common Era Calendar and that it’s January 9th, 2018.  That should work.  Everything should be simple right? For many of people, it probably is. For us programmers, it isn’t.

Let’s start with a simple sentence, “Run the job at midnight on Saturday.” Can we agree on when to run it? Most of us would probably run it just as Saturday is beginning. But some would argue that it’s just as valid run it at the end of Saturday.  I have in fact seen both arguments. This is where our common use of the language can fall apart. Fortunately though, we can remedy the issue. The military for example, for whom precision timing can be critical would say something like, “Run the job at 00:00 on Saturday.”  Now at least we’re in agreement.

But even then, we love to muck things up. Let me start with being a pedant for a second and point out that there is technically no such thing as 12 PM or 12 AM.  “What?”, you might say? “Of course there is!” Nope, sorry. Going back to the Latin PM and AM mean Post-Meridiem and Ante-Meridiem, i.e. after and before the middle of the day. So technically, what we call 12 Noon can’t be either (since it’s neither before nor after the time of the middle of the day, it IS the middle of the day). And equally, one can argue that 12 Midnight is neither.  And yet, you hear folks use the terms anyway.

Almost always, but not always though 12PM is associated with Noon and 12AM with Midnight. This follows because 12:00:01 IS after the middle of the day. So it makes sense to call the second before that also PM. Yet, that said, I have seen multiple times signs claiming that a place is open for dinner from say 7:00PM-12:00PM and or open “All Day from 7:00 AM-12:00PM” and they’re clearly open after lunch and even after dinner. (And by the way, does it strike you as a strange that we count 12AM, 1AM, 2AM etc to 11AM.. and start over at 12PM, 1PM… i.e. the 12 is considered part of the next set of hours even though we immediately move back to 1 after it? It’s one reason I really prefer a 24 hour clock.)

So I get pedantic about this when folks say 12PM or 12AM and ask them to clarify. This is especially important when it comes to scheduling tasks in say SQL Server.

BUT, we have yet another problem. I’m in the Eastern Time Zone of the US. You might be in the Pacific Time Zone of the US.  I want to hold a meeting at 3:00 PM.  Is that my time or your time?  Most modern scheduling software will correctly put this into my calendar as a 3:00 PM meeting and into yours as a 12 Noon meeting.

Yet that’s still not enough. I was recently reminded of this a few months ago as I started to schedule my PASS Summit into my calendar. I put the events in while I was in the Eastern Timezone, forgetting that when I got to Seattle, my calendar would “nicely” shift things for me 3 hours.  This meant rather than say thinking I wanted to attend the 9:00 AM Summit, I wanted to attend a 6:00 AM Summit.  Fortunately again, the software I discovered DOES let me specify what timezone the appointment actually is in when I set it up.

And one more aside. If we schedule a meeting at 3:00 PM (and we both agree on what that means) what happens if I say “Oh, I have a conflict, can we move that back an hour?” We we moving it backwards in time to 2:00 PM, or backwards in the sense of “further away” and mean 4:00 PM?

So, we can agree that hours are tough. But it can get worse.  Here’s a question for you. When was George Washington born? My father was always proud that he shared George Washington’s Birthday. But did he?  Was it February 22nd 1732? What if I told you he was born February 11th 1731? Both are technically correct (which is the best kind of correct.)

We all know about leap years. We have them because it doesn’t take exactly 365 days to orbit the sun. It takes closer to 365.25 days to orbit the sun. But even THAT isn’t really accurate enough. When Julius Caesar reformed the Roman Calendar, he added the concept of leap years. He know that without them, the calendar would slowly get out of synch with the seasons. Before you knew it, July would start becoming the middle of winter and who would want that! (Ok, technically it would take a few hundred years, but you get the point).

The problem was, scheduling Leap Years still wasn’t enough. By 1582, despite leap years, the calendar had “slipped” by 10 days.  So Pope Gregory instituted the current calendar most of the world uses which added the more complex rule of leap years every 4 years, unless the year is divisible by 100 which are not leap years, except in the cases of when it’s divisible by 400 when it is a leap year.

Now, Pope Gregory had a lot of influence over parts of Europe, so predominately Catholic countries adopted the changes almost immediately, in 1582.  But understandably, the more Protestant countries were a bit slower to adopt. The Great Britain and the Colonies didn’t adopt it until 1752, after George Washington’s birth. So, he was born on either day depending on which calendar you’re using. And by then things had slipped 11 days. (The change in years is a related, but different issue that had to do with what was considered the first day of the year. It wasn’t always January 1st you know.)

Now, when Y2K rolled around, I have to admit, I started to wonder, and still do, what would have happened if we had had computers in 1899. Would they have gotten the lack of a leap year correct? My guess is, “probably not”. And in fact, ironically enough, I recall at least one software package (I can’t recall the name) that is well prepared for 2100 and 2200 and 2300, but was NOT prepared for the year 2000 and in fact skipped the leap day that year. (Oh, by the way to really blow your mind, depending on the calendaring system, the leap day is actually February 24th. Or perhaps a more accurate way of saying it is that the leap day is inserted after the 53rd day of the year.)

In conclusion let’s just say time been on my mind a lot lately, partly because I’ve orbited the Sun just over 50 times now and because it’s a new Year. And as a developer, at times handling dates can be far tougher than it looks at first pass, you have to deal with midnight boundaries, timezones, leap years (or the lack of them) and even wholesale shifts in calendars (and this is ignoring completely different calendars such as the numerous lunar based ones that may or may not have entire leap months!) Oh and completely left out any mention of leap seconds! Yes, you can have December 31st 23:59:60 as a valid time.

But when you think about it, other than the fact that time keeps slippin’ (slippin’, slippin’) into the future, all measurement is really arbitrary.  We pick a 0 point and go with it. We just have to agree at some point (in time, yes, the irony is not lost on me) what that 0 point is and how we’ll measure from there, and we’re all good.

Or are we? I’ll leave you with this one final thought. Far into the future, possibly trillions of years, when the Universe has expanded so much that the distance between particles is far enough that none can interact, essentially nothing will be changing. Can you even have time if you have no clock against which to measure it? Will time eventually run out?

I could go on and on about time, but, I seem to have run out of it.

 

Starting off the New Year… wrong

Posted on by
2

Ok, I had plans for a great blog post on time and how we measure it and how it really is arbitrary. But… that will have to wait. (I suppose that brings its own irony about time and waiting and all that. Hmm, now I may need a post about that!)

But, circumstances suggested a different post.

This one started with an email from my boss last year (who will remain nameless for his sake. 🙂  “Greg, I hacked together this web page so my team-members can track their hours. I need you to make a few tweaks to it. And don’t worry, we’ll replace it by the end of the year.”  Yes, that sound you hear is your head hitting the desk like mine, because you KNOW what is coming next. Here we are in January of 2018 and guess what, the web page is still in place.

And of course, it’s not just HIS (now former, he’s moved on) team that is using it. Apparently his boss liked what it could do, so his boss (my boss^2) declared that ALL his teams would use it.  So instead of just 4-5 people using it, there’s close to 30-40 people using it.

So, remember the first rule of development, “Oh don’t worry about this, we’ll replace it soon” never happens.  His original code made a lot of assumptions (which at the time I suppose seemed reasonable). For example, since many schedules are formed around work-weeks, he was originally storing hours by the week (and then day of the week) they were worked in. For example, if someone worked for 6 hours on January 5th of last year, the table stored that as “WEEK 1, day 5”.

Now, before anyone completely thinks this is nuts, do keep in mind, many places, including my last job at GE did everything by Week of the Year.  There’s some advantages to this (that I won’t go into here).

For the most part, the code worked and I didn’t care. But, at one point I was asked to do a report based not on Work Weeks, but on an actual calendar month. So, I had to figure out for example that February 1st occurred during Work Week 5, on the 4th day. And go from there.

So, I hacked that together.  Then where was a request for another report and another. Pretty soon it was getting to be a pain to keep track of all this. And I realized another problem. My boss had gotten lucky in 2017. January 1st occurred on a Sunday, which meant that Work Week 1, Day 1 was a natural starting point.

I started to worry about what would happen when 2018 rolled around. His code would probably break.  So I finally took the plunge and started to refactor the code.  I also added new features as they were requested.  Things were going great.

Until yesterday.  So now we get to another good rule of development: “Use Version Control” So simple. Even for a one person shop like me it’s a good idea. I had put it off for awhile, but finally downloaded the git plug-in for Visual Studio and started to use it.

So yesterday, a user reported that they couldn’t enter hours for last week. I pulled up the app and realized that yes, in fact it was coded in such a way you couldn’t go back into a previous year to enter hours. No problem, I can fix that!

Well, let me add a rule I had sort of missed; “Understand HOW to use Version Control”. I won’t go into details, but let’s just say, I wasn’t committing like I should have been or thought I was. So, in an attempt to get a clean base and all, I merged things… “poorly“. I had the branches I wanted, but had not properly committed stuff to them.

The work of the last few weeks was GONE. I know, you’re saying, “just go to your backups Greg, because of course a person who writes about DR has proper backups, right?”  Yeah, right! Let’s not go there!

Anyway, I spent 4 hours last night and 2 this morning recreating the code. Fortunately, it dawned on me, being .NET code, it was really just CLR and that perhaps with a good decompiler, I could get most of the code back without too much effort. I want to give props to RedGate’s .NET Reflector. Of the two decompilers I tried, it was clearly the better one. While I lost my variable names and the decompiled code isn’t quite what I’d call human written, it was close enough I could in short order recreate hours and hours of work I had done.

In the meantime, I also talked to some of my programming buddies on an RPI chat server (ask me about it sometime) about git and better procedures.

And here’s where I realized my fundamental mistake. It wasn’t just misunderstanding how Visual Studio was interacting with git and the branches I was creating, it was that somewhere in the back of my head I had decided that commits should be used only when major steps were completed. It was almost like I was afraid I’d run out; or perhaps complicate the history with too many of them.  But, you know what? Commits aren’t scarce resources. And I’m the only one reading the history. I don’t really care if I’ve got 10 commits or 100. The more the better in many ways. Had I been making commits much more frequently, I’d have saved myself a lot of work. (And I can discuss having a remote store at some point, etc.)

So really, the point of this hastily, sleep-deprived written blog isn’t so much to talk about dates and apps that never get replaced, but about a much deeper problem I was having. It wasn’t just failing to fully understand git commands, it was failing to understand how I should be using git in the first place.

So, to riff on an old phrase, “Commit Early, Commit often”.

Oh and I did hack together a way for that user to enter hours for last year. It’s good enough. I’m sure I won’t need it a year from now. The code will be all replaced or refactored by then I’m sure!