Thursday, February 23, 2012

How much milage do you get with SQL::Abstract?


I have been hearing a lot about SQL::Abstract. So I started trying to
put some queries together with it. It is quite interesting but leaves
me unsure about whether or not it's right for me.

The module takes data structures and returns the query statement and
the bind values that need to be passed to a DBI handle. I like this
because it allows me to just worry about the data I need to make the
query without having to worry about the sql syntax.

On the other hand is writing sql hard enough to justify this kind of
abstraction? One thing that I see happening is that if I am writing
more complex queries, I would probably just go to my database client
and start typing out queries to get what I want. Plus, at least in the
beginning I would probably be translating from raw sql to SQL::Abstract
in my head.

I guess it's kind of nifty that SQL::Abstract keeps me from having to type
so much in order to interact with the database. Does anyone use
SQL::Abstract and (love|hate) it? I'd love to hear other people's
experience with this module

Saturday, February 4, 2012

Hash de-duplication in Perl


If I were to ask you to take a list of values and remove duplicates, how would you do it? The most obvious way would be to compare every value to every other value and removing anything equivalent. However this is probably the most inefficient way as well.

Thankfully, a hash data structure has some properties that helps us with this kind of task. Due to the fact that hash keys cannot be duplicated we can just load every value as a hash key with a value. I usually choose 1.


If you run the code above you should get similar output to:


As you can see, all duplicates have been removed.

Every time you insert an item from the array as the hash key it's going to assign a "1" to that value. So once a duplicate comes along it will just write another "1" into the same hash key. Happy de-duplicating.

Thursday, February 2, 2012

TIMTOWTDI doesn't mean anything goes


Perl is a language that provides a lot of freedom. The philosophy of
"There's more than one way to do it", allows coders to be as
expressive and creative as they want to be. Unfortunately this
provides the impression that one has license to eschew best
practices.

Nothing could be further from the truth. As they say, with freedom
comes great responsibility. Sure, when you are writing one liners or
scrap code who cares, but when you are writing something serious
please make it easy to read.

I have seen too many nested ternary operators within nested maps to
forget the pain that unclear code can be to manage. What's more is I
can't understand why someone would do things like this. Yes, by some
miracle the code worked but could the original author make any sense
of it? Did they care?

Then there are the indestructible spaghetti blobs. These happen when
somebody doesn't feel like segmenting their code into reusable chunks.
So you end up having to make 5-10 small changes spread out amongst
1000 lines in order to work on the same feature.

Whoever writes this kind of code in a group setting is being
inconsiderate to any future maintainer. And if the only maintainer is
the author then they are still only hurting themselves. Sure, there may
be more than one way to do it, but please make it a manageable one.