Perl Tutorial: Don't name a variable i, y or j

I worked with a guy named Dean back in 89-91 at Dupont that taught me a really simple trick. Most people use the variable names i, y or j for simple counters ( damn Fortran). I don't know about emacs, but in vi, a search for 'i' is painful. But searching for "ii" is much less painful.

My counters are now always 2 letters for this reason.

So if you are going to use simple non-descriptive pointer variables, use something you can reasonably search.

Moleskine Cahier Notebooks

I carry the small cahier in my back pocket all times. It is great for quick notes. Ok, mostly honey do lists.

I found one trick to it surviving a few months in my back pocket. Take a piece of heavy packing tape reinforce the binding with it.

Because of my use, I wish the last pages where not perforated. I keep 1-2 index cards in the pocket for that.

This was a quick one.

Perl tutorial : usage() and here dcuments

I tend to write many Perl utilities. Some are just a few hundred lines. But the user needs to know how to use it. As is usual, written documentation is not well maintained and rarely read. But if the default behavior of a application is to print a small man page when there is an invalid parameter, then you have useful and used documentation.

I make this a feature of everything I expect to be used by others. If it is that complex, I put it in anyway so I do not have to read the code. Just run

myscript -help

Actually any invalid option will work. I usually don't have a specific test for "-help".

Here documents like in shell scripts are handled like double quoted strings. Variables are interpreted.

So instead of

sub usage
{
print "fobar() -dir DIR\n";
print " -dir DIR is the directory to ...\n";
exit(); //yes I always assume that usage() is an exit point.
}

do

sub usage
{
print <<endodcs
fobar() -dir DIR
-dir DIR is the directory to ...
enddocs
; #end of print statement
exit();
}

Perl Tutorial: Function Pointers

In C the function pointer is how to passing functions around. In Perl using an ampersand in front of a string is treated an a function call.

sub foo { print "called foo\n"; }
our $functname = "foo";
&{$funcname}();

Using this technique, I was able to override functions based on the product I was building.

For the current default product I has a series of calls to perform a build. Some might be:

• checkout
• email
• installer

So I set a naming convention. Another product lets say foobar1_0 was a previous build and the current product is foobar2_0. The checkout or installer procedure might have changed between the two releases.

The current script will build foobar2_0 by default. But when foobar1_0 requires a patch release, a build has to be done using the old checkout and installer procedures.

I define a library foobar1_0.pm for the foobar1_0 build rules:

sub foobar1_0_checkout()
{
}
sub foobar1_0_installer()
{
}

//we are defining overrides for checkout and installer,
// but like build, nothing else is overridden. e.x in the full code, there are
// about 40 definitions of function and global variables.
//NOP is a No op function for functions that are not to be run.
%foobar1_0_map = {
# variables that need to be set
"checkout"=> "foobar1_0_checkout",
"installer"=> "foobar1_0_installer",
"make_test" => "NOP"
"build"=>"build"
};

In the main build script we do the following:

//$project_prefix is a parameter. in our case "foobar1_0"
$curmapname = $project_prefix."_map"

//Notice %$curmapname is also a indirect reference.
//%cur_map is now a reference to %foobar1_0_map
%cur_map = %$curmapname

If the main project is built, we do not override %cur_map. But no matter what, we do a checkout by calling
&{$cur_map{checkout}}();

The truth is, I even allow main to be overridden. Yes, in my perl code I usually define a main() function.

So, function pointers are alive an well in Perl.

Note: You can not use strict to do this coding. If someone finds a way, I'd love to update this posting.

Perl Tutorials

I've been doing some heavy Perl coding for over 5 years now. I think my most challenging was a build script I inherited. When I started, there was one copy of the script for each branch and there was no error checking.

This means bugs in one had to be fixed in 2-3 other places. Also the build rarely ran to successful completion.

When I left 3 years later, there was one script. Not only was there only one script, but it handled multiple products.

I am going to write series of post detailing the tricks. Many have been published elsewhere. One or two of them I have only seen in this particular piece of code.

I'll try to write 1 or 2 posts a week until I exhaust this topic.

Am I a Rockstar Software Engineer?

I just saw a blog on Read Write Web titled "Top 10 Traits of a Rockstar Software Engineer"

1. Loves To Code
2. Gets Things Done
3. Continuously Refactors Code
4. Uses Design Patterns
5. Writes Tests
6. Leverages Existing Code
7. Focuses on Usability
8. Writes Maintainable Code
9. Can Code in Any Language
10. Knows Basic Computer Science

Am I a rockstar software engineer?
I love to code, I love to play with computers. I've always said I get paid to have a hobby.
I do refactor my code as I go. Common code sequences into methods. Data structure into proper objects. Functionally breakdown code into separate files. Very reusable code into libraries.

There is so much available code, that I rarely start from scratch anymore. "Leveraging Existing Code" is one of the biggest time savers out there. I just finished a C# app to manipulate excel spreadsheets. If it was not for other peoples code, I'd still be scratching my head 2 weeks later. Mostly because the documentation from microsoft is horrible. But I was able to find examples and snippets that let me write a nice time saver app in 3 days.

I alway focus on usability. I always write out use cases. For UI code I always story board and get feed back from as many people as time allows. If no one can use what your writing, that is not "Getting Things Done". Don't forgete, usability has to do with the messages and the help text as well. Not just the user interface. We've all seen app that look good, but if something happens, it takes the original engineer to know what the error message means.

I have a saying that might piss of those that have come after me. I assume the next guy isn't as smart as me. This forces me to follow the KISS principle. So I do not try to write ridiculously obfuscated code unless required. It pisses me off when people do it to f*ck with the next guy. Because I thing that is the only reason to ever do it without a great explanation. When that is required, the comments explaining the code is always longer than the code.

Another part of maintainability is documentation. I always try to make sure the "main" code files have comments that explain the overall workings of the project. This is so that the next guy can have a clues as to how things flow. I am not really big on full blown comments. Mostly because I know I can be as bad as the next guy when it come to maintaining them. The exception to this is for common libraries. No one should have to use a library that isn't well documented.

Now, here is my favorite. My tool belt has many tools in it. Perl, C#, C++, sql, expect, bash, javascript, PHP, jsaon, xml, xml schemas, xslt, java, cobol, pl/1, fortran, pascal, autoit, silk. I love to learn new languages and play with new tools. The idea is to understand the philosophy of the tool. How it is meant to be used and how to stretch it's use. How to use the right tool for the job. I am only claiming to have full working knowledge of what I am currently using. You want some xslt, gove me a few days to review the book so I have come back up to speed. Ok, for C++, skimming the 2000 pages required to come back up to sped can take a month.

I do have a few flaws.

I'd have to say my flaws are number "4. uses design patterns". I use design patterns, but I am not religious about it. When designing a larger system I do look at The book. I also believe in another form of pattern. If a very well known book uses a particular coding style, or has a specific approach to a problem I am solving, I will copy it. To me this goes to number 8.

Another issue is number 5, "Writes Tests". I'm big on using debuggers and informal test methods. Normally when I write project plans for larger projects I usually have to fight for time to test and document. So formal unit tests are out. It sucks, but in the last few years I have not been allowed the extra time.

This last one has more to do with when I went to school. In the early 80's a CS bachelors degree took 2 routes. Programmer or mathematician. Taking the programmer route I wrote lots of language parsers. But never took the algorithm analysis class. For Data structures I used Knuth volume 1 chapter 2. So I learned about linked lists of various forms. The math requirements was only 2 semesters of calculus. That was more than enough math for me.

But I always get it done. I said that in my interview at Webroot Software. I had a great back and forth about the meaning of "Get's things done". Done is always a compromise for your day job or your venture. Get's things done becomes "what is good enough to ship". Only with hobby code does Get it done ever mean "I can't think of anything else to do to it for now".

Like a great painter that is never finished with a painting, a software engineer always has a todo list in their code to define done, an odd bug that only you will ever know is there (hopefully).

Am I a rockstar? Not the lead singer. More like the drummer. I keep the rhythm for the group, I get a cool solo once or twice during the show, but the other guy gets the groupies. But I know things would sound like shit without me.

Google App Engine - First App

OK, I was one of the first 10,000 people to sight up for Google App Engine.

I do not know if I'll be allowed, but I want to write a digg tool. Since Digg does not let you search your history, I think I'll write a tool.

I'll either find an api to feed the dugg stories to del.icio.us or Google bookmarks allowing your to add comments and tags. Or to keep a local DB of comments and tags to store the meta data for digg history.

With ideas in my head for toys and possible ventures, I just need more money in the bank or an angel.

Since I am not sure of the revenue potential, I'll have to go with more money in the bank.

Go gold go. Sorry Mr. Greenback.

Oy Vey I am writing .net code

I have this manual task I am stuck doing at work. Gathering the result a manual as well. But I am trying to automate it. I am using perfmon to track performance of certain processes. I have perfmon writing this to csv files.

I manually grab the entries from each of the result files to create a summary worksheet. I also graph certain columns, then create a summary worksheet of the graphed results.

I am writing a C# app to create this spreadsheet.

I do not want to be known as a .net kind of guy. But I don't really want others to go through the pain I've gone through.

I guess I write about it once I have posts on some other topics I want to be known for written. This wway I post both sets.

Work verus Self Tought Programming Experience

When I interview someone and they have lots buzzwords, I tend to ask them to tie the buzzword to a job listed on the resume. Many times half the items where in school or they read a book.

School is fine for a kid with a couple of years of experience. But if you are working for more than a couple of years, pull it off your resume.

Today, "read a book" is still not good. But there are advantages to book learn'n. When solving a problem at work, you learn what you need to learn to complete the task. When reading the book, you get to learn about the full breadth of a topic. But that does not mean to put it on the resume.

But, with the web and web services, people can prove what they learned from the book to prove competence. Creating a blog or a wiki, or posting more correct answers than questions on forums. Also with services live AWS, you can implement a service if it is applicable. Maybe create a project on sourceforge. This allows you to prove your book learn'n with real code people can examine.

I have some scripts I wrote a few years ago that had some real cool Perl tricks in them. I am going to show my Perl experience by writing a series of short tutorials, posted here, to show how well I know perl. Or how well I think I know perl :D

I am hoping to do that with Ruby. Write some scripts and post them, or participate in some forums.