Consider the following fairly simple class, which creates a lookup object for month names:

Firstly, I'm not planning on breaking compatibility with Type::Params. The new API would live under a different namespace, such as Type::Params2.

The API for Type::Params is currently:

use feature 'state';
use Type::Params qw( compile compile_named_oo );
use Types::Standard -types;

sub function_with_positional_parameters {
  state $check = compile( ArrayRef, Int, Int );
  my ( $list, $start, $end ) = $check->( @_ );

  my @slice = @{$list}[ $start .. $end ];
  return \@slice;
}

sub function_with_na…

The lighting in my bedroom uses Philips Hue bulbs — specifically, the coloured ones. Last night, I decided it would be nice to set the three lights in my bedroom to cycle slowly through a set of warm colours using a script.

I didn't want harsh transitions from one colour to the next, but for the lighting to fade from one colour to the next in a smooth gradient. Also, I didn't want the three bulbs to all be the exact same colour, but wanted each bulb to be at different stage in the cycle, like they're "chasing" each other through the colours.

So I whipped up a quick script. It requires the command-line tool hueadm to be installed and set up before we start. You can run hueadm lights to get a list of available lights, and in particular, their ID numbers.

Today I released Zydeco::Lite, a re-implementation of Zydeco but just using standard Perl syntax. So for example, class { ... } becomes class(sub { ...});.

This has the advantage of much faster compile time, similar run time speed, fewer dependencies, and compatibility with older versions of Perl before the keyword API was introduced. Of course, in some circumstances these aren't important concerns, so the nicer syntax of the full Zydeco will be preferred.

Zydeco and Zydeco::Lite are both based on MooX::Press which itself is based on Moo, Type::Tiny, and other modules. I've taken the synopsis example from the Zydeco documentation and rewritten it using the different layers of abstraction.

So I like to keep local copies of my blogs.perl.org blog posts as Atom entries, but noticed yesterday that I had a few gaps in my collection. The Atom feeds offered by blogs.perl.org only have the most recent articles though, so I decided to write a quick script to scrape the posts. Luckily, I managed to get a table containing the URLs for each post I needed, so I didn't need to bother with following links to find the pages; I just needed to grab the content from them.

I thought some people might find the code interesting especially for its use of lazy attributes. This is one of those "it only needs to be used once, so making the code maintainable isn't important" kinds of projects, do bear that in mind. I've cleaned up the whitespace and added comments for this blog post, but other than that, it's just a quickly hacked together script.

Mom is a shortcut for creating Moo classes (and roles). It allows you to define a Moo class with the brevity of Class::Tiny. (In fact, Mom is even briefer.)

A simple example:

Technically, I already announced it, but now I've renamed it. MooX::Pression is now called Zydeco.

Moops had a memorable name, and I think the naming really helped it gain a following. MooX::Pression was just meh. So now it's Zydeco. Zydeco is a fun word and pretty short to type. It's a musical genre that blends jazz, blues, and Louisiana French Creole, and it just seemed like a good fit for a module that takes what I feel are some of the coolest features of Perl programming, and blen…

The test suite for MooX::Pression used to run in 79 seconds on my laptop. Now it's at 10 seconds.

And no, I didn't cut out any tests — I switched from using Keyword::Declare to a combination of Keyword::Simple and PPR. (Keyword::Declare is a wrapper around Keyword::Simple and PPR, but I found out by using them directly, I could massively improve compile-time speed.)

MooX::Pression allows you to build classes and roles with multimethods, types, method signatures, and sweet, sweet, sugary syntax…

Kind of like Moops but with less hacky parsing.

MooX::Press is a quick way of building a bunch of Moo roles and classes in one use statement.

The most basic example would be:

  package MyApp {
    use MooX::Press class => ['Foo', 'Bar'];
  }
  
  my $thing1 = MyApp::Foo->new();
  my $thing2 = MyApp->new_foo();   # alternative constructor

But do-nothing classes with a constructor and nothing else aren't very exciting. Let's define a class with some subclasses which have attributes and roles and methods and stuff.

Type::Tiny is probably best known as a way of having Moose-like type constraints in Moo, but it can be used for so much more. This is the seventh in a series of posts showing other things you can use Type::Tiny for. This article along with the earlier ones in the series can be found on my blog and in the Cool Uses for Perl section of PerlMonks.

For small projects, the type constraints in Types::Standard and other CPAN type libraries are probably enough to satisfy your needs. You can do things like:

   use Types::Common::Numeric qw(PositiveInt);
   
   has user_id => (
      is   => 'ro',
      isa  => PositiveInt,
   );

However for larger apps, say you need to check user identity numbers in an handful of places throughout your code and you use PositiveInt everywhere, then if you ever feel the need to change the constraint for them, you'll need to hunt through your code to look for every use of PositiveInt, make sure it's not being used for some other reason (like to check an age or a counter), and update it.

So it is helpful to make your own application-specific type library. You can define your own UserId type constraint, and use that everywhere. If the format of your identifiers ever changes, you only need to change the definition of the type constraint.