Writings

I’ve been writing SQL Scripts in Oracle over the past few days, and since it’s not my native SQL land (I much prefer SQL Server), I sent an email to one of our native PL/SQL guys and asked him to look over the script I wrote.  One of the things he mentioned for me to fix was that the script should be in all lowercase because the server is a Unix server. Ok.

So I did the complete non-programmer thing and I started going through and changing the SQL Keywords to lowercase, as well as all the table names.  About a 1/3 of the way through it I realized thatt I could just as easily create a small application that would do this for me.  My instinct was to use Perl, but given that I haven’t used it in years, I opted instead to create a C# application to do it for me. Over the weekend I’m going to pull out my Camel Book and see what I can remember.

The C# code is trivial, but it’s fairly representative as to how I write code. I follow Curly’s Law:

Curly: Do you know what the secret of life is?

Curly: This. [holds up one finger]

Mitch: Your finger?

Curly: One thing. Just one thing. You stick to that and the rest don’t mean shit.

Mitch: But what is the “one thing?”

Curly: [smiles] That’s what you have to find out.

An algorithm, function, method, or whatever you call it in your favorite language should only do one thing. That’s it. One. It feels a lot like speaking in three word sentences, but once you get the hang of it, it makes it much easier to test your code. And who wouldn’t want to test their code? (grin)

Spending 10 minutes creating this tiny little application could have been spent manually checking the SQL scripts, but that’s no fun, and now I have a way to do it for all of the SQL Scripts I write. I can simply write them in ways that are readable to me, and convert them to the ‘required’ way with no fuss.

Have you used Twitter Grader?

If so, you’ve just fallen prey to your account being hacked. Don’t worry, your password is safe, but this application just sent out link spam as you.

You’re not alone.

The attacker apparently got in through a hole in Twitter Grader that allowed him to send tweets through every user that authorized Twitter Grader. Ever.

That’s a scary thought, but it’s going to be more common as an API based world takes over. It already happens in Facebook. Every application you authorize brings up an omnious looking dialog box.

Allowing Pet Society access will let it pull your profile information, photos, your friends’ info and other content it requires to work.

Why does this application need all that?

Didn’t API designers ever hear of the principle of least privilege?

The principle of least privilege (POLP) is the practice of limiting access to the minimal level that will allow normal functioning.

Once you get on the road of API security, you still have to worry about revoking access when it’s no longer needed, also a central  tenet in computer security.

Twitter allows this in a backhanded fashion. The onus is put on the user to remember that they authorized an application.  Sometimes, these applications can lurk for months and still have Read and Write access to your twitter account:

Pop Quiz: Out of all of these applications, which ones do I really need to have perpetual access to my account?

None of them.

Asking ourselves “Why”?

If we pop the Why Stack, we find out how to keep this from happening again:

1. Why did this attack work? Because Twitter Grader used Read/Write Access to Perform its function.

2. Why did TG use Read/Write access? So it could send out a tweet telling others about twitter grader after they used the service.

3. Why did it keep R/W access? Because there is no mechanism in place to automatically revoke it after it’s done.

4. Why isn’t there a mechanism in place? Because we didn’t write one.

Lessons Learned:

1. Always revoke application access to your account after whatever you use has fulfilled its purpose.

2. Never give any application your OAuth token if you aren’t completely comfortable with it tweeting as you.

3. Security fundamentals aren’t.

Update:

• Dharmesh Shah of Hubspot wrote up the analysis of the attack and an apology.
• The Guardian posted an online article about the incident.

Even though I’m colorblind and didn’t realize that Jeff Atwood’s IDE color scheme contains both red and green, I still use his Visual Studio Scheme.

His blog went down. And the files? The files, they are gone.

So, I’ve mirrored them here.

• Jeff Atwood’s IDE Color Scheme

Smoke Test – Non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.

Origin – When testing new hardware; engineers would flip the power on and check to see if there was smoke. If so, it failed the smoke test.

Anecdote:

We write banking software for mini-computers. Our Help Desk got a call from a customer who was new to mini-computer operations. The call went something like this:

Customer: “There is smoke coming from the back of the computer. What should I do?”
Tech Support: “Get out of the computer room and call the fire department.”
Customer: “Should I make a backup first?”
Tech Support: “Get out of the computer room and call the fire department.”
Customer: “Shouldn’t I at least run the shutdown procedure?”
Tech Support: “Get out of the computer room and call the fire department.”

In ASP.NET MVC-land, there’s no such thing as a location that you or I think of. It’s all controllers, actions, and route values.

Someone forgot to tell relative URLs that.

If you’re using a relative URL in ASP.NET MVC, sooner or later you’ll bump up into the same problem I did.

You have a route, it looks like this:

         routes.MapRoute("Edit",
                "{controller}/{action}/{id}/{*pagename}",
                new { controller = "Page", action = "Edit", id = "", pagename="" }
                );

You would expect that anything pointing to:

http://localhost:3919/Page/Edit/11?pagename=news

and:

http://localhost:3919/Page/Edit/11/news

would match, right?

They do. Except when you want to include a physical resource. You know, like a script.

Your script folder is a physical location, these routes are not. But the script doesn’t know that.

If you were to drag the script from the Visual Studio IDE to the editor window, you’d get something like the following:

<script src="../../Scripts/tinyMCE/tiny_mce.js" type="text/javascript"></script>

Guess what? That matches the first route, but not the second. Ooops.

If you’re going to use a static resource in ASP.NET MVC, be aware of two things:

1. controllers and route values aren’t tied to any particular paths.

2. Static resources care about paths.

I blame part of this on Visual Studio. ASP.NET MVC shouldn’t let you shoot yourself in the foot so easily. It knows you’re dealing with MVC, it should give you absolute paths when you drag and drop items.

Who has two thumbs and feels embarassed that he spent an hour debugging this issue, down to a line-by-line compare of the differing files? This guy.

I forgot the sliver that says, “Time spent making Graph jams to sketch out how work time is spent.” That’s about 8% of my day right there.

We complain about companies. We complain about our working environment, or how we don’t have automated builds, or how we just can’t seem to get managers to realize we need large monitors and little interruptions.

The companies aren’t the problem. We are.

The last time you talked to a recruiter (headhunter or otherwise), what questions did you ask him? If you’re like me, you asked about the job, the company, the pay, the benefits, and whether it’s a contract or permanent position.  And just like me, you became the problem.

The reason why companies don’t improve our work environments is because we don’t hold their feet to the fire. We don’t ask the questions that need to be asked.

It’s up to us to ask the right questions.

The Joel Test is a good place to start. It’s written by someone who is respected both by businesses and by the software community.  Better than all that is the fact that his name wasn’t something like “Vladlimir”. That doesn’t sound good at all. “The Vladlimir Test” (bonus points if you say it with a faux russian accent).

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The Joel test should be the first thing you send to a recruiter. Don’t continue the conversation until you have an answer to your questions.

Repetition, Repetition, Repetition.

It sounds obstructionist, I know. But unless you’re living under a bridge (how’s the wifi access?), you’re hurting yourself by not doing this. When you send this to every recruiter you come in contact with, and your friends do the same, they start to become immersed in our culture. They see it repeatedly, and it becomes a part of their contact with their client.  Their clients then realize that we mean business, and they’ll start to institute change.  It won’t happen overnight, but it will happen.

Expand. Once you get employed, bring it up to your manager. Be that instrument for change. Institute those items that your team is missing on this list. When you leave your company, point out specific reasons why you left — be sure to include some bullet points from above.

Why the Joel Test?

Well, the “George Test” isn’t written yet. But I do have some questions that I pose. I don’t just pose these questions for their direct answers, but because of what those answers tell me about the company.

1. How’s the Internet Access?

Companies that blocking software rank low on my list of companies to call “Home”. I surf the internet looking for answers, and when a programming site gets blocked, I have to spend time to find a way around that. That’s time I’m not being productive.

2. How much overtime do you expect?

Deathmarches suck. I left a company because of a continual death march.  It wasn’t one or two, it was endemic in the company — and it came from the top down. The company was ‘sales driven’ and that included selling items that weren’t actually in the product yet. Since we were ‘contractually obligated’ to provide those features, the deathmarches were to implement those features before the client walked. If they waffle when they answer that question, beware. There are studies that prove that working more than 40 hours a week is harmful. Any software team that doesn’t know that isn’t worth working for.

3. What’s the dress code?

This gives me an idea of what type of company it is. If it’s a software company, generally it should be quite relaxed (Dress pants and a button down together are a stretch). There’s no need for it not to be. The more time developers have to spend on dry-cleaning, the more work turns into a chore.

4. Do you conduct Code Reviews? Brown Bag Lunches?

5. How many meetings do you have?

When programmers are in meetings, they aren’t productive. Normally, they’re bored and wondering why they’re in the meeting in the first place. Meetings should be kept to a minimum. As in a number less than 2 per week. 0 is good. I like 0.

6. Do you pay for me to attend professional conferences?

If you want the best, you’d better pay for the best. If you want to be cheaper and pay for the good or mediocore, you better be willing to pay to make them better. If you want a warm body, talk to someone else. I spend my free time coding, talking to others about code, or reading about code. Conferences are the ‘next level’. They are the thing that re-energizes the masses (In fact, every Microsoft Conference invariably reinvigerates the masses for about 6 months until everyone realizes it’s bullshit. See: “Cloud” computing).

7. Why should I work for you?

This is a way to see what businesses are passionate about what they do. The ones that aren’t don’t need your dedication and time.

Wasn’t it your own Hartley who said, nothing reveals humanity so well as the games it plays? Almost right. Actually, you reveal yourselves best in how you play.
– Q to Riker, “Hide and Q”
Star Trek: The Next Generation

How someone writes code can tell you a lot about them.

Fizzbuzz, although simple, provides plenty of fodder for discussion, and in that discussion can show you whether or not a programmer has the chops to produce quality code.

Fizzbuzz can be used to validate resume buzzwords.  If someone declares themself as an ‘Expert’ in C#, it’s really easy to see if they really are. I mean, an Expert should know the modulus operator, right?

Take this example:

There are a few good starting points to be made from this piece of code: 1. What is the modulus operator in your favorite languge? 2. Where’s the bug? 3. How can we improve this code to reduce duplication?

If the candiate believes that the modulus operator for their favorite language is mod, and they aren’t in Visual Basic, then the interview should be terminated. There’s no sense in going past that point.

While there isn’t a bug in this code per se, it could use some refactoring; the logic is left wanting, to put it simply. The order of operations is opposite of what you’d expect.  3 comes before 5, and in any loop 3 will always come before 5. This isn’t a bug, but it is a logical error, and fixing logical errors are central to debugging harder problems.  If your maintanence programmer has to figure out why you did something counter intuitively, it heightens the chance that he’s going to make a mistake.

Finally, the code can be improved substantially by using a string variable and appending each part to it.  If a candidate has gotten past the first gate and into the second, this question will help shape your mind on what sort of programmer they are.

Example ‘fixed’ code:

It doesn’t have to be a complex code sample to be of use in an interview, but it does have to be done on the spot. Using a code sample is the only way to really see what sort of code the programmer turns out.

Don’t neglect this tool when interviewing programmers, or your bottom line will regret it.

But all the colors mix together – to grey. – Dave Matthews Band “Grey Street”

I wrote about my colorblindness yesterday.

It was hard to write that sentence, and even harder to write that post yesterday. I used the word ‘disability’ in my post yesterday.  I didn’t put that word in there, my fiancee did. That’s how hard it is for me to write about it. 

It shouldn’t be, but it is. 

There’s embarassment, sure. Even more is that when you’re blind, people get why that’s an issue. There are best-practices out the wazoo. But when you’re colorblind, the level of caring about your web experience ranks somewhere between apathy and ignorance.

But it is a disability. It is not as severe as blindness or deafness, to be sure. But unlike blindness, it has no representation in the minds of website designers. It’s a non-issue.

At one time we had to worry about colors. Remember these?

We’ve come a long way in the battle for web design. We’ve even come to the point where we can laugh at our former works of art. At one time, there was a notion of web-safe colors. As soon as technology allowed, we tore down that wall and kept its ruins as mementos of a barbaric time. We congratulated ourselves and heralded a new age, instituting best practices for accessibilty and starting an entire cult based around fixing web accessibilty. We thought we won, but we didn’t.

Date Usability, Don’t Just Flirt With Her

 Accessibility is usability’s sister. The one you have to impress to score a date with Usability. The annoying one that you’d rather tune out completely, but can’t. we missed this in our celebration.

Examples of our failure are everywhere, even from Google:

The annoying sister butts in again. Were it not for the numbers, there’d be no way for me to tell which one is which.  Even with the numbers, I still have to do mental gymnastics, the very kind usability experts rail against.

Stack Overflow recently started including vote totals; If you click on a vote it tells you how many were upvotes and how many were downvotes.  The original implementation (left) was fine. No need to change it. But the website creator decided to change it to a green color to indicate ‘good’ and a red color to indicate ‘bad’:

So, which one’s better?  I see color, but they both look an annoying shade of red, one darker than the other.  It would have been better never to institute the ‘fix’ at all.  The newest iteration shows a + and a – next to the votes — which is also helpful, but it doesn’t take away from the pain the second image induces when I look at it.

Let me say that again:

Trying to distinguish red from green is painful.

Design for Colorblindness

You may wonder why you even need to design for colorblindness.

If you’re a web-based business, 1 in 12 of your customers are colorblind.

Here’s how to cater to the colorblind demographic:

1. Keep conflicting colors apart. Red and Green shouldn’t be in the same zipcode. We can see them fine when they’re apart, but when they’re together, we get headaches.

2. Study up on Colorblindness. See what it’s like to be colorblind.

3. Don’t use colors as the only distinguishing information; and obey rule #1.

4. If you must use colors (like on a graph) then make sure to use Colorblind safe colors.

Bottom line: paying lip-service to accessibility means paying lip-service to your customers.

I’m Red-Green Colorblind, and it embarrasses me.

I didn’t realize I was red-green colorblind until I enlisted in the Army.  During my trip to MEPS, I took a red-green colorblind test for my Military Occupational Specialty (A fancy phrase for ‘Job’) 13F (Another fancy code that means ‘Forward Observer’).

I failed the test. 

I’m not sure how I was still placed in that job, because by all rights someone should have stopped the placement — but who am I to argue? I enjoyed the hell out of my time in the Army and am really glad someone screwed up their job that day. 

That was the day I woke up; the day I found out I’d been missing something all those years.  I was 17.

I’m 27 now. Being fully aware of my disability I have to ask my fiancee if what I’m wearing ‘works’. She spends extra time ribbing me for this. I think she’s getting paid to do it. She mutters something about kindergarteners knowing their colors. I wonder why I fell in love with a teacher.

Being red-green colorblind means that I can’t tell red and green apart when they’re together. 

Christmas is a nightmare for me.

There are different levels to color-blindness, I happen to fall in the deuteranopic category.  That means that dark green looks black to me, and red and greens resemble each other when they’re close together.  I can tell a shade difference at times, but it’s only for specific shades. 

It’s embarrassing because whenever I think of my colorblindness,  I think of how we’re an unrepresented minority, almost forgotten in the web-design landscape. You often hear Web designers talk about accessibility for blind people, but how often do you hear them talk about accessible websites for colorblind individuals?

Where you see a cascade of colors, I see grey. 

Where you see joy and festivities around the holidays, I dread parties because I might comment on someone’s red dress and then find out it is green. 

Where you look at clever color schemes and see that the voting mechanism is seperated by more than one dimension, I’m constantly reminded of what I cannot see. 

Is it the end of the world?  No.  Does it royally suck?  Yeah. 

Tell someone in a wheelchair that they can’t have access to the building simply because it’s old and doesn’t have a ramp.  See how far that gets you.  We cater to all other disabilities, but if you’re colorblind, you get nothing.

If you’re a web developer, design for colorblindness.You wouldn’t antagonize any other disability, so antagonize us?

Spend time in our shoes: see what it’s like to be colorblind on the internet.