Testing the RuneStone interactive Python courses server in docker

I’ve been working on setting up a Docker container environment allowing to test the RuneStone Interactive server.

RuneStone Interactive allows the publication of courses containing interactive Python examples, and while most of the content is static (the Python examples are run innside a Python interpreter implemented in JavaScript, hence locally in the JS VM of the Web browser), the tool also offers an environment allowing to monitor the progress of learners in a course, which is dynamic and is queried by the browser over AJAX APIs.

That’s the part which I wanted to be able to operate for test purposes. As it is a web2py application, it’s not exactly obvious to gather all dependencies and run locally. Well, in fact it is, but I want to understand the architecture of the tool to be able to understand the deployment constraints, so making a docker image will help in this purpose.

The result is the following :

Now, it’s easier to test the writing of a new course (yet another container above the latter one), and directly test for real.

BoF “retour expérience enseignement Python” lors de la PyConFr 2014

Nous avons organisé une BoF “retour expérience enseignement Python” lors de la PyConFr 2014 à Lyon.

Cette BoF s’inscrivait dans la continuité des présentations du thème Enseignement / Recherche de la conférence.

Environ 40 participants ont pris sur leur temps de pause (merci aux organisateurs de nous avoir fourni des sandwiches de façon prioritaire) pour partager des éléments de retour d’expérience.

Voici quelques éléments qui m’ont semblé intéressants, qui pourront peut-être vous intéresser, qui ont été abordés durant la BoF, ou que j’ai collectés dans les présentations de la matinée (j’ai un peu délaissé l’amphi de l’après-midi, pour aller discuter avec quelques connaissances aussi présentes à la conf) :

  • enseignement :
    • deux environnements assez populaires : IPython notebooks, et Sage. Le deuxième éventuellement intégré avec le premier (SageCell). Les deux permettent d’avoir une interface Web qui semble offrir un certain avantage pour une population d’apprenants “génération FaceBook” qui trouve facile de rentrer du texte dans des zones de saisie d’une page Web (contrairement à des environnements type ligne de commande ou éditeurs plutôt effrayants). Avantage de disposer de LaTeX ou de texte (et plus) et de code dans un même document.
    • Même si Matlab reste assez utilisé dans certains labos (poids du legacy), l’enseignement semble pas mal passer à IPython, même si certains inconvénients existent parfois (plantages des kernels avec MatPlotLib, par ex.).
    • Livre : Calcul mathématique avec Sage
    • Les notebooks permettent de rendre la programmation vivante : le prof tape le code : montre les erreurs, les typos, etc. Rend le
      processus plus accessible.
    • Côté notation des devoirs, corrections deux solutions en environnements MOOC avec de nombreux apprenants :
  • Recherche :
    • le LaTeX embarqué dans des Notebooks IPython amène certains à s’y intéresser alors qu’ils n’y viendraient pas naturellement (“elle
      est belle ta formule, t’as fait ça comment ?” : double clic, et hop 😉
    • On commence à croiser des Notebooks IPython en matériel supplémentaire pour des publications académiques

Using RDFAlchemy together with RDFLib’s SPARQLStore to query DBPedia and process resources in OO way

I’ve been searching for interesting ways to manipulate RDF graphs in Python, to create an application that would handle Linked Data Resources in an OO-way, i.e. using Python classes and not tables/sets/lists of triples. The data will be persisted in graphs in a triple store, accessed through a SPARQL enpoint.

In this post, I’ll illustrate how I managed to tie RDFLib’s SPARQLStore plugin and RDFAlchemy to reach a rather nice looking result.

Continue reading “Using RDFAlchemy together with RDFLib’s SPARQLStore to query DBPedia and process resources in OO way”

Working on a TWiki to MediaWiki converter (targetting FusionForge wikis)

I’m currently working on a wiki converter allowing me to transfer old TWiki wikis (hosted on picoforge) to MediaWikis hosted on FusionForge.

Unlike existing tools that I’ve found that more or less target the same needs, mine will address two peculiarities :

  • using MediaWiki’s API to perform the import, where many tools seemed to use SQL requests: this should allow non-administrator users to do the job,
  • importing to wikis of projects hosted on FusionForge instances, even when the project is not public, which means that the API calls need to authenticate to FusionForge first.

The tool is written in Python, and will include my own crappy wiki syntax converter in Python, instead of spawning existing Perl scripts, as others did.

It may happen to work for FosWiki too, but I don’t intend to use it beyond our old TWiki installations, for a start.

Stay tuned for more progress updates.

Edit: I’ve now released a first version.

Publishing RDF views for tastypie/django resources

Here’s some documentation about a hack I’ve been working on to allow publication of RDF views for Tastypie resources (in Django applications).

While working on implementing support for RDF meta-data for descriptions of Debian packages for the Debian Package Tracking System rewrite, I’ve tried and idetify which libraries/frameworks would allow to create some RDF views for Django model objects with a minimal effort.

Ideally, this would save the hassle of writing code, and could just be a matter of mapping some Django model fields to proper ontology attributes.

I haven’t found an existing tool to do so, but it seemed to me that Tastypie could offer a nice starting point. Tastypie (I focused on v. 0.9.15 which is currently in Debian testing) offers some REST content-negociation support, and other niceties.

This post is an attempt at documenting an initial implementation for my problem. I’ve implemented it as some code in the example blog application described in the Tastypie documentation. Unfortunately, it’s not yet a patch that could be applied to Tastypie, to add this as a standard feature.

The code is available in my git clone of Tastypie, based on 0.9.15, and lies in the commit(s) between the example_myapp and rdfviews branches. It needs an up to date RDFLib to work (Debian’s is too old, btw).

It basically relies on the addition of a _rdf_mapping dict in the Django model objects, and an RdfModelResource as a base class for Tastypie ModelResources.

To provide an RDF view for a ModelResource, it also requires to declare a particular MetaClass, and adding a few bits to its Meta subclass.

The principle is that the dehydratation steps of the Tastypie system will replace fields values by their RDF objects counterparts, as either RDFLib Literals or URIRefs. Then the resuting Bundle will be converted to some RDFLib Graph. It is then just a matter of serialization of that Graph to turtle (I’ve not added another format, but it should be pretty straightforward).

There’s a bit of hackish drak magic in the code, in particular when introspecting the Tastypie / Django resource / model objects to be able to dynamically add some dehydrate_FOO methods to perform the conversion to Literals or URIRefs.

Custom dehydrateFoo methods can still be written to process the fields in particular ways.

I’ve added some LDP style paging along the way, so I hope it will be quite usable by LDP compatible tools.

Here’s the result :

First, listing all resources :

$ curl -H 'Accept: text/turtle' "http://localhost:8000/api/v1/entry/"
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

</api/v1/entry/#list> dcterms:hasPart </api/v1/entry/1/#post>,
</api/v1/entry/2/#post>,
</api/v1/entry/3/#post> .

Then, details of one particular post :

$ curl -L -H 'Accept: text/turtle' "http://localhost:8000/api/v1/entry/1"
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

</api/v1/entry/1/#post> a sioc:Post ;
dcterms:created "2011-05-21T22:46:38+00:00"^^xsd:dateTime ;
dcterms:title "Another Post" ;
sioc:content "MESSAGE: This will prbbly be my lst post. /MESSAGE" ;
sioc:has_creator </api/v1/user/1/> ;
owl:sameAs </posts/another-post#post> .

I hope this is usable, and welcome any feedback.