Community Bonding Period
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 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 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 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.
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 my github account.