From a2dc4200acf469a05f9f028439ffdb2c6180d3d9 Mon Sep 17 00:00:00 2001 From: Carlos Sosa Date: Thu, 15 Aug 2019 22:15:44 -0700 Subject: Added gsoc entries --- gsoc/2011-05-24-bonding-period.org | 78 +++++++++++++++ gsoc/2011-05-31-project-schedule.org | 67 +++++++++++++ gsoc/2011-05-31-status-report-week-1.org | 59 ++++++++++++ gsoc/2011-06-06-status-report-2.org | 123 ++++++++++++++++++++++++ gsoc/2011-06-14-status-report-3.org | 64 ++++++++++++ gsoc/2011-06-21-status-report-4.org | 81 ++++++++++++++++ gsoc/2011-06-29-status-report-5.org | 64 ++++++++++++ gsoc/2011-06-30-status-report-6.org | 54 +++++++++++ gsoc/2011-07-12-status-report-7.org | 69 +++++++++++++ gsoc/2011-07-20-midterm-evaluations.org | 41 ++++++++ gsoc/2011-07-20-status-report-8.org | 76 +++++++++++++++ gsoc/2011-07-27-current-state-dancer-script.org | 118 +++++++++++++++++++++++ gsoc/2011-07-28-status-report-9.org | 70 ++++++++++++++ gsoc/2011-08-04-status-report-10.org | 42 ++++++++ gsoc/2011-08-22-conclusion-report.org | 37 +++++++ 15 files changed, 1043 insertions(+) create mode 100755 gsoc/2011-05-24-bonding-period.org create mode 100755 gsoc/2011-05-31-project-schedule.org create mode 100755 gsoc/2011-05-31-status-report-week-1.org create mode 100755 gsoc/2011-06-06-status-report-2.org create mode 100755 gsoc/2011-06-14-status-report-3.org create mode 100755 gsoc/2011-06-21-status-report-4.org create mode 100755 gsoc/2011-06-29-status-report-5.org create mode 100755 gsoc/2011-06-30-status-report-6.org create mode 100755 gsoc/2011-07-12-status-report-7.org create mode 100755 gsoc/2011-07-20-midterm-evaluations.org create mode 100755 gsoc/2011-07-20-status-report-8.org create mode 100755 gsoc/2011-07-27-current-state-dancer-script.org create mode 100755 gsoc/2011-07-28-status-report-9.org create mode 100755 gsoc/2011-08-04-status-report-10.org create mode 100755 gsoc/2011-08-22-conclusion-report.org 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. -- cgit v1.3-2-g0d8e