Secrets of learning Moodle development

At a moodle developer meeting recently, some developers were asking if a mentoring scheme could be started up for new developers who wish to get into moodle development. Unfortunately, there just aren’t enough hands on deck with time to manage to do the mentoring for something like this, despite the obvious long term benefits.

I suspect we will always be on an uphill battle to improve our documentation and resources (like many things in life, documentation isn’t very exciting or give instant payoffs to our users), but there are some resources which should be very useful to new developers: http://dev.moodle.org, Moodle Docs and of course the forums of http://moodle.org.

When I think back to how I have learnt about various aspects of moodle development i’ve not really used many of those resources very much, instead i’ve been lead by the constructivist approach! My journey into moodle development started in MDL-6784, this was my second bug report, first patch and first accepted patch into moodle! Since this first patch i’ve reported/fixed/watched/contributed to many many moodle bugs and I think this is my secret to moodle development!

Of course this is really no secret at all, the code and bugs are open for everyone to see. But I believe that spending time finding, reproducing and resolving bug reports gives new developers an invaluable insight into various aspects - which libraries do what, what are the caeats of x, how to fix y and where to go looking for future bugs! By watching bug reports, seeing comments, reviewing patches and fixes commited slowly your knowledge of moodle wil become massive, despite a lack of dedicated mentor!

I do have a few general tips for moodle debugging which I i’d like to share (and apologise as they feel ‘obvious’ to me)!

• You’ve set debugging to DEBUG_DEVELOPER, right?!
• print_object() is basically print_r with whitespace and I use it at least 1000 times a day[1]. Its not just for objects ;-) Print statement debugging might not be sexy but its essential and useful
• debugging() prints a stack trace - why wouldn’t you use it!
• grep backwards for lang strings! (grep ‘my error message’, find the lang string name (myerrormessage) and then grep for that)
• I die() lots.
• We have CVS history and bug numbers for a reason! Look at CVS history of a file and bug numbers/linked issues!
• Keeping up to speed with CVS history is a really useful exercise, if time consuming

I often wonder if I would still be in moodleland if my first patch was not reviewed as speedily as it was, I think probably not. In which case how do we ensure potential contributors such as myself don’t get lost in our workloads and we encourage new contributors!? Its interesting to consider.

If you are a new contributor please don’t be put off by lack of review, pester us and ensure your work is reviewed because moodle is really great place to work! You could look at some other bugs while you are waiting ;-) I’m off hoidaying - see you all soon!

[1] I also exaggerate 100s of times a day too.