Revisiting Perl

As I wrote in a previous blog post, I did indeed dig out my Programming Perl book over the weekend and pulled out this particular solution. I’m sure there are other Perl solutions that are much more elegant and much shorter, but give me a break, ok? It’s been a while.

#! usr/bin/perl -w
$file = $ARGV[0];
$output = “new$file”; 
open (FH, “$file”) or die $!;
open (FH1, “>$output”) or die $!;
while(my $line = <FH>) {
    $op = lc($line);
    print FH1 $op;
}
close FH;
close FH1;

What is your Perl solution?

Edit: After Googling for a solution, I found the following on the interwebs:

perl -wpl -e ‘s/^.*$/U$&/g;’ filename

How’s that for small?

Standups: A Cure for the common Meeting

Meetings: A classified ad for hell:

Business people love meetings. Oh God, do they love meetings. Need to pass information along? Hold a meeting! Need to appear like you’re in the thick of it all? Hold a meeting! Want to crucify your subordinates under a mountain of action items? Hold a meeting!

Evil yes, but Meetings are a nasty requirement for ‘getting everyone on the same page’, and letting everyone know where the reelase stands. Unless you’re in chaos driven development, this is a Good Thing™.

To this end, the Agile folks came up with the Daily Standup meeting.  In order to get rid of the ‘ew, meeting‘ feeling, a stand up does the following and only the following:

  • Starts precisely on time
  • All are welcome, but only “pigs” (Team Members) may speak
  • Limited to 15 minutes
  • Occurs at the same location and same time every day

Each “pig” answers the following questions:

  • What have you done since yesterday?
  • What are you planning to do today?
  • Do you have any problems preventing you from accomplishing your goal?

The metaphor of the pig comes from a joke that is appropos to software development:

A chicken and a pig are together when the chicken says, “Let’s start a restaurant!”.
The pig thinks it over and says, “What would we call this restaurant?”.
The chicken says, “Ham n’ Eggs!”.
The pig says, “No thanks, I’d be committed, but you’d only be involved!”.

 

A key requirement of the daily standup meeting is that participants stand up during the meeting. The “stand up” part keeps the meeting down to a sane 15 minutes. You can read Martin Fowler’s excellent expansive treatise on the topic, or you can follow these three four simple steps:

  • Stand Up
  • Last in, First to Talk
  • Stay focused on “Yesterday, Today, Obstacles.”
  • All team members participate

That’s it.

 

Curly’s Law

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)

 

namespace LCConverter
{
    class LCConverter
    {
        static void Main(string[] args)
        {
            string oldfilename = CreateStringFromFile(args[0]);
            string newfilename = args[1];
            string lcFile = oldfilename.ToLowerInvariant();
            GenerateNewFile(newfilename, lcFile);
        }
        private static string CreateStringFromFile(string filename)
        {
            return System.IO.File.ReadAllText(filename);
        }

       
        private static void GenerateNewFile(string newfilename, string lcFile)
        {
            System.IO.File.WriteAllText(newfilename, lcFile);
        }
    }
}

 

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.

Coming In Through The Back Door

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.

biz stone search

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.

teh facebook, it is evil

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:

Open Auth Settings

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:

 

 

 

Smoke Test

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.”

 

What’s in a [Route] Name?

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.

It’s up to Us

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.

 

Practical Uses For Fizzbuzz – Part 2

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:

 

for (i = 1, i <= 100, i++) 
{      
    if (i mod 5 == 0 && i mod 3 == 0) 
        print “fizzBuzz”;     
    else if (i mod 5 == 0)
        print “buzz”;
    else if (i mod 3 == 0)
        print “fizz”; }
}

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:

for (int i = 1; i <= 100; i++)
{
    string output = String.Empty;
    if (i % 3 == 0)
        output += “fizz”;
    if (i % 5 == 0)
        output += “buzz”;
    if (output == String.Empty)
        output = i.ToString();
    Console.WriteLine(output);
}

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.