The 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 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
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
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,
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 devel branch
at my github repo.)
Thinking ahead of the schedule, I ended up messing
Dancer::FileUtils . From that,
franck added new steps and worked with me around the
following steps, and how-to follow up the proposal schedule.
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 migrating
the functions of the script into methods. Now I’m almost done with the
Dancer::Script->new->run() method. I’ve even catch some calls in the
obfuscated code of the script.
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 my github account.