Sharing Powerpoint course content

In the last couple of months I looked into solutions for sharing my course presentations (PowerPoint files) with others. My main goal would be to provide an experience as close as possible to the actual in-class courses for people that missed courses. This means that I would like the course content to be available to others as a full-length presentation with an audio narration.
The easiest way to do it with PowerPoint is to record the audio using the Record Narration feature. The problem with sharing PowerPoint files with narration are multiple. I have some solutions to these problems, but they lead into other problems.
The first major problem comes from PowerPoint itself: it can record narrations only in PCM format. That means that an audio narration (recorded with mono, 16 bit, 22KHz quality) takes about 150MB/hour (about 352Kbps). As a solution, I can link the audio narration file (instead of embedding it into PowerPoint) and compressed later as an MP3. Compressing it with FFmpeg is a painless process (just run one command) and takes only a few minutes. Compressed as an MP3 at 8Kbps, I will get around 3,5MB/hour for the narration which is quite ok. The problem that shows up in this case is that the file are linked (so I have to handle all of them with the main ppt file), and even worse, the PowerPoint stores the absolute path to the file (so moving the ppt file to another is very difficult if you want to keep the narration working).
The second major problem is that students must have PowerPoint (full version or viewer-only) installed and they need to download the file in order to view it. To make things more complicated, if the narration is linked it will not work unless the files are save in the same folder (i.e. same disk, path, folder name) as it was when narration was recorded. A MAJOR blocker. Combined, these two problems, put the ppt file sharing solution out of the game. I'll prepare the course in PowerPoint, but I need another method to share it using Moodle.
Due to certain restrictions (I won't go into details), I can not use presentations or videos sharing services with public access (like slideshare.com or youtube.com).
The solution I'm looking into for my problem is share the presentations as Flash content, so I'm looking into different PowerPoint to Flash converting solutions. To sum up my requirements, I want the solution to have the following features:

• small file output (I guess that means Flash with MP3 sound files)
• easy to publish in Moodle (i.e. a single swf file to upload instead of a bunch of different files)
• easy to create (i.e. click a few programs to transform from PowerPoint to Flash; as few as possible command line typing)
• free/unexpensive as in open source, freeware or adware (but with a decent sized banner and without affecting usability)
• fast conversion from ppt to swf (or batch conversion)
• (optional) as many features as possible (some feature examples are slide notes, slide thumbnails, different controls, search in slides, narrator information)

Obviously, I will not get all there requirements fulfilled, but I'll try to get as close as possible.

Click-to-translate feature for Moodle

Lately I tried to improve the quality of my university's Moodle platform. Among other things (i.e. upgrades, new backup setups, new theme, etc) I also wanted to improve the quality of the Romanian translations. The Romanian language pack of Moodle 1.9 its quite good from the student/user point of view, but it still has some problems:

• the string for administrator/teacher views, reports, forms are not fully translated; I understand why: there little to gain in usability from translating them as many administrators use the English language (including me)
• new strings are not translated yet (maybe they are in CVS, but I did not look there)
• bugs

When I tried to fix or add some translations, I faced a problem that I believe is the source of many translation bugs: the lack of context information. For example, how do you translate "fullname". If it refers to a course, then it could be just that "Full name"; but if it refers to a user name, then it could also be "First and last name". Unfortunately, this is a bug in the Romanian language pack: when you create a course (in the Romanian interface) the full name will display "First and last name" (in Romanian, of course). Obviously, this is confusing for new users.
Even if you can guess the correct ad-litteram translation of a string, you could always benefit from knowing in what context it is used. This way, you can provide a better semantic translation.
In order to have this context information available, I patched Moodle to save the get_string results and send them to the browser (for user which have language editing capabilities). Then, using a simple JQuery/JavaScript script (sorry again for JQuery, I just found it much more pleasant than YUI) when the user performs a proper action (right-click while holding down Control), I display a list of the strings matching the element under the current mouse position. In this list, the user can click the string she/he wants to change/translate. A frame specific to that string is displayed where the user can edit the translation source and save it. The changes required patching lib/moodlelib.php (where get_string is) and lib/weblib.php (where the page footer is generated).
Initially, I wanted to do this a fully AJAX process (similar to Google's "suggest a better translation"), but I had to replicate a lot of the admin/lang.php content. This is not good, especially for future updates. Thus, I decided to open a frame with the translation editing form. The problem with this approach is that some translation files are just big and take very long to show up (frequently freezing Firefox for 5-10 seconds). Therefore, I patched admin/lang.php so that I can provide a particular string and it will display/edit only that string (loading/saving is very fast this way). Of course, the automatic translation feature using Google Language API is still in place and working fine.
Except for the new JavaScript for the editing console (which is about 80 lines of code, including many comments), the other changes are minor, allowing this feature to work with different Moodle versions.
Let's take now an example. Consider my local Moodle sandbox. As you can notice, the "Please register you site..." is not translated.

I'm an administrator, so I have language editing capabilities. When I right-click on that text (or an area that includes it, like a div, table cell, etc), I get a list of translatable string inside the HTML element I clicked. I go and click on the proper text:

Next, a frame loads displaying the editing form only for the pleaseregister string from the admin.php language file (which is currently untranslated in Romanian):

Taking advantage of the Google translation feature, I click on the English version of the text (on the left) in order to get it translated automatically into Romanian.

After making sure the translation is ok (and it was in this case), I can save it. Sometimes the Google translation needs a bit of work, but it's still a much better starting point than starting from zero.

If I would not patched admin/lang.php in order to display only the string I want to edit, then editing admin.php would mean to load a long form (which completely hangs Firefox for 10 seconds) and then scroll down to about 80% of the page or  search for the string I wanted.

Automatic translation for Moodle UI strings with Google Translation API

Today I installed a fresh copy of Moodle 1.9. I'm reviewing it in order to upgrade our university's site (from Moodle 1.8) and another site (using Moodle 1.6). As always, I started going through all it's settings, looking for new features or things that changed. When I reached the Language section, I installed the Romanian language, just to make sure installation is working. However, I noticed that the Romanian language pack is missing 26.7% of strings (2672 to be more precise). Some translated string are also a bit weird.
I remembered that about two years ago, I patched Drupal in order to get automatic translation using Google Translate. At that time, Google translate did not provide any web services API, nor AJAX, and the translation of text containing HTML tags was very poor. The patch was doing simple HTTP requests, parsing of the HTTP response, some simple cleanup and in the end, it stored the translation into the Drupal locale messages.
Google Translate nowadays has much more languages than it used to backthen is AJAX based and offers web services, too. I was wondering how does it handle HTML tags and how hard would be to get it into the Moodle language editor. After 2 hours of coding and reading its API, I came up with this (sorry for JQuery, I know Moodle likes YUI):

$translang = preg_replace('/_.*/', '', $currentlang);
echo '
<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load("language", "1")
  google.load("jquery", "1.4.1")
</script>
<script type="text/javascript">
  $(document).ready(function() {
    $("form .translator .stren").click(function() {
      var src = $(this);
      var dst = $("[name=\'stringXXX" + this.id + "\']")
      var tokens = [];
      var text = src.text().replace(/\$a(->\w*)?/g, function(match) {
        return "TK" + (tokens.push(match)-1);
      });
      google.language.translate(text, "en", "' . $translang .'", function(result) {
        if (!result.error) {
          dst.text(result.translation.replace(/TK\d+/g, function(match) {
            return tokens[match.substring(2)];
          })).css("background-color", "yellow")
        }
      })
    })
  });
</script>';

This will allow a translator to click on any string in the Language editing section and get a Google translation for that string. The translation is saved in the corresponding textarea (which is marked with yellow). You can then check, edit, undo, or save these changes.

GSoC 2009 sum-up

After I finished my previous post, I recalled a few moments when things didn't work the way I wanted (or didn't work at all). One thing led to another and I start thinking what were the main challenges I faced during this project. If I was to make such a list, it would be probably look like this:

• missing documentation for the recording widgets:
• for riffly, I had some help from their support team regarding their API and metadata services (thanks Steven) and some I had to find out by myself through try-and-error (and Firebug and Wireshark and XDegug and so on);
• for nanogong, I had to go through their applet java code to find out how it works. Maybe I'm missing the big picture (since nanogong is only a piece of a larger project), but it seems to me that this code was unnecesary complicated in some places, and missing a lot in others (some said: "so what, it's code that works").
• working on still in development code (both repository and Moodle 2.0):
• there have been quite a few occasions in which I updated my CVS only to find out it contains broken code which was commited in by mistake;
• the repository code is still going through some changes and the coding style felt in some parts a bit rough; this feeling was in part due to the particular tasks and contraints that I was facing with my plugins; however, the documentation pages and the existing plugins proved a valueable source of information in many case (thanks dongsheng).
• less important, but still a tiny problem was that the repository code is missing comments in some places (especially in Javascript, filepicker and webservice code), has out of date comments in other places, and has in a few places comments like this:
  

  Don't modify this file unless you know how it works

Anyway, even with all these issues, finishing this project was never at risk, because Jerome was very helpfull and quick in response, providing me with usefull tips, coding help and great feedback, and occasionally collecting feedback and advices on my befalf from other Moodle developers. He's also very pacient and he gave me a lot of freedom to work on the project on my own pace.

Dongsheng (who designed and developed the repository API) was also very supportive, helping me when I got stuck with the repository API and quickly fixing repository bugs so that I can move on.

Last, but not least, Helen was very helpful with the administrative part, keeping me (and the others) informed and focused on my schedule, stepping in on a few occations to make sure I have a great (and complete) GSoC experience.

Completed audio repository plugins

During Google Summer of Code 2009 project I worked on implementing repository plugins that would allow users to record audio files directly into Moodle. Initially, the plan was to provide a single recording only, but things went a bit further, and I also implemented a collection management feature.

Both plugins have integrated help pages for all their features, but additional help (mostly for developers) is in the Record audio repository plugin wiki page. Some discutions focused on audio and/or video recording in Moodle are in the Record audio repository plugin (was Wanted: New feature ideas for GSOC projects) and GSOC: Record Audio/Video directly into resources/activities forums. The later is more general, not only about the repository plugin. Last, but not least, there also a place for feature requests and bug reports in the MDL-18341 ticket.

The plugins are not included in the Moodle releases (not even the 2.0 dev daily build). In order to test them, you'll need to use a 2.0 dev daily build.

The Riffly plugin allows audio-only or audio-video recording inside the Moodle repositories. The flv files are stored on riffly.com servers and, optionally, they can be downloaded into Moodle (to go under Moodle File API control). Recorded files and the recording flash object is available in all places where the repository is used to select files.

After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire riffly folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you'll have the option to create riffly site-wide, course-wide or per-user collections. For each collection, you can choose what type of content it accepts: audio, audio-video or none of them (to get a locked collection).

The Nanogong plugin allows audio-only recording inside the Moodle repositories. The wav files are stored into Moodle using the File API. The sound files can be recorded using the ImaACPCM or Speex codecs. As for the riffly plugin, recorded files and the recording applet are available in all places where the repository is used to select files.

After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire nanogong folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you can select the codec used and the quality of the sound for the site-wide recording instance. This instance will be shared by all users of your site (because it only handles recording, and File API handles the rest).

Nanogong applet how-to

This is a compilation of the notes I tookon nanogong appet. I think I got everything here and I didn't missed anything.

The nanogong applet accepts the following (optional) parameters:

• SoundFileURL = URL = address of a sound file that should be loaded on applet init (default "")
• Start = true|false = if true, the applet will start playing the file from SoundFileURL after loading (default false)
• ShowAudioLevel = true|false = if true, it displays the audiometer (i.e. VU meter) (default true)
• ShowRecordButton = true|false = if true, it displays the record button (default true)
• ShowSpeedButton = true|false = if true, it displays the faster/slower playback buttons (default true)
• ShowSaveButton = true|false = if true, it displays the saved file locally button (default true)
• Color = HTML color (including # prefix) = the color of the applet's background (default #FFFFFF)
• AudioFormat = ImaADPCM|Speex = the codec used for sound encoding (default Speex)
• SamplingRate = integer = the sampling rate of the sound recording (default 44100); allowed values depend on the AudioFormat:
• 8000|11025|22050|44100 = for IMA_ADPCM audioformat
• 8000|16000|32000|44100 = for Speex audioformat
• SpeexQuality = 1...10 = quality of sound compression for the speex codec (1 = lowest, 10 = highest quality) (default: 10)

Appart from SoundFileURL and Start parameters, which allow sound to be played as soon as the applet is loaded, the nanogong applet can be controlled using the sendGongRequest method. In order to do this, the applet should have an id, which makes it easy to get a reference to it in JavaScript. Here's an example:

HTML:
<applet id="nanogong" archive="nanogong.jar" code="gong.NanoGong" width="180" height="40"></applet>

JavaScript:
var recorder = document.getElementById('nanogong');
if (recorder == null) {
 alert("recorder not found");
 return;
}
var result = recorder.sendGongRequest(...request name..., ...parameters...);

The following requests names (and parameters) are accepted (including returned values, but without quotes):

• playMedia StartTime EndTime - plays the media between the StartTime (optional; default: current position) and EndTime (optional; default: end of sound) seconds; return value is "StartTime;EndTime" (values parsed by the applet)
• recordMedia Duration - record Duration (optional; default: maximum accepted) seconds of sound; return value is "Duration" (values parsed by the applet)
• pauseMedia - pause the media playback or recording; return value is "Time" (current playback time)
• stopMedia - stops the media playback or recording; return value is "" (if playback) or "Duration" (total recording time, if recording)
• setMediaTime Time - sets the current playback time; return value is "Time" (value parsed by the script)
• getMediaTime - gets the current playback time; return value is "Time" (current playback time)
• getMediaDuration - gets the total playback time; return value is "Time" (total playback time)
• setMediaRate Rate - sets the playback rate (between 0.5 and 1.5); return value is "Rate" (value parsed by the script)
• getMediaRate - gets the playback rate (between 0.5 and 1.5); return value is "Rate" (current playback rate)
• getMediaStatus - gets the current status: playing, recording,paused, paused recording, stopping, stopped, closing, or closed; return value is "Status"
• getAudioLevel - gets the current audio level (in 0.00 format); return value is "Audio level"
• saveMessage Type Filename Path - saves the audio file (many features)
• postToForm URL Parameter Cookies Filename - send the sound file via HTTP post to the URL address (including the Cookies), with the file send as the Parameter form item and with local name Filename; return value is the response of the server.
• loadFromURL URL Start - load the sound file from the URL and playsit if Start=true; return value is "URL" (value parsed by the applet)
• getVersion - gets the applet version number; return value is "Version"

Here's an exemple that also uploads the registered message (2 files in the same directory):

File: record.php
------------------------
<?php
if(isset($_GET['save'])) {
  move_uploaded_file($_FILES['sndfile']['tmp_name'], '/tmp/' .
$_FILES['sndfile']['name']);
  echo 'Your file have been saved.';
  exit;
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>The NanoGong Applet</title>
  <script src="nanogong.js" type="text/javascript" language="javascript"/>
</head>
<body>
  <h1>The NanoGong Applet</h1>
  <applet id="nanogong" archive="nanogong.jar" code="gong.NanoGong"
width="180" height="40">
  <param name="AudioFormat" value="ImaADPCM" />
  </applet>
  <input type="button" onclick="sendFile('nanogong')" value="Send" />
</body>
</html>

nanogong.js
------------------------
function sendFile(applet_id) {
var recorder = document.getElementById(applet_id);
if (recorder == null) {
  alert("recorder not found");
  return;
}

var duration =parseInt(recorder.sendGongRequest("GetMediaDuration", "audio")) || 0;
if (duration <= 0) {
  alert("no recording found");
  return;
}

// upload the voice file to the server
var msg = recorder.sendGongRequest("PostToForm","record.php?save=1", "sndfile", "cookie=SomeText", "myfile");
alert(msg);
}

The problem with the current applet is that it is not signed and it contains code for saving files locally. This makes browsers to ask the user if they trust the applet publisher. This is annoying and it may raise concerns for unfamiliar users. There are three solutions to this problem:

• leave it as it is (maybe show a message to the user, explaining what the browser is complaining about)
• sign a copy of the nanogong.jar file with some valid certificate (maybe a moodle certificate)
• delete the local file saving code (not very important), recompile the applet and hope that the browser will not complain anymore.

Almost there

The riffly plugin repository is almost completed. Jerome is helping me with QA and squashing bugs. The plugin now supports multiple instances (per site, per course and/or per user) and each of this instances can be setup to support only audio media, only video media or audio and video. Also, each instance can be setup to download the riff files locally (for management using Moodle's File API) or to link to the files on riffly.com (very useful, if you have limited storage space or bandwidth).

Meanwhile, I started work on the second plugin, which is using the Java applet nanogong.

Code is in CVS

The code up to now it's in CVS. I did some changes to the recording scripts, factoring out the common part in record.php. After Jerome noticed that recording is limited to 10s, I fixed that and set a limit to 1 hour. I also fixed some other bugs that Jerome reported and made some changes to the UI (the recording links placed at the top now; no longer mixed with the recorded content). I'm currently working on integrating this plugin with File API.

CVS write access

My application for CVS write access was accepted and now I have write access to contrib/plugins/repository/riffly. I'll commit the plugin as soon as possible (probably after I'll do the changes Jerome proposed).

Midterm plugin

This week I "finished" the repository plugin for integration of riffly.com web services. I got carried away so I added more features than I initially planned for (like video recording). Before going into more details, you can go and download the plugin from the ticket #MDL-18341.

Instalation: Inside the tgz'ed file you'll find only one folder (called riffly) that you'll have to extract in the repository folder of your Moodle instalation. After that, go to Moodle's Site Administration menu and drill into Plugins/Repositories/Manage repositories. Click on the "Add Riffly" link and then enable the Riffly repository plugin.

Usage: As I said, the plugin has many features (although some of them are not as visible as they could be), so I will not present them all and let you discover them by yourself. Just a few tips:

• how to insert a riff in your document: you'll have to use TinyMCE's "Insert/edit embeded media" button. Click on it and then click on the Browse button (to the right of the File/URL textbox). In the File Picker, select the riffly source. There you'll see the riff manager option, the record audio option, the record video option and any riffs you recorded previously (or added manually through the manager). Select the riff you want or record a new one, enter its name (or a description) and click the "Select this file" button. The rest is business as usual.
• how to manage your riffs: follow the previous steps, but select the "Manage collection" instead of an riff. You'll see a list with all the riffs in your repository (including their name/description, ID and preview areas). You can remove items from the repository or you can add new items if you know their IDs (Yes, you can share riffs with your friends by sharing these IDs)

Things that might go wrong: The code was developed against the HEAD of Moodle's CVS and it works ok. However, I spent an entire day tracking down a bug that prevented the file picker to show its content (repository categories and items). It seems a bug found its way into commit 1.19 of lib/form/editor.php (Petr was so kind to help me find it). Either check it was fixed in a following version or use the 1.18 version from HEAD.

Things that didn't go as planned: I broke my Moodle working enviroment twice this week with CVS updates. It's normal for a product in development phase, but that doesn't make it less annoying. 

I planned to create a TinyMCE to ease the proces of recording (and open the file picker directly). I never developed for TinyMCE before. I got maybe 60% of it done, but yesterday I got stuck in some JavaScript issues. Today, I found some ways to make it work, but I'll have to postpone work on it for a while.

Because of the TinyMCE plugin, I didn't have time to write the text filter, which would be probably much more easier and straightforward (I went with the challenging/fun part).

Back to work

My short trip to Iaşi is over. I attendend the ECODAM 2009 Doctoral Summer Workshop. There I assisted to some very interesting lectures (both from invited speakers and from other PhD students) and I also gave a talk about bonds representations in Ising spin glasses.

Unfortunatelly, last moment problems before leaving stopped me from submitting the last week's work summary and once got there my online time was very limited (between lectures, organizing activities, and spending time with my favorite niece). Therefore I'll do a two week summary in one post.

I finished the code for retrieving riffs metadata from Riffly. This is used when the user manually adds a riff to the repository.

I refactored the JavaScript code for integration of Riffly callback API with Moodle. It's much cleaner now, using AJAX POST to send the data back to Moodle repository and callback functions to update the File Picker location only if the riff ID was correctly stored in Moodle. If the store process fails, the the File Picker location will not change, so the user will be able to retry.

One problem that gave me major headaches (especially because I didn't have an Internet connection to search for more data) was the inconsistence between YUI's asyncRequest docs and implementation. Documentation says that the callback can be a function or an object. This is either wrong, or Moodle's YUI version it's older, because a function doesn't work. Finally I found the solution: use an object with success and failure methods.

When I updated code from CVS, I got the surprise that the HTML meta got deprecated from print_header. I was using it to inject some small JavaScript code (a hack, I know). Anyway, I had to learn about the new way to do it: using the require dynamic property of the global $PAGE variable. So now, the JS is on its own file, connection to Moodle through the riffly JavaScript variable.

Finally, I applied for write access in contrib/plugins/repository/riffly so I can start to commit.

To do: these are some ideas that might be good to implement:

• automatically select a newly recorded file (to save the user a few clicks);
• implement a text filter (Jerome sugested to look at the youtube filter for an example) instead of using flash objects;
• create a TinyMCE plugin to make recording easier than it is now (about 3 mouse clicks instead of the current 6 clicks).

First glimpse

The plugin I'm working on is starting to get a face, too. I almost finished the rough user interface. It doesn't have all the bells and whistles of Mihai's work, but it's enough now for testing the backend. I'll probably have to work on it some more after I get the feedback from Jerome. This is how it looks right now.

The user accesses the repository instance (in this case, called something). She/he will always see two pseudo-entries: manage collection and record. In addition to these, all the audio items in this instance's collection will be available for selection.

NB: The repository framework only supports thumbnail images for previews. This is not very usefull in the case of audio content. One of these solutions could be used:

1. implement a way to add textual description to entries and display those instead of generic "Audio file" text
2. implement a way that plugins can render their own HTML code for thumbnail (I think this is more usefull: @todo: check this with Jerome and Dongsheng)

The Manage collection entry displays a page where the collection entries can be deleted, previewed or added. This is usefull if you want to move items from one collection to another or to add an item that you now recorded.

NB: The i18n is not fully implemented and many language strings are missing.

Finally, the Record entry displays the recording Flash object. It allows users to record audio content and save it. I'm still fighting some JavaScript issue in order to automatically store riff ID and select it in the file picker after recording. This also brought me to my first contact with YUI. It's ok, but I like JQuery better. JQuery is simply more fancy, lightweight, and ... more fun.

Riffly API update

These are some additional information I managed to obtain about the riffly.com services. First of all, the API does not offer an username/password authentication method for premium users. If a user has a premium account, they add their domain in their control panel on riffly.com, so it will auto-detect any riffs that are played from their domain.

Second, the metadata for riffs is only available though JavaScript. More exactly, imagine you have the ID of a riff: B47686169D7111DC9B0D44CF0D09CCE3. In order to get its metadata you have to read http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3, which will give you something like this:

{
  "created" : "1196227339",
  "riffly_id" : "B47686169D7111DC9B0D44CF0D09CCE3",
  "playbacks" : "80",
  "type" : "video"
}

The most useful things here are the created timestamp and the playbacks count. Unfortunatelly, in order to display these in the File Picker, I would have to get these files for each riff and parse them in PHP. I'm not sure it's worth it.

A possible solution is to find the a way to embed some <script> tags in the File Picker that load JavaScript from this address http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3?callback=myCallback. The code produced by this address will call the myCallback function. Unfortunatelly, I'm not sure this will work with HTTPS Moodle instalations.

Meeting with Petr

Today I talked to Petr about the plugin progress. The discussion was very useful because he pointed out that teachers are allowed to embed objects and applets, but students aren't (for XSS reasons). It seems that the current method for students to embed objects is providing a link and let the filters take care of the rest (I'll have to check that).

No riffly.com reply yet

I haven't got a reply from riffly.com, yet. It's not urgent, because I can work on other stuff, but I was curious to get more details. I have another batch of questions ready for them, but one thing at a time.

Repository "Hello world" (aka Riffly.com)

This week I've worked the repository plugin for the riffly.com audio services. Starting the plugin was easy. The documentation presents clearly the required first steps. Thei are not hard to follow.

Moving on and getting into more details proved harder, due to the gaps in the documentation. For answers to many questions I had to dig into the repository lib code and trace the control flow. I guess the code is still in working because there are many code comments left, some obsolete comments, and many non-documented functions (too many?).  Yeah, and the Ajax part did make the process harder in some places.

Anyway, I got a skeleton of the plugin in place :). I still have some unanswered questions (like is the link and ref_id return types treated diferently, and how?).

Another issue is missing information about the riffly premium features. I wrote them requesting details, but I haven't received an answer yet.

Netbeans vs Eclipse (for PHP)

All weekend I've tested Netbeans and Eclipse with my PHP projects, mainly Moodle (since it has the larger codebase).

I've been using Eclipse Europa with PDT 1.0.3 for almost an year now since Petr recomended it to me. I'm very happy with it, although on a few occations the workspace got corrupted and some of the features stopped working (code completion, code dereferencing, etc).

So this weekend I tested Eclipse Ganymade with PDT 2.0 and Netbeans 6.5. Ganymede was quickly out of race (for now) due to too much memory hogging. Netbeans was OK, but it felt like its PHP features are somehow behind PDT's: file parsing/opening was slower, code dereferecing worked incorrectly on a few occations, and after a few hours of working the memory consumption was also large. I liked it code completion speed and coding helps.

I was expecting more from Netbeans, but I guess it's still too much focused on Java. Eclipse seems more general. So for now, I'll keep my Eclipse.

Coding starts.... NOW!

Well, GSoC coding starts today. I finished the functional specification, but I still need to prepare some mockups to make it cleaner. Jerome suggested balsamiq. I'll give it a try.
Jerome gave me some very good advices about dealing with common stuff vs. specific issues in it:

the question to ask yourself is: What are the difference between java applet and web services for the final users (Moodle admin and the guy wanted to record a sound)? If the difference needs a few sentences to be explained, you can have one paragraph. If you need half a chapter to explain the difference, it probably needs distinct chapters/use cases.

On a separate issue, I think Elena has an easier project code-wise, but more challenging "inspirational-wise".

Repository APIs

Finally, after long and frequent interruptions I was able to complete reading Moodle's Repository API & friends. The specification is still under construction, but it showcases an interesting and powerful concept with a very clean API.

First entry

This is my first blog entry. As I write right now, I'm not a big fan of blogs. However, I started this in order to help me keep track of my progress while working on Moodle with Google Summer of Code and other projects I'm doing.
It might also prove useful helping me "bookmark" stuff I found useful once and I can't find it anymore (like USP).
I've added a task to my Google Calendar to see in one year from now if my impressions about blogs changed.