Please don't create tests like this in Perl

I just came across a test like: And of course, it was silently doing something/nothing/everything. I'd guess most experience Perl coders will notice that the eval will only run the test if the request doesn't throw an exception. Which might be kind of ok but there is no catch or check of the $@ later. If a check is added for $@ later, it will make the test pattern pretty messy Please don't write this type of test. Please. Instead use Test::Exception and drop into a sub. Something along the lines of: This is better for a couple of reasons: test will show some output in case of exception test will stop instead of just pushing on with a bunch of mostly false error (unless the test wants to this to check bad input :) test is simpler to understand (no response, give up) __END__

Dancer Sessions using PSGI

A few weeks on #dancer channel, a user was having issues using Dancer::Session::PSGI . I've never worked directly with Plack besides reading the handbook and few play apps. (well a few weeks ago, I dug into Dancer::Debug .). Using both together was an intriguing problem stuck in my mind. The person on the channel was reporting unreliable reading of session data and other odd behavior. As I started to dig into the problem, I realized that i need to create two apps, one pure Plack and one Dancer with middleware wrapper. I created a public repo on github with my test apps: Dancer and Plack session . Since, I didn't want to deal with html and wanted a bit of structure with return data, I made both test apps return JSON and have pretty simple routes I started off using the documentation from Plack::Middleware::Session to create this test app : Next I created a Test Dancer PSGI app , which basically had a way to show value and update it. Here is the non-exciting Dancer

Template Toolkit Debugging inside of Perl Dancer

The other day someone was asking how to enable Template Toolkit debugging inside of Perl Dancer in the #dancer IRC channel, it seemed like a good time for a write up. The template engine configuration directive supports passing through various options like start_tag and stop_tag as explained in Dancer::Template::TemplateToolkit POD. And alludes to being able to pass other options. How To pass TT options like those found in Template::Constants , there must be a DEBUG section in engines -> template_toolkit , usually found in config.yml . Example Snippet Here is an example: A few notes Remove leading DEBUG_ from TT constants. The option DEBUG_PLUGINS becomes plugins . Multiple options can be separated with a comma. Example: DEBUG: "provider,plugins" . Be warned, some of these options can lead to tons of information :) __END__

What's installed on my ec2

What's installed on my ec2? I swear between debian/ubuntu/mac os x/irix (well not anymore), I can never remember how to list installed packages on my ec2.  Here is is: sudo yum list installed Plus or minus sudo depending on who you are. For once, the command is what i'd expect. __END__

Toying around with backbone.js

Toying around with Backbone.js At $work, we've been using more and more backbone.js  to create a more responsive front end experience and help the dev team manage the code. I like backbone.js and find that its it is very helpful to seperate data and code on the client. But I've found that it challenges me to think in different ways. I find it helpful to create an app so I did :) Introducing Brewers Radio Finder Over the years, i've often driven between Milwaukee and St. Paul, MN. While on the drive, there are areas of the state where finding the close Brewer's radio station is tough and figuring out which station is the closest to you is difficult when looking at the map from Brewers Radio network . Am I currently closer to Reedsburg or Portage? The app is pretty simple, you can type in or give it your current location and it will show the 3 closest Brewers radio stations to you.  You can check it out at . 

backbonejs' alteration of ajax handler parameters

As I spend time learning  Backbone  I've found some unexpected things (to me probably not to others). Today I found that even though  Backbone  fetch allows you to pass in typical jQuery  ajax  options (like success or error handlers), it will alter what parameters are passed back to those handlers. In jQuery Here is an example of plain jane ajax call (in older style jQuery before renaming of events): In backbone handler In backbone fetch changes up what you receive. It is nicely stated in that section: The  options  hash takes  success  and  error  callbacks which will both be passed  (collection, response, options)  as arguments. I only read that like 3 times before i actually saw that note :) Here is an example of backbone success handler: The one really nice part of the different parameters is that backbone gives you objects instead of raw-ish data. This means if you need to create two different models (or collections) from the same call, you can pass i

Altering TT's INCLUDE_PATH in Dancer with Custom View

Altering Template Toolkit's INCLUDE_PATH in Dancer This just came up on Dancer 's mailing list and I've been sitting on this code (and post) for a few months since the project I was working on didn't need it. Basically Dancer's Template Toolkit view requires you completely alter it or use the default setting. This is pain if you just want to add to it but not have to manage all the changes. I created a new TT view class, to get inside the TT init and add to the INCLUDE_PATH instead of replace it. The code was a bit involved and I extended it a bit by adding a customization flag in each environment (if needed). On to the code Here is the code and config that i used to do this Disclaimer I don't recall all the other issues that i ran into while doing this. It was over 6 months ago but post questions if you have them __END__