Posts by Yanick Champoux
I have been working on my game recently and wanted to check out how to dig some caves. Without readily available software to do my excavations, I decided to give it a shot myself. To come up with an algorithm to create a decent dungeon or cave system was the hard part. At the end, I went with a very simple recipe that seems to gives fair results.
Somebody at $work asked me how I use Git to deploy stuff, probably working under the false hypothesis that wisdom is in any way, shape or form affiliated with yours truly. The fool…Yet, it is true that I had my share of tinkering with Git, and that I might have gleaned from my experience. So I sent him a couple of links leading to more wisdom-certified sources. They are listed at the end of this blog entry; if you have more good articles/blog posts that you’d like to add to the pile, please don’t be shy and mention them in the comments. But I can’t just stop there, really. So, if you allow me, I’ll dust off the good ol’ soap-box, hop on it, and share my thoughts on the subject.
My colleages and I want to set up a LAN radio station, so that we can all groove to the same soundtrack. To make things interesting, we want to be able to dynamically add songs to the playlist. From any machine. And since I don’t really have time to do something like that, I’m setting myself a deadline of one evening to get it running. Got it? Good. For it’s time to rip our shirts. And dance the Haka.
Git::CPAN::Patch could already seed a local repository with the latest distribution of a module, or its whole BackPAN history, or its GitPAN mirror. But with version 0.7.0, it can now go straight for the meat and clone the distribution’s officil git repository, provided that it’s specified in its META.json or META.yml. Please allow me to demonstrate:
Okay, so MooseX::Role::BuildInstanceOf is not one of my modules. And while I submited the patch, the feature itself was born out of fREW’s DBIx::Class::DeploymentHandler. So, in all this, my role was at best to be the pollinator agent between two beautiful flowers. But, hey, it’s not like a little bit of noise is going to hurt any of the involved parties, sooo… let’s see what the buzz’s about.
In our last episode, we began our journey into the wonderful and only slightly scary world of Pod::Weaver. By the end of the blog entry, we victorously managed to, hum, mimic perldoc -u. Not terribly impressive, maybe, but a necessary baseline for the upcoming niftiness. Niftiness that begins with today’s installment, as we are going to take a closer look at all the Pod::Weaver gnomes and fairies that we can enlist to help create our POD.
Dancer::Plugin::Cache::CHI v1.2.0 has hit CPAN a few days ago. In that release, four new goodies have appeared. Here’s a look at them.
Pod::Weaver, which does to POD what Dist::Zilla does to distribution files, is all that, only moreso. But it feels so powerful, holds so much promises to make my life easier once I manage to master it, that I won’t let the steep learning curve deter me. I’ll climb down my brain bicycle, and push it up that hill. And I’ll provide a running (well, walking slowly) commentary as I go along, in the hope that it’ll help other peeps who might want to venture is those exciting yet dark waters. Okay. Enough preamble. Let’s get cracking.
The Dancer plugin mechanism primary aims to provide a way to encapsulate pieces of functionality that can be re-used by different applications. But, it’s so light-weight and handy, that’s it’s easy to also use it to encapsulate parts of the application itself. In that way, it’s very reminescent of the concept of role. Let’s look at this example.
As I was crafting my Dancer presentation for Summercamp 2011, I noticed that there wasn’t a Dancer template for Template::Declare. Well, now there’s one, have a look.