Sometimes in a weak moment we ho our code out for bread, butter and tight deadlines. In this flurry, we may have missed a step in the object memory cleanup dance1. When one thinks they may have sprung an object memory leak, they can turn to the aid of Devel::LeakGuard::Object. It builds upon the admirable Devel::Leak::Object by providing more control over the leak report.
That's being said let's get down and dirty with an example.
or... when we only need a bicycle wheel, sometimes we need to re-invent our wheel slightly to get the job done.
Recently I ran into a situation where a client had a queue system that placed requests into queue files to be processed on another system. Until now, these queue files were created on one machine and network-copied to the processing server. This required a lot of server setup and left a lot of pieces to easily break. It also gave no clear way to log the submission to the queue.
To solve this problem and to make it more easily to integrate, we decided to accept the queue submission via http. We could implement it to take care of these queue files and add some logging and sanity to their current situation. The idea would be to handle a request, validate the submission, log the status and then write the given request to the queue directory.
Seems simple right?
Recently, there's been a distinction between a "developer" and a "programmer". Forgive me, I'm not citing the source as I don't feel digging around in Google for a while would help make this point any better, but I read an article stating that "Developers take pre-fabricated items and glue them together, as fast as they can, doing as little programming as necessary, where programmers convert caffeine into code; they live for the sheer idea of programming".
While this holds a good deal of truth, I have my own take on it....
The big buzz nowadays in the web-application hosting world is cloud servers. Cloud servers are virtual machines that can be deployed quickly and easily by the customer without intervention by the hosting company. They tend to live in very large data centers on clusters of hardware with specialized software designed to automatically manage the allocation, de-allocation and scaling of virtual machines.
The big player in the Cloud computing space is Amazon's Elastic Compute Cloud, or EC2. I've done a lot of work with hosting web applications on EC2 cloud servers and I find them to be extremely convenient and functional, especially compared to physical machines. They are, however, on the whole more expensive and require some specialized knowledge to manage effectively.
There is a relative newcomer to the cloud serving space, Mosso from Rackspace. Mosso's offering is quite similar to EC2, though the prices tend to be slightly cheaper.
There is very little in the way of direct comparison between EC2 and Mosso's Cloud servers and while the information about each is available, it takes some digging to get the real scoop.
In todays article, we will dig into both Amazon's EC2 and Mosso's Cloud-Servers with an eye toward the differences that will really matter to you as you try to decide which virtual server cluster upon which to deploy your Perl or Catalyst application.
So, it is still a bit of work to setup Reaction applications. The Tutorial walks you through it, but that’s still many lines of code and many places to introduce errors.
What I came up with last week is a module called ReactionX-Jumpstart,
that comes with a reaction-jumpstart script that works similar to what
Catalyst provides with its catalyst.pl.
It is nowhere near complete, it lacks many things and doesn’t even create the application’s scripts yet, but this is just a matter of time and decision making.
Now, let’s see what it can do.
