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

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.

use warnings; use strict; use Data::Dumper; my @list = ( 1, 2, 2, 3, 4, 4, 4, 5 ); my %number_hash;; foreach my $number (@list) { $number_hash{$number} = 1; } my @unique_value_list = keys(%number_hash); print Dumper(\@unique_value_list);
If you run the code above you should get similar output to:

$VAR1 = [ '4', '1', '3', '2', '5' ];
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.

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.

Testing with sqlite

It can be daunting to start thinking about how you are going to test
database interaction for your app. Especially if you have never tested
database interaction. I have received several suggestions as to which
modules to use, however I have found the best success with just
creating a small sqlite db in memory,filling it with test data and
passing the db handle.

For example:

my $dbh = DBI->connect("dbi:SQLite:dbname=:memory:","","") or die DBI::errstr;

Then you can just start inserting your test case data and then set up the tests to pass or fail accordingly.

That's not to say that that I think this is the best way to go about
things. It's just that the database testing I have needed to do so far
hasn't been complex enough for me to have to go and find a more
dynamic way to perform the tests.

Now I have run into situations at thewhere sqlite doesn't fit the
bill. This usually entails when database specific functions are
used. For example, if the Oracle "TO_DATE" function is passed to a sqlite database, then it's going to fail.

So sure, sqlite testing is great in most cases, however if you have a
database team who writes your queries for you, or you tend to want to
do a lot of database specific operations I would suggest testing with
the same database you are using in production.

Working with DateTime.pm

Lately I have been using the DateTime module for handling dates. While it cuts down on some of the laborious aspects of dealing with time intervals and date formatting there are some methods that can be confusing.


1) delta always returns positive. I have been advised to use delta to get the differences between days, however it always returns a positive number. I imagine there is a good reason for this and it would be great if someone could tell me why it is useful when you have alternatives such as subtract().


2) now() always comes back in UTC Unless you read the docs it is easy to assume that you are going to get now() in your own time zone.


Given that daylight savings time observed in different ways in different countries, converting time-zones is confusing. The correct way to subtract dates with datetime according to the docs: Always do your date math in UTC. Then you can convert the dates to whatever timezone is appropriate when its time to display the results.


It looks to me like DateTime makes time manipulation simple enough without glossing over important details. Given it is tricky when the default is utc but one can easily come to an understanding of the module's behavior if they test appropriately.

For Docs Go to the CPAN

Lazy Lists in Perl 6

Today I have been learning about laziness in perl6. Most specifically, I have been playing with gather { take }. You can find an excellent explanation in this Blog. Anyway. The example in the blog applies the x * (x + 1) as the function to be applied to the input list. I have played around putting in different functions and plugging in values. Eventually I came up with a script to spit out tax based on user input.

use v6;

my @tax_table = gather {
     for 1..1000 {
          take $_ * .0825;
      }
}

my $amount = prompt("How much are you paying? ");

say "Tax Due is @tax_table[$amount]";

Everyone remotely interested in Perl 6 should go to the Perl 5 to 6 blog. So far it is the most useful Perl 6 resource I've seen.

One-liner: Finding files that include a match

These ARE the files you're looking for

Today I am going to share a one-liner I use often to find file names.
Say for example you would like to print all files in the current directory that include the word Fred. You could use this one-liner:

perl -wnl -e '/Fred/ and print $ARGV and close ARGV' *

w is for warnings
n is for looping
l is for line end processing

The "and close ARGV" part at the end is to save time and keep you from double-printing file names. If 'Fred' pops up 50 times in a file, and you don't add the "and close ARGV" then the file name will show up 50 times in standard out. Another benefit of this is that since you are closing the file after you find 'Fred' the first time, you will no longer continue to process the file and thus you are saving time.

Finding all matching lines

Another way I use this one liner is to find examples from config files. For example, say I have a directory full of configuration files and I want to see how many of them use the same option:

perl -wnl -e '/^option_name/ and print "$_\n"' /path/to/configs/*

This one-liner instead prints every match to standard out. We got rid of the and close ARGV this time, because we really don't need it. If we are matching the entire config option, it should only show up once in the file. Otherwise say we are trying to match multiple similar config options (e.g. option_name_1 option_name_2). In that case we would want to print out each match "and close ARGV" would only allow us to print the first one.

I hope this helps you the next time you need to glean information from a large number of files.