By Kieren Diment
Over the past couple of months, Matt Trout and I have been putting together a book proposal for the Catalyst web framework. We did this because a. we want to publish a book about Catalyst, and b. because a publisher approached us. Now that the proposal is in, the editorial board are concerned that there is insufficient market.
I've looked at a bunch of statistics (mailing list size, Google hits, IRC channel size, Amazon sales rankings and more) to compare the size of Catalyst to a group of other web frameworks. Catalyst comes out at the bottom of the top of this list, in that it's the least popular of the "big" frameworks - Ruby on Rails, Django and so on. On the other hand, it's clearly an order of magnitude more popular than the small frameworks (Pylons, Turbogears and the like). We also know that Catalyst runs some pretty big streaming media websites, including some that we're a bit embarrassed (NSFW) to talk about. Catalyst is also rumoured to be running the BBC iPlayer.
Our publisher now has cold feet, and wants to collect more data on the size of the market before they give us the go-ahead, so if you use Catalyst, please answer a short survey for us . My aim is 100 responses (10% of mailing list subscribers).
The questions are as follows:
- What country are you in?
- How many people are on your team?
- How many of those people are writing code with Catalyst? If there are non Catalyst coders on your team, how many of the whole team would you like to be writing Catalyst code?
- How many people using Catalyst on your team are subscribers to the Catalyst mailing list?
- How many people writing Catalyst code on your team use the #catalyst IRC channel on irc.perl.org?
- What do you see as potential for growth of Catalyst in your organisation? How many people do you think will be using Catalyst in your organisation in 12 months? In 2 years?
Please email your answers to firstname.lastname@example.org.
The mighty Tim Bunce has added yet more cool features in 2.07. Brief summary:
- Runs on Windows
- You can now turn off statement-level profiling and just have subroutine-level profiling, for speed's sake
- Tracks recursion more accurately
- Subroutine calls made within string evals are now shown in reports.
Check the full change log for all the details.
Can we just all please buy Tim a beer for all his work on Devel::NYTProf, and Adam Kaplan for starting it? NYTProf is fantastic.
By Ricardo Signes
At the Pittsburgh Perl Workshop this year, I gave a lightning talk about Dist::Zilla, the system I am increasingly using to manage my CPAN distributions. I'm using it instead of writing a
Makefile.PL, but it doesn't do the same thing as Module::Build or ExtUtils::MakeMaker. I'm using it instead of running
module-starter, but it doesn't do the same things as Module::Starter. I've had some people say, "So should I stop using X and use Dist::Zilla instead?" The answer is complicated.
(Well, actually, for now the answer is simple: probably not. Dist::Zilla is a lot of fun and I really, really appreciate the amount of work it saves me, but it's really young, underbaked, and probably full of bugs that I haven't noticed yet. Still, the adventurous may enjoy it.)
The idea behind Dist::Zilla is that once you've configured it, all you need to do to build well-packaged CPAN distributions is write code and documentation. If you're thinking, "but that's what I've been doing anyway!" then first consider this: If you are writing
=head1 NAMEnnMyModule - awesome module by methen you are not just writing code and documentation. If you are adding a license to every file, again, you are not just writing code and documentation.
If you use, say, Module::Starter to get all this written for you, then you're safe from writing that boilerplate stuff. Unfortunately, if you need to change the license, or you want to add a 'BUGTRACKER' section to every module, Module::Starter can't help you. It creates a bunch of files and then its job is done. It never, ever looks at your module-started distribution and fixes up things. This also means that if you realize that your templates have failed to include
use strictfor your last three module-started distributions, you have to fix them by hand. The same goes for the stock templates, which until recently didn't include a license declaration in the
With Dist::Zilla this content is not created at startup. It is not stored in your repository. Instead, the files in your repo are just the code, documentation, and the Dist::Zilla configuration. When you run
dzil build, your files are rebuilt every time, adding all the boilerplate content from your current setup. If you want to change the license everywhere, you change one line. If you want to start adding a VERSION header, you tweak the Pod::Weaver plugin's configuration.
So, there does exist a
dzil newcommand for starting a new distribution. All it really does, though, is make a directory (maybe) and add a stock configuration file. Why would it add anything else? If you want any code, you would only be writing the actual code needed, not any boilerplate, so adding anything would be foolish.
dzil release, which goes beyond what Module::Starter (and its competitors) do and into the realm of ShipIt or Module::Release. I'm hoping I can integrate with or steal from one of those sort of tools. Right now, it exists, but all it does is build a dist and upload it. In the future, it will have at least two more kinds of plugins to make the release phase more useful: VCS (so it can check in and tag releases) and changelog management. It has a changelog thing now, but it stinks and isn't very useful. In the future, you won't need to edit a changelog. It will be able to read changes out of your commits, or you will just tell it to record a changelog entry. Then the Changes file can be generated as needed.
For now, I am manually editing my Changes file.
So, eventually Dist::Zilla could obsolete Module::Starter for people who like what Dist::Zilla does. Then again, people might still want to have starter templates that add minimal boilerplate for using certain frameworks. We'll see what happens.
Ricardo Signes was thrust into the job market with only a rudimentary humanities education, and was forced to learn to fend for himself. He is now a full-time Perl programmer, maintainer of the Perl Email Project, and frequent contributor to the CPAN.
As Chris Prather pointed out in Write your code like it's going on CPAN, Perl's module toolchain is getting better every day, and the support for good coding habits can help even if you don't want to distribute your code. However, starting a module distribution from scratch can be a daunting task.
I wrote Module::Starter a few years ago to make it easy to create a module distribution, but never wrote the kind of basic introduction that it needed. Now, Perl Training Australia has done just that with one of its Perl Tips, Starting a module with Module::Starter. I've already absorbed it into the Module::Starter distribution.
Module::Starter does happen to be getting a little long in the tooth, and I know that Ricardo Signes, for one, has started his own module creation magic. If Ricardo or any other authors would like to let Perlbuzz readers know about their projects, let me know.
By Chris Prather, from his recent blog entry
One of the things I've discovered recently, and wished I'd known years ago is you need to write all your Perl applications like you were gonna be posting them to CPAN, even if you have no intention of ever doing so.
At work we are starting to migrate from a legacy system that was written in the grandest of late 90s CGI (the code is clear, easy to read and for this era of script well documented, but lacks any architectural cohesion and has been patched and re-patched over the years to handle new use cases). This system is absolutely core to our daily business. You might even argue that it is our daily business.
One of my tasks was to add Validation on some of the input parameters. My boss wants to move to something testable so I created a Validation module that contained a bunch of validation functions for the various pieces of data, and when we could easily do so we wrapped CPAN validation modules (Regexp::Common we love you!). This however added a couple of new dependencies to our system. This is where writing it like a CPAN package comes in.
I added a Makefile.PL for the system. We have no intention of ever releasing this code, but the Makefile.PL uses Module::Install and lists the dependencies. The magic of this is that for recent versions of
cpanyou can just type
cpan .and it will automatically install all the dependencies for the current directory. Failing that you can always run
perl Makefile.PL && make && make testand it'll install dependencies and run your test suite.
By treating code we were never going to release to CPAN as if we were, we win the support of all of the CPAN toolchain. A toolchain that is getting better every day.