Re-factoring ModExec Day 2

Today I got tests done, and I kinda abandoned Error.pm for exception handling. I switched over to using Try::Tiny since it looks like there are known issues with Error.pm in more modern frameworks like Moose. I’m going to try to avoid using ##no critic as much as I can, but I had to use it twice in my ModExec::Exception class since I wanted to include the sugar functions from Try::Tiny, and since I want to use die() in my throws to keep the object intact.

Here’s tonight’s changeset: http://tinyurl.com/nuzvnzt

Next up is the base class, ModExec, itself.

Exceptions in Perl, Then and Now

In re-factoring ModExec, I have started with the exceptions. I’m debating how I used to do them. When I first started I used Error qw/:try/ and Error::Simple for exceptions. I still think I will, it looks like it’s still being well-maintained by Shlomi Fish (see here).

I think that the piece I will bite off first is to get some test coverage around my exceptions and add documentation. They’re not much more than what you get with Error::Simple, but there’s some stuff in there for stack dumps and things like that.

Goals for this first pass are:

  1. Pass a `perlcritic -3` for all exception code
  2. Add POD for all exception code
  3. Add a test for at least some of the methods (more tests will be added later)

Before and After

Here are some GitHub links:

Re-factoring Your Old Projects

Once upon a time I maintained a very small, lightweight framework to allow for Perl interfaces to be integrated with directly from client-side JavaScript. I called this framework ModExec. This framework took into account the various security implications which I’m sure are already sounding the klaxons in your brain. I even managed to get this framework into a state where I was proud enough to present it to the Perl Special Interest Group in Lisle, IL in 2006. Man, those were the days… and that was 7 years ago. Continue reading Re-factoring Your Old Projects

Gist of the Day: Named Capture in Perl Regular Expressions (Briefly)

One of the largest critiques I see about regular expressions is that they lack readability. Well, in Perl 5.10 named capture was added (http://perldoc.perl.org/perlretut.html) which I think adds an awful lot of readability to Perl regular expressions. Continue reading Gist of the Day: Named Capture in Perl Regular Expressions (Briefly)

Gist of the Day: Playing with Forks

Parallel processing is all the rage these days, and life has me at a point where I’m needing to use it. I am having to minimize dependencies in the task at hand, so I’m having to forego my usual CPAN modules and use basic system calls. It’s not terribly complicated, but just to refresh myself on the basics I went ahead and whipped up a quick demo that I thought others might find useful. This is a very simple demonstration of how to use fork() and wait(). Continue reading Gist of the Day: Playing with Forks

Gist of the Day: Test::MockModule for Repeatable Tests!

I like repeatable tests. The #1 benefit of repeatable tests is that they’re repeatable. This also means they’re less vulnerable to data changes (e.g. this test depends on this product record remaining unchanged) and don’t pollute your environment. There are two ways that I think you can make your tests repeatable, and I think both of them are equally valid, and each should be used in their appropriate time:

  1. Creating and tearing down fixtures
  2. Using some sort of mocking framework to force a repeatable result from an up-stream dependency that is not what you’re trying to test

Continue reading Gist of the Day: Test::MockModule for Repeatable Tests!

Not Gone, Just Moving

Hey all, I just wanted to let you know that I didn’t die… I am only going through a job change and a move, so I am currently bogged down with a number of things.

I expect to be back up and running again by next weekend at the latest. I suspect very few people care, but in the event that you do, now you know.

I’ll share all of the details when I have them 🙂

Gist of the Day: How to Test a File You Wrote!

First, I suppose I should apologize for two days of silence. I am currently going through a major life transition, so things could get a little spotty for a while. I haven’t forgotten about you. I actually have had a couple of days where my experiment for the Gist of the Day failed, and I couldn’t get something working in time to put it up.

Today, however, I do have something for you!

Today we are going to cover two topics very briefly (as usual): 1) how do you factor files you wrote into your tests, and 2) how do you write your code with testing in mind (which you should). Continue reading Gist of the Day: How to Test a File You Wrote!

Gist of the Day: There’s More Than One Way to Switch Your Class!

In programming you will commonly see abstraction layers. Say, for instance, you wanted to have a program to take some arbitrary data format and load it into your data. We’ll call it product feeds (just because some people like relevant examples). So, you want to pull in product data from various different web sites and vendors to list some products on your site. Now if you have ever done this task before then you’re already thinking “jeez, what a pain in the ass it is to get everybody to use the same format!” If you’ve done this task before then you’ve probably already dabbled in this type of abstraction. In Perl – my go-to language (since I arbitrarily prefer it) – this usually results in dynamically loading a “driver” class based on the data format which is likely vendor-specific. This makes it easy/easier for you to allow each data source to have its own format while using them all in the same way.

If you were to pick a Design Pattern for this, you would do well to choose a Factory pattern. In Perl, since you have so much dynamic leeway, you don’t need to go with a pure Factory pattern here, but what you end up with I think is most certainly in keeping with a factory pattern.

For this Gist, I will demonstrate three common ways to get from knowing which class you need to getting that class:

Continue reading Gist of the Day: There’s More Than One Way to Switch Your Class!

Gist of the Day: Mojo Merging Hashes

Mojolicious is a fun module/framework/thing for me. How do I love Mojolicious? Let me count the ways (sorry Shakespeare):

  1. Mojo has ridiculously few dependencies, especially when compared to other web frameworks
  2. Mojo brings web servers (morbo and hypnotoad) with it
  3. Mojo does MVC, or doesn’t do MVC, whatever I want to do
  4. Mojo has templates, and they’re outstanding
  5. Mojo does routes very simply, which is badass
  6. I can write an entire web application in only one file (though it could get big and may not be advisable) using Mojolicious::Lite
  7. Mojo has helpers which are actually helpful
  8. Mojo is crazy fast, so fast that if there is a performance problem I’m pretty sure it’s me
  9. The more I use Mojo, the more I find cool stuff that it can do Continue reading Gist of the Day: Mojo Merging Hashes