[Dancer-users] Dancer::GSoC Status Report for Week #3

[Carlos Ivan Sosa]

I know that Franck Cuny as been forwarding my status reports, but when
ever I can
I will post them to the list. If you feel like reading any other stuff
related to my project,
you can find all my posts in http://log.gnusosa.net/code/gsoc

Suggestions, questions and comments are welcomed. Thanks. :)

# The format continues as last time. You can access the HTML
# formatted version of this text going to
http://log.gnusosa.net/code/gsoc/status-report-3

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 catatyst.pl, one feature did made me
think of the possibility of implementing such in our script bin/
dancer. That feature works around writing new updated files with the
ending .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, 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.