Blog | RSS | Photo Gallery | Wish List     Eric's Blob
    HPM Social Meeting, Feb 12 2003 Posted at 22:37 by Eric
    We had our Harrisburg Perl Mongers social meeting again this Wednesday. We meet every second Wednesday. I am well aware that people have been particularly busy lately. Some have been having difficulty seeing their own wives, let alone finding time for a Perl meeting.

    Knowing people's schedules, I was particularly pleased to see the turnout this week. It was several people more than I had expected. Although a few notable faces were missed, we definitely had a good time. It's certainly a neat group to get together with.

    One person in particular who couldn't make it, was Maurice, the group leader. He found himself in a bummer of a predicament recently, when he found himself looking for a job. After many months, he finally found one... which was two and a half hours away. He's currently commuting.

    Maurice is looking to hand over the reigns, as he doesn't feel that he'll be able to participate as much as he'd hope. Left nominated, is me. While no one has responded to his public query for thoughts on his nomination, I'm inclined to think that most could care less. Not that anyone is cynicle, but that our group is fairly self sufficient. Maurice provided a lot to the group, helping to keep everyone involved, find out how they are using Perl, and such. Others frequently pitch in too, making everyone an important asset.

    I would happily accept, I feel that I have a lot of great ideas that we can implement as a group. At the same time, great leaders often lead best by inspiring people, and then staying out of the way. There is certainly a compromise in the above. Surely I'll have an opportunity to explore the line. Equally as certain is the fact that I'll error on both sides at one time or another. It appears to be a neat learning experience for me though, and hopefully I'll be able to make a difference, and help the Harrisburg Perl Mongers to thrive. It should be fun.
    | |

    Hubris is Dead. Durn! Posted at 20:34 by Eric
    False laziness and false impatience strike back. Hubris falls over dead! Well, darned if I didn't just forget everything I ever knew about the three virtues of a programmer (laziness, impatience, and hubris). Further, the number one thing I've been studying lately, design, just went out the window.

    The book entitled "The Pragmatic Programmer discusses a concept called broken windows. Apparently, in New York, it is illegal to have a home with a broken window. It actually encourages others, if a window breaks, to leave it that way. Suddenly, all sorts of people have broken windows. But it gets worse. Now that things appear to be really run down, graffiti begins to appear. And then crime rises in that same area. All because of a broken window.

    I actually built a house from the ground up, complete with broken windows. I allowed pressure to get things done affect my judgement as to how I should develop a piece of software. I was given a project that I thought would take 2-3 weeks to complete. No big thing. But throughout the whole process, I was frequently told that this needed to be done quickly, as quick as possible.

    So, I fired up my text editor, and started banging out code to get the job done. Neither Perl nor Vim were at fault here. Several mistakes stand out:
    • Code Seperation
      Although I had a variety of functionality, I stuck it all in the same file. I had the perfect opportunity to create seperate modules at this point, allowing for quick usage in the future. It's quite certain that this functionality will need to be reused in the near future in another project.

    • Logging/Debugging
      Anyone who uses print or warn statements for debugging is making life unnecessarily hard on themselves. There is an excellent module available to Perl programmers called Log::Log4perl. Using a config file, you define what the log level should be at. So certain things will print out during debug mode, and (hopefully) less would print out during normal execution while in production. You can even do things differently based on if you are in debug mode or not. But I skipped out on all these features. No, my code is full of... stricken with.. warn and print statements. I'll have to manually remove each one when this code goes into production.

    • Config File
      There are a variety of options set within the program. Now, it was done reasonably well within the code. They were not hard coded where it was used, they are all config variables defined at "sensible" locations. However, it was insensible of me to do this in the first place. These options shouldn't be defined within the program. This stuff should be easily configurable via a simple text-based config file. Now, if I want to change any of this, I have to open up the code, and risk breaking it in order to change variables within it.

    The fact is, it's going to take me longer on this project to move from development to production because of all this, that it would have taken if I coded it right to begin with. It's really not all that hard to do the above. But I got a false sense of security in that if I hurry through everything, I can see things working quicker, and I can show that off to those looking over my shoulder asking for results. On a project this small, by just waiting a few more days before showing off any features, I could have it coded right the first time.

    I believe that no matter which way it was coded, it will go into production at the same time. The poor way simply front-loads the visible features. Not included in the time estimates above is the fact that I'm going to go ahead and refactor it to make it right. I'll seperate different functionality into modules, I'll create a config file(s), and I'll use Log4perl to do logging and debugging.

    I hope to learn from this experience. First, I am eager to fix all the above, and to see how it looks when done properly. Second, I look forward to being able to start another project, and to do it right from the ground up. What disturbs me is that I know all this, and I do it well when I want to. So the learning experience here is to decide to do it, each time.
    | |