Using crontab

I found a great page that gives a very short an concize manual for using crontabs: http://www.adminschoice.com/docs/crontab.htm

Style broken when installing Dokeos on one local computer then seeing it from another

A frequent question I’ve been asked is why, when installing Dokeos on a local computer, then trying to see it from another computer, the styles are broken (the homepage appears as a list of links from top to bottom).

This is all a question of Name Resolution (or DNS).

How you did it

The initial problem lies on how you did the installation on your local computer: you downloaded Dokeos, then took the easy way and installed it on “http://localhost/dokeos/”, or “http://127.0.0.1″, or even your local IP “http://192.168.0.15″ for example. Didn’t you?

Well, Dokeos remembers that, and asks you, during the installation process, what URL you want to access your portal with. You remember that?

Why this is a problem

As Dokeos remembered it, it will now serve the future pages as if they were starting with http://localhost, or whatever name you gave it during the first install. You can check that, from the other computer, by pressing CTRL-U in your navigator. You will see links like this for the query to the stylesheet (CSS): http://localhost/dokeos/main/css/dokeos_blue/default.css. Well, guess what… “localhost” for the secondary computer is not equal to “localhost” for the main computer. In fact, “localhost” on the secondary computer is pretty much itself, so he’s trying to look like this: http://myself/dokeos/main/css…

This means that the secondary computer is expecting Dokeos to be installed locally as well, which, in general, is not the case. If it was the case, you would probably get even more problems in the current situation anyway.

How you should do it

The *best* solution is to give the first computer (the server) a public name. This public name can be a public subdomain name (like courses.yourinstitution.com for example), but this implies an access to defining such a name. This name will be permanent and equal for all, so everybody will know where the computer is and you will define this subdomain name at the moment you install Dokeos, then use it with all the other computers. If you don’t have a permanent internet connexion, however, and you use an external domain name server (the one from your internet service provider for example), this configuration will not work.

The second best solution is to have a local name server and define a name for the Dokeos server on that local domain name server. This works like above except you don’t need an internet connexion for that to work. Sometimes, the router can act like a name server (see your router’s documentation).

The third solution (which is not one of the best one, but still works in a closed environment) is to make sure the server has a fixed, permanent IP address, and define a unique name for the Dokeos server (like say: “www.dokeos.local”) then define this name on every computer (including the server).

Under Linux, this is done by defining a line with the fixed IP address of the Dokeos server, a space, and the given local domain name (www.dokeos.local for example) in the /etc/hosts file (you need root permissions to edit this file).

Under Windows, the same file exists with the same format, but you have to look a bit deeper to find it: C:\Windows\System32\drivers\etc\hosts.

Don’t hesitate to report if you found a better solution.

The free software activist game – draft

If you are a free software activist like me and want people you expose free software to in conference, large meetings and other gatherings like that (preferably developer-oriented) to understand what the value of free software is, here is a game proposal for you to try out (please report on the success of this method if you do implement it). It is inspired from a recent SCRUM course we took here at BeezNest Latino.

General considerations

• You will probably need 30 minutes at a minimum to implement the game
• This should work for 30 to 150 people, which should all be in the same room
• You will have to explain the rules to each teams category separately (they can already start working one you’re done explaining, but they will have to stop exactly 10 minutes after starting)

Material

• 1 sheet of paper for each participant (can be a quarter of A4, or even smaller)
• 1 pen for each participant (this might be costly, so you can depend on each participant having one or having minimum 2 pens per team)

Preparations

• Try to use maximum 10 minutes for the whole preparation process, so max 2 minutes to get team leaders to line up in front of you, max 2 minutes for you to explain the rules to all categories, and max 2 minutes for them to get back to their seats and start working.
• Try to plan for enough space to give each team its own round-circle
• Plan to distribute pens and papers quickly and efficiently
• Assistants will have to form teams of 5 (minimum 5 per team, can be up to 8 but you’d better ask for 5)
• Teams will be split in three “types”: type A, type B, type C
• Give one paper and one pen to each participant
• In each team, there will be: 1 team leader, 1 salesman, 1 developer, 1 designer, 1 quality assurance guy (software tester)
• You (and ideally a few other guys) will represent the Product Owner: that is, you will receive the work done by each team, through the salesmen, and decide which is best for your company. The price is considered equal for each feature.
• If there are more people than what makes an equal number of teams in the three categories, assign more teams to category C

Rules

You will have to explain the rules to each category of teams at a time: first, teams A*, second, teams B*, third, teams C*. Try to give each team a number (A1, B5, C3, …)

The following rules are true for all teams, but there are a few rules specific to each team category:

All

• Will have 10 minutes to complete the game (develop one feature – you can imagine something appropriate to the circumstances here, or you can use the list of features suggestions below)
• The salesman will have to present his product to all product owner in 30 seconds
• The product owner will decide (secretely) which team won for each category, and will ask the other categories to vote as well (on the back of their paper, or by folding the paper in a specific way)
• All members of the group must write something on his paper
• Team leaders help the other members of the team who are having difficulties (they are the scrummasters)
• Salesmen make sure they understand the product and all its goodness (including quality and design)
• Developers make sure they describe the feature in many details
• Designers make sure they draw a set of screenshots for the salesmen to present at the end
• Testers make sure they test every detail of the system (including the user interface) and confirm with the developer and designer that every feature works
• Teams can choose whether to sell their software or the fruit of their work

Teams A

• Will be considered as representing companies being located in the same city, so they will actually compete very closely with the other teams in category A
• All of A teams will develop the *same*, proprietary, feature
• Team leaders and salesmen can “spy” on other teams

Teams B

• Will be considered as representing companies being located in different countries/states of your continent, so they will have to compete if they have a very competitive product
• All of B teams will develop different, proprietary, features
• Team leaders and salesmen can “spy” on other teams

Teams C

• Will be considered as representing companies worldwide which already have a competitive product based on open-source software
• All of C teams can decide to work with other teams in order to get several features back to their customer
• They can only sell what they developed directly, they are forced to “give away” the rest

Features list suggestion

• Store contacts
• Send an e-mail to a contacts
• Store an invoice
• Request the status of a stock of products
• Request information about a company
• Chat
• Find an address
• Show a street on a map
• Show a translation
• Find an image
• Find the definition of a word
• …

Ending the game

The assistants have to put their sheets in the hands of the salesmen and the salesmen will stand-up and go line-up in front of the stage, once the time is up for their category. Teams not sending their salesmen in line will be eliminated (they delivered behind schedule).

Each salesman comes in a line to present his product (30 seconds max). He says his team number (e.g. A3) and starts describing his solution. He stays on stage until all salesmen have given their description (should be 2.5 minutes max for 5 teams)

At the end of each category, the other categories vote for the best team. You count the vote (“Put your hand in the air, all people voting for team A3″) and declare the winner.

Note that categories A and B should not know that category C was able to share their work. This is why categories A and B will actually understand better the point of free software.

Conclusions

Whatever the results are, they should always tend to these conclusions

• a majority of teams of category C have performed better, because they were allowed to share, and they made an effort to learn from each other, while concentrating on its own customer’s satisfaction
• the salesmen are necessary because they are the ones through which the work of the team is presented. The best salesmen give a considerable advantage to its team
• sharing, in the same environment (which is a competitive international market), leads to better solutions than the equivalent non-sharing mode
• all assistants will have spent a good time

These rules are to be considered licensed as Creative Commons BY-SA (http://creativecommons.org/licenses/by-sa/2.0/)

A series of short, good articles about PHP

I just realized, through Chris Shifflet’s twitter feed, that there is a website called PHPAdvent, that gives a list of articles by celebrities or half-celebrities of the PHP world (including a few interesting ones about PHP advocacy).

http://phpadvent.org/2008

La formación, en la raíz del alma organizativa

El alma de las organizaciones

Just one exception to the English language here. I’m currently reading a short handbook by Javier Fernández Aguado, which was given to me by Josep Lozano, organizer of the infamous Expoelearning event in Spain when he came to participate in the Dokeos Users Days América in June 2009. The book is called “El alma de las organizaciones” and is describing what makes the spirit of organizations. In particular, there are two paragraphs which get close enough to what we are trying to facilitate with Dokeos:

El planeta se encuentra en mano de los audaces, no de los excesivamente cuerdos. El positivismo puro y duro conduce al pesimismo, tras avanzar por el lamentable camino [...] de los razonamientos paralizantes. En realidad, nos convertimos en profetas de nuestro propio destino: llegamos en cierto modo donde queremos llegar.

La verdadera sabiduría, fruto de una formación ampliamente asumida, reclama algo de ebriedad, de alienación verdadera (de alius: capacidad de hacerse otro, para contemplar la realidad con objectividad). Un cierto grado de locura es preciso para no limitarse a la reiteración apática y cuasi desesperante de lo ya intentado por otros.

I’m leaving it to the reader to translate this using Google Translate or whatever seems more appropriate, but it kind of confirms a few things I’ve been thinking about during the last few months.

PHP 5.3.1 is out

PHP 5.3.1 is out with around 100 bugfixes + security patches. See details here

Time tracking in Dokeos’ exercises for 1.8.6.2

Dokeos 1.8.6.2 will ship a new beta tool, the time tracker for exercises. It’s been asked for since 2004, as far as I can remember working on Dokeos, but I have always refused to start implementing it, mostly because it was a risky business to have to support a JavaScript widget with the lack of portable JS libraries.

Since the adoption of JQuery globally in Dokeos though, things have changed, and although *nobody* financed that development (which I am quite disappointed about, actually), we have taken the responsibility to put it inside 1.8.6.2.

This is one more big step in the run against Moodle, which seemed to loose speed constantly for the last two years (see activity graph on Ohloh), and for which we were always getting justifications like:

• more flexible (we still have some work to do on the graphical flexibility here)
• supports UTF-8 (technically, we now do this as well, and support might actually be better than in Moodle, we didn’t check that)
• allows for timed exams (1.8.6.2 will support that)
• is faster/more efficient (I am still waiting for data to prove argument and I seriously doubt it)

We are also working constantly on improving the time and scores tracking overall, as this is a highly sensible matter for most of us.

The rest of the features set that varies is generally considered moot (=not important/useless) by users in many cases, but we have a bunch of things that Moodle doesn’t have yet.

Now as we prepare for Dokeos 2.0 and Moodle 2.0, I’m growing more curious about how this is all going to work in the future.

Great speaker tips

Tips on how to speak in front of an audience, by Professor Patrick Winston of the MIT. Great resource if you are doing a lot of presentations, be them courses, commercial presentations, motivational talks or any kind of meeting where you are the main focus of attention, actually.

Working on online translation for Akelos

We are currently working on the development (or co-development, as a base was made available to us by the Akelos team itself) of a plugin to Akelos that fixes the current problems of language variables duplication, deprecation and need for a manual edition of the files.

There are still a few things to be fixed in terms of getting that into a production environment for Akelos instead of just the development environment, but we’re working on that.

Sakai tricky to install from normal Linux distribution

We have a student working for us on comparisons between various LMSes here, and we recently moved on to Sakai. We’ve been looking a bit at installing it on an Ubuntu 9.04 and boy… is this a challenge.

While there seems to be a few sources of documentation around the web (including on the Sakai website itself) on how to install it, they’re all giving a 20 pages-long guide on how to install a specific version of Java (from sources), a specific version of Tomcat (from sources) and a specific version of Sakai (from sources as well). It seems like you need to be an active Java developer, used to the Tomcat stuff to actually get a chance to install it.

Now that makes me recall our numerous users who complained about the fact that installing the videoconference in Dokeos 1.8.5 was impossible. Well, let me say that you require at least double the skills to install Sakai.

The website mentions there are packages for Windows, Mac and Linux, yet the link to the corresponding page is broken (why’s that, I wonder).

An article from a Java developer gives you the impression it is a breeze to install, yes we are talking about a previous, outdated, version of Sakai.

A big negative point for Sakai (yes, you can try it online, but obviously you might want to try out scaling and building your own site on a local server).