The best way to get a feel for a module is to work with it, I decided to try my hand at a small, unassuming maze game. For the maze creation itself, I used Games::Maze, and with that out of the way, the resulting program turned out to be quite simple, have a look.
A customer contacted us regarding a problem with one of their replication servers. We found they had deleted some binary logs from the master and relay logs from the slave to release space. It is not a good idea to delete logs that aren’t cached by the slave, in case they are needed. At least keep relay logs in slave to keep the replication working.
Since writing a blog entry sorely to talk about a software release bearing my name would be slightly… ah… self-serving (and we couldn’t have that in a blog, now, could we?), I thought to expand a little bit on the topic and discuss why I am contributing to other peoples’ modules, and how I usually go about it.
When I begin to work with a module, most of the time what I do is to look at its pod, and copy the code in the synopsis that I’ll use as a a baseline. I’m pretty sure there’s already a better tool to do it somewhere in CPAN, here’s my little podsyn script that does all the hard work for me.
With Dist::Zilla, so far I was manually setting up the new version number in the dist.ini of my distributions. But, as I’m a lazy, lazy man, automating the process was still at the back of my mind. Well, I finally found the time to work on this. The result is Dist::Zilla::Plugin::Author::YANICK::NextSemanticVersion, which currently lives in the Dist::Zilla::PluginBundle::YANICK distribution (and, of course, in its GitHub repository).
Welcome to my first blog post in this series on database consolidation tips. Let’s get down to business…
A few days ago, had you asked me one big plus of Catalyst over Dancer, I would have said “chained actions”. Chained actions allow to split the logic underlaying an uri into smaller components associated with its segments. A very neat, DRY-friendly ways of doing things. Have a look.
All the tools you need to write a Dancer plugin are contained in he helper module Dancer::Plugin. To invoke them, you just need to ‘use’ Dancer::Plugin within your module — all the inheritance stuff is taken care of behind the curtain
Let’s say you want to serve static http content from a machine. The sensible thing to do would be to install Apache/Nginx/Lighttp. But let’s say — because of insane configuration, red tape, cruel whims of the gods — that you can’t do the sensible thing. Fortunately, there’s a few aces you can pull from out of your sleeve. One of them is to use Dancer as a spur-of-the-moment barebone web server
Say theres a website you would like to tweet directly from. Not via a Twitter client, not using a service like Yoolink, not through a Firefox plugin. No, you really want to be able to have a honest to God “Tweet this” input field on the website itself. It’s a strange requirement, for sure, but it’s a mission that I’d been given a few days ago. Here’s how I did it.