Programming

Dutch Perl Workshop 2018

The Dutch Perl Workshop is an chance for Perl developers in the Netherlands to get together, meet old acquaintances, make new friends in the community and share some of the cool things we have learned and developed in the language. This year was lovely, despite the very high (for the Netherlands) temperatures. We were treated to presentations on everything from Perl on embedded devices to the inner workings of the Hash mechanism in Perl6 to suggestions for streamlining how Perl performs in extremely high traffic situations. Great stuff.

We also got a moving talk from Elizabeth Mattijsen on her experiences with Perl and the community around it and suggestions on how to grow into the future. Liz has been a driving force in Perl development and advocacy and is now spending much of her time working on Perl6 functions. Her talk was about the current “rift” between Perl 5 and Perl 6 and how to think about this division going forward. Great stuff all around!

 

After the talks and lightning talks and final thanks for the sponsors (Booking.com, cPanel, and Perl6.org) it was time for Barbeque, refreshing beverages, conversation and games. Wendy brought a whole bunch of board games and Mark Overmeer asked me to bring a game I recently created, “Merchants and Pirates”. I made this game for friends and family and it was a hoot to share it with my Perl friends!

Alas, all good things….  So, I caught a ride to the train station (thanks John van Krieken!) and it was back to Breda. Slightly soused and looking forward to the next time I can get together with this awesome group of people!

 

Presentation: Template::Toolkit as a cheap API

I’m just going to copy and paste my slides from this Lightning Talk delivered at the 2016 Dutch Perl Workshop. Lightning talks have a maximum of 5 minutes, and I wanted to do something light and fun. These talks are usually at the end of the day and having something that I could deliver with some energy and humor really helped.
The point of this presentation is that Perl allows you to do things that just work, even if you are ‘cheating’ to make it work. In this instance, I turned a template rendering system into an API interface to reuse some methods from a different script. This is not stable or good practice, a point I emphasized, but it WAS clever and I thought sharing it would be fun.

 

 

 

 

 

Template::Toolkit

The Cheap API

Richard Still

https://oakbox.com

Situation:

Mature” application – a rat’s nest of legacy code written by a deranged madman**

Using Template::Toolkit

No TIME

Need some of those functions in another application (script or JS)

3 years ago **

Using Template::Toolkit, you are already putting everything into a single data structure before sending it to be rendered:

$templater->process($template, $TTvars, \$output, binmode=>’:utf8′)

or $self->Probe(\@include_path, $templater->error);

Instead of sending to TT, redirect the output to JSON

if( $sending_to_api ){

use CGI;

my $q = new CGI;

use JSON;

my $utf8_encoded_json_text = encode_json $TTvars;

print $q->header(‘application/json’);

print $utf8_encoded_json_text;

exit;

}

 

Re-Use for free!

1) “Yes, I know that refactoring the original code into modules is more stable and would yield better code.”

2) “Yes, I know that ‘No Time’ is not a good excuse.”

3) “Yes, other formats for export are available, JSON just gives me the option of using this content in an AJAX interface.”

Experienced Software Developer

Sometimes a company changes direction, sometimes you work yourself out of a job, sometimes you leave a job for reasons totally unrelated to the job, but no matter what the cause, it’s a hard reality that sometimes, you have to look for a new job.

How do I present myself in this market? I regularly sit down with clients and talk about their wants and needs. I participate in planning meetings. I do technical support when something goes wrong. I became a subject matter expert in something I knew nothing about (psychometric testing) to understand the best way to help other people do their jobs better. I taught myself statistics, reviewed legal regulations from different countries, created educational videos, translated complex concepts into working code and translated hundreds of pages of text into English from Dutch. I acted as the first contact for English-speaking customers, did trainings, wrote ads . . . how do I write a resume that doesn’t read like “War and Peace”? Which job title covers all of that?

In my heart, I think of myself as a Software Architect, solving problems both for my company and for our clients. I’m a wizard creating magic black boxes that just work and do what you expect them to do, quickly and reliably, on all platforms, without a lot of fuss. All of the other stuff I do is, to my mind, just supporting my coding addiction. “Software Architect” doesn’t cover all of those other things and “Coding Junky” just seems like a bad title to put on my resume.

After working on a product for 14 years, thinking about it, tinkering with it, sweating bullets over it and cheering it on, I am starting to look around and see what the job market is like. The biggest thing on my resume is the language I program in, Perl. I love Perl, I love the community, I love the flexibility and the fact that every year there are new tools being added to my set of possible solutions. But Perl is not the language du jour, it might still be the duct tape of the internet, but when was the last time you thought duct tape was interesting or exciting?

The problem is that job listings mention specific technologies and buzz words while I have been focusing on solving problems as efficiently as possible. At various times in the last 14 years, I’ve:

  • written a ton of Javascript
  • hacked PHP code
  • tinkered with NodeJS
  • played around with statistical libraries
  • submitted bug reports and pushed the development of some core Perl modules
  • used three different bug tracking platforms and 2 different version control systems
  • taught myself to make whiteboard videos
  • taught myself audio editing
  • written marketing text
  • learned about SEO
  • learned enough SOAP and XML to be dangerous
  • wrestled with PDF generation
  • agonized over gettext translations

… and so many other things that I have, frankly, blocked them out. But “Really Good Problem Solver” doesn’t bring up any hits on job search sites, either. I will continue to try various titles and industries in these searches, I will just have to hope that my definition of “Experienced Software Developer” means the same thing to me that it does to a hiring manager.