Code Reuse and Don’t Re-invent The Wheel



I'm sure glad someone reinvented the wheel so we aren't using stone wheels.

I’m sure glad someone reinvented the wheel so we aren’t using stone wheels.

Every once in a while someone on any one of a number of forums I monitor asks the innocent question “how do I write a module to do?” Even I have given the answer “Check CPAN and you’ll find a module that does that already.” The answer I try to avoid is “Don’t reinvent the wheel!”

I have several  thoughts on that statement.

Sometimes the wheel works fine.

To the left here is a stone wheel.  I have my doubts that anybody actually made ox carts with stone wheels but that is certainly a popular idea.  Even the TV cartoon series “The Flintstones” featured Fred Flintstone revving up his car that featured stone rollers fore and aft made of stone.

The one application I’ve seen for a stone wheel is at a grist mill.  There are more modern replacements for aa stone millstone but I think that even today there is a charm and a quality that is lost with modern grinding wheels to mill grain.

That provides us with a very good example of a wheel that really doesn’t need to be reinvented, but someone decided to anyway and perhaps there were one or more advantages to using the modern version found.

Sometimes the wheel just needs to be improved.

One example of evolving improvements in wheels has been a really good thing.  Like at the evolution of automotive tires over the last century.  We are inventing better tires every years.  Improvements in lifespan, tread wear, traction, foul weather handling and many others have been beneficial to all of us over the years.

Bicycle wheels are another area where the wheel has been improved over the years.

Sometimes the wheel won’t work at all.

airless-tires-lunar-wheel_1

Airless Lunar Rover Wheels

Thinking about wheels I consider the lunar rover’s wheels. They are airless non-pnuematic wheels. Given that the Earth’s moon is an aireless environment this makes a whole lotta sense.  I would imagine the stresses on an inflated tire would be a detriment and finding a way to eliminate the intrisic hazards of an air filled wheel is a good thing.

Other wheel designs I’ve seen aren’t even circles.  I remember seeing a robot with “wheels” that consisted of three spokes each with a pad that was flat in one dimension and curved along its travel path.  The wheels were installed in such a fashion that two pads were always in contact with the travel surface.

That’s reinventing the wheel in such a way that made sense of the application at hand which was to build a stair climbing robot.

Why code re-use?

I tend to be very lazy and can’t stand writing the same code over and over again.  Similar to that line of thinking there are folks out there that have written modules (CPAN and other sources) that do the job very well.  So “why reinvent the wheel” indeed.  If I can plagiarize (with violating copyright or patent) I will.  If a module does the job for me use it.

Summing my thoughts up I have to say that a knee jerk reaction doesn’t cut it.  Use your common sense.  If you need to build something to fit your needs do it.

Problem Solving in Perl (or any programming language)



1210769359IZf8c0A recent posting on Perl Monks and one of the answers to it struck a chord with me. The question was “how do you convert code to a module?” and part of the answer was “plan it to be a module in the first place.”

There is a truth in there but it may not have been presented very well in my opinion.

A lot of us have heard the old saw about “How do you eat an elephant?” “One bite at a time.”

When I have a programming problem to solve my approach is to diagram out the problem and think of how I’d do it manually first. What are steps I’d take to make this all work (see my prior post on modularity here) and divide the larger task up.

Then I’ll take each of those steps and break them down further into smaller components.  Break each of those components down and so forth until it can’t be broken down any further.

Sample flow chart. Used these during 1972-1980 time frame to diagram out programs.

Sample flow chart. Used these during 1972-1980 time frame to diagram out programs.

Back when I first started programming in 1972 we used go through a process called “flow charting” and we’d manually draw diagrams showing each step.  Still have flow chart templates (green plastic) at home. Later on the technique of using “pseudocode” was introduced, a technique I still use to this day.

Both are valid techniques as far as I’m concerned.  Whatever helps you visualize the pieces of the puzzle.

Next, look at what you’ve diagrammed out and figure out what pieces could be grouped together as a logical unit.  In Perl this would end up being a module.

An example:  I’m writing an application that does bill presentation and payment collection. At a very high level here are the major components of that application:

  • User authentication  – we only want the right people seeing the right bill
  • Account information retrieval — Get the amount they owe (might be itemizted), past balances, payments made, etc.
  • Present the statement — Lay the information out in a human readable format that makes intuitive sense.
  • Funds collection — Take tender information from the user (credit card, checking account, PayPal, etc) and present it to a payment gateway.
  • Payment validation — was the payment successfully processed
  • Application of funds to the statement.
  • Present updated status to the customer

Right off the bat if I were writing this application I see several modules that I could right (and would be useful to me later when writing other applicaitons).  I’ll name them below in “Perl-ese.”

  • MyApp::Authenticate — where MyApp is the name of my application, handle logins, logouts, logging of sessions, session creation.
  • MyApp::Session — Session tracking, creation, tear down (Used by MyApp::Authenticate)
  • MyApp::Logging — Used by all modules to provide a logging interface for PCI compliance.
  • MyApp::UI::Display — dynamic HTML page creation
  • MyApp::PaymentGatway — Handles communication with the various payment aggregators such as PayPal, Visa, Amex, Master Card, etc etc.   Each payment method may have a separate sub-module (eg. MyApp::PaymentGateway::PayPal)
  • MyApp::DB — Handles and tracks connections to the database where bill information is stored and possible user authentication store.
  • MyApp::DB::SQL — encapsulation of SQL queries for the application
  • MyApp::Util — anything that doesn’t fit.

The main part of the application would use each of these modules and sub-modules as appropriate to during the phases of the application outlined above.  For instance when I user first interacts with our application:

Notice this makes your code a lot more readable as well.  Years later and you have to either modify the code or figure out where something is breaking it is easier to to remember what you did and why.

Problem solving in a program language is no different that problem solving in any other context.  Break the bigger problem into smaller pieces and eat that elephant one bite at a time.

6590

Modularity in Perl — Reasons Why & Best Practice



modularity_01In my honest opinion one of the greatest strengths of Perl is the ability to organize code in distinct modular units. Heck this is also true of other languages but in my honest opinion nobody does it as well as Perl.

That said a lot of programmers fail to take advantage of that in my belief because they do not understand the fundamentals of making their code modular.

OK so what are the right ways and what are the wrong ways of implementing modular code.  In this post I am going to walk you through all that with a real life example of a modular design of a web application.

Continue reading →

Basic Troubleshooting 101 In a Corporate World.



computer-doctor
Over on Perl Monks I see lots of folks posting questions about why their code doesn’t work.  Sometimes the reason the code doesn’t work is due to a misunderstanding of how Perl itself works (regexes and such can be tricky) or a missing piece of syntax or whatever.

A good deal of the time I realize that the person asking the question probably could have found the answer themselves if they had followed basic troubleshooting techniques.  What I’ve discovered over the years is the the hallowed halls of education (Universities and such) do not teach basic troubleshooting skills as evidenced by people I’ve worked with that are recent college graduates.

Granted, experience is a good teacher but a lot of pain and suffering can be avoided if basic troubleshooting techniques are used.  In this article I am going to attempt to illustrate basic troubleshooting and how it applies to Perl.

My “university” was the US Navy.  The Navy taught all of their technical people good troubleshooting skills.  When you are aboard a ship it is rather difficult to call out to the company that built this whiz bang high tech radar system that enables your ship to navigate through fog without bumping into things. The Electronics Technician has to think for themselves and find the problem and fix it sometimes with “The Brass” breathing down their neck wanting to know what is taking so long.
ICO
The theory of troubleshooting we were taught can be applied to hardware, software, people, dogs, horses .. eh.. you get the idea.  That theory was called “The ICO Concept” where ICO stands for Input, Coversion, Output.  The theory holds that any system no matter how complex can be broken down into an input, some conversion and an output.  Each system has one or more inputs.  Some conversion takes place and one or more outputs comes out of that system.  First you check your inputs and make sure they are there and are proper.  For instance if one of your inputs to the radar is 110VAC and the breaker is off, you solution is obvious.  Let’s push on and to illustrate the technique and make it applicable to Perl I’ll take a hypothetical situation:

Continue reading →

Why I still use Perl



In the year 1989 or so I was cruising around USENET looking for stuff to download from comp.unix.sources (I think it was) and noticed these uuencoded SHAR files for something called Perl.  I downloaded them to my Sparc I workstation and when I looked at the documentation it was love at first site.

You see, I was in the middle of writing a script to automate my backups.  I needed to generate lists of files mapped to a media along with dates.  I had some of it written and had stuff that had awk piping to sed piping to sort piping back to awk… well you get the idea. So one of the first things I played with was a utility that came with Perl called “a2p” which converted an awk script to Perl. After I saw how Perl did the same sort of thing awk did I stopped writing awk scripts.

One thing led to another and I found myself no longer writing shell scripts but doing everything in Perl.

Perl was not as well developed as it is today. Perl is much more “grown up” than it was in the eighties and now features Object Oriented programming and a well established user community including a peer reviewed entity called “Perl Monks.”

Extending the functionality of Perl is very easy these days and there exists an extensive collection of Perl modules that can be “bolted on” and are free for the taking at CPAN.

So why do I still use Perl?

First off it has become my second language. When I’m asked to or discover the need for a script my first instinct is to open an Emacs editor window and type “#!/usr/bin/perl -w” followed by “use strict;” It’s a no-brainer for me.

There are things I need to do that Perl just provides me the best way of doing such.

I’ve written applications in C, C++, Rocky Mountain Basic, Java, JavaScript, Assembler, FORTRAN and even way back in the day COBOL. Then there’s Perl. I’ve written scripts in TCL/TK, Bash, KSH and Perl.

In the world of writing scripts Perl just stands way out in front in terms of doing text manipulation, pattern matching and automation in general. Unix (and Linux) system calls are available right from the scripting language which is a huge plus. Shell commands like sed, awk, grep, tr and others are built right into the language.

When I write a Perl script I have a reasonable good expectation that it will run the same everywhere. Perl comes by default with many flavors of Unix and Linux.

When it comes to writing applications I seem to be able to go from idea to finished application much quicker than I’ve seen with other languages when I write them in Perl. Not to mention the fact that I don’t have to compile source to run it since it is interpreted.

There certainly are areas where I feel Perl falls down on the job. Performance issues can happen when dozens of users try to use a web application written in Perl if they are not written properly. However that can be true of any language.

I’ll probably use Perl for the foreseeable future for most stuff that I do. I have been know to write web applications in Java using JSF and Hibernate but still for most stuff I write in Perl.

Welcome to Blue Cowdawg’s Perl Blog



This is a rebirth

My old blogsphere came apart at the seems and for whatever reason my VPS provider could not seem to be able to put it back together again. Well, I wanted to ditch that VPS anyway so here’s a new one.

This blog site is all about sharing information with others that I’ve gleaned over the many years that I have written code in Perl. Besides my blog, I’d also suggest you visit Perl Monks which is a peer reviewed site for posting questions and answers about Perl. I spend a lot of time there myself.

This site is going to be a work in progress forever. I’ll be adding to it as my whim takes me.