Added gsoc entries

15 files changed, 1043 insertions, 0 deletions

diff --git a/gsoc/2011-05-24-bonding-period.org b/gsoc/2011-05-24-bonding-period.org
new file mode 100755
index 0000000..7ac5977
--- /dev/null
+++ b/gsoc/2011-05-24-bonding-period.org
@@ -0,0 +1,78 @@
+#+title:         Community Bonding Period
+#+date:          2011-05-24
+#+layout:        post
+#+category:      gsoc
+
+The [[http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bonding-all.html][community bonding period]] finishes today. Today is the start of the
+coding period for every selected student. Some like myself, have taken
+on the task of studying the whole project that they will be
+collaborating with. Others, used that time to code and play around
+with what they think might work, and settle to do work in the last
+week of the bonding period.
+
+In my case, the bonding period with the Dancer developer team, has
+taught me a whole lot in those 3 weeks.
+
+Much of the administration, pull-requests reviews, and queries from
+users who fork Perl Dancer is done in the IRC channel of the project,
+#dancer at irc.perl.org . I'm amazed at the speed on which everybody
+collaborates via IRC, mail, and the [[http://github.com/sukria/Dancer][Dancer github repo]]. The speed at
+which other users answer to the Dancer mailing list is fantastic, I've
+never seen a mid-size project mailing list so dedicated to helping
+out. The features requests are mostly pulled from the github repo.
+While most of the feedback from users deploying Dancer for production
+purposes comes from the mailing list, some do join the channel, and
+pull out a quick hello and thank you.
+
+Now on detailing what I've learned with regards of my coding project.
+Refactoring the script into a module will be something new for me,
+specially, since I don't know what are the detailed best practices of
+the developers team. I've read and seen several PR's from
+~ambs~ , ~bigpresh~ , and even
+~franck~ , my mentor. But there are still more work that I
+need to do, to quite understand how they administrate their PR's.
+
+**** So what does the script currently do?
+Well it's pretty straight forward. It grabs the current directory, the
+given ~app_name~ , stores it into two variables who work they way
+through functions that create a directory structure, the "default"
+views & layouts, and at the end passes through two writing functions
+who output the files in the correct order while writing the filenames
+to the MANIFEST file. Note that each "default" file that a clean
+startup Dancer app starts with, is embedded in the scaffolding script
+just mentioned, therefore, you can find a ~write_file~ function, and a
+~write_data_file~ function in the script. The last used for writing
+binary data into the images files, and favicon. To note more on that,
+the javascript and the css files for the public folder, are obfuscated
+in the code of the script along with the binary data for the images.
+
+**** My work in those weeks
+The work done by me in those weeks, was mostly play and study the
+~Catalyst::Script*~ related modules. Since the module I'm working on,
+will be somewhat based on those modules, but with another twist. I
+took the liberty to try them at home. By the second week of the
+bonding period, I was moving forward doing commits to my forked repo,
+and ended screwing up a branch. (See the commits in the [[http://github.com/gnusosa/Dancer][devel branch
+at my github repo]].)
+
+Thinking ahead of the schedule, I ended up messing
+~Dancer::FileUtils~ . From that, ~sawyer~  and
+~franck~  added new steps and worked with me around the
+following steps, and how-to follow up the proposal schedule.
+
+**** Real work
+Good organization leads to fast coding and good practices. That's a
+something I've always read, but never thought about it too seriously
+until now. After deciding the steps and what to take on. The coding
+went smooth. I created a new branch on my repo, and started [[https://github.com/gnusosa/Dancer/commit/cc2ab08eb0e6c303066f52207c8a04185408833f][migrating
+the functions of the script into methods.]] Now I'm almost done with the
+~Dancer::Script->new->run()~ method. I've even [[https://github.com/gnusosa/Dancer/commit/0a82e94850ff3662091e727271dd9405baa88d9d][catch some calls in the
+obfuscated code]] of the script.
+
+**** What's next?
+By now, what was supposed to be done for this week is almost complete,
+the rough draft. After finishing that, I can assure that,
+adding/removing functions, and refactoring the module will come quite
+fast.
+
+To see more of what I'm doing, visit [[http://github.com/gnusosa/Dancer][my github account]].
diff --git a/gsoc/2011-05-31-project-schedule.org b/gsoc/2011-05-31-project-schedule.org
new file mode 100755
index 0000000..5b71290
--- /dev/null
+++ b/gsoc/2011-05-31-project-schedule.org
@@ -0,0 +1,67 @@
+#+title:         Project schedule
+#+date:          2011-05-31
+#+layout:        post
+#+category:      gsoc
+
+The following is a modification made by my mentors to the original
+schedule found in [[http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gnusosa/1][here]]
+
+**** Week #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: 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
+Finish successfully moving the old script intact to an object oriented
+module. Write tests for the current object oriented module.
+
+**** Week #3: 5 - 11 June
+Study =Catalyst= scripts and =Catalyst::ScriptRunner=, derive a code from
+both to merge to the project.
+
+**** Week #4: 12 - 18 June
+Write the upgrade methods and 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 an upgrade log file
+for the upgrade process for outdated Dancer setups.
+
+**** Week #7: 3 - 8 July
+Go over the tests and add any
+missing test to allow extensive coverage.
+
+**** Week #8: 10 - 16 July
+Prepare the Midterm report, describe the status of the project and
+further plans.
+
+**** Week #9: 17 - 23 July
+Document the module, and the 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.
diff --git a/gsoc/2011-05-31-status-report-week-1.org b/gsoc/2011-05-31-status-report-week-1.org
new file mode 100755
index 0000000..882052c
--- /dev/null
+++ b/gsoc/2011-05-31-status-report-week-1.org
@@ -0,0 +1,59 @@
+#+title:         Status Report For Week #1
+#+date:          2011-05-31
+#+layout:        post
+#+category:      gsoc
+
+Since I started working in the middle of the Community Bonding Period,
+there was not much to do to the module in the week #1. However, some
+progress was made with the module. For now, the module ~Script.pm~ is
+fully capable of writing a dancer app from the call of the script
+~bin/dancer~. These was the expected work for the week #1.
+
+**** What I worked on the week #1?
+Well basically, moving the functions to object-oriented methods. We
+all know that by default in almost every module, you add
+~Module->new(%args)->run;~ and the methods. From that I also moved the
+functions from ~get_*~ to ~set_*~, for example, ~get_lib_path~ to
+~set_lib_path~ in the new object constructor. You can find more detail
+in the [[https://github.com/gnusosa/Dancer/commit/e946254caa5b33cdcb75a60b34ec39ee5e3c56e8][most recent commit]] I made in [[http://github.com/gnusosa/Dancer][my github account]].
+
+**** What I learned in the week #1?
+I learned to appreciate steps and instructions, for the second time I
+screwed up my repo, and all because I thought moving and stripping
+functions would reduce work. When in reality, I was just adding more
+work and steps. Reinvention of the wheel destroys, and it takes the
+most precious hours of your day. On another side, ~git~ is the tool of
+the year for me. I love to sync and clone repositories in my two
+netbooks, any change can be updated in any local repo in matter of
+seconds. ~torvalds++~ \\
+Related to Perl code, I learned that idiomatic pragmas and other
+idiosyncrasies are great for refactoring, but not for rough drafting.
+I guess Perl sticks to the Unix philosophy point, which tell us that
+simple is better. However, I think that a more idiomatic code is more
+maintainable, but I don't want to start a debate, I just want to keep
+learning. I guess, time and work will tell. As of working habits, I
+made better use of ~perldoc~ and ~man~ for any Perl related
+documentation. I bought [[http://www.onyxneon.com/books/modern_perl/index.html][Modern Perl]] and [[http://www.effectiveperlprogramming.com/][Effective Perl Programming]],
+and both books are next to my keyboard on a daily basis. The chapter
+"Objects" in ~Modern Perl~ helped me to grasp what was essentially
+needed to migrate the functions to object methods, and adding the new
+class object. Most doubts on the topic, were later answered by
+~franck~ in the middle of my commits revisions.
+
+**** What's next?
+For week #2, the tasks are as follows:
+
+- Migrate the script to an Object Oriented module.
+- Write tests for the OO Module.
+- If needed, refactor and modify the module.
+
+From what you can read, the first point is already completed. But
+these works great for me, since it gives more time to study and learn
+from the testing settings that Dancer modules work with. I've barely
+played with tests before, and I think this is a great time to start
+working on a topic I lack knowledge of.
+
+Because the module rough draft was written in a quick matter, ~sawyer~
+decided to modify the project schedule, and add other tasks according
+to the time and the work done. You can find the new [[http://gnusosa.net/gsoc/2011/05/31/project-schedule.html][project schedule]]
+in my [[http://gnusosa.net/gsoc/][GSoC section]].
diff --git a/gsoc/2011-06-06-status-report-2.org b/gsoc/2011-06-06-status-report-2.org
new file mode 100755
index 0000000..59c74c0
--- /dev/null
+++ b/gsoc/2011-06-06-status-report-2.org
@@ -0,0 +1,123 @@
+#+title:         Status Report for Week #2
+#+date:          2011-06-06
+#+layout:        post
+#+category:      gsoc
+
+This week was more relaxed and fun, since my mentors, =sawyer= &
+=franck=, helped in the process of reviewing my commits and every bad
+code snippet that I unintentionally commit. As well, it was a week
+when I decided to take on other activities, and get off the grid for a
+while. To disconnect helps to review all the most random ideas and
+actions of your day. This is included in the student guidelines of the
+GSoC as a good practice. So just like =sawyer= told me, relax. That's
+the lesson of this week for me.
+
+*** What I worked on week #2
+I finished the OO module of the creation of a Dancer app. I finally
+finished successfully moving the old script intact to an object
+oriented module. Yes, just like the project schedule suggests, the
+module is done, for now. So now more of a rough draft, it's an actual
+working OO module, that writes, modifies, and asks about writing on
+top of existing dirs/files on the current path. As it was expect from
+the old script the module does verbose the help POD and the version of
+the local installed Dancer setup, and keeps track of the most current
+Dancer version on CPAN.
+
+After that, I started working on the tests. This was my real
+challenge, but not so much on the side of the technical detail of the
+methods from Test::More, and what is expect from each testing method.
+The real work for me, was the dealt of time you invest thinking about
+what to test. So I wrote tests for the =new= method which declares the
+class and returns itself. Inside of that method, you can find =_set_*=
+methods that establish the working global variables of the module. I
+added tests to those, and several other methods which returned lists
+and objects. Along to that, I added string tests for this returned
+list, and other tests for text.
+
+
+*** What I learned in the week #2?
+Well pretty much everything was related to tests, and basically, it
+comes down to when to or what to implement a test to. So what to test?
+Basically:
+
+- Anything that can return a condition in binary.
+- Anything that is an object.
+- Anything that is identified by a keyword or string.
+- Anything that access a file, read or write.
+- Anything that returns a scalar that can be compared.
+
+I used the standard module for any unit-test in Perl, [[http://search.cpan.org/~mschwern/Test-Simple-2.00_07/lib/Test/More.pm][Test::More]].
+For my tests I only used the following from =Test::More=:
+
+#+BEGIN_SRC perl
+#define the tests
+use Test::More tests => n;
+
+use_ok( 'Some::Module' ); #it loads?
+
+#for definitions, scalars and strings comparisons.
+ok($got eq $expected, $test_name);
+
+is  ($got, $expected, $test_name);
+isnt($got, $expected, $test_name);
+
+#for object, and classes testing.
+can_ok($module, @methods);
+isa_ok($object, $class);
+#+END_SRC
+
+Most of the tests I wrote were thought on the functionality of the
+module. That's why I didn't use =Dancer::Test= which is great for
+testing a functional Dancer app, but not for the module that creates
+the app. Following that guideline, I find that testing something you
+don't use is not quite common. It is always noted to be done on an
+specific issue. So I took this as the real guideline of all I did, and
+is something I took from =Modern Perl=:
+
+- Each =.t= file should correspond to a =.pm= file.
+- Each =.t= file should correspond to a feature.
+
+So what you get from the last, a pretty solid guideline for your test
+organization, and after you've done all that work you can merge every
+=.t= file into one big file, for example =01-basic.t= in common =CPAN=
+modules.
+
+As an example of one of my tests. Here is =new.t=:
+
+#+BEGIN_SRC perl
+use strict;
+use warnings;
+use Test::More tests => 4;
+use Dancer::Script;
+
+use_ok( 'Dancer::Script' );
+
+my $script = Dancer::Script->new(
+appname => 'Hello', path => '.', check_version => '1');
+
+isa_ok( $script, 'Dancer::Script', );
+can_ok( $script, 'parse_opts',
+ 'validate_app_name', );
+can_ok( $script, '_set_application_path',
+'_set_script_path', '_set_lib_path', );
+#+END_SRC
+
+*** What's next?
+For week #3, the following are the key points:
+
+- Study =Catalyst= scripts and =Catalyst::ScriptRunner=.
+- Derive a code from both to merge to the project.
+
+The first point won't be that hard, since I took the time to study
+both Script modules, and work on something that might work, at least
+model wise. It will depend on what my mentors think is best for the
+project. On the second point, I find it a bit difficult, but since
+=Dancer::Script= is fully working, it might help as a reference to
+compare with Catalyst scripts.
+
+On another note, everybody seemed to be relaxing for the weekend, or
+working on another stuff that was not related to GSoC. I guess
+everybody needs some time off the grid. Will see how this works in
+week #3 for all the mentors and the students. Let's hope that
+everybody can have some time for their own work and activities.
+
diff --git a/gsoc/2011-06-14-status-report-3.org b/gsoc/2011-06-14-status-report-3.org
new file mode 100755
index 0000000..52e09bb
--- /dev/null
+++ b/gsoc/2011-06-14-status-report-3.org
@@ -0,0 +1,64 @@
+#+title:         Status Report for Week #3
+#+date:          2011-06-14
+#+layout:        post
+#+category:      gsoc
+
+Well on week #3, I wasn't able to do much work due to the schoolwork
+load of this month. Just like every other participant of GSoC, I
+dedicated half of my days to studying and writing to prepare for my
+finals. Aside from that, I could review the ideas related to the
+upgrade/update process on the project. I met with my mentors to
+sync-up with current events related to that week work, but since not
+much work had been done on the repo, it seemed unnecessary.
+
+*** What I worked on week #2
+For week #3, most of my time was invested in investigating which
+upgrade/update process would be better for the project. It's
+stipulated has the work for week #4, but before that I did the
+research based on =Catalyst::Scripts*, catalyst.pl, Catalyst::Helper=.
+So what my mentors and me decided, was to mimic the scripts
+organization from Catalyst. From [[http://beta.metacpan.org/module/catalyst][catatyst.pl]], one feature did made me
+think of the possibility of implementing such in our script
+=bin/dancer=. That feature works around writing [[http://beta.metacpan.org/module/catalyst#NOTE][new updated files with
+the extension .new]], that way the user can still have its old files,
+and chose which solution is best, or start hacking the migration of
+such deprecated functions, method, file into a solution the user might
+find best fit for his application.
+
+Dancer's developers and contributors write a lot of code that works
+around with what we call, "automagically". Which is what I was looking
+for my project, an automatic yet not so stressful way to
+upgrade/update outdated files, and that works for almost every
+situation. That way is a magical and automatic solution. What I
+decided to go for as of this moment of the project, is to use or write
+an algorithm that would parse each file in the lib, the config file,
+and the environments files, to look for outdated subs and functions.
+So this is where the upgrade/update process stands as of right now. So
+for a start we decided, that I could use a module, and if that module
+seems solid and lean, we might stick to it. But since Dancer depends
+on very basic modules, I don't want to add more to this well thought
+line of decisions of what works and what doesn't for Dancer. However,
+=sawyer= suggested that I could write the portion that we need for the
+upgrade/update process.
+
+So if you know of such module, or you have worked on string-to-string
+comparison with a solid module, [[mailto:gnusosa@gnusosa.net][please let me know]]. Suggestions are
+welcome, and they really help. =:)=
+
+*** What's next?
+For week #4, the following must be accomplished:
+
+- Write the upgrade/update methods.
+- Write the tests for the upgrade/updates methods.
+
+This means I will be back on writing code to =Dancer::Script= and add
+a quick tweak to =bin/dancer= script. Also, to work again with tests,
+is what keeps me more motivated, I really like the whole test then
+write code as you go workflow, and I would like to try it more after
+GSoC is over. But for that I will need a solid base with testing. So
+more code, more tests, more coffee. =:)=
+
+So to every mentor and participant, have a great week #4, and to
+everybody still working they way through finals, best of luck and give
+yourself the time to relax. Cheers.
+
diff --git a/gsoc/2011-06-21-status-report-4.org b/gsoc/2011-06-21-status-report-4.org
new file mode 100755
index 0000000..26d99b1
--- /dev/null
+++ b/gsoc/2011-06-21-status-report-4.org
@@ -0,0 +1,81 @@
+#+title:         Status Report for Week #4
+#+date:          2011-06-21
+#+layout:        post
+#+category:      gsoc
+
+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][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:
+
+#+BEGIN_SRC perl
+#!/usr/bin/env perl
+use Dancer::Script;
+
+Dancer::Script->run_scaffold($method);
+#+END_SRC
+
+Where =$method= can be cgi for =CGI=, and fcgi for =FastCGI=. The last
+was influenced by [[http://beta.metacpan.org/module/Catalyst::ScriptRunner#___pod][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 [[http://plackperl.org/][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 [[http://search.cpan.org/~bobtfish/][Tomas Doran]] for writing
+the =Catalyst::ScriptRole= and =Catalyst::ScriptRunner= modules.
+(Please do correct me if I'm wrong.)
diff --git a/gsoc/2011-06-29-status-report-5.org b/gsoc/2011-06-29-status-report-5.org
new file mode 100755
index 0000000..ce563f4
--- /dev/null
+++ b/gsoc/2011-06-29-status-report-5.org
@@ -0,0 +1,64 @@
+#+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.
diff --git a/gsoc/2011-06-30-status-report-6.org b/gsoc/2011-06-30-status-report-6.org
new file mode 100755
index 0000000..2a46755
--- /dev/null
+++ b/gsoc/2011-06-30-status-report-6.org
@@ -0,0 +1,54 @@
+#+title:         Status Report for Week #6
+#+date:          2011-07-06
+#+layout:        post
+#+category:      gsoc
+
+For week #6, The main work was done around the debugging log. At
+first, the main goal for week #6 was to reformat the way the output
+log of the current Script.pm module was working. I worked on the way
+it was outputting the writing process and such, and also on writing a
+log output into a file. By the time I met with my mentor, Franck. He
+noted that the file output wasn't going to be needed as much as we
+thought it would be, and advise to move from the old good ol' print
+output and use other method that doesn't require a new module to be
+added to the long list of imports that the module already makes use
+of.
+
+*** What I worked on Week #6
+Most of the output was done with several print outs with good ol'
+[[http://perldoc.perl.org/functions/print.html][print]], this left the message completely out-of-context, a needless
+output. I first commited an extension of the last behavior, which seem
+to work and also wrote the output to a file called 'built.log'. The
+commit took out the point of writing the output log to a file like
+noted in the project schedule. But IMHO, the commit wasn't as solid as
+I liked it to be. It was simple output with print which I didn't seem
+right. Here is the link to the [[https://github.com/gnusosa/Dancer/commit/0dd96d5a8733661236e69ad118fe534d37139590][commit]].
+
+After that, =franck= reviewed the commit, and told me to focus on
+using =Dancer::Logger=. So instead of using good ol' =print=, I should
+use the logger that Dancer come with. After checking it out with
+Franck, the output log as a file wasn't necessary at the moment. So I
+commited with a modified logic based on the writes stages of
+=Script.pm=. Here is the [[https://github.com/gnusosa/Dancer/commit/8500da87ad000cc5687bca5f457ceee428efba76][commit]].
+
+Before that, my approach was to use Log4perl, but as =franck= noted,
+it was more than what we needed. =debug= method from Dancer::Logger
+was sufficient to write to the output we want it, without rewriting
+anything else.
+
+*** What's next?
+For week #7, the following are the key points:
+
+        - Add more tests.
+        - Go over the current tests.
+        - Check for any other feature to add.
+
+For week #7, it's mostly to check on what other work and commits can
+be added before the midterm report. Week #8 will be about the midterm
+report, and somewhat a deal of work same as week #7.
+
+So expect reports for week #7 and week #8 more related with the
+meetings of my mentors & I. They would be good weeks to manage other
+fixes, I might missed, or any other request that my mentors might
+have.
+
diff --git a/gsoc/2011-07-12-status-report-7.org b/gsoc/2011-07-12-status-report-7.org
new file mode 100755
index 0000000..6b0d9fb
--- /dev/null
+++ b/gsoc/2011-07-12-status-report-7.org
@@ -0,0 +1,69 @@
+#+title:         Status Report for Week #7
+#+date:          2011-07-12
+#+layout:        post
+#+category:      gsoc
+
+Week #7 like the last week was about testing, but to be more specific,
+to test that the module does work in multiple platforms. But I also
+ended adding another test. For several days, I met with my mentors to
+discuss the future of the module, and to reply to my suggestions. From
+the last week, as a suggestion from Franck, I removed the 'build.log'
+functionality. Also as a suggestion by Sawyer, I renamed ='built.log'=
+to =build.log=. This will be a future implementation. I also checked
+for changes in the current =script/dancer= from Dancer's HEAD github
+repo. There was no reasonable change to add to =Script.pm=, although
+there was a change in the lib file path, that I added in a commit in
+the first weeks.
+
+More than adding, more tests, the work I did was directed to the
+maintaining of the module itself. How it run, what did it run, and how
+other tests worked with the script. I even ended up changing a test in
+the =19_dancer= script dir.
+
+*** What I worked on Week #7
+For Week #7, I added a log output using =Dancer::Logger=, a modified
+version of the one I wrote in week #6. After that I added the output
+log test file called =05_output.t=, made it work and test it first on
+a Mac. Here is the [[https://github.com/gnusosa/Dancer/commit/8a7b2867632c09e5f04c03b8eb3db5c207970549][commit]].
+
+After that, I added several missing =debug= methods to Script.pm, and
+worked around another missing log output. Here is [[https://github.com/gnusosa/Dancer/commit/708491d84d5b0d29cddea2eec397dee0171312fc][the commit.]]
+
+For all that, I was constantly testing the files in =t= dir.
+Specially, the ones in =19_dancer/object=, the tests related to
+Script.pm. For all of them, I tried installing Dancer from my working
+repo and testing everything. I tested in Windows XP, Mac OS X ([[https://gist.github.com/1077586][x86]] &
+[[https://gist.github.com/1077585][PPC]]), and [[https://gist.github.com/1077583][Debian]]. In each platform, all the =object= tests passed,
+however, the test 01_script.t kept on failing every single time. This
+was the longest problem I had worked on, it took me day and a half to
+find out that it was as simple as removing a number. The problem was
+that the new console log out printed its messages to level 1 like
+=1>=, therefore, the test was to look for a correct string in =2>= not
+in level 1. After a disappointing run against my debugging skills, I
+finally commited the quick fix, that ended with that. Here is [[https://github.com/gnusosa/Dancer/commit/66eefa28aac020ea27d0c6b1db8275517c9f8a8d][the commit]].
+
+*** What's next?
+For week #7, the following are the key points:
+
+- Prepare the Midterm report.
+- Code review, if possible.
+- Describe the status of the project and further plans.
+
+So now that the basic layout is solid, we can add more features, and
+work on other details. For instance, now that Dancer is more complex,
+and full of new ways to output data. Instead, of scaffolding a single
+route into =MyApp.pm=, I think it would be wise to add an example of
+several output ways that Dancer offers. This will be the ones I always
+see to be more requested in the Dancer's IRC channel #dancer @
+irc.perl.org. For example, the hooks, and how to deploy files with
+send_file or the recent send_data. :)
+
+There is also a need of approval from my mentors, Franck & Sawyer, but
+for other matters, like adding a build log, working with more tests,
+rebasing, and such. I hope that the code review can help and work for
+that.
+
+Good luck and the best of the cheers to everybody in the midterm
+period. This goes for both, mentors & students.
+
+
diff --git a/gsoc/2011-07-20-midterm-evaluations.org b/gsoc/2011-07-20-midterm-evaluations.org
new file mode 100755
index 0000000..e4cff03
--- /dev/null
+++ b/gsoc/2011-07-20-midterm-evaluations.org
@@ -0,0 +1,41 @@
+#+title:         Midterm Evaluations
+#+date:          2011-07-20
+#+layout:        post
+#+category:      gsoc
+
+At the day July 15, I received an email from The Google Open Source
+Programs Team stating that I successfully passed the Midterm
+Evaluations. This means that I passed the first evaluation and part of
+Google Summer of Code 2011 program.
+
+I know this a late news since it's already July 20th, but I didn't had
+much time to write due to other personal issues with regards of my
+move away from my hometown.
+
+I want to give my sincere appreciation to everybody that helped me in
+the first part, cheered me up, and to everybody that was involved with
+my work. This is of course to my mentors, [[http://lumberjaph.net/][Franck Cuny]] and [[http://blogs.perl.org/users/sawyer_x/][Sawyer X]],
+the Dancer core team ([[http://ambs.perl-hackers.net/][ambs]], [[http://www.preshweb.co.uk/][bigpresh]], [[http://www.sukria.net/][sukria]], [[http://damien.krotkine.com/][dams]]), [[http://www.perlfoundation.org/][the Perl
+Foundation]] people: rafl and mdk. Also [[http://msud.pl/][Hobbestigrou]] for his sincere
+comments and chats, that have occur from time to time.
+
+Now for the second part of the program, my routine is more
+established, and I know how my work flow is. I can quickly catch-up
+with work if I get behind schedule, and work around several instances
+of issues.
+
+But more than that, the first part gave me a glance of how the
+community works, how everybody works with each other, and how
+everything must be documented for further reference. Now, I can truly
+say that more than the community, the whole project is about hard
+work, spending time for any PR, issue or feature. It's a great
+commitment to the community. The time every developer adds to the
+project, and helping out is the soul of the project; every
+contribution be it, helping someone on the #dancer channel or adding a
+really impressive PR is what thrives this project to the successful
+software that Dancer is.
+
+So for everybody, that helps me, helps others, and the ones that help
+not only on Dancer but other fields related to Perl and FOSS, thanks
+for your time.
+
diff --git a/gsoc/2011-07-20-status-report-8.org b/gsoc/2011-07-20-status-report-8.org
new file mode 100755
index 0000000..4c78f06
--- /dev/null
+++ b/gsoc/2011-07-20-status-report-8.org
@@ -0,0 +1,76 @@
+#+title:         Status Report for Week #8
+#+date:          2011-07-20
+#+layout:        post
+#+category:      gsoc
+
+Week #8 was all about code review and meeting with my mentors, not
+that we met a whole lot, but the few huddles were about code review
+and future tasks. I met with Franck, he tested the few tests that I
+work with. Found an error, and quickly fixed with a single string.
+After that I added to [[https://github.com/gnusosa/Dancer/commit/50e3c883709f60a14b21311e4d0c027428262dde][a single commit]]. That did the fix. The
+conversation moved on to future tasks. As of first feature, I will not
+add more routes to =MyApp.pm= that is scaffolded with =script/dancer=.
+This will only add more lines for the user to delete, and make more
+tedious starting to work on writing more code. After all that's why
+there is a lot of documentation in [[http://search.cpan.org/dist/Dancer/lib/Dancer/Cookbook.pod][=Dancer::Cookbook=]] and others. I
+would basically end-up reinventing the wheel. We don't want that.
+
+From that conversation, Franck established that we should add a better
+verbose output of the module. We are moving to a better format by
+using =Dancer::Logger::Abstract= and formatted to a better output.
+
+You can read the whole conversation at this [[https://gist.github.com/1095775][gist]].
+
+*** What I worked on Week #8
+I worked on rebasing my current [[https://github.com/gnusosa/Dancer/tree/devel][devel branch]] from my [[https://github.com/gnusosa/Dancer][Dancer repo]] to
+the [[https://github.com/sukria/Dancer][current devel repo in sukrias Dancer repo]] at github. At which I
+failed to rebase. But this was due to the fact that I kept writing
+code without pulling from the base branch in Dancer's github repo. But
+this would be quite clear to be fixed in time, since =Dancer::Script=
+was written without anything recently added to the new releases nor
+the test file for this.
+
+For that week, my work was also dedicated to set the format for
+=Dancer::Logger::Abstract=. I went with "%L> %m" for the format in
+which, I couldn't find anything new, but just commit without thinking
+about it. I will rewrite this, based on my current work for
+=Dancer::Logger=.
+
+So more of the work on writing code, it was more of planning what was
+going to happen in week #9. After all the schedule marked for us to
+prepare for the midterm reports and work on planning new
+features/changes or fixes. Basically, that's what I did when I met
+with my mentors.
+
+I did run =perltidy= for my current repo that was not correctly
+formatted. But as Franck noted, my current branch =refactoring/script=
+still had =.perltidyrc= which was a huge help for the actual
+re-formatting of each file.
+
+Franck, added a new task for the week #9, which is move
+=Dancer::Script= to use =Dancer::Object=. A module which will make
+more elegant our =$self= calls. For example, moving from doing
+=$self->{appname}= you could do =$self->appname= with that module.
+Which is totally more elegant.
+
+*** What's next?
+For week #9, the following are the key points:
+
+- Move to =Dancer::Object=.
+- Write the documentation for the module.
+- Rebase up-to-date and test.
+- Re-format everything with =perltidy=.
+
+I can't wait to start writing the documentation, and how it will shape
+off is what I'm more excited about. There isn't going to be much
+content, but this will be new to me, since somebody will finally
+critique my content.
+
+Now that the midterm evaluations are over, I'm more calm and ready to
+work. I can say that it was a heck of nervous feelings to me. I've
+never felt so competent at my work, but then again a lot of people
+that I mention in this [[http://gnusosa.net/gsoc/2011/07/20/midterm-evaluations.html][post]], are the ones that helped me pass through
+this last weeks rumble.
+
+Congratulations to every mentor and student that pass their midterms
+successfully.
diff --git a/gsoc/2011-07-27-current-state-dancer-script.org b/gsoc/2011-07-27-current-state-dancer-script.org
new file mode 100755
index 0000000..579f09f
--- /dev/null
+++ b/gsoc/2011-07-27-current-state-dancer-script.org
@@ -0,0 +1,118 @@
+#+title:         Current State of Dancer::Script
+#+date:          2011-07-27
+#+layout:        post
+#+category:      gsoc
+
+Now that more than half of the program of GSoC has passed, Franck
+asked for me to do a write-up of my work, so everybody can check it
+and evaluate to see if it can be merged with the current devel repo of
+Dancer.
+
+You can check my whole work at [[https://github.com/gnusosa/Dancer][my repo in github]], and if you care to
+make changes, just PR at will *:)*
+
+*** Introducing Dancer::Script
+Dancer::Script module is a mash-up between the old script/dancer
+utility that we currently use to scaffold every new Dancer application
+and some other content that I added with management from Sawyer and
+Franck.
+
+Dancer::Script makes use of Dancer::Object and Dancer::Logger, the
+last so we can get better log outputs from the whole scaffolding
+process
+
+*** So what happened to =script/dancer= executable?
+
+Well, it became a 8 lines executables that only calls =Dancer::Script=
+*:D*
+
+#+begin_src perl
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Dancer::Script;
+
+Dancer::Script->init->run;
+#+end_src
+
+In the same matter, I modified =dispatch.cgi= and =dispatch.fcgi= so
+it will call =Dancer::Script=.
+
+=dispatch.fcgi=
+
+#+begin_src perl
+#!/usr/bin/env perl
+
+use Dancer::Script;
+
+Dancer::Script->run_scaffold('fcgi');
+#+end_src
+
+=Dancer::Script::run_scaffold_cgi= and
+=Dancer::Script::run_scaffold_fcgi= runs the code for the deployment
+of =CGI= and =FastCGI=. This way, every new change in Plack/PSGI that
+the team encounters and wish to add, can be directly added to
+=Dancer::Script= without the need of scaffolding a new Dancer
+application in every update that is done to Dancer. Since there are
+common releases and quick-updates in between weeks, I believe that
+this is a justified method.
+
+*** Verbose output
+Now that =Dancer::Script= makes use of =Dancer::Logger=, the following
+methods replaced good ol' =print=, the methods =error()= and
+=debug()=.
+
+So if we do =dancer -a Hello::World= we get a pretty output like the
+following:
+
+#+begin_src sh
+Carlos-Computer:test $ dancer -a Hello::World
+debug> Writing directory: Hello-World
+debug> Successfully wrote the directory: Hello-World
+debug> Writing directory: Hello-World/bin
+debug> Successfully wrote the directory: Hello-World/bin
+debug> Writing file: Hello-World/bin/app.pl
+debug> Successfully wrote: Hello-World/bin/app.pl
+.............
+#+end_src
+
+The same goes for =error()=
+
+#+begin_src sh
+Carlos-Computer:test $ dancer -a 1World
+error> Error: Invalid application name.
+error> Application names must not contain colons, dots, hyphens or start with a number.
+Carlos-Computer:test $
+#+end_src
+
+*** Is that all?
+Well, feature-wise speaking it is. But the other good part is that
+=Dancer::Script= is fully an object module that can be run without
+=script/dancer=. For example:
+
+#+begin_src perl
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Dancer::Script;
+
+Dancer::Script->init(appname => 'Hello::World', path => '/home/gnusosa/')->run;
+#+end_src
+
+So if you need to do something really specific with =Dancer::Script=,
+you don't need to call =script/dancer= and run your automagically
+work.
+
+*** But that's not all!
+Now that we have =Dancer::Script=, it will allow for future
+subclassing for extra features that anybody could write themselves.
+We'll also be able to easily add plugins so we could have flavors of
+=Dancer::Script=. Just like the ones that create a =Dist::Zilla= based
+dist or a Dancer plugin dist, etc... A lot of possibilities. *:)*
+
+This is the current state of my work, I hope you like it, and expect
+feedback of all kind. Thanks for your time. =:)=
diff --git a/gsoc/2011-07-28-status-report-9.org b/gsoc/2011-07-28-status-report-9.org
new file mode 100755
index 0000000..6a8314e
--- /dev/null
+++ b/gsoc/2011-07-28-status-report-9.org
@@ -0,0 +1,70 @@
+#+title:         Status Report for Week #9
+#+date:          2011-07-28
+#+layout:        post
+#+category:      gsoc
+
+For week #9, I met for a few days with my mentors, but didn't set new
+tasks, it was mostly code review. They did help me out with the
+migration of =Dancer::Script= to =Dancer::Object=. After that I added
+some other details to my commits, modifications that my mentors had
+been pushing since the last weeks. From that most of my time was taken
+by handling the module with =Dancer::Object=. After that, tests and
+more tests were part of the whole week. It was really more about me
+studying what I was going to do than actually writing code. I did
+format the log outputs in the module and added new error messages.
+
+*** What I worked on Week #9
+I completely moved everything to =Dancer::Object=, so not only did we
+make use of =Dancer::Logger=, but also take more on =Dancer= modules,
+instead of adding more dependencies. So what does this means? Well,
+that you go from using this:
+
+#+begin_src perl
+$self->{appname} = $appname;
+#+end_src
+
+To using this:
+
+#+begin_src perl
+$self->appname($appname);
+#+end_src
+
+This makes the reading/writing more elegant, and you make use of less
+lines per action or logic block. You can find more about that
+modification in this [[https://github.com/gnusosa/Dancer/commit/ff85edfc8707645d04679d492ad51c426df985c5][commit]].
+
+While I was at this I used =perltidy= to indent and format correctly
+my files, so I could present =Dancer::Script= to the core team of
+=Dancer=. So the end-of-lines, tabs, and spaces that my editor was
+doing, are no longer in my files.
+
+While I was modifying stuff related to the module, Franck ask me to
+modify all the =subs= naming into =private methods=. The methods moved
+from =templates= to =_templates=, and so forth in the file. The
+following [[https://github.com/gnusosa/Dancer/commit/f75f9605b011564070e6032ec027f84ca6b3ceb6][commit]] shows the changes.
+
+For last, I added the new error outputs using the method =error()=
+from =Dancer::Logger::Abstract=. Since I was already using =debug=
+method, it felt right to also make use of =error()=. You can find
+those lines changes in this [[https://github.com/gnusosa/Dancer/commit/8b57c8b258eed80f6d502bf8e88e62a5cba99838][commit]].
+
+*** What's next?
+For week #10, the following are the key points:
+
+- Finish and polish the documentation for the module.
+- Fix new errors in several tests.
+- Write a code hand-out of the plugins implementation.
+- Add detailed tests to each plugin function.
+
+So this week's work is more than I thought, but I'm happy because of
+the progress I've made without much guidance for week #9. For week
+#10, I'm happy to say that this would take me all the week, including
+the weekend. I don't want to get stuck in the most important thing:
+the documentation.
+
+On another note, I introduced =Dancer::Script= to the Dancer's core
+development team in the following post I did in the middle of the
+week. Here is the [[http://gnusosa.net/gsoc/2011/07/27/current-state-dancer-script.html][post]]. I had a positive feedback, so thanks to
+everyone that read my post.
+
+Cheers to everybody!
diff --git a/gsoc/2011-08-04-status-report-10.org b/gsoc/2011-08-04-status-report-10.org
new file mode 100755
index 0000000..c4ea935
--- /dev/null
+++ b/gsoc/2011-08-04-status-report-10.org
@@ -0,0 +1,42 @@
+#+title:         Status Report for Week #10
+#+date:          2011-08-04
+#+layout:        post
+#+category:      gsoc
+
+Week #10 was actually quite fun. I added =POD= documentation to
+=Dancer::Script=, fixed some tests that were broken by the move to
+=Dancer::Object=, and also fixed typos and other stuff.
+
+So what was the fun part? Particularly, studying everybody else
+documentation in the =Dancer::Cookbook=, I still don't think that my
+documentation is the best, but far from very-basic is what I was
+trying to achieve.
+
+I did meet with my mentors to discuss the work of week #10, which was
+really not very detailed in the project schedule. It was about dealing
+with the plugin reimplementation of =Dancer::Plugin= to
+=Dancer::Script=. After a couple of questions, we decided that it
+would be best to see how other web frameworks handle their files.
+
+*** What I worked on Week #10
+My whole work for that week was to achieve better results for the =t=
+test files. So after commiting and commiting, nothing worked, until I
+got to the point that I had to review every test. So the answer of
+every issue was the fact that we moved to =Dancer::Object=. Here is
+[[https://github.com/gnusosa/Dancer/commit/4e047458d57e6b282418cb6189cbf306954167f6][the commit for the tests files]].
+
+I also took a look to the documentation in other modules, and added to
+the module my version of what I think is correct for =Dancer::Script=.
+You can find the documentation in [[https://github.com/gnusosa/Dancer/commit/6fd70b55bcaa2b7d017b2fcf29809da6181a7bfe][this commit]] and in [[https://github.com/gnusosa/Dancer/commit/b147630522fe23d9986b0f7bbdbfed7162b96e4b][this commit]].
+
+*** What's next?
+
+- Add a better documentation.
+- Look for a new method to store template files.
+- Implement the new method to store template files.
+- Add tests for the documentation (if possible).
+
+For week #11, it's mostly study and implement several new ideas. Just
+like in any other features, Dancer is gaining from the knowledge and
+methods that other frameworks have successfully applied. One phrases
+comes to mind, "standing on the shoulders of giants..."
diff --git a/gsoc/2011-08-22-conclusion-report.org b/gsoc/2011-08-22-conclusion-report.org
new file mode 100755
index 0000000..3b94eae
--- /dev/null
+++ b/gsoc/2011-08-22-conclusion-report.org
@@ -0,0 +1,37 @@
+#+title:         Concluding Status Report
+#+date:          2011-08-22
+#+layout:        post
+#+category:      gsoc
+
+Well, after my last =Status Report=, my project proposal was
+completed, at least, that was what my mentors stated. Therefore, my
+mentors suggested to stop coding the last feature that we agreed on,
+the external templates for the files. So my mentors decided that I
+should stop, on the last commit, and rebase to the commit before the
+last commit. That commit before the last head in the repo, will be the
+one to be packed and uploaded to the GSoC website and repo.
+
+=Dancer::Script= is now a complete OO module, that makes use of the
+same dependencies that Dancer calls for. With the inclusion of
+=Dancer::Object= to the module, there is the capability of rolling
+their own versions of the scaffolding module, just like =Dist::Zilla=
+dists. From that, the module adds several functions for any Dancer
+deployment, and works better without the need of re-scaffolding
+another app each Dancer update.
+
+I wrote a post with a better description of =Dancer::Script=. You can
+find it [[http://gnusosa.net/gsoc/2011/07/27/current-state-dancer-script.html][here]].
+
+In conclusion, now that the project is complete, I'm more than
+grateful for the opportunity. To work with my mentors, Franck and
+Sawyer, was really a great learning experience, and the community was
+really helpful. More than helping out, I felt like part of the team.
+For that, I will continue to contribute to Dancer and other Perl web
+frameworks, and probably move to other fields that Perl is useful in.
+
+Aside from that, I will apply again, and hope to work for the The Perl
+Foundation again in the following GSoC, probably for the Dancer web
+framework again. Let's keep this going =:)=
+
+See you around on IRC, any Perl related site, or mailing list. I hope
+to work with everyone again.