La trappola del Sorcio

Guardo con affetto e comprensione i fanboy di Star Wars agitarsi paventando agghiaccianti mashup come quello della foto:

In fin dei conti stanno passando quello che tutti noi ammiratori di Tony Stark & soci abbiamo passato nel 2009, quando La Casa del Sorcio Michi ha acquisito Marvel entertaninment, tre anni dopo l’acquisizione di Pixar. Proprio l’altra sera si discuteva al Pub con Gambadilegno e Macchianera di come non ci sia niente di nuovo sotto il sole, in fin dei conti sono anni che il Sorcio ha le redini in mano: tutti i geek verranno assimilati. A tal proposito, nel pacchetto costato 4.05 miliardi di dollari ci sta pure la Industrial Light&Magic, che dovrebbe occuparsi degli effetti speciali del prossimo Star Trek di JJ Abrams.

Topolin, Topolin, viva Topolin!

Advertisements

Your private PyPi on OpenShift

There are a lot of reasons to run your own,  private Cheese Shop and one of these is distributing code and packages you don’t want to publish because either proprietary or for internal use in your company. Does it worth it installing and configuring a server, setup some pieces of software, keep the service up and running? Yes and no: there are other simpler ways to distribute your reserved python stuff. But what if you could deploy and run shuch an application in, let’s say, 10 minutes or so? Let’s do it the OpenShift way.

How do I setup my own PyPi?

Just create an account if you don’t already have one and start an application called, let’s say, “pypi” with a “Python 2.6” web cartidge. Then clone the application repository locally:

git clone ssh://blabla@pypi-yourdomain.rhcloud.com/~/git/pypi.git/

cd into the repository, add the PyPi Example repo as a remote and pull data from it

cd pypi
git remote add upstream -m master git://github.com/masci/pypi-example.git
git pull -s recursive -X theirs upstream master

Now you’re ready to push your app to the gear:

git push

Done. Go to http://pypi-yourdomain.rhcloud.com and enjoy your private Cheese Shop. If you want to login in the admin use admin/admin credentials. The default configuration protects all the pypi related urls with user authentication, performed with HTTP Basic Auth so you can smoothly run pip or easy_install which will ask you for an username and a password.

How do I install packages from my own pypi?

pip install -i http://pypi-yourdomain.rhcloud.com/pypi/ your_secret_package

How do I publish packages to my pypi?

Write these lines on the file ~/.pypirc

[distutils]
 index-servers = mypypi
[mypypi]
 repository: http://pypi-yourdomain.rhcloud.com/pypi/
 username: admin
 password: admin

And register your package

cd yourpackagesource
python setup.py register -r mypypi sdist upload -r mypypi

Advanced use

PyPi Example is, how may I say, an example app, not exactly a production ready system (well, it depends on your needs). Nevertheless it serves media files through authentication with django-sendfiles so you can play a bit with its backend to improve performances. It handles authorizations, so you could add user and groups through the django admin and state who can do what. The application is based  on djangopypi, so you can rely on a rather active opensource project for the pypi part. And even if you don’t need a private PyPi you could always take a look at the code and see how it works an almost unattended django deployment on OpenShift.

Serving Django media files in OpenShift

As you may already know, setting up a Django instance on the OpenShift platform is a matter of less than 5 minutes.

Through the web management console you can create an  application using the “Python 2.6” web cartridge thus setting up a gear to host (guess!) a Python enviroment. You clone the gear repository, add the Example App code as a template, push the repo and you’re done.

There’s a folder in gear’s filesystem called data designed to contain files you don’t want to lose among application deployments. This storage is perfect for containing files that users upload through your Django application, and the settings file provided by the Example App is aware of this:

# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = os.environ.get('OPENSHIFT_DATA_DIR', '')

The OPENSHIFT_DATA_DIR environment variable is always available inside your gear and contains the absolute path to the data dir.

File uploads work out of the box but problems arise when you try to access files contained in the MEDIA_ROOT folder –  by default Apache serves the files contained in <app>/wsgi/static but knows nothing about the data dir located at <app>/../, so you will likely get a 404 trying to access files under the MEDIA_URL. To workaround this problem you can redirect requests for MEDIA_URL to STATIC_URL and symlink the data folder from the static folder.

To redirect requests, create a .htaccess file in the <app>/wsgi folder containing exactly these lines:

RewriteEngine On
RewriteRule ^application/media/(.+)$ /static/$1 [L]

If you manually make the symlink in <app>/wsgi/static,  it will be lost on the next deployment (remember? Only data folder won’t change) so you better let OpenShift do it for you during application deployment. Open the file at <app>/.openshift/action_hooks/build and add the following lines:

if [ ! -d $OPENSHIFT_DATA_DIR/media ]; then
mkdir $OPENSHIFT_DATA_DIR/media
fi

ln -sf $OPENSHIFT_DATA_DIR/media $OPENSHIFT_REPO_DIR/wsgi/static/media

That’s it, commit and push the modifications above and grab files from your media folder.

Trenitalia merda

Appena tornato da Madrid. Ave, Metro, Cercanias… un’esperienza con il trasporto pubblico mai stata più felice. Trascorse poche ore dall’ultimo viaggio fatto con Renfe è una doccia bollente (visto il periodo) cercare di acquistare un biglietto su trenitalia.com. Riassumo brevemente:

  1. Provo ad acquistare, mi obbliga a creare un account.
  2. Creo l’account, mi obbliga a cambiare la password.
  3. Cambio la password, quella nuova non funziona.
  4. Me la faccio rispedire, mi arriva in chiaro tutta uppercase.
  5. Provo la password uppercase, niente.
  6. Cancello l’account.
  7. Reitero dal punto 1), niente.
  8. Provo a creare un nuovo utente, userid: porcXXXio
  9. L’utente porcXXXio è già preso, chissà da chi e perché. Ok, vado in stazione a fare i biglietti.

Por el partido de futbol de mañana staremo a vedere, intanto l’europeo della civiltà l’abbiamo già perso.

Deploy Django on a subdirectory (or a subpath) with mod_python

It doesn’t matter for how long you’ve been using Django – as much as you think you know it, at some point Django will surprise you transforming simple tasks into issues taking hours to be solved. I’ve never had the need to deploy a Django instance anywhere but the root of the domain name (e.g. http://example.com/myapp). Till last weekend, when I spent almost two hours to figure out how to do it without making a mess of the urls.py module (configuring Apache and mod_wsgi to serve a subpath was straightforward and it’s not covered by this article).

Actually Django does a really good job handling URL prefixes and, to be honest, I wouldn’t write these lines if I didn’t make use of the bittersweet Django Admin. AFAIK, problems arise in the following:

  • Your webserver does not set SCRIPT_NAME environment variable
  • Using the django-admin
  • Using {% url %} template tag
  • Using @login_required decorator

For the latter there’s a quick solution: set LOGIN_URL and LOGOUT_URL variables in your settings.py with the desired url path. In all the other cases, you’ve to play with the SCRIPT_NAME environment variable,  defined in CGI standard, which holds the request URL’s path which points at the application target. Well hidden (IMHO) at the bottom of this page you can find a quick and clean solution to manually set the SCRIPT_NAME variable: just define FORCE_SCRIPT_NAME in your settings.py, e.g. FORCE_SCRIPT_NAME=’/myapp’ without the trailing slash. That’s all.

Milliways, the game at the end of the Universe

Milliways is a game developed for the “5 BUTTONS Competition” (follow the link for the details) contest hosted at experimentalgameplay in collaboration with 02L. Games have to support UnitaZero as their one and only input device, and that’s the fun part!

Basically it’s a cooperative puzzle game (2-5 players) in Tetris style: a row of 5 dice fall to the bottom of the screen and each pad change the face of the corrisponding dice when triggered. When all the 5 dice shows the same face the row disappear. If the rows reach the top of the screen the game is over (you know how Tetris works, don’t you?). Game concept and development are very simple but players’ interaction could be interesting (or I hope so).

Tracks played during the game are courtesy of  The Shaidon Effect, the rest of the components is in the public domain or has a CC license.

The game was developed using Python and Pygame, the code is open source and you can find it here: https://bitbucket.org/masci/milliways/

I wrapped-up a Windows executable with PyInstaller, tested only on a Win7 Pro SP1 machine: http://dl.dropbox.com/u/6417369/milliways.zip

The game is named after “The restaurant at the end of the universe” –  I was reading that novel during the early development.