Status Report for Week #4 in gnusosa

Status Report for Week #4

Week #4 was more about writing what I investigated from week #3 into the module. It felt like a continuation of week #3, but this time what was studied, it was written. But again, I was lost with what was the best implementation to take from Catalyst::Scripts. Again that doubt, was the one that made me analyze what I was doing. After a failed approach to what my mentors were asking for, I came to the solution, thanks to the help of sawyer. After a while, franck, gave a review on what I thought was the correct route. Which is what I needed, an approach to what I needed to code. If you don’t know what you’re doing, you don’t know what to code.

What I worked on week #4

I added the method run_scaffold which will select between to helper methods, cgi & fastcgi. Each run_scaffold_* is part of Dancer::Script, and are called by run_scaffold. Before getting to this point, I tried a string-to-string comparison, that ended up in a fail attempt to modify the real issue. You can find the failed attempt here: https://gist.github.com/1038873 What I was trying to do, was to create a new MyApp.pm.new file, scrape the file while looking for the deprecated functions, as listed in the hash file. This was obviously a complex approach to a simple solution like Dancer::Script->run_scaffold($method).

Now that was for Dancer::Script, to the actual files dispatch.cgi and dispatch.fcgi, I just added the following:

#!/usr/bin/env perl
use Dancer::Script;

Dancer::Script->run_scaffold($method);

Where $method can be cgi for CGI, and fcgi for FastCGI. The last was influenced by Catalyst::ScriptRunner. That script runner works just like the method I implemented for the module, but it’s more specific on the App and what process to run or deploy. Which is more complex than what Dancer::Script implements.

This way the core developers or any one contributing to Dancer’s deployment will only have to upgrade the methods run_scaffold_* without needing to touch the code to write the files dispatch.{cgi,fcgi} or any new deployment file.

What I learned on week #4

Basically, I moved from thinking that an upgrade process can be handled by string-to-string comparison, or other read-and-write algorithms. This is the main advantage behind removing the necessity of an actual read-and-write upgrade, that way you have a file that works with the code on a module, but that it doesn’t change with newer versions of Dancer. What really changes, is the module that runs the deployment code. This will help if any new addition of a major feature or fix to Plack/PSGI is needed on Dancer’s deployment. Quickly, any developer can add the fix to Dancer::Script::run_scaffold_* without touching any dispatch.* file. So for any old Dancer application we will only need the user to write a new dispatch.* file with the the dancer script without removing the other files in the Dancer app structure.

What’s next?

For week #5, the following are the key points:

Add the module to Dancer’s core.
Run it against several outdated setups.
Review the results and calibrate the tests to the resulting patterns.

So now it’s time to test everything back and test roughly, so my code doesn’t screw up anything. I think this will be the most rough weekend due to the fact that, I have to do several tasks that aren’t relate it to each other, but with the help of my mentors I guess I can be back on track. Not that I’m off the track, but I always seem to go ahead of schedule or go to a different route. My bad.

So the Shout’out is to the Catalyst team and Tomas Doran for writing the Catalyst::ScriptRole and Catalyst::ScriptRunner modules. (Please do correct me if I’m wrong.)

Carlos Sosa