August 2009 Archives

I have asked TPF to send a check to our venue for Frozen Perl 2010. It should have arrived a few weeks ago, so hopefully the accountants on both sides are on top of things.

Frozen Perl 2010 will be on Feb 6th with classes preceding, and a hackathon proceeding.

See you all there

In June I gave a talk at yapc about how not to be a noob (slides).

I just found out that one of my very first projects that I had at the U of M was retired and replaced with a similar system re-written by a student (just like when I wrote it). The problem with this is that they missed the most important thing they could have done.

They should have asked me what I wished I had done differently. As a result they made a lot of the same mistakes that I made. This is really disappointing. These students had full time employees monitoring them, and they never were directed to seek my assistance.

I will reiterate one point that I talked about in June:

Learn from those around you with more experience. That experience counts for something, and you can re-learn it, or you can learn from them, and create a better product.

I am not the only developer they could have talked to, and they should have talked to someone, but instead they recreated the bad design that was in front of them, because they didn't ask if there could have been a better design.

There is always the possibility that there is something I am not considering, but none the less, I am disappointed.

How would you go about teaching Perl (or any language) to children?

Here is my plan for my own offspring. The main points of this plan are: taking it slow, and: taking baby steps, and trying to show results at each step giving positive feedback to the child..

Before I get into the plan, I want to point out that this intended for the teacher to already be a programmer, or at least be able to learn on their own, since a lot of the teaching will be individual in this case.

1. Output.
   
   Start with printing simple Hello world. If you cannot see what the program did, then it isn't any fun at all to do.
   
   
2. \Variables.
   
   Start simple, Teach how to store a number into $x, then how to store a string, and printing them back to the screen. Explain that when Perl 5 sees a '$' it expects 'something it can print' (a scalar). This will help when later working with arrays and hashes.
   
   This first part of this step should include arithmetic so that the child can actually have something useful with his or her program, even if it is a big complicated calculator.
   
   Move along to hashes. explain it as a bucket where you say something is something else like John is tall. Point out that if you say that John is skinny, that you lose the tall, because John can only be one thing at time.
   
   Then do arrays. I saved this one  for last, because of the possible confusions with the zero based arrays in Perl and most other languages. I like to describe the index, as "move X spots from the beginning"
   
   For each type of variable make sure that the child can put data in, and get it back out, and print it to the screen again.
   
   This might be a good time to point out the difference between array context and scalar context, or you might want to wait till later.
   
   
3. Now you might want to teach about use strict;
   my favorite example is
   $ZipCode = '12345';
   print $ZIPCode;
   If you want to separate it with a lot of code inbetween that will help make the point.
   then turn on strict, and show how the compiler complains immediately, making it a lot easier.
   
4. Loops.
   
   Start with a foreach loop, since it is the simplest construct. I suggest starting with a local variable to avoid $_: (you should always avoid $_)
   foreach my $item (@array){
   ...
   }
   
   next cover a while loop, since it has simple syntax, and move on to the for loop
   
   
5. Special variables
   
   since they are going to need to know, teach about $_,@ARGV @ENV and %ENV.
   Show them where to learn about the other special variables and what they do.
6. Branching constructs
   
   teach about if/else blocks. do not encourage use of the postfix notations:
   $x = 3 if $x==2;
   rant: Damien Conway is correct about the postfix notation being a bad idea. The idea of a thousand lines of code not being executed because of the last line, seems like a bad way to go. /rant
   
   Instead of the postfix if construct, teach $x = $x==2 ? $x=3 : $x;
   It does the same thing, and avoids some potentially bad behavior.
   
   
7. subroutines.
   create a subroutine, take in some inputs, use @_ as well as shift;
   do something with the data, and then return something.
   
   This might be a good time to point out the difference between array context and scalar context, by returning an array from the function.
   
8. loading libraries, using someone elses code.
   
   Show off why Perl is so great! up till now they haven't learned anything that another language couldn't have offered. Show the the CPAN. Show the perl core libraries. show how to use perldoc, show how to really start having fun with Perl.
   

Advanced topics that I will cover at a later date

1. create a cgi script
   
2. using databases
3. creating a package of your own
4. hashes with several layers of internals (leading towards objects)
5. use bless to make an oo object.

I will start to teach my nine year old daughter Perl using these steps. Here's hoping she is interested and that I can keep her interested... I will post my progress as it goes along

I don't often think about why I like to program, so I figured I would put some reasons here as to why I like programming.

1. I like creating solutions to problems.
   
   I like the design process of defining the problem(need), finding the solution, and creating that solution for someone.
2. I like hard the sciences.
   
   Unlike those with Liberal Arts degrees and the fields that they go into, either my software works, or it doesn't. You cannot argue with an error log showing crashes. Measuring success at certain points in the development cycle are fairly simple: there was a bug, now there isn't, or "We need a function that takes x, does y, and produces z". These things are very measurable, and very gratifying to complete.
3. Technology.
   
   Lets be honest, I like technology and gadgets. I like seeing hardware prompting innovation. I like ideas where something simple like GPS on a phone is suddenly used in social networking, or combining the phones camera with the gps, compass, and tilt sensor to create new ways of viewing the world with photo/social networking.
4. I get to meet people.
   
   Because of my usage of Perl, I have met several interesting people from the Perl community. Some of these people have lots of clout and name recognition, and some don't, but equally as intelligent and interesting.
5. I can work from home.
   
   Because I do all my development in Perl, and all the tools I use (Apache, emacs, Perl, mod_perl) are open source, it is very easy to put all these things on a laptop and go home and work from there. Because of things like Strawberry Perl I am not even required to have a linux machine or a Mac. I can use pretty much whatever hardware/software I have at home (and I do!).

That's all that comes to mind right now, but as time goes on, I will think of more, and maybe I will have a 'remake' of this blog post in the future.

The room for Frozen Perl has been reserved, and I have requested that TPF send a check for the downpayment.

Organization meetings start on 8/27.

If you are interested in helping organize, please email me, or leave a comment here.

If you are interested in a sponsorship opportunity, I would be happy to hear from you, please contact me either my leaving a comment here, or by any of my University contact info.

After getting into work this morning at 5:00 A.M. waiting for someone else to do their part in a system upgrade, I thought a post about the cons to being a programmer would be appropriate.

Lets face it, being a programmer isn't always fun and peachy. Sometimes it really sucks, and lets face it, there are days you go home and just dread working the next day.

If any of the following are intolerable to you, then you should think carefully about being a programmer.

1. If you cannot stand seeing your work thrown away.
   
   This one is probably the biggest surprise for new programmers. The majority of programming is 'Do it once', and then 'Do it right'. I have found that working for a University that there are customers that demand that specific features get put into code and then that feature is NEVER used. Sometimes the code never makes it to a production environment. Sometimes entire projects are scrapped before you can even have the satisfaction of seeing code that runs half way properly.
   
   I have seen many new programmers, both young and old, get frustrated by this. You need to understand that the first draft of any program is just that: A DRAFT. BETA SOFTWARE! I usually find that the customer didn't artculate what they really wanted, and now that there is something to look at, the customer can more easily describe what they want.
   
   Just understand that you did your best to meet their requirements, and now they better understand their requirements and can better meet your needs for requirments after seeing a running version of the program.
   
   
2. I goofed up, and now you have to fix it.
   
   I used to get this all the time. A customer would screw up a process, or put bad data in, and it would become my problem to find and fix the problem.
   
   For about 3 years one of my tasks was to run a report every month, to find the mistakes that were entered into our PBX database that affected our export to the police for E911. The process to enter the numbers in, never changed (I think it is still the same now two years later even), however, there were a few individuals who couldn't follow the process and would consistently mess up the E911 export and I would have to find/follow up on the fixing of this data.
   
   Another example of this comes not from customers but other programmers. Once there was an application that had a University wide user base. When some programmers/admins decided to replace the vendor that ran the backend software/hardware. They neglected to consider this University wide front end. As a result I had to throw together a CGI program that duplicated the essence of the first application. One day later I had an application that is embarassing to re-read, but it worked, and did the job.
   
   
3. Deadlines.
   
   Sometimes projects have a deadline. A lot of my deadlines are related to the fact that students are not on campus but on August 15th, they start coming back. This cannot get pushed back, no matter how much I want it.
   
   Sometimes this deadline is artificial, and unreasonably set. Sometimes managers don't understand the amount of time needed to do certain things is not easily guessable. Sometimes they guess themselves and make bad decisions that come down hard on you.
   
   Given that I work in Academia meeting deadlines is less of an issue for me, but I was moved into an ISO group that needs to break even when looking at the books externally, so I am getting a better feel for what this is like lately. My managers have been very good at including the developers in the estimation process, so I cannot complaint too much about this topic.
   
   
4. Customers that don't understand what you do, or how you can help.
   
   This requires patients on your part. YOU need to teach the managers/customers exactly what you are capable of, and YOU need to be willing work with them. This type of problem if allowed to persist, can leave you watching too much youtube, and not enough programming, and may leave you without projects/jobs.
   
   
5. Working off hours to do upgrades/deployments.
   
   Updating a system usually requires you to wait until there are nearly no users on the system. This can mean working on weekends or like me today, showing up to the office at 5:00 A.M. This is usually a planned event, and can be forseen, but sometimes vendors put out emergency security patches, so sometimes they are unavoidably unplanned.
   
   
6. Reading someone elses code.
   
   Lets face it, this can really suck. However, if you cannot read someone else's code you really cannot be any use on a team. Reading someone elses code, is sometimes like untangling six strings of Christmas lights you bought at a garage sale for $.25. Sometimes it is no fun at all, but you are getting paid to do it ...
   
   
7. Spending days on problems before making progress.
   
   This one really sucks sometimes, however you hopefully have something/someone to help you beside the internet. Sometimes you can spend days working through problems, one baby step at a time, and never seem to get anywhere.
   
   This can happen when joining into open source projects that have a very fluid code base, and everything is in flux. I spent a month trying to get the bleeding edge of MojoMojo installed.
   
   Everyday was the same:
   Run 'svn up'.
   Run the catalyst server,. find (some of) the missing/out of date modules (they changed every day).
   Run CPAN installers, find out that module X doesn't install
   Fix and install module X
   Re-run the catalyst server find the next dependancy change
   etc ...
   Its 5:00, go home, and start all over the next morning.
   
   
8. Writing readable code, adhering to coding standards/styles that are not your own.
   
   If other people cannot read/fix your code, then your code is unusable. If they have to re-write it with the first bug, then you shouldn't have bothered in the first place. The exception to this can be found in #2 above, however, that is the exception and not the rule. About a month later, I re-wrote the entire program using all the coding standards and rules that my group uses.
   
   Noone likes the allstar programmer, and while it gives you job security, you can never take a long vacation without a cellphone and laptop. You also will breed contempt with your fellow programmers who have to re-read/redo your code.
   
   

I am sure there are more to add to this list, but these are the few that come to mind at my office 2.5 hours before I usually get out of bed.

I hope that some newer programmers look at this and can sse that thier job doesn't suck as bad as they think it does. We are all in the same boat, and we all are dealing with the same problems as they are.