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.
We have incident reporting procedures at Pythian. This incident report was sent just recently internally at Pythian. We learned some good lessons from it so I hope it would be useful to the community as well – As part of our incident management process, you will find below a summary of the details from the incident that occurred on July 29th at 3PM EDT. Overview: Pythian employees were de-motivated by the lack of refreshments on Friday afternoon
I already aluded to the fact in a few posts already, but just to make it a wee bit more public: a few weeks ago, someone had a lapse of common sense and knighted me Maintainer of DBD::Oracle. mouahahaha *ahem* I mean, I’m honored to be allowed to at the wheel of what is one of the most venerable battleships of the CPAN armada, and hereby swear to serve her at the best of my abilities.
If we are observing more and more swapping in (ver frequent si in vmstat) then we could look at decreasing swappiness.
In order to play with the swappiness, you can temporarily set it by doing the following…
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…