>Implementing a log parser. Exciting stuff, I know.. but we need to get to the data in a useable form, so just parsing events out of logs and tossing them into a database that is going to be used to build nice reports (or crappy ones, time will tell). All I know is File::Tail::Dir is yummy and saving me quite a bit of annoyance. 
A simple callback that passes the data along to my parser and creates some nice puffy database objects to deflate.. oh yeah.
Category Archives: perl
>Recommended Read – Catalyst 5.9
>Take a few minutes and read this post about Catalyst 5.9 and what it brings to the table. A great step forward for Catalyst and Plack.
>Anyone using carton yet?
>Took a look at carton today, after catching a quick glimpse from Miyagawa at YAPC::NA 2011. Seems cool, going to try to use it for a new project I started on today. The app is nothing special, just going to build out a small management daemon for my home server/hosting box/bitcoin rig. This will give me a chance to build a plack app with starman. Good stuff.
>MooseX::POE
>Started laying some of the foundation utility modules for the current app I’m working on. Using MooseX::POE because I like the syntax over using MooseX::Declare and MooseX::POE::SweetArgs. I don’t need that much sugar to enjoy my Kool-Aid!
So yeah, put together a simple wrapper class for getting input from a socket connection. I looked at utilizing POEx::Role::TCPClient since that’s exactly the type of thing I’ve written a simplified version of, but it does not seem to work with the current release of POE. *sigh* (The incompatibility seems to be within POEx::Role::SessionInstantiation but I got lost looking down the rabbit hole on that one, maybe I’ll take another look after a few breaths of air).
So anyhow, I got that built then put together an app controller to handle everything. Now I need to do some more thinking on my data requirements as far as what kind of backend is going to be needed. More on that once I can finally nail down a decision on this…
>Looking over Bread::Board
>Took a look at Bread::Board today. Pretty neat stuff. You can use Bread::Board to wire together your components (complete with the “without the wires” pun) into your application. I love it. I’m going to take another look at Ox to see whether I want to play around with Bread::Board directly or use Ox on top of it to make things a bit cleaner/easier.
On that note, what are people using to implement communication between components on non-event driven environments? Message Queues?
>pid locking
>So I’ve had some issues with duplicate processes running and that kind of confused me. I looked in the code and I’m using Proc::Pid::File to control the processes and exiting out if the old process is still running. I finally found some time to dig into this further late last week. It seems that the logic the module currently has you use is essentially:
if pidAlive
then exit
else
updatePid
end if
The problem here is that there is a race condition between the checking for alive and updating the pid file to take control. What is happening on our system is:
process1: is pidAlive? no.
process2: is pidAlive? no.
process1: update pidFile.
process2: update pidFile.
Now both process1 and process2 are running, the pid file reflects process2 is alive, nothing indicates that process1 is alive, so if the restart or shutdown systems are used, they talk to process2 but process1 keeps on trucking. At this point process3 can check the pid and it’s not alive so it will go ahead and start up perpetuating the problem.
What is really needed would be a single method that will eliminate the race condition:
begin getPid
create pid file if it does not exist
exclusive lock pid file
if pid and pid is running then
result is false
else
result is true
update pid file to our pid
end if
release exclusive lock
return result
end getPid
The problem with this solution? Proc::Pid::File has been around for quite a while and a lot of people are using it. We can’t just change the API like that. We need to find a way to keep the same API, but change the logic to match what I’ve proposed.
I’ll need to give this some more thought on how to work around this without changing the API. Perhaps it’s just continue to support the current API, and add a new method to do both at once but do it cleanly instead of just using it as a wrapper to call both in sequence.
>Reflecting back..
>An interesting week this week, working on a variety of tasks. Unfortunately not all of it Perl related. I did get a chance to spend some time working with Reflex. Overall I really like how it ties into my Moose objects, with the only downside being things were quite flaky at runtime. A quick chat on #reflex reminded me of Rocco’s words from YAPC to use the git version until he has some time to put some polish on his recent changes and push out a release to CPAN.
While this thought was reassuring that things will work better once I pull from git, it also reminded me that I probably can’t really consider using Reflex for any production destined development. This would include my current project. 
i know POE will get the job done, it’s just not as clean and integrated as Reflex so it would have been nice.
Next week I’ll get back to scoping things out using MooseX::POE and see how it holds up. I think I’m already using that in one of my recent Moose objects and things are running sharply in production so sounds good.
>friday… i mean, it’s friday. come on.
>Pushed out the code release this morning to move the refactored event code to production. Overall things went smoothly. Transitioned to the upgraded code smoothly in our facility and the other main facility. One of the international facilities had an issue, but I tracked that down and released a small upgrade to resolve that. I’ll be adding a unit test for that condition this weekend or next week.
Back on to perl specific topics, I looked more at Reflex today. I have a new project, in the early stages of design and prototyping. Pretty sure I want to use reflex to implement the necessary event modules. I’m still not entirely up to speed on how it all works together, but it’s slowly starting to click. Once I get some hands on it’ll spread like butah’ I’m sure.
>testing code updates
>Tested my recent code changes today. Things ran ok for about five minutes, then my cached data expired and I hit a few hiccups. This was a good thing, in the process of tracking down where things went wrong I cleaned up quite a bit of the way things were being handled. I’m still not thrilled with how I’m handling some of the asynchronous calls, but I just did not have time to fully rethink how things work on a fundamental level. I know how I would do it were I to do it all over again, so I learn.. and we move on. And should the current system fall over, I know how I’d like to fix it. Hopefully that won’t ever be needed.
While I was testing I went ahead and debugged a couple web services I was utilizing that did not appear to behave as expected, worked out nicely to get my interactions with those cleaned up.
Overall pretty happy with how the system is running now, testing is complete, I’ve tagged the release v2.2.0 and will be pushing it to our production environments tomorrow morning. I’d push it now, but honestly I need a good nights sleep and I’m not willing to risk it.
>ridin’ dirty!
>Ridin’ dirty this evening, writing a quick export script and slumming it without Moosey goodness in my perl. Feels wrong. :) This kind of work makes me appreciate all the work that goes into Moose and what kind of benefits that gives to me and my code.