sub num_month {
  my $date = shift;
    
  my %months  = (JAN => '01', FEB => '02', MAR => '03', 
                APR => '04', MAY=> '05', JUN => '06', 
                JUL => '07', AUG => '08', SEP => '09', 
                OCT => '10', NOV => '11', DEC => '12');
                
  my @tokens = split (" ", $date);
  my $date;
  foreach my $num (@tokens) {
     my $strBegin = substr($num, 0, 3);
     my $date =~ s/$strBegin/$months{uc $strBegin}/;  
  }
  return $date;
}

my $element = {
          'check' => {
                     'field' => 'OLK_BO_BK_TYPE'
                   },
          'type' => 'case',
          'case' => [
                    {
                      'value' => '1',
                      'resultset' => 'BROKER'
                    },
                    {
                      'value' => '3',
                      'resultset' => {
                                      'field' => 'OLK_BO_BK_DESC'
                                     },
                    },
                  ]
        };

my $element = {
          'check' = 'OLK_BO_BK_TYPE',
          'type' => 'case',
          'case' => [
                    {
                      'value' => '1',
                      'resultset' => 'BROKER'
                    },
                    {
                      'value' => '3',
                      'resultset' => 'OLK_BO_BK_DESC'
                    },
                  ]
        };        

hash_walk($element);

sub hash_walk
{
  my $element = shift;
           
  if(ref($element) =~ /HASH/ )
  {    
      foreach my $key (keys %$element)
      {
          if ($key =~ /field/)
          { 
             # do something here? 
             print "found $$element{$key}\n";
          }   
          hash_walk($$element{$key});
      }
  }
  elsif (ref($element) =~ /ARRAY/)
  {
      foreach my $index (@$element)
      {
        hash_walk($index);
      }
  }  
}

Why does Perl 5.8.8 complain "no" not allowed in expression in this program:

use strict; use warnings;
grep { no strict 'refs'; }qw(x);

use strict; use warnings;
grep { 0; no strict 'refs'; }qw(x);

        open(MAIL, "|mail $EMAIL");
        print MAIL "To: $EMAIL\n";
        print MAIL "From: $FROM\n";
        print MAIL "Subject: $MAILSUB\n";
        print MAIL "Content-Type: text/plain; charset=\"iso-8859-1\"";

        open(MESSAGE, "<", "$TMPFILE") or die "$!";
        print MAIL <MESSAGE>;
        close MESSAGE;
        close MAIL;

Name - John
filename "LKTA_mic4.cfg"; }
Name - Tim
filename "LKTA_mic2.cfg"; }
Name - Jane
filename "LKTA_mic1.cfg"; }
Name - Jim
filename "LKTA_mic3.cfg"; }
Name - Don
filename "LKTA_mic1.cfg"; }
Name - Cody
filename "LKTA_mic4.cfg"; }

Name - John
filename "LKTA_mic1.cfg"; }
Name - Tim
filename "LKTA_mic2.cfg"; }
Name - Jane
filename "LKTA_mic3.cfg"; }
Name - Jim
filename "LKTA_mic4.cfg"; }
Name - Don
filename "LKTA_mic1.cfg"; }
Name - Cody
filename "LKTA_mic2.cfg"; }

#get data from DB
my $sth = $dbh->prepare("SELECT * FROM publications") or error($cgi, "
+Error #1");
$sth->execute( ) or error($cgi, "Error #2: ".  $dbh->errstr(  ));


#loop through data
while (my $data = $sth->fetchrow_hashref) {

#pull out only the first 15 words from the pubText field 
#this is where I need suggestions, the code below does not work
while ($count < 15){
@copy = split " ", $data->{pubText};
$count ++
}

#print resulting data
print qq{
                  <td width="195" align="left" valign="top"><div class
+="newsBox"><span class="newsTitle">$data->{pubTitle}</span><br />
                      @copy
                      <a href="http://linkToFullArticle.html">More...<
+/a>
                  </div></td>
};
}

The Send-a-Newbie project is the Perl community at its best. People with a bit of spare money have donated to a fund to send people to [http://yapceurope2009.org/|YAPC::Europe. Edmund von der Burg and a team of trusted helpers have counted the money and closely examined the applications that they received. Edmund writes:

First, a quick recap: the Send-a-Newbie program is meant to help people go to YAPC who have never been to a YAPC before, are unable to do so by their own means and already involved in some way in the Perl community.

Applications were submitted, questions were asked, answers were given, difficult choices made and we now have our lucky YAPC Newbies.

We're delighted to announce that we will be sending the following three to YAPC in Lisbon:

Alan: Based in India, started using Perl about a year and a half ago. Since then, he's contributed to several CPAN modules, released WWW::Rapidshare::Free and is currently working on the TPF grant "Fixing Bugs in the Archive::Zip Perl Module". He's never been to any meetings of the Perl community.

Alistair: Based in Scotland, has just finished university, started using Perl for creating his websites and performing several small tasks. When choosing a placement (for his degree) he chose a Perl shop in London, and became part of London.pm

Rosellyne: Based in England, self-funded university student. Also a grant manager for TPF (past four years), member of London.pm and active on PerlMonks. Keen to meet people she's worked with for years.

There were other great applications that we will not be able to send. Hopefully they'll be able to attend a future YAPC.

All of this is possible due to the lovely people who have donated and helped. It's been a great demonstration of the community that has formed around Perl. Thanks also to the YAPC::EU organizers who have been supportive of this project right from the start.

Thank you to all involved and see you all at YAPC::EU::2009!

The three lucky participants will have their travel, hotel and conference fees paid. They'll have to pay for their own beer.

Note: This is republished from Perl Hacks.

When I first heard the term "best practice" at London Business School in 1999 I fell in love with the term. It seemed to epitomize everything I loved about good management: a desire to cull the best; thoughtful consideration of what works and what does not; a business's willingness to reinvent itself on an ever growing understanding.

The term "best practice" grew out of and was popularized via the corporate learning literature of the mid and late ninties. As organizations began applying techniques like TQM (total quality management) and Six Sigma throughout the 1980's and early 1990's it became increasingly clear that some work groups outperformed others - even in the same organizations. These sub-divisions were said to have "best practices" and management experts began discussing how these well performing divisions could teach their methods for success to other parts of their company.

In the last 10 years the term "best practice" has lost much of its association with the process of learning. Instead best practice has become a buzz word that is increasingly associated with a laundry list of rules and procedures. Perhaps it is our innate need to measure ourselves against a standard. Or perhaps it is the word "best". There can only be one best, even if it takes a process to find it. Why reinvent the wheel once the best has been found?

Nowhere is this more clear than in the way many organizations and some monks seem to use Damian Conway's book on Perl best practices. The best practice in Damian Conway's book refers (or should refer) to the process that Damian Conway went through while developing his coding practice. He wrote this book in part because, over the years, his own coding style had come to resemble an archeological dig though his own coding history. Interview with Damian Conway, Brian d foy. However, few people talk about his process, whereas many preach (or complain about) his rule list.

It may be human nature to turn best practices into best rules, but it isn't good management:

1. Best practice by the rulebook oversimplifies the knowledge transfer process. Knowlege consists of several components: facts, recipes, thinking processes, information gathering skills, and methods of evaluation. Rules are only effective in transferring the first two of these. However, all the rest are essential. Without them rules get out of date or will be applied in counter productive ways.

Facts, recipes, and coding standards are like wheels and brakes. But they do not drive the car. If the driver doesn't know the difference between the brake and the accelerator, the car will crash no matter how wonderful the wheels. Hard to communicate skills like information gathering and methods of evaluation are what drive the coding car, not the rules capturing layout and syntax.

If we focus only on rules, it is natural to assume that knowledge will be transferred simply by giving people enough motivation to follow rules. But this doesn't turn out to be the case.

In 1996 (Strategic Management Journal), Gabriel Szulanski (The Wharton School) published a study analyzing the impediments to knowledge transfer. (see Exploring internal stickiness: Impediments to the transfer of best practice in the firm). He considered many factors that might get in the way. The study concluded that motivation was overshadowed by three other issues: "lack of absorptive capacity", "causal ambiguity", and "arduousness of the relationship".

If rules alone were enough none of these would matter. "Lack of absorptive capacity" means that the necessary background knowledge to understand and value the rule is missing. Causal ambiguity means insufficient knowledge of how the rules relate to outcomes. Put in plain English: we aren't very good at applying rules without reasons or context.

However, explaining rules also means transferring judgment - something that cannot be captured purely in the rules themselves. And this brings us to the last barrier to knowledge transfer: "arduousness of the relationship". This awkward term refers to how well the knowledge provider and receiver work together. Do they have a mentoring relationship that can answer questions and provide background information? Or are they simply conduits for authority, insisting on the value of the rules without helping show how the knowledge can be adapted to exceptional situations?

2. An overemphasis on rules is a short-term investment in a long-term illusion. Software is full of symbols and a great deal of code is boiler plate. It is easy to imagine that rules play a large role in software and the right set of rules will have a large payback.

This might be true if writing software were merely a transformation process. But if it were, we'd have developed software to automatically translate business processes, math books, and motion studies into software long ago. To be sure some of the coding today could probably be done by software, but not all of it. In every human endeavor there is a certain amount of boiler plate activity that passes for intellectual labour. This can be automated. But there is also a certain amount of genuine creativity and analysis. It takes a human being to know which is which. It takes a human being to do the later.

If we want superior development teams, we need to spend our energy nurturing what only we humans can do. This is where our investment needs to sit. As for the things we can do with rules: if we focus our skills on the creative portions we will figure out a way to write software that makes the boiler plate things go away. It is only a matter of time.

3. Rules that free us from thinking do not provide for change. Rules that free us from thinking are, by their very nature, static. In 1994 a management book "Built to Last" took the management world by storm and became a knock out best seller for several years thereafter. 10 years later, the magazine "Fast Company" wrote an article reviewing the impact of the book and the companies featured in that book. Was Build to Last Built to Last - in 2004 about half the companies described no longer would qualify as built to last. When interviewed for the article, one of the authors of the book, James C. Collins, argued that these companies had lost sight of what had made them great. He emphasized "Theeee most important part of the book is chapter four! ... Preserve the core! And! Stimulate progress! To be built to last, you have to be built for change!"

4. If it isn't abnormal it can't produce abnormal returns. The things that can be reduced to judgment-free rules offer no competitive advantage because they can be easily reproduced. No matter how hard we try we cannot build the best coding shop by following everybody else's rules. To excel, our practices need to be closely matched to our team's strengths and weaknesses.

Some of the more recent management literature has begun stressing the concept of "signature practices". Signature practices are practices that are unique to an organization. They capture its special ethos and talents and serve as a focal point around which the company (or coding team) can develop its competitive edge. (See, for example "Beyond Best Practice", by Linda Gratton and Sumatra Ghoshal, Sloan Management Review, April 15, 2005).

I don't mean to be knocking rules. They have their place. But if we want to have an outstanding development team, our definition of best practice needs to expand beyond rules. We need to think about what makes our teams thrive. What helps them be at their most creative? What gets them into flow? When are they best at sharing knowledge with each other? At understanding each others code? Incorporating new team members? At meeting customers' needs? And then we have to be prepared to be ruthless in getting rid of anything that gets in the way of that. Even if it is the rules themselves.

Best, beth

Update: Clarification of point #4, in response to mzedeler below.

How much Perl love you?

Write the perl command with your nic, and try!

perl -explorer

Disclaimer: I am NOT responsible of your nic! :)

Credits: netsoul

Imagine you need to integrate with an application that uses SOAP and the SOAP methods return things like available fields and their properties and lists of options etc. Something like this interface for posting job adverts on a site. So you need to fetch the data and display it in an easier to read format, with the option lists in whatever format your application requires, ...

This is what I just whipped up. Note especially how XML::Rules let me neatly extract just the data I need in the format that makes them easy to display.

Sorry I can't give you a working username and password so this is what the result looks like:

$x = '3336703366667337000033670003'
     ;$d=sub {chr unpack('N',pack (
     'B32',substr(('0'x32).((shift)
     * (shift)),-32) )) ;};print ${
     dx( $d, $x) }; sub dx{ while (
     $_[1]=~/(\d{6})(\d{1})/g){$out
     .= &{ $_[0]}($1 ,$2); }\$out;}