use Perl

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

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 procrastinate...er, 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.

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.

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.

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 ponie-pumpking@perl.org. 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.

        Jesse