blogs.perl.org

Travis is a continuous integration (CI) platform for github users, which is free to use. You can set it up so that every time you push one of your CPAN distributions to github, Travis will test it against different versions of Perl.

I've only just started playing with Travis, but I can already see benefits for using it in parallel with CPAN Testers. Why not give it a go on CPAN Day? :-)

If you have an idea what to do with any of these domains, please let me know and I'd be glad to transfer the ownership to you instead of letting random people register them after they expire.

Just a quick reminder that noted perl luminary brian d foy will be at Chicago Perl Mongers tonight. He will be running his Become a CPAN Author Workshop which is a great way to start contributing to this famous repository. So if you have wanted to start playing with CPAN or you just want to meet brian then come on over! It is free as in beer AND there will be free beer!

It's a good idea to specify the minimum Perl version required by your distribution. It's useful information for people looking at your code, it's helpful for CPAN Testers (which will report NA for old perls, rather than failing), and it makes the requirement clear to people who are trying to install your module on an older Perl.

I had a big Catalyst App serving HTML.

Some time later a RESTful interface was needed so I added RESTful controllers using Catalyst::Controller::REST

But that broke Plack::Middleware::CSRFBlock, because the REST calls don't request a form and thus cannot add the secure token to POST requests.

Thinking about a solution it dawned on my that having a single App serving HTML and RESTful requests is probably a bad design choice.

Thankfully most of my business logic is in my DBIx::Class schema so splitting up one Catalyst App into two Catalyst Apps under the same namespace shouldn't be much of a problem.

Let's call the old App 'MyApp'. I wanted the new Apps to be named 'MyApp::Web::HTML' and 'MyApp::Web::API'

First part was to create lib/MyApp/Web/API and lib/MyApp/Web/HTML folders and moving as much components (Controllers/Views/Forms) there as possible. This part meant quite some renaming of file and package names. Your IDE can be quite helpful with that.

Don't you just hate it? You've finished reading, again, that blog entry about database design and you're feeling that you can design something reasonable, and then you see this table:

You can easily see that Customer1, Customer2, and Customer3 are wrong, but what about the rest? Try as you might, you can't quite put all of the rules together that easily to figure out what's wrong with the above table.

There's a shortcut, though, and it makes it very easy to start understanding database design.

If your CPAN distributions aren't already on github, then I think you should consider adding them. Github is the most popular code hosting service, so it's the first place many people will look for your code.

If your distributions are on github, it makes it a lot easier for people to submit changes (like bug fixes) via pull requests. And if it's easier, it's more likely that people will.

If you do add your dists to github, then you should make sure that you give the repo in the dist's metadata and the documentation too.

Come hang out with us at Essen Haus tonight and participate in a series of mini-talks about where Perl can go. You might be surprised.?

[From my blog.]