diff options
Diffstat (limited to 'gsoc/2011-06-14-status-report-3.org')
| -rwxr-xr-x | gsoc/2011-06-14-status-report-3.org | 64 |
1 files changed, 64 insertions, 0 deletions
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. + |