Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jesse (2531)

  (email not shown publicly)

Journal of jesse (2531)

Wednesday November 29, 2006
02:02 PM

Genericish dispatcher/controller logic with Jifty

In the past couple days, a few folks from the CGI::App and Catalyst communities have posted examples of their dispatcher/controller layout and syntax. Here's what a similar example might look like in Jifty:

use warnings;
use strict;

package MyApp::Dispatcher;
use Jifty::Dispatcher -base;

under '/admin/account' => run {
    before '*' => set object_type => 'account';
    before qr'/(\d+)' => run { set id => $1; };

    on '/'         => show 'crud/index';
    on '/create'   => show 'crud/create';
    on '/*/update' => show 'crud/update';
    on '/*'        => show 'crud/view';

Edit: jibsheet pointed out that I'd misunderstood the Catalyst example. the code above should now be a more faithful implementation

Monday August 07, 2006
02:19 PM

Hiveminder is alive!

We've just launched Hiveminder, a shared todo list service. Hiveminder makes it easy to keep track of everything you need to do and to share tasks with the people you love (and those you just need to do things for you.) You can assign tasks to anyone who has an email address. They don't even have to sign up for an account.

You can defer tasks until tomorrow, next week or next year, with a click of your mouse. "But first" and "and then" links on every task make it easy to, to model complex projects.

We wouldn't be Web 2.0™ compliant if we didn't let you tag each task with useful keywords.

Groups let you share tasks with a set of friends or coworkers (and help keep work out of your way when you're getting stuff done at home).

We'll be rolling out paid premium services later this year, but basic accounts will always be free.

Come take a tour and sign up for an account.

And of course, yes, it's built on Perl and Jifty, our web application framework.

Wednesday July 26, 2006
03:58 AM

OSCAL - Scheduling for oscon

[ #30430 ]
Kellan put together a fantastic session scheduler for OSCON: Sexy! (Even if it is in rails ;)
Monday July 03, 2006
11:43 PM


We're getting close to launching Hiveminder, our new hosted service. I've got 5 beta accounts waiting for the first five people to comment on this post. I'll need your email address, either in the comment or in private mail to
Monday June 05, 2006
03:21 PM

Best Practical Solutions Announces SVK Acquisition

Best Practical Solutions Announces SVK Acquisition - Total World Domination Plan Proceeding Apace

Every ticketing system sucks. Here at Best Practical, we're really proud of the fact that RT sucks less than everything else out there and helps many thousands of organizations around the world get their work done with less pain and suffering.

We're a small software development shop. Between the publicly available versions of RT available and our customer projects, we maintain at least half a dozen active lines of development at any one time. When we first started to do this sort of thing, each merge took about six hours to integrate. That was ok when we were merging two branches once a month....and totally failed when we were trying to merge changes across six branches.

In 2003, Chia-liang Kao (clkao) took a year off work to create a version control system that would let him hike and explore hot springs in Taiwan's mountains and still be able to be a productive software developer. He ended up creating SVK, an advanced distributed version control system which runs atop Subversion, the industry standard enterprise version control system. SVK let clkao mirror remote Subversion repositories, create local branches, hack while offline and later resynchronize his changes with the upstream Subversion servers. SVK is the best version control system for getting your work done while you're hiking in the mountains. It just so happens that what makes SVK wonderful when you're soaking in the hot springs makes it an excellent platform for getting your work done halfway around the world, on an airplane, in a cafe or in your office.

SVK's advanced branching and merging revolutionized our development process here at Best Practical. What used to take us days now takes minutes. We can get more work done faster than ever before. We've been rabid supporters of SVK since its birth. When clkao and I started talking about how I bootstrapped RT into a business and how Best Practical might be able to do something similar for SVK, I literally jumped at the opportunity to help. (And by that, I mean that I jumped on a plane to London on a day's notice to talk face to face about SVK's future.)

  I'm pleased to announce that as of today, Chia-liang Kao has joined me as a partner at Best Practical Solutions and we're pleased to announce that SVK is now a Best Practical product. We remain 100% committed to keeping both RT and SVK open source and are excited about about all the cool new functionality we'll be able to offer users of both products.

Over the next couple months, we'll be announcing new support, consulting and custom development services related to SVK and software revision control. You'll also see SVK's website, mailing list and repository move to Best Practical, where we can offer a higher level of service for all users.

Friday April 21, 2006
05:48 PM

All together now.

It looks like folks are listening. I've been on about continuations for web programming for a while. (Not as long as some. ;)
Even Catalyst is getting in on the action.
Wednesday April 19, 2006
08:33 PM

At OSCON: Smalltalk is the new Ruby [1]

OSCON's coming up in Portland in July. I always go to OSCON for the hallway track. (And it's worth it for that alone.) The sessions have never really been my thing.

But this year, there's actually something that I'm dying to see: Avi Bryant's talk on Seaside.

Seaside is a somewhat heretical web framework. They generate their HTML. They don't embrace meaningful URLs. They use Smalltalk, of all things.

Of course, by making these crazy choices, they get insane amounts of power. When we were building Jifty, we stole liberally from everything that had good ideas. We dragged Rails down a dark alley and rifled through its pockets. We grabbed Catalyst's wallet.

But really, Seaside's killer features like Continuations and Halos...just stopped me in my tracks. Once we got them into our grubby little perlish hands, I realized: This is the way development is supposed to be.

So. Now I get to see the master explain the rest of Seaside's magic. That's worth the ticket price right there. Especially because then I'm going to go home and spend the next few weeks stealing the rest. ;)

Oh. And I'm giving a talk on Jifty, too.

[1] Really, it's been Ruby since before Ruby was Ruby.

Sunday December 25, 2005
04:15 AM

Jifty It's out. I'm rather tired. You'll get a proper release announcement later today. Enjoy your present.
Wednesday December 14, 2005
06:00 PM

Call for Pumpking: Do you want a Ponie?

Two and a half years ago, Fotango announced their sponsorship of the Perl 6 effort, in the form of the "Ponie" project to port the Perl 5 runtime to the Parrot Virtual Machine. For the past year, Nicholas Clark has worked as the pumpking for Ponie as part of his work for Fotango. He's recently moved on from Fotango and it's time for Ponie to do so as well. We're currently interviewing for a new pumpking to take over his role.

The Ponie pumpking needs to manage the route we take to get the Ponie source code from where it is now to its eventual goal: a Perl 5 runtime fully integrated with the Parrot virtual machine.

You won't start from nothing. Nick and Artur Bergman before him have developed a plan to get us to the glorious future and have made a significant dent in that plan, but there's still a huge amount to do.

You'll need to be able to work with the existing plan and expand and revise it as necessary, based on feedback and discoveries made while working through the current tasks.

Ponie is an open source project. While you'll likely be doing a lot of the heavy lifting, you also need to be able to nurture the community and implementation. Contributors will be submitting patches. You'll need to work with them to refine their patches and recruit some of them as core committers.

This is primarily a C hacking role rather than a Perl hacking role. (That is, you'll be coding Perl, not coding /in/ Perl.) You absolutely need a good working knowledge of C and would be well-served to have some experience managing large projects written in C. And yes, an intimate knowledge of Perl's internals would definitely come in handy.

There's one thing about Ponie that might really appeal to you if you have a pretty good handle on Perl 5's internals. Ponie is the perfect opportunity to clean up and refactor the guts you hate most. It's a huge refactoring project and you'll have more than a little freedom to make things faster, cleaner, saner, more maintainable and generally _better_.

If you're interested in being the next Ponie pumpking, please submit a brief bio to We won't consider applications posted publicly.

Over the coming weeks, Nicholas Clark and I will work to pick his successor. Nick and I look forward to hearing from you.


Tuesday November 22, 2005
12:51 AM

Too Early? Too Often?

So. We have this new application. It's not done yet. It's agressively not done yet.

That's not to say we don't have users. We do. And they're giving us good feedback. There's lots we want to do with this application. It has a bright future. It may or may not displace Google as the epiecenter of the internet. (Ok. we know it won't displace Google. That's not even something we're trying to do.)

But there are other things in the same space as our application. Some of them are better (for now). Most of them are abysmally bad.

What we have isn't polished. There are still rough edges here and there. And it's far from feature complete. But it is useful. (Either that or it's so bad that our users take pity on us and lie about it being useful. )

This thing we're doing is hosted, so it's not a problem to grow it day by day and feature by feature. We've got a nice comprehensive test suite. We aren't afraid to roll new releases every day until it's right.

So. do we throw open the doors, invite the world in to see what we've got, possibly laugh at us and walk away before we're ready with something we think is great?

Or do we wait and let the space get even yet more crowded while we hide in our bat-cave with our not-quite-there-but-still-neat application?