OU blog

Personal Blogs

Christopher Douce

London Associate Lecturer development day, London, November 2013

Visible to anyone in the world

The Open University is divided into a number of regions and twice a year the London region runs a staff development event for its associate lecturers who live in and close to our capital.  This blog post is a brief summary of an event that took place on Saturday 16 November 2013.  My own role during the day was quite a modest one (I was only required to do a couple of introductions).  This meant that I was able to wear my ‘tutor hat’ for much of the day.

Challenges for ESL students

ESL is, of course, a common abbreviation for ‘English as a second language’.  From time to time I’m asked what the university is able to do to help students who struggle with English.  There are a couple of schools of thought about this.  One school of thought is that English and writing skills should be embedded within modules (this is certainly the case within computing and engineering modules).  Another school of thought is that there should be a particular course or module that is dedicated to writing (which is the approach that the science faculty takes).  There are, of course, pros and cons with either approach.  The aim of this session was to offer tutors useful guidance about different resources and materials that could be shared with students.  It also aimed to help tutors chat about different challenges they have faced.

One skill that was considered to be important was the reading of papers, and a point was made that this is something that could be practiced.  Reading is, of course, a prelude to writing.  Although some people might argue that university level academic writing is something that is done only within the university (or academic) context, it can also be argued that learning how to write in an academic way can benefit learners in other ways, i.e. when it comes to writing for business and commerce, or the ability to distil evidence and construct cohesive arguments.

One question that was raised was, ‘how do you offer feedback in instances where students may struggle to read suggestions?’  This was a very good question, and sometimes interventions, or special sessions to help students are necessary.

Our discussions about writing led onto other discussions about plagiarism and academic conduct.  Plagiarism is, of course, a word that has very negative connotations.  In some cultures, using the words of an authority may be considered to be a mark of respect.  On the other hand, developing the ability to write in one’s own words is a really important part of distance learning; it’s both important and necessary for students to demonstrate how they are able to evaluate materials. 

The university has very clear policies about plagiarism and academic practice, and this is something that I’ve blogged about previously.  (Academic practice conference: day 1 summary, day 2 summary). From the tutor’s perspective, it isn’t an easy task to address these issues thoroughly and sensitively.  One thing that tutors could do is to run an activity (which exposes issues that relate to academic conduct).  Tutors (or module teams) could show how things should be done, and then tutors could facilitate a discussion using on-line forums, for example.

Another discussion that I’ve noted was the use of the ‘voice’.  Different modules may have a preference as to whether students can or should write in the first person.   One of the arguments about writing in the third person is that it allows other voices to be more clearly exposed.

During the session, we were all encouraged to do a bit of group work.  We were given a sample of writing and we were asked, ‘what resource would you choose to share with your students to try to help them with their writing skills?’  This was a fun activity and it emphasised that there is a lot of resources that both students and tutors can draw on.

To underline this point of resources, there were sets of study skills booklets that were available in the presentation room.  These had the titles:  Studying with the OU – UK learning approach, Reading and Taking Notes, Preparing Assignments and Thinking Critically.  If you’re interested, these can be downloaded from the Skills for Study website.

Developing resources and pedagogy for OU Live

I arrived at this afternoon session slightly late, since I was having too much fun chatting to colleagues.  OU Live is an asynchronous teaching and learning tool (which is a posh term to say that people can do things at the same time).  In essence, think ‘skype with a whiteboard’.  It allows tutors to run on-line sessions with groups of students, offering both audio and text-chat channels.  From my own experience, running OU Live can be pretty hard going, so I try to take every opportunity that I can (time permitting) to attend whatever training sessions the university offers.

This afternoon session was presented in two parts.  The first part was from the perspective of a science tutor (Catherine Halliwell), whereas the second part was from the perspective of a languages tutor.

Science perspective

I arrived in the session right at the moment when an important point was being made.  This was: ‘find a style of delivery that suits you’. It can be quite easy to use OU Live just to give ‘lectures’, but it is possible to use it to deliver dynamic interactive sessions.

One thing that tutors can do is to record their on-line sessions.  More students might use a recording of a session than there are students who are able to attend a live session.  One of the benefits of recordings is that they have the potential to become a very useful resource.  Tutor might, for example, refer students to sections of a recording when they start to revise for their exams.  Another thought is that you could explicitly refer to them when a tutor gives assignment feedback (guiding students to parts of a presentation where you have explained potentially difficulty concepts).

Catherine mentioned that her faculty had trialled the use of pairing tutors together to run single OU Live session.  Her module, a third level chemistry module, has 10 hours of tuition time.  Each session was shared; one tutor would take the lead, and the other would be a ‘wing man’.

Another aspect to OU Live pedagogy which can be easily overlooked is the importance of preparation.  Students can be asked to carry out certain activities before a session, such as completing one or more worksheets, for instance, to help to prepare students – or even performing observations, with the view to sharing data.

Catherine also spoke about some features that I had never used, but had been (slightly) aware of.  One of these features was the ‘file transfer’ facility, which could be used by the tutor to send students sets of ‘unseen questions’, perhaps in the form of a word document.  In some ways, this could be considered to be the electronic equivalent of giving everyone some handouts.  (I can also see that this would be especially useful during programming sessions, where tutors might hand out working copies of computer code to all participants).

We were given a number of very useful tips: make the first session as interactive as possible, and feel free to use a silly example.  Also, use things like voting, or drawing on a map.  Another thought is to turn the webcam on at the start so that the participants know who you are (you can turn it off after a few minutes, of course!)  Tutors should try their best to make their sessions friendly and fun.

There are a number of other points to bear in mind: some students can be reluctant to use the microphone, and this is okay.  Another approach (and one that I’ve heard of before) is to use OU Live as an informal drop-in session, where students are able to log in to have a chat with a tutor at a pre-arranged time.  It’s also important to take the time to look at a student’s profile to make sure whether there are any additional requirements that need to be taken into account.   Finally, because it’s possible to record a session, a tutor can always say, ‘I’m going to go through this bit quite quickly; because I’m recording this, you can always go back and play it back later if there’s anything that you miss’.

Languages perspective

The presentation from our language tutor was rather different.  We were given, quite literally, an A to Z tour of topics that relate to the use of OU Live, leaving us (and our facilitator), pretty breathless!

A couple of points that I’ve noted include the importance of developing routines and forcing habits (in terms of running sessions at the same time).  It’s also a good idea to send group emails, both before and after sessions (so students are aware of what is going to happen).  In terms of preparation, it’s a good idea to get on-line around half an hour before just to make sure that you don’t run across any technical problems or issues; having been confronted with the situation of Java software updates in the past this is very sound advice.

During the question and answer session at the end of the afternoon, the issue of the recording of day schools also cropped up again.  Our tutors were very pragmatic about this: recording of OU Live sessions should happen, since it allows the creation of resources that all students can use (especially those who could not attend any of the sessions).  It is therefore important to let all students know that recording is going to take place either before events, or at the start of an event.

Reflections

There’s always something to pick up from these events.   There were two main things that I gained from this session.  The first was the early discussions about language support consolidated what I already knew about the importance of academic conduct (and how the university procedures work).  Secondly, I picked up some tips about how to connect things together, i.e. connecting together assignment feedback with the use of OU Live recordings. 

The next event is to be held at the London School of Economics in March.   This event is likely to include a Mathematics Computing and Technology faculty specific session which will be held in the afternoon.  The fine detail hasn’t yet been decided on, but this too is also likely to be a good day.

Permalink
Share post
Christopher Douce

Database abstraction layers and Moodle

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 July 2010, 17:47

4815223101_d522684c99.jpg

One of the great things about Moodle is that it can be used with a number of different database systems.  It can use popular open source databases such as MySQL or Postgres, or commercial offerings from Oracle or Microsoft. 

The great thing about offering this level of flexibility is that it can make the adoption of Moodle into an existing IT infrastructure a whole lot easier.  If you have an IT department which is Microsoft centric, then adopting Moodle or slotting it into an existing IT infrastructure might not cause too much upset.  Similarly, if your IT department uses Linux and has a dedicated database server that runs Postgres, offering choice of back end technologies can make things easier for system administrators.

This post is all about exploring how Moodle works with so many different database systems.  The keywords that I am starting with is database abstraction layer.  Wikipedia defines a database abstraction layer as ‘an application programming interface which unifies the communication between a computer application and databases’.  In some cases, a database abstraction layer can also help to maintain good application performance by caching important data, avoiding the need to repeatedly request data from a database engine.

Here are my questions: how does a Moodle developer save stuff to and get stuff from a database? Does Moodle have a database abstraction layer?  If it does, how might it work?  Finally, are there other database abstraction layers or mechanisms out there that could be used?  Let’s begin with the first question.

Getting stuff in and out

What instructions or mechanisms do developers used to get data into and out of Moodle, or a database that Moodle is using?  My first port of call is the Moodle documentation.  After a couple of clicks I find something called the Moodle Database Abstraction Layer.  This looks interesting but way too complicated (and initially confusing) for me to understand in one go.  What I’m interested in is an example.

I turn to the Moodle codebase and using my development environment I perform a text search (or grep) with  the word SELECT, which I know to be a frequently used part of the SQL database language which underpins most relational database systems, and browse through the results.  I quickly uncover a function called get_record_sql which seems to be the way to send SQL language commands to a database.

Another search reveals that the function is defined within a file called dmlib.php.  This library is said to contain all the Data Manipulation Language functions used to interact with the DB.  Comments within the file are reported to be ‘generic’ and work with a number of different databases.  A link to a documentation page is also provided, but seems to be describe functions that relate to the development version of Moodle, not the version that I am using (version 1.9).

It seems that functions named get_record_sql, get_record_select and update_record (amongst others) are all used to write to and read from a database that is used with Moodle.  To write new Moodle modules requires a developer to know a vocabulary of abstraction functions. 

The second question can be answered relatively easily: Moodle does seem to have a database abstraction layer.  Judging from the documentation it seems to have two different types of abstraction layers: one for the usage of a database, another for the creation of database structures.  I’ll try to write something about this second type in another post.

How does it work?

How does the Moodle abstraction layer work?  How does it act as an intermediary between the Moodle application and the chosen database engine? There seems to be a magic global variable called $db, and the abstraction layer code seems to be replete with comments about something called ADOdb.  Is ADOdb the magic that speaks to the different databases?

Another search for the phrase '$db =’ yields a set of interesting results, including files contained within a folder called adodb (lib/adodb).  This seems to be a database access library for PHP.  I uncover a link to the ADOdb sourceforge project from where the code originated and I’m rudely confronted with some sample code.

At this point, it seems that Moodle uses different two layers to 'get' and 'set' data.  It begins with the Moodle-world functions (the database manipulation language functions).  Calls are then passed to ADOdb, where they are magically ushered towards the database.

Other questions come to mind, such as: why did the Moodle developers choose ADOdb?  This question does not have an answer that can be easily uncovered.

Other abstraction layers

A quick glance at two of my PHP books point towards different database (or data) abstraction layers.  My copy of Programming PHP, for example, emphasises the use of a library called PEAR DB (named after the PHP Extension and Application Repository).  Clicking this previous link tells me that the PEAR DB library has since been replaced by something called MDB2.  My PHP Cookbook, on the other hand emphasises the use of PDO, which is a part of PHP 5 (a version of the PHP engine that the Moodle community has only relatively recently adopted).

So, why did the Moodle developers choose ADOdb when there are all these other mechanisms on offer?  I haven't managed to uncover forum discussion that explains the precise motivation for the choice.  Moodle release notes go back to May 2005, but the earliest forum discussion I can find that relates to ADOdb dates back to 2002.  Perhaps the choice could be put down as a happy accident of history and one that has facilitated amazing database interoperability.

One thing is clear: PDO is the (relatively) new kid on the 'database abstraction' block, and other software developers are asking the interesting (and difficult to answer) question of 'ADOdb or PDO: which is better?'  In trying to answer this question myself, I uncovered a slideshare presentation and a blog post that tries to compare the two technologies by using benchmarks to see which is faster.  PDO, it seems, is a central part of PHP 5 and has been written in 'native code' which might explain why is reported as being faster.

The debates about which database interface technology is better are interesting but don't directly arrive at a clear conclusion.  Different technologies may do similar things in slightly different ways, and sometimes a choice of one or the other may boil down to what the programmers have used in the past.  Unpicking the subtle advantages and disadvantages of each approach needs lots of time and determination.  And when you have an answer, affecting a change may be difficult.

Future developments?

I recently uncovered a really interesting Moodle forum discussion on the topic of database abstraction (amongst other things).  Subjects included differences between various database systems, the possibility of using stored procedures, the difficulty of mapping object-oriented data structures to relational database engines and so on.  All great fun for computer scientists and application developers!

One thing bugs me about the Moodle database abstraction layer is that it is very shallow.  It requires module developers to know a lot of stuff about things that ideally they shouldn't need to know about.  To add courses and modules, you have to know a little about the structure of the Moodle database and how to work with it.  There is very little code that separates the world of SQL statements (passed on to databases using DML and ADOdb) and the interfaces that are presented to users.

It could be argued adding additional layers of abstraction to more firmly manage data flow between Moodle application code and the database would place additional demands on the Moodle programmers.  In turn, it this could make it harder for occasional contributors, particularly those working within academic institutions to make contributions to the code base.  I strongly disagree with this argument.  Creating a more sophisticated (or layered) database abstraction approach may open up the possibility of making more effective use of functions of different database engines and make the Moodle code base easier to understand (if the abstractions are designed correctly).

One way to consider ways about how the abstraction layer might be improved is to look at how other open source projects solve the same problem.  I was recently told about the Drupal database abstraction layer.  One useful activity might be to investigate its design and learn about what decisions have helped to guide its development.

Summary

Databases can be a tough subject.  Creating an application that can work with different database engines effectively and efficiently is a big software engineering challenge.  This challenge, on the other hand, can make things a lot easier for those people who are responsible for the management and operation of IT services.  Providing application choice can increase the opportunities for an application to be used.

What is certain is that the database abstraction mechanisms that are currently used in Moodle will change as Moodle evolves and database engines are updated.  At the time of writing work is underway to further develop the Moodle database abstraction layer.  I look forward to seeing how it changes.

Image acknowledgement: pinksherbert, from Flickr.

Permalink
Share post
Christopher Douce

Discovering Moodle profile fields

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 July 2010, 12:58

EU4ALL logo

One way to improve e-learning user experience is to attempt to present material that match a learners precise needs and preferences. In terms of accessibility, it would be non-sensical to provide a screen reader user with a digital video resource, if that resource contained images or illustrations which did not have accompanying auditory explanations.

The previous post explored how it might be possible to add a new category of resource to Moodle, an 'adaptable resource'. This post will try to explore a related piece of the puzzle by examining how it might be possible to tell Moodle about your own e-learning content preferences.

Some background

A learner might use a range of different e-learning systems at different schools or universities during a learning career. One problem might be the need to continually tell different systems what your content preferences might be. Let's face it: this is trouble! Not only would this take time, but it would also no doubt introduce errors. One solution to this might be to allow a user to store their preferences on a server somewhere. This server could then share user preferences to different systems, subject to some form of magic authentication.

A learning management system could be used allow a learner (or someone acting on behalf of a learner) to edit and change their centrally managed preferences. The question is: how could we demonstrate this idea using Moodle?

Let's begin from where I left off in the previous post: user profile developer pages.

Returning to code

What this page says is that it's possible for a user of Moodle to store extra 'stuff' about a group of users to a database. This sounds great! But how does it work? In true developer fashion, ignoring all the user documentation, I delved into the source code and then browsed over the database structures. I found quite a few tables that relate to the user. There were tables relating to fields, data and categories, and a hint of previous accessibility development work as evidenced by the presence of a 'screenreader' field (but more of this later).

It soon became clear that there was quite a lot of existing functionality that might be able to be 'leveraged' (horrid word!) to facilitate (another one) the entering of user preferences. I liked what I saw: code where the functions were not too (not bigger than a screenful) and had the odd set of comments (you can read that in two different ways). Looking at the code, whilst useful, is never enough. It was time to have a look to see what the user sees.

Return to the user interface

Within a couple of minutes, I found it was possible to construct a way to enable both the user and the administrator to enter extra data against a particular user profile. Using the Moodle tools I created a really quick pull down menu to represent a learner specifying their preferences.

4815188614_d799dfb361.jpg

I should note, that a single menu represents a tip of the iceberg regarding the issue of entering user preferences! My titles are undoubtedly badly chosen. Also, there are existing metadata standards, such as AccMD (powerpoint), which can be used to describe user preferences, but I certainly won't go this thorny area here...

Along the way I stumbled across some documentation pages that describes the Moodle user profile.

Joining the dots (or nodes)

Okay, so this part of Moodle might be able to be used as a simple user interface to allow a user to specify their content preferences, but how (and where?) might I store other information like 'special-magic-numbers' or identifiers that can allow the VLE to understand that other systems are referring to the same user? (I hope this sentence makes sense!)

It seems that there are ways to store additional stuff in a Moodle profile too, fields that can be accessed and used by an administrator, but cannot be seen or edited by learners.

But... why?

As ever, one simple question has created a whole raft of others:

  1. Where did this feature come from?
  2. How is the data represented in the db? (looking at things from a developers eyes again!)
  3. What part of the code should I modify so I can connect the Moodle user interface to some kind of magic 'preferences server'?
  4. What does this mysterious 'screenreader' option do?

I'll leave some of them for another day, but I shall 'touch upon' answers to the first and the fourth.

Answers... of a sort

Apparently the capability to add profile fields (and categorize them) was added in version 1.8 of Moodle (which also incorporated a number of accessibility enhancements). I've tried to find the discussions on the forum that culminated in the addition of this feature, but I've had no joy - but what I have learnt is that there is talk about making an even more customisable version of the user interface, but I digress.

Wishing to know more, I turned my attention to the code to see what it could tell me. References to the screen reader profile tag is found scattered throughout the codebase. It appears to change how certain parts of the HTML is presented to browsers. It is found in the chat module, within the file type resource code, the question engine code (where additional feedback is presented to screen reader users), and in some of the currently mysterious theme code. I sense this question is a bit harder to answer than I had initially anticipated!

Onwards and upwards (or should it be downwards?)

Now that I know roughly how to make a custom user profile interface, my next task is to identify where in the code I should add some magic to make Moodle speak to different servers. Wish me luck!

Permalink
Share post
Christopher Douce

Working with new Moodle resource types

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 2 Dec 2008, 17:14

Moodle logo

As a part of the EU4ALL project, I have been trying to figure out how to add a new resource type. The idea is to add a resource known as an 'adaptable resource', whereby different media types are presented to the user depending on their accessibility preferences. The issue of how and where to assign or change these preferences is currently a question that has to be resolved. This post is intended as a bunch of 'notes to self' about what I have found during the last couple of days exploring and poking around the Moodle code base.

To explore the code, I've been using a couple of tools: SQLYog, which was recommended to me by an illustrious IET developer (to allow me to explore an instance of a Moodle MySQL database I have running on my home machine), and NuSphere, a PHP IDE. I did try the Zend IDE a year or so back, but abandoned it since I became rather confused!

So, how is it possible to add a new resource to Moodle? Initially, I decided to look at an existing resource, beginning with the simplest one that I could find: a simple text resource. By browsing the code base I seemed to find the rough area where the 'resource code' lives. I also browsed around the developer documentation page an unearthed a resource class template. Great!

In development, one question instantiates a tree of others. The most fundamental question is: how does this code work? I need to answer this big one to make a change. This is too big, so I split it into two other questions: (1) how can you modity a form that allows you to enter the parameters that describe an adaptable resource (currently it is to be a simple numerical value, from what I understand), and (2) how can I take the values held within a form and update them to the MySQL database? This requires an understanding of further magic code. As a note to myself, let's have a look at each of these in turn.

Entering stuff

Looking at the text resource code, there seemed to be a bit of object-oriented polymorphism going on. The name of the directory where the resource code is important too! There is a magic function called display which appears to make some further magic calls to create some data entry fields - but these calls are quite a long way away from the pure HTML that is presented in the browser window.

This is another question: how does the magic functions in display() get turned into HTML? The answer apparently lies with the application of a forms library called PERL. If I figure out how to add functions in a way that would work for this library, I can ask the user for whatever I want.

The form uses some object-oriented principles. Individual controls are added to 'the form', and then a function is executed that 'prints out' or renders each of the controls, without you having to go near to producing your own HTML.

Another interesting observation, is that the display function I have uncovered only relates to a small part of a bigger form. This is due to subclassing and polymorphism that is being used, but this is a distraction... now I have a little understanding of what is happening (thanks to the NuSphere debugger!), I'll park this question for the time being. There are other mysterious areas to explore!

Storing stuff

When a Moodle user edits a course resource, there are a couple of buttons that appear at the bottom of the screen. These are 'save and return', 'save and display' and 'cancel'. Looking at these buttons from a HCI perspective I think, 'buttons doing two different things?? surely this is a bad idea!'. But I digress.

My question is, 'what happens when the tutor (or administrator) clicks on either of the save buttons - where does the data go? Or more precisely, how does the data get saved?

Moodle seems to have a thin database layer: a set of functions that allows you to send SQL statements and receive data in response. Since the contents of the resource form is held in what can only be described as a 'big variable' (PHP has a funny approach to object-oriented programming if you've used other languages), the Moodle developers have figured out a way to transfer the contents of a form to the database, by matching on-screen fields to database fields.

This seems to work well: but on the downside is the database update code that Moodle code generates appear to be rather big, and an implicit dependency is created between the form and the database structure. Other systems that I've looked at make use of stored procedures, which has the potential to boost performance and security on one hand, but on the other restrict the database platforms that an application can be used with.

Moving forwards

Now I know (roughly) how to add extra bits to a new resource type, the next thing I have to do is figure out how to write the functions that I need. After I've done that I'll have to hook up my edits to the database, and figure out how to best display the data that I've produced. I already have some idea about how to do this since I have created a paper prototype.

But before going down that road, I think I'll continue my survey of the Moodle codebase by exploring what sections can potentially relate to adding and manipulation of user parameters and settings. I think I'll start by looking at the user profile developer pages.

Looking towards the longer term, I will also have to connect Moodle to a number of different web services. Wish me luck!

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2258930