Carlos Sosa

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: What I was trying to do, was to create a 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:

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.)