Developer Module

Developer Module

by Colin Chambers -
Number of replies: 15
I've been working on the Moodle project at the Open University since February and I'm impressed with what I've seen so far giving that this is an open source project with a number of volunteers and a very distributed set of people contributing.

One thing I think that would really help is to have a Moodle Module developed with developers in mind. Some where that encourages tinkering and learning as you develop. Particular areas that developers seem interested in at the moment are performance, unit testing and my pet focus separating the view from the back ground code much like an MVC structure.

I've been programming for several years in asp and javascript where we didn't have debuggers and other wonderful kit to help us and there wasn't anything on the web either. So I've built my own toolkit that helps me lift the lid on my code and try things out.

I planning to provide a set of classes with set of template scripts which show how they're used. All a developer needs to do is:
  • Copy the template
  • Add the code to test
  • begin testing using the toolkit
an example testing script is
testLoop.php

<?php
require_once setup.php;

$profiler = new Profile();
$out = new Out();

// Begin test code
$arr = array("one", "two", "three");
reset($arr);

$limit = 1000;
var $x;
var $string = '';
// test while
profiler->beginstep('while');
for($x=0;$x<$limit;$x++){
while (list(, $value) = each($arr)) {
// Do something
string.= "Value: $value<br />\n";
}
}
$profiler->endStep();

// Reset test values
$x=0;
$string = '';

profiler->beginStep('foreach');
// Test foreach
for($x=0;$x<$limit;$x++){
foreach ($arr as $value) {
// Do something
string.= "Value: $value<br />\n";
}
}
$profiler->endStep();

// End test code
$steps = $profiler->getSteps();
$out->append('The test took '.$profiler->getElapsedTime().' seconds.');
foreach(steps as step){
$out->append('Step '.$step->getName().' took '.$step->getSeconds().' seconds.');
}
out->flush();
require_once teardown.php;
?>

I'm showing php code here but I have found very quick and simple methods to help with:
and others. I'm also always learning from other people and with so many helpful people on these forums I'm sure there are lots of tips we can all share.

So I just wanted to see if this would be of interest to any one and if any one has any input they'd like to give. I think it would be a great way to improve the quality of the code we currently have while making the process fun and enjoyable by hopefully making it simpler.
Average of ratings: -
In reply to Colin Chambers

Re: Developer Module

by Colin Chambers -
Ok, it seems like I've confused some people. I'm good at that! So just to clarify

I'm talking about helping to educate people and provide them with examples of good practice.

for example with unit testing I just wonder how easy it is for a really inexperienced developer to just go and create unit tests (a lot of us experienced coders are also new to the idea as well). So I might consider creating a couple of test templates to use or I'd just point out good examples within the current Moodle code.

It seems simple I know but for inexperienced developers or developers that haven't had access to a particular tool before. It might make it easier for them to get going and remove a barrier for them in using unit tests or any of the other tools we have available.

In reply to Colin Chambers

Re: Developer Module

by Martín Langhoff -
(Note - this is generally meant for new developers, I suspect Colin knows a good bit of this, if not all wink )

My usual practice in any OSS project is to read the existing code, focussing on areas of the code where I know the project leaders and old hands focus.

"cvs annotate" and changelogs are very helpful in this practice. If you do that, I'd say follow "moodler" and "stronk7" for a while. That's what I did when I started working with Moodle, and every other OSS project that I've worked with. Like a journalist at a newspaper, you have to follow the style, and the style is defined by the project leaders.

If you do that, you'll find lots of things about moodle style, in coding style but also in architectural style.

IOWs, the bet intro is to read the existing code. I usually give people an intro to the high-level directories, what APIs they correspond to, a bit more about key libs (moodlelib, weblib, dmllib) and then a stab at resolving a few bugs. If you are keen on making things easier for people, I'd suggest a bit of "Cliff's Notes" guide...

If you do that, one of the things that might surprise people is that MVC isn't widely used. There isn't any consensus that MVC is worth the complexity and performance costs - which are often huge. The move to MoodleForms (based on Quickforms) has brought some benefits (consistency, accessibility) but at a huge cost in line count and complexity.

I don't want to have an MVC flame here -- what we have to address are the actual problems that we are seeing with MoodleForms. In either case, the discussion belongs elsewhere - run a search for moodleforms in this forum. Or for MVC for past flamefests wink
In reply to Martín Langhoff

Re: Developer Module

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Of course, what Martin is saying here is just principle 3 from http://docs.moodle.org/en/Pedagogy#Social_Constructionism_as_a_Referent.
In reply to Tim Hunt

Re: Developer Module

by Anthony Forth -

I can see how a 'template' module with some of the resources people commonly need/use and examples of best practice, like unit testing, could help people get up and running quickly if they want to develop their own module or maybe customise existing modules for their own use.

In reply to Tim Hunt

Re: Developer Module

by Colin Chambers -
Thanks Tim I hadn't seen that page before. I didn't realise I had a social constructionist point of view until I got to the OU and began working on Moodle. At least I now know what to call myself. So in terms of the 5 points.
  1. I'd like a collaborative module that's built like Moodle itself has been built by the community
  2. You can't learn to play tennis with out hitting a ball. I want to encourage people to just write code the way they are most comfortable and let them use the templates and tools to find out for themselves how it can be improved. I find the process of self discovery to be one of the most powerful teachers.
  3. Experts in Moodle code should be able to point to good practice or key points of code for relevant areas. Can't we have a simple place to begin working on a particular section for those who just want to get stuck in. For example a template on how to write a good block or just a line telling some one which block to copy. If we already have this on the wiki then a url to it. It doesn't have to be detailed just help the guy get from a to b really quickly
  4. I don't know the profile of the development community but I expect there are a few dedicated coders who have the time and energy to read code and documentation like us at teh OU who are paid to do it. Being OSS I expect most (anybody know how many) just do it in their spare time and have a life outside so its just their hobby. All they want to do is contribute, they don't want to be told their code isn't faster enough, not scalable or reliable they just want some one to make it easy for them to write good code because they don't have the time to become a great coder. They may not even speak english as a first language or may be dyslexic so reading code isn't the easiest thing for them.
  5. Keeping things flexible is always the challenge and it's the only way I've known how to keep up. So the templates and tools I'm thinking of will be very lightweight and simple. Pretty much following the KISS principle
Sorry to go on but now that I've seen these points I think it's helped me make things a bit clearer. thanks Tim
In reply to Martín Langhoff

Re: Developer Module

by Colin Chambers -
Some good points Martin. Thanks. What I'm really trying to advocate is making it easier for developers particularly those who are inexperienced or time poor to see very quickly how their code performs. By doing this they get to learn a bit about what techinques work best in particular situations and they also produce, hopefully, better faster more scalable and reliable code.

For me it's just about making the process of writing, debugging and analysing code quicker. I'm thinking of people who don't have lots of time to read code, who just enjoy the process of programming. I know that I am fascinated how two sets of code appear to do the same thing but with a simple analysis I find that one works twice as fast as the other. I'm excited when I find this out and I begin using it when I can. I feel proud that I know something and often I have learnt a little bit about how the compiler or language itself works.

That's why I just like the idea of simple templates so that a guy can come home from work. Write a little piece of code for a module he's working on and whenever he's stumped or wants to analyse it a little he just plugs it into a template and sees the result. At least this way he knows he's done something to make sure it's good code. Sure there may still be extra work to do but we've given him a few tools to make the job easier and he's spent more time coding and enjoying the process.

I can certainly see what you're saying about MVC and I'm not concerned whether we go down that route. Right now I just want to make it easier to write good code.
In reply to Colin Chambers

Re: Developer Module

by Martín Langhoff -

Most of what you're after already exists I think wink I usually point people to mod/label (with caveats that it cheats on some things) and to mod/resource. For more complex stuff, mod/forum is a good reference. The 3 of them are actively maintained by core developers, so they'll show current "best practice".

All of those need Cliff's notes -- but the real cliff's notes are in the commit messages, so I tend to focus on teaching people how to get a good changelog / patchseries view of the code.

It may seem a tad harder, but

  • the code is maintained by core developers - it won't be out-of-date
  • it's not artificially simplified code - it gets a real job done
  • it walks users through actual moodle code
  • the skills learned (namely, how to learn from the functioning code and from CVS) are a million times more long lived... portable to other APIs within moodle, and to other projects too!

Of course -- it won't hurt to have the sample you describe. I wonder how do you ensure it's relevant, authoritative, current...?

(BTW: my approach to the "template" thing in practice tends to be - figure out which module/block/whatever is the most similar to what I'm trying to achieve and start by copying those files, gutting the bits I don't need, and reworking the rest...)

In reply to Martín Langhoff

Re: Developer Module

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators
Martin > "my approach to the "template" thing in practice tends to be - figure out which module/block/whatever is the most similar to what I'm trying to achieve and start by copying those files, gutting the bits I don't need, and reworking the rest"

I totally second that view. I'm afraid a "sample developer module" which would do nothing real would not be too useful.

Joseph

In reply to Joseph Rézeau

Re: Developer Module

by Colin Chambers -
I'm not expecting it to be useful to everyone. We all work in different ways. I'm saying how many people can say just how fast, scalable and reliable their code is.

I never used to be able to because I had no benchmarking tools. I'm not expecting an iso standard that can be compared to other projects. I just like to try two different methods and see which one scales the most. I just don't want to have to figure out how to do it. The barriers to doing things like this are normally time pressures and the fact you normally have to right the tool yourself or use some else code.

I just think it would be nice if I had some part of moodle that did this for me and I could just drop in my code. Templates of quality code aren't what I want to focus on. Just a simple space where you can test out and analyse your code. I just want to encourage people to take apart their code or other peoples and experiment with different ways of putting it back together and seeing the impact it has
In reply to Colin Chambers

Re: Developer Module

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers
Just by the way, on the topic of performance, I posted (and several others improved) a 'perspective.php' script in here some time ago. It could be run on a test Moodle installation and told you how long things took - so you could get a basic idea that, for example, a file write is much faster than a database query. And for just how incredibly slow PHP is at CPU-bound activities.... but that it's still lots faster than disk reads or database queries.

(And for how different systems vary - there might be some where that isn't true, or is less true.)

I found that quite useful in confirming - and in some cases revising - my personal intuitions.

I'm rushing home now so don't have time to look up that thread, however it can probably be found easily with search? Might be useful.

--sam
In reply to sam marshall

Re: Developer Module

by Colin Chambers -
Thanks sams. That's the kind of thing I'm talking about. I've done the same kind of thing before and I like being able to prove to myself that the code I've written is as fast as it can be given the language I'm using and the limits imposed. If you've already written something I'll look it up.
In reply to sam marshall

Re: Developer Module

by Colin Chambers -
I found the post at http://moodle.org/mod/forum/discuss.php?d=57028 and it taught me a few things I didn't know, which is the point. I didn't realise update record was so slow. Is this the adodb layer or php itself or postgres and php but that is terrible. If it's ok with you Sam I might include this in the module I'm planning because it just shows really quickly to any developer the cost of basic things they do.

As a side note the kind of issue I would use the tool set for is to investigate performance issues. For example something I would want to know about is how best to use the serialise and unserialise methods or whether to ignore them at all because in my Offline Moodle code I choose to leave the db alone for obvious reasons and just save session based stuff to disk (I didn't want to waste precious server ram on this stuff) so I serialised things to disk. I read somewhere though that the unserialise process can be particularly slow on large complicated data so I want to know how best to use it if at all. Perhaps, as is often the case there is an exponential increase in time with each layer of complexity eg 1d array 0.001 ms 2 d array 0.01ms 3d array 0.1 ms. Therefore the quickest thing is to break the info into multiple objects and serialise separately and reverse this in the unserialise. This way I get the same result but much faster with just a little coding sugar to tie it all together.
In reply to sam marshall

Re: Developer Module

by Colin Chambers -
I looked back over the thread you started and you got a lot of people thinking and discussing things and I think everyone learned a lot or hadn't thought about things in that way. That's the kind of discussion I want to encourage. Get people thinking about these issues when they write their code and the whole of Moodle should get faater over time through our general efforts. Then we should not have to dedicate time to performacne improvements because our habits are good. The starting point is to make it easy to get the habit started by providing simle easy to use tools just like your script
In reply to Colin Chambers

Re: Developer Module

by Martín Langhoff -

I just like to try two different methods and see which one scales the most

Ah, easy: put each in a loop and run it 1000 times, time it with microtime(). Do it over a real-life-sized dataset.

I just think it would be nice if I had some part of moodle that did this for me

It's just a loop! wink