PerlSchool

| No Comments | No TrackBacks

I first used Perl in 2002 - about 10 years ago.  Over the years, I have continued to dabble in it but often felt that stuff like Mason and mod_perl were a little beyond what I needed to achieve.  So I stuck with a Perl/CGI format when writing web pages.  A recent post persuaded me to move forward from there - that is a work in progress.

So, after 10 years, why go to Modern Perl for Non-Perl Programmers held by Dave Cross @ Perl School

(I  will confess I was a little concerned I'd be taking a place that could be used by someone else but I am glad I went.)

Dave started with a walk through the basics of Perl, sigils, arrays, hashes and lists.  Most of this I had encountered before, but, back when I just started Perl, I got confused between the use of (), [] and {} and what a list actually was.  As a result, I ended up with some fairly interesting results trying to define hashes, arrays and access the elements and key value pairs within.

I came from a C programming background; web and mail server work so I was used to strongly typed languages.  With some languages you can have really mad hard typing; you can declare two integers on two separate lines and then get the compiler to consider them of different types - even though they are both integers.  Before that I'd been in engineering software, FORTRAN mostly but some C and even BBC Basic.

So Perl is a loosely typed language, identifying variables more by some form of structure than by type.  Fine.  Having Perl categorised as a loosely typed language really helped me feel Perl was a little more solid.

Solid is useful.

Then we got onto arrays and hashes, neither of which I had misunderstood, although, back in 2002 it was the first time I had encountered associative arrays - but I'm glad the Perl community has decided to call them hashes. 

Not least, because hash is a lot easier and quicker to type than associative array.  4 chars as opposed to 16.  (Another Perl habit - less typing == good.)

So .. hashes and arrays.  Originally, I had a hard time remembering where to use the (), [], and {} with hashes and arrays.  One part, accessing an array element or a hash key value pair was easy - $arr[$index] for arrays and $hash{key} for hashes.

The next part, defining hashes and arrays wasn't so easy and in my early years I used to use () to define an array and {} to define a hash.  Then I would have problems accessing hash key value pairs and never quite understood why.

Today

#!/usr/bin/env perl

use Modern::Perl 2011;
use autodie;

my %hash = { fred => 'wilma',
          barney => 'george'
          }; 
say %hash;
say $hash->{barney};
gives these errors

Global symbol "$hash" requires explicit package name at ./test.pl line 11.
Execution of ./test.pl aborted due to compilation errors.
Which helps a lot.  As a beginner I rarely understood my mistake.

Changing
 
say $hash->{barney};
to
say $hash{barney};
today gives

Reference found where even-sized list expected at ./test.pl line 6.
Use of uninitialized value $hash{"HASH(0x111d998)"} in say at ./test.pl line 10.
HASH(0x111d998)
Use of uninitialized value in say at ./test.pl line 11.
which is an improvement (of sorts!) in that the program doesn't completely die - it just declares a warning about $hash{..}.

There are two solutions to this error - declaring a hash ref or properly declaring a hash.

I tended to use the former

my $hash = { fred => 'wilma',
          barney => 'george'
          }; 
and then of course $hash->{barney} would work.  And the dereferencing of hashes of hashes got to be fun. 

I finally drummed it into myself, via copious re-readings to the Camel book, that hashes could be defined via %hash = (...); but it took some time to drum that in. 

As a consequence, I felt I didn't quite hook into the language.

The bit that made my day at Perl School is really, really quite simple.

Both array and hash definitions are list assignments. 

So simple, and so clear.  And worth it; really worth it. 

I felt like I had finally landed on Planet Perl. 
(Probably a bit of an exaggeration but on solid ground at last!)


dlocate

| No Comments | No TrackBacks
I've been using rkhunter and tripwire in a Debian install.

rkhunter is designed to check for rootkits and tripwire reports changes in files.  Both are useful and configurable.

The other part of this equation is checking what is reported as changed was meant to be changed. I needed to be able to review files and verify what package they belong to and I found dlocate.

dpkg -S does a similar job.

Finding the package name means I can at least compare the reported change against the package in /var/cache/apr/archive.


The bug #576680 refers to rkhunter v1.3.6

I'm running rkhunter v1.3.8 on Debian wheezy and found that 

 RTKT_FILE_WHITELIST="/etc/init.d/hdparm:hdparm /etc/init.d/.depend.boot:hdparm"

sufficed to remove the Xzibit Rootkit warning about the hdparm string in /etc/init.d/hdparm and /etc/init.d/.depend.boot on a --check 

I got the hint from Machine Cycle and the /etc/rkhunter.conf file : 

#
# The following two options can be used to whitelist files and directories
# that would normally be flagged with a warning during the various rootkit
# and malware checks. If the file or directory name contains a space, then
# the percent character ('%') must be used instead. Only existing files and
# directories can be specified, and these must be full pathnames not links.
#
# Additionally, the RTKT_FILE_WHITELIST option may include a string after the
# file name (separated by a colon). This will then only whitelist that string
# in that file (as part of the malware checks). For example:
#
#     RTKT_FILE_WHITELIST="/etc/rc.local:hdparm"

Sadly, the domain name of agilecookbook.com no longer holds the agilecookbook.

The registration changed hands in july this year.

Does anyone knows where the book went ?. ....


The git community book

| No Comments | No TrackBacks
is available for free download here
No reason not to grok git anymore :)

I really like the typesetting 

Free stats book

| No Comments | No TrackBacks
Just found a free stats book
Can't vouch for the accuracy - yet - but reads well.

A timely and pertinent post on geekfeminism.org about the perennial T-shirt problem for most women.  


I’ll be attending a workshop soon.  There were rumours of a free t-shirt but the women’s sizes stop at 38 inch so that puts me out of the running for one of those.  My choice is therefore limited to the men’s selection - which at least has more colours.  

You can compare the paucity of women’s designs available via spreadshirt.net against the range in sizes and shapes available at Company Casuals

I’m sure most so-awkwardly-non-spreadshirt-sized tech women attending such conferences and workshops find the restricted subset offered disappointing if not down-right annoying.  

<irony>
Of course, it’s ultimately my fault I’m not the right size and shape for the female T-shirts offered.  

And I’m being a bit rude to complain, I should instead be considerate of the effort the conference organizers have made in ensuring promotional T-shirts to be made available at all.
</irony>

It would just be really, really be nice if there was one that fitted and was the right length for me but I have to decide the T-shirt problem doesn’t defeat the workshop content or not go over a T-shirt.

I am interested in the workshop content although it might be nice to be able to reflect that interest with a nice fitting good looking promotional T-shirt.  Handy when out and about perhaps even trying to promote the language.

I’m also not presenting nor helping out this year so I am not bound by any circumstance to wear the workshop’s promotional gear.

There are probably more than a few out there who have a problem of some degree or other with this entry. There are those who don’t understand the problem so I’d like to ask them the question -

  When did the size or shape of any part of your anatomy last become an issue in your public and professional domain?


Zen and the Art of Perl

| No Comments | No TrackBacks

On the oppositeness of pop, push, shift and unshift with Perl


I had reason to use
perl -f unshift

unshift ARRAY,LIST 
     Does the opposite of a "shift". Or the opposite of a "push", depending on how you look
     at it. Prepends list to the front of the array, and returns the new number of elements in
     the array. 
         unshift(@ARGV, '-e') unless $ARGV[0] =~ /^-/; 
     Note the LIST is prepended whole, not one element at a time, so the prepended
     elements stay in the same order. Use "reverse" to do the reverse.
The second sentence piqued my curiosity enough to check the differences between shift, unshift, push and pop. After all, surely an unshift operation was the same as a push operation?

I already knew that shift pops off the front of the array and I learned unshift pushes onto the front of the array.  The opposite-ness is clear.  

I was familiar with the concept of pop and push w.r.t stack operations, pop something on to the stack and pop it off ... anyone remember the postfix (reverse Polish) notation exercises in their CS A-Level?

In Perl, pop pops off the end of the array and push pushes onto the end of the array.  And that provides a different kind of oppositeness to unshift/shift operations.  

I misinterpreted the second sentence on the basis of previously stored information.

The use of pop/push and shift/unshift in other languages is quite common.  It's not just a Perl thing.  

Debian Women Mentoring Scheme

| No Comments | No TrackBacks
The Debian Women mentoring scheme is up and running again. More information can be found on the Debian Women's mentoring page. If you have always wanted to get involved in the Debian project - take a look at that page and send in an email. It's now as simple as that.

If the SCT system isn't good enough for people at the British Medical Journal then it isn't good enough for me.

If you want to opt out you can download the form, print out the third page and send it in to your GP surgery.

Curious to note the NHS is running a presumed opt-in policy with the SCR.

There's been advice against running under such a presumption - e.g. for mailing lists - leaving clients, customers or site visitors with the choice to opt-in rather than assuming they'll opt-in and making it difficult to opt-out. I think that is an aspect of systems engineering and design - usable, friendly and inviting to humans rather than being monolithic and stone-deaf to all complaints and queries.

You might want to check if you are in the pilot project for the SCR and, if you don't need your medical details to be online then opt-out. There are security concerns within the NHS.