An overview of Ruby on Rails from a Django user

So Ruby On Rails is worshipped as the best thing to develop a web-application after sliced bread, so I’ve decided to take a look at it. Ruby on Rails use an Model-Controller-View (MVC) pattern, which has the goal to disentangle the way you represent the data with the data itself. It may does not make too much sense, but trust me, it does.

The MVC paradigm is also used in Django, which is a python web-framework which uses the same principle and which I’m familiar with, given the fact I’ve picked it up to develop the SustainableSouk.

So the first thing I needed to do is to map my Python knowledge to Ruby, and my Django knowledge to Rails.

Difference in the languages

Ruby is a dynamic typed language, with an interpreter which takes care of the garbage collector and so on. Both languages are strongly Object-Oriented, and mostly they work in the same way, however there are some little difference which are good to point out: (1) the return value at the end of one method, (2) the difference between puts and print

Talk is cheap, show me the code — Linus Torwalds

The same class in Python and Ruby

As you can see, the languages are amazingly similar at first glance.
Ruby does not care about indentation, but it defines the logical code with a keyword at the beginning (class or def for example), and it closes them with the end keyword.

The other major difference, at this level, is the implicit return of the method. In Ruby every method return the last line. And puts covers the same function of print.

The frameworks

Well, let’s move on on Rails, are we not here for that?
Rails ships with rake tasks, which makes very quick to throw the scaffolding of a project in no time (rails new my_project). This is similar to the django startproject command for djangonauts.

Ruby is all about configuration, and somehow resembles a lot django. You have a controller (view in django) function which gets called when a certain url match a certain pattern, defined in the config.rb (urls.py in django). The main difference is that ruby gives a lot of urls for free using a RESTful scheme.

So the best way to get used with a system is to create something, so I set up a repo to do just that.

The process is quite straightforward, especially if you already know HTML5, CSS, SCSS and Javascript which are assets you can re-use in the rails app. I’ve deployed the demo app on heroku here

Summary

Moving from Python to Ruby, and from Django to Rails is not a too big jump, and I reckon, at least at the beginning when you don’t go deep into other libraries, you can get quite up to speed pretty soon. At the end, it’s more or less the same way of thinking.

P.S.: If you are in Cambridge and interested at Django, HTML5 and so on we have set up a Django Cambridge Meetup and our first event-get-together is going to be on the 17th of October. I hope to see you there.

How to push to two different git repositories in one go

Branching illustration

Branching it’s good:
http://git-scm.com/

With the new release of Neuronvisio (0.8.3) we have improved the documentation, gave the software a new home (http://neuronvisio.org) and created a new fork under the NeuralEnsemble orgs.

I think for Python and Neuroscience it would be good to have a website similar to http://pinaxproject.com/ecosystem, to give visibility to the different projects and avoid to re-invent the wheel, however for now using the same space in NeuroEnsemble orgs it’s a good start. I didn’t want to move or transfer my repository there directly,  but I wanted to have a mirror of my repo https://github.com/mattions/neuronvisio in that space, without having to manually update it. I’ve looked how to open a mirror fork on github, but to no avail. So I came up with a possible solution, using the ability of git to push to different repositories.

My solution was to create a new remote point, called all in the local git config (.git/config in your repo) with the following format:

[remote "all"]
url = git@github.com:mattions/neuronvisio.git
url = git@github.com:NeuralEnsemble/neuronvisio.git

This way I can push to both the repos with a single command

git push all

Both the repos will be updated in one go. Neat.

Profiling python app

If you have to profile application, in python for example, it’s good to read this blog post which I found very useful information.

The profile is used to compare pytables, a python imlementation of HDF5 and pickle, which is a classic choice which you ran into if you are dealing with saving big files on the harddrive.

The best tool so far seems to be the massif profiler, which comes with the valgrind suite. How valgrind works:

This will run the script through valgrind

valgrind --tool=massif python test_scal.py

This produces a “massif.out.?????” file which is a text file, but not in a very readable format. To get a more human-readable file, use ms_print

ms_print massif.out.????? > profile.txt

So I’ve run some test to check the scalability of HDF5.

import tables
import numpy as np

h5file = tables.openFile('test4.h5', mode='w', title="Test Array")
array_len = 10000000
arrays = np.arange(1)

for x in arrays:
    x_a = np.zeros(array_len, dtype=float)
    h5file.createArray(h5file.root, "test" + str(x), x_a)

h5file.close()

This is the memory used for one array

 

profile_one_array

Profiling one numpy array

This is for two arrays

profile_two_arrays

Profiling two numpy arrays

Four arrays

profiling_four_arrays

Profiling four numpy arrays

And this is for fifty

profile_fifty_arrays

Profiling fifty numpy arrays

As soon you enter the loop the efficiency is preserved in a really nice way
Summing up:

  • one ~ 87 Mb
  • two ~ 163 Mb
  • four ~ 163 Mb
  • fifty ~ 163 Mb

So the problem is not on pytables, but it lies somewhere else..

Python 3.0 . Here it comes…

Python 3.0 is out. Has been released yesterday and the first production stable release is ready to be grabbed. This release breaks the compabilities with the 2.x series. Nothing will work anymore :)

Things that I would like to to underline:

  • The print statment becomes a function (so you need the brackets) print "Hello World" becomes print("Hello Wolrd")
  • dict.keys() or dict.values() give a view that is a “lazy” list read-only. It’s an iterator and you cannot pop stuff out of it. If you need a proper list you have to force it with list(dict.values())

So take a look on the documentation to have a proper idea of what’s going on, read this small paper to know why there was the need to do this change and before start screaming around check this blog post too that give a clear answer to the question: “What to do about the python 3.0?”

Have fun with the new python….
I mean HH :)