I have experimented with the Makefile idea too. Perl-Critic-Jed is an ordinary web application. But it includes a custom Makefile that builds the dependencies and other stuff. I find it useful, but others probably think it is weird.
The Perl toolchain is great for distributing libraries, but lousy for distributing applications, especially if they contain lots of non-code assets. I think part of the problem is that there's no consensus on how user-space applications should be organized or where they should go on the file system.
]]>I am working on adding MCE directly to the Perl::Critic API, so that all clients can reap the benefits.
Each Policy could also be run in parallel, but I doubt it would help. Most of the overhead is parsing the file.
]]>all_critic_ok()
function then no code changes are required -- just upgrade and fire away.
For the moment, this is just a developer release so you'll have to fetch it explicitly (using cpanm) as THALJEF/Test-Perl-Critic-1.02_002.tar.gz
. MCE is very robust and it should behave well on all sorts of platforms and hardware. But I'd really appreciate if you give it a try and report any problems on GitHub.
Update: That should be version 1.02_002
, not 1.02_001
as originally written.
Thanks. Enjoy!
]]>The back end is now written in Modern Perl™ using Mojolicious. And the front end uses Bootstrap and jQuery to create a productive and fun user experience.
The source code is on GitHub as Perl-Critic/Perl-Critic-Jed and I welcome pull requests. If you're looking for an opportunity to contribute to a public site, this is a great place to start.
Check it out now: http://perlcritic.com
]]>I would love to do more of these. If your local PM group or team at $work would like to learn more about static analysis with Perl::Critic, or dependency management with Pinto please get in touch with me. I am thaljef@cpan.org.
I'm looking forward to hearing from you!
[1] Big thanks to Tom Metro for extending the invitation, and Rick ... for handling the technical setup.
script
but not scriptreplay
. I'll have to try that next time.]]>
We all know the hazards of doing a live demonstration. And with command-line tools, there is the added risk of annoying the audience while you stumble around the keyboard.
I wanted to make all that go away. So I created App::Cleo. It includes the cleo
utility which runs pre-recorded commands interactively. You can step through each command simply by pressing the space bar. So no more typos!
Sometimes, you want to stop and explain something in the middle of the command. For that, you can put breakpoints inside your commands. And when things go wrong, you can redo the current or previous command by pressing r
or p
respectively.
You can see cleo
in action in this video (the live demonstration starts around 10:47).
PS: It wouldn't surprise me if there is already some kind of tool for this. If you know what it is, please enlighten me.
]]>Well, that's half the reason I started Stratopan. The sample is pretty small now, but imagine having visibility into which modules (and which versions) people actually use!
]]>merge
command. At the moment, it is only capable of doing a fast-forward merge (that is, when the target stack hasn't changed since you last forked or merged it). I still plan to support other types of merges, but I actually think fast-forward merging will cover the majority of scenarios.
Most of the time, stacks are short-lived. You make a copy of the stack, upgrade some packages, and then build your app. If your tests fail, you probably throw the new stack away and stay with your current packages. If your tests pass, then you immediately merge the new stack back into the original.
This release also contains reset
and revert
commands that are similar (but not identical) to the same commands you find in git. All the new commands are experimental, so the interface and behavior are subject to change.
So I'm not calling the grant work "done" just yet. Once these new commands have been battle-tested a bit, then we'll see where things stand.
]]>That's correct. And the nice thing is (IMHO) that the repository is stable, so you'll always get the same version of the CPAN libraries, until you decide to change them.
]]>I've got a wildcard cert of my own, and I thought of setting up an HTTPS proxy to blogs.perl.org. But I'm not sure if that is ethical or prudent.
]]>This will be my fourth YAPC, and I'm especially excited this year. There have been a lot of advancements in asynchronous programming, meta-object protocols, and web frameworks. So I'm really looking forward to presentations on those.
And of course, there are all the hidden gems that I discover at YAPC -- things I had never expected to learn, but turn out to be incredibly useful or enlightening. Those alone are well worth the expense of attending.
And I always enjoy meeting all the fantastic people who have contributed to Perl::Critic and Pinto over the years. So if you see me, please come up and say "hi". I am pretty easy to spot -- I'm usually the only guy wearing a suit and tie.
Hope to see you all in June!
Pinto is a powerful tool for creating and managing a private CPAN. Pinto make it easy to control your dependencies and ensure your app is built with the right module versions every time. The latest release (0.099) includes a boatload of exciting enhancements. Here are the highlights[1]:
]]>$> pinto pull 'Moose==2.0007'
Or you can use a complex version range specification, like this:
$> pinto pull 'Moose>2.0007,!=2.1100,<=2.1200'
This particular feature was financed by the crowdfunding campaign brian d foy organized last year. So I'm very happy to report that I've finally delivered the goods, and I want to thank all of the wonderful campaign contributors for their support.
--skip-missing-prerequisites
option that tells it to ignore any prerequisite packages that it can't find. This is especially useful when you're populating a repository with your private distributions and you don't want to worry about satisfying all the private prerequisites because you're going to add them later.You can install Pinto from CPAN like any other module, but I recommend using the installer script which builds Pinto into a separate directory using blessed versions of all the dependencies. It just takes one command:
$> curl -L http://getpinto.stratopan.com | bash
[1] These features are described in more detail in the change log.
Enjoy!
]]>