Added gsoc entries

1 files changed, 123 insertions, 0 deletions

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