Carlos Ivan Sosa
gnusosa@gnusosa.net
google id: gnusosa
Removing the upgrading necessity of the Dancer script with a module.

Abstract

Rewriting the scaffolding script of Dancer as an object-oriented module, allowing testing and extendability, as well as user plugins. Changing the requirement of upgrade (which has become difficult for new and experienced users) and factoring in the logics in the module so the script could be as slim as possible with no need for any upgrades (similar to Catalyst and other projects). Solidifying the skeleton-scaffolding script and the Plack handler script will benefit all Dancer users (whether beginners, intermediate or advanced) and allow Dancer to compete better in the production-level web frameworks domain. As of the standing status of the scaffolding script for Dancer's upgrade, it's more of a workaround solution with several ideas on the air rather than a solid solution to the issue. A module will benefit both Dancer users and core developers, for both testing and developing purposes.

Benefits to the Perl/Open Source Community

• For the Dancer framework project, it will add an upgrade module to the core that will effectively eliminate the need for upgrading an entire Dancer setup.

   

• For the users of the Dancer framework and the web applications developers, to create a module that will assist in the migration process, while avoiding the need for a migration process. This would add more consistency to the migration process between outdated setups and the changes in the Dancer core.

   

• If the scaffolding script is replaced with a module, it will make more maintainable the code and the process of the migration process.

   

• A module in the core of Dancer can open suggestions for tests in the upgrade process, and what should be upgraded in different environments for different web applications.

   

Deliverables

• A brand-new structured object oriented module with upgrade functions for the Dancer core.

   

• Built the module using/based on Dancer::App, that way it will work better with the whole Dancer ecosystem.

   

• Built the module that will avoid much of the scaffolding process. For this, Catalyst::ScriptRunner can be used as a guide on how-to fork such task.

   

• Implement Sawyer X's suggestion and work, as also the requested from the Dancer community for the upgrade module. Commit the final result of the suggestions to the core.

   

• Documentation on the upgrade module based on the current Dancer's core documentation.

   

• A dynamic test suite that will set the configuration for each action in the upgrade process.

   

• Paving the way for additional advanced options such as freezing Dancer version, better local::lib integration and issues of the likes that are at the top of Dancer users' priority list for production-stable websites.

   

Project Details

This module will be crucial to Dancer and is expected to be integrated into the core once complete, effectively replacing the current mechanism.

As of today there are several suggestions and requests of a process to update outdated Dancer setups; Dancer as been used since its early revisions, and this has carried out applications that need to be updated for security purposes. From this, the main purpose is not only to subside outdated applications, but to think for the future of Dancer's applications. What makes my project relevant and worth the work is this missing feature in Dancer. My project definitive goals are aimed for a well-tested module for the Dancer's core, and that will be based on Catalyst's ScriptRunner (Catalyst::ScriptRunner). That way there should be no abundance in the scaffolding process. Having the project development around Dancer's core will suffice for a documentation based on this and from this. The project will feature specific tests for both environments in the default Dancer application setup.

The main purpose is to construct the module that will go directly to the Dancer's core, but packaged around the core as an aside module for this specific purpose: to remove the upgrade process that will be fixed so it will not scaffold a script that will later have to be upgraded. From this, the two main benefits for the Dancer project are: the reusable code and the first attempt of an upgrade process in the project. Still, the goal is to code an upgrade module for the Dancer Core, that will suffice the removal of the upgrade process in each important or vital commit/update/fix in each Dancer application.

For the last, Catalyst scripts and Catalyst::ScriptRunner will influence the way the module is to be writing, and what specifications can we take out of Catalyst for the sole purpose of the scaffolding process.

By the time that project is finished, if it meets the expectations and goals, I will have more time to work on the documentation, and the users view point, since the development of the upgrade module will be more specific for Dancer's core developers.

If the project those not suffice the goals detailed and the expectations from the developers by the end of the summer, this project will still be the base and the first attempt to work with Dancer's upgrade process.

Project Schedule

Note that the Project Schedule might be susceptible to alterations according to me progress, and the suggestions made by the mentors. For example, if the code is committed in a quicker matter, I will be able to push further time for more tests or any added feature that needs to be polished.

• Week #1-1,April 25 - 23 May

  Gather current Dancer's core, plugin and packaging documentation, and study this as an introduction. Arrange the working schedule with the mentors based on the observed goals, and schedule a better working process based on the timeline.

   

• Week #1-2,24 - 28 May

  Review and select suggestions from users, developers, and mentors on the module. Study the possibilities of the upgrade module, and code a rough draft to be worked on.

   

• Week #2,29 May - 4 June

  Study Catalyst scripts and Catalyst::ScriptRunner, derive a code from both to merge to the project.

   

• Week #3,5 - 11 June

  Make a list of the possible tests for the rough drafted upgrade module. Test the rough drafted module against Dancer's core, and add more tests.

   

• Week #4,12 - 18 June

  Make the specialized blocks of codes and comments that will compare string and text for the features of any upgrade between the current Dancer setup and any commit. Add tests for those.

   

• Week #5,19 - 25 June

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

   

• Week #6,26 June - 2 July

  Add the capability of exporting an upgrade log that will verbose the module progress, and the changes made for the outdated tested Dancer setup.

   

• Week #7,3 - 8 July

  Make sure that they are enough tests for the whole spec, and add tests to upgrade log functions.

   

• Week #8,10 - 16 July

  Prepare the Midterm report, describe the status of the project and further plans.

   

• Week #9,17 - 23 July

  Make the documentation for classes, methods and subroutines accessible via the Dancer config.yml

   

• Week #10,24 - 30 July

  Write a code hand-out of the plugins implementation: How it must work, how will it work and for what functions. Add detailed tests to each plugin function

   

• Week #11,31 July - 6 August

  Calibrate and polish the plugin implementations, while tracing each test successful output to see what can be added. Write a rough draft of the documentation relating the plugin feature.

   

• Week #12,7 - 13 August

  Review the documentation and make it more user-friendly.

   

• Week #13,14 - 22 August

  Finish what was left undone, make sure the tests are well-written, the coverage is high and the documentation covers every aspect of the project.

References and Likely Mentors

I have had communication via mail and IRC with both Sawyer X, Franck Cuny and Florian Ragwitz. From whom Sawyer X is listed as a mentor for this project. Aside from the feedback and help, they gave me a startup on the details of the project. Made a note on the specific and important parts of the project.

License

The project will be licensed under the same terms as Perl itself: Artistic + GPL.

Bio

My name is Carlos Ivan Sosa, I am on a second year of transfer courses for a Computer Science degree or a like, currently enrolled in Imperial Valley Community College. Located in Imperial Valley, California.

I've worked with Perl since 2006 for System Administration purposes. It was until 2008 that I became more involved with Perl Web Frameworks. At this point, my Perl idioms and syntax were basic. Until 2009 that I was employed by a web developing office, that I started coding with PHP, Ruby, and getting more involved with MVC and other frameworks. It is in December of 2009, that I become fond of coding Perl Web frameworks. My interest arose from Dancer and Plack/PSGI; this took me to write my own Dancer applications.

I've been working as a sysadmin since junior high in several governmental offices in Mexico, where I'm originally from. By High School, I was schooled with the C programming language, and C++. Which let me to work developing accounting and database tools in C++ first, than in Java. I was employed by a foreign company in my hometown, and I was part of team which consisted of 20 programmers.

I'm also proficient user of Gentoo, but prefer Debian in my servers. My work tools are: dwm, git, gnu screen, vim, rxvt-unicode, and w3m.

Eligibility

I am an eligible student with paperwork to prove it if necessary.