Sam's Blog entries for category 'tutorial' Subscribe to feed for category 'tutorial'

Bash-itunes plugin tutorial

Date: Friday, 15 June 2012, 11:03.

Categories: bash-itunes, itunes, cli, bash, shell-scripting, apple-script, tutorial.

In v1.2.0 of bash-itunes, my project to control iTunes from the command-line, I've added plugin support for sub-commands.

This allows you, or anyone else, to add new commands to the basic script without needing to alter the script itself.

Read below the cut for details and a walkthrough of creating a new plugin.

In the comments to a previous article, I mentioned that I use Module::Starter when starting a new distribution.

I actually use a custom profile along with the very handy Test::XT to produce robust release tests that won't break when people are just trying to install with the minimum fuss.

I thought it might be useful for other people if I wrote a quick tutorial on how to achieve the same results themselves.

Readable Regexps: Why you should use /x

Date: Wednesday, 2 June 2010, 09:53.

Categories: perl, ironman, regexp, craft, basic, tutorial.

Regexps are one of Perl's strongest features, but they're also one of the causes of Perl's greatest criticism: that it looks like line noise.

If you've ever had to examine someone else's regexp, or worse debug one, you'll probably agree that there's some merit in that criticism.

It doesn't have to be that way however, there's some simple steps you can take to make your regexps more readable and more maintainable, and this week we look at one of them: the /x modifier.

Did you mean +, not *, in that regexp?

Date: Wednesday, 28 April 2010, 13:36.

Categories: perl, ironman, regexp, craft, basic, tutorial.

Continuing from my previous article "Anchoring Regexps", another common regexp mistake I see is use of * where the author really meant +.

So today I cover + and *: what's the difference and why does it matter?

Anchoring Regexps

Date: Thursday, 22 April 2010, 15:14.

Categories: perl, ironman, regexp, craft, optimization, basic, tutorial.

A common mistake I find whenever I look at someone else's regexps, is a failure to anchor the regexp.

This is often, in my experience, the single biggest thing you can do to improve the performance of a regexp: it's one of those things you should learn to do in every regexp where applicable, which should be almost every regexp unless you're specifically looking for "something somewhere in the middle but I don't know where".

So, what is anchoring, and why does it have such a big impact?

Last week, in "Monkey-patching Benchmark.pm to auto-correct custom controls", we covered how to monkey-patch Benchmark.pm into giving us the results we wanted, and saw that one alternative method was to wrap the module instead.

This week, we investigate how to do this, and see what unpleasant surprises lie in wait when wrapping a procedural module.

In "Advanced Benchmark Analysis I: Yet more white-space trimming", I mentioned that you could automatically take into account the cost of your control benchmark and eliminate it from the rest of your results.

This blog entry shows you how to monkey-patch Benchmark.pm to let you do just that.

In my previous blog entry, "Advanced Benchmark Analysis I: Yet more white-space trimming", I left you with the thought that our benchmarks changed with changing input.

This article shows you how to analyze those changes and how to draw conclusions from them.

Seems my previous blog, "Some simple "white-space trim" benchmarks" caught people's attention, and I've received some interesting suggestions and observations worthy of a followup article, this also gives me the chance to delve into explaining more advanced benchmark analysis.

So, deep breath, here goes.

Some simple "white-space trim" benchmarks

Date: Wednesday, 3 March 2010, 15:38.

Categories: perl, ironman, benchmarking, trim, regexp, optimization, basic, tutorial.

Laufeyjarson asked on Monday, about stripping whitespace from both ends of a string. The comments contains lots of suggestions, but no hard figures, so I thought I'd reproduce them here along with the code used to generate the benchmarks - it provides a simple example of how to write a quick and reliable benchmark.

Browse Sam's Blog Subscribe to Sam's Blog

By year: 2010, 2011, 2012, 2013.

Or by: category or series.

© 2009-2013 Sam Graham, unless otherwise noted. All rights reserved.