---
title:         "Status Report for Week #5"
date:          2011-06-29
layout:        post
category:      gsoc
---
For Week #5, there was more testing, but these time for
=Dancer::Script= in a real working environment. But, =bin/dancer=
script was also tested as part of the Dancer application creation in
this step-by-step scaffolding process.

While my mentors were at the [[http://journeesperl.fr/fpw2011/][French Perl Workshop]], I met with my
mentors, and discussed what I was working on, and what was next. In
that meeting, =sawyer= pointed out several problems with the tests,
and the way I added several variables and broke the tests files.
=franck= did a review on a code I wrote to check the =name= variable
supplied by the user. For that commit, here is the [[https://github.com/gnusosa/Dancer/commit/7560b3aff69160b9b44d9e53f8ab393b5880806e][link]].

*** What I worked on Week #5

So more then working on writing code, I tested Dancer::Script and the
method =run_scaffold= against working Dancer applications. For
example, this blog was running with =Dancer::Script=, and I tried on
another working application for the same purpose. They all run
correctly. The only problem that was occurring when loading the
module, was a horrible message of Subroutine's stacking each other. In
a [[https://github.com/gnusosa/Dancer/commit/d5aeb954583354b0b69c09413cae3c5d17797204][single commit]], it was fixed by =sawyer=.

Upon having a successful day testing Dancer applications, I went back
to test the scaffolding process of creating a working Dancer
application. I discovered a bug, and another problem with the logic
for selecting the correct Dancer MyApp.pm without a directory, all
dependent on the =name= given by the user. Let me explain more about
the problem, so given a name to =bin/dancer= script like this
=Foo::Bar=, this name will produce =../Foo-Bar/lib/Foo/Bar.pm=. That
is what is expected. But, if you entered =Foo= only, its output
=../Foo/lib/Foo/Foo.pm= when the correct structure is
=../Foo/lib/Foo.pm=. Which breaks the call in =app.pl= for =Foo=
package in the =lib= dir. So what I did was just added some simple
logic to select the correct way it should be structured. You can find
it in this [[https://github.com/gnusosa/Dancer/commit/e889f8018abecf93e6b45d1afdcec3e8c6b09743][commit]].

So after this several commits, the module =Dancer::Script= and the
=run_scaffold= method runs as expected.

*** What's next?

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

        - Add an upgrade log file.
        - Add a built log file.
        - Add tests to each log creation process.

I'm currently working in a way to use the write methods from
=Dancer::Script= to write the logs needed. Well see what I get, I will
commit soon about the usage of such methods. Probably use =write_file=
method, and print out everything to it.

Aside from the work, I seem to be back-on-track and on-point, not
ahead of the schedule, but a bit further then current week. All to the
help of my mentors. Thank you, Franck and Sawyer.

The Shout'out goes to [[https://github.com/hobbestigrou][hobbestigrou]], creator of [[https://github.com/hobbestigrou/Dancer-Plugin-Feed][Dancer::Plugin::Feed]]
and other plugins. For letting me use [[https://github.com/hobbestigrou/MahewinSexyUrl][MahewinSexyURL]] to test
Dancer::Script on a working application.