FatGeekUK

For the last 5 years I have classed myself as a Ruby on Rails developer. More recently, I realise I might possibly not be able to say that. I have been using Django a lot. I love RoR, but Django has some nice features. One of them is its ORM query mechanism, but things are changing....

IT, as in IT work.

I have been a professional coder (don't laugh) for over 20 years. Yesterday, My son(Alex, 12) and I where in the car, and as is natural, our discussion got around to copyright. Where it has been, where it is going, why it is as it currently is. During the discussion, I realised, I have run my career all wrong.

Every language has its rough spots.

Ruby for instance does not handle array slices very nicely.

>> a = [1, 2, 3]
=> [1, 2, 3]
>> a[0]
=> 1
>> a[0..1]
=> [1, 2]
>> a[2, 3]
=> [3]
>> a[3, 4]
=> []
>> a[4, 5]
=> nil


 

Now, thats evil. Why should a[3, 4] give you an empty array (which is expected) but a[4, 5] give you nil!

But, Ruby gets some things right.....

>> a='1,2,3'
=> "1,2,3"
>> a.split(',')
=> ["1", "2", "3"]
>> a = '1'
=> "1"
>> a.split(',')
=> ["1"]
>> a = ''
=> ""
>> a.split(',')
=> []
>>
  See that? an empty string gets you an empty array.

Theoretically, it SHOULD give you an array with a single empty text element, but it is nicer than that.

Not Evil.

Python on the other hand....

>>> a = '1,2,3'
>>> a.split(',')
['1', '2', '3']
>>> a = '1'
>>> a.split(',')
['1']
>>> a = ''
>>> a.split(',')
['']

Evil! pure and simple.

And lets look at slicing....

>>> a=(1,2,3,)
>>> a[0:1]
(1,)
>>> a[0:2]
(1, 2)
>>> a[0:3]
(1, 2, 3)
>>> a[0:4]
(1, 2, 3)
>>> a[1:4]
(2, 3)
>>> a[2:4]
(3,)
>>> a[3:4]
()
>>> a[4:5]
()
>>> a[6:7]
()
>>> a[7]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: tuple index out of range
 

In some ways that is better, slicing works nicely, but indexing a single element raises an index error.

Surely, if it is happy to slice the array outside of its limits and return a valid result, why not handle

accessing an element outside of the limits too?

 

I have written code in many languages (Basic, dBase, C, Sculptor 4GL, Assembler(many flavours) Perl, VBA, Javascript, Ruby and finally, Python.

For much of my experience of Ruby, I viewed Python as a sibling language. I thought Ruby and Python where rough equals in capability and complexity.

It took me about 3 months of Python coding to realise that this is very far from the truth.

Ruby and Python are not compadres, they are not friends, they don't work at the same level.

Ruby is much simpler than Python, it has far less 'language' there. For a start, python is a compiled bytecode language (you do notice all those PYC files all over the place don't you?).

That and its explicit binding mechanism (all those import statements at the head of a python file just make my ruby sensibilities scream!) make for a much quicker language than Ruby.

When you add to that all this stuff about decorators, metaclasses etc, that takes some getting used to. The whole idea that methods associated with an instance are actually method instances that need calling (forgetting @property for the moment).

When I read about that, my mouth started watering, there must be some REALLY interesting uses for that! But then I let it stew for a while.

Really, all that does is force the coder to recognise that there are properties and then there are methods, and to require the user to know the difference.

With ruby, you don't need that. Well, really, with ruby, there are really ONLY ever methods, this forces encapsulation much more completely than Pythons default behaviour does.

Looking more deeply into decorators and metaclasses, I realise that they are trying to give the same sort of versatility to Python that Rubys blocks give to it.

Blocks affect EVERY aspect of Ruby, without blocks ruby is a rather dull, flat language. With them, it is a rich, expressive language that allows for some truely lovely DSL applications. Python tries to get the same functionality from metaclasses, decorators etc, but it just feels that much more forced. Having to use several different but interlocking constructs to ALMOST do what Rubys blocks do. This MIGHT be as a consequence of limitations enforced on the language by its bytecode underpinnings, I don't know enough yet to be able to say.

So, I suppose my final word on the issue is that Ruby is NOT a sibling of Python, its probably more of a teenager to Pythons twentysomething. There is a LOT more depth to Python than there is to Ruby, but thats not because the depth brings anything extra, it's more because Rubys simplicity is sufficient for the task. Python IS faster though, and probably always will be.

The later the binding, the slower the runtime performance.

I have been spending a lot of time writing Django code (as you have probably noticed). In the past, I have been quite derisory about Django, there are many things that I don't like. Djangos ORM is NOT one of the problems. Well, fundamentally, it isn't. On the surface it stinks. So, lets get the nasty out of the way first. Some examples. In Rails, how do I find a particular instance if I know the ID? instance = Model.find(123) in Django instance = Model.objects.get(pk=123) Thats UGLY. This whole idea of managers, is a nice idea, but it is not entirely pretty. Now for the good thing. in Ruby if you do... object_list = Model.find(:all) you will get a big array filled with instances of all the objects in the database. Needless to say, this can SWALLOW your system. So, you have to be careful with AcriveRecord::Base, you get what you ask for, and if you ask for the moon, your system will fall to its knees and die. in Django if you do.... object_list = Model.objects.all() You will get an object that pretends to be an array, and only when you access chunks of it will it actually go over to the DB and pull back the required information. Thats NICE. BUT, it means you have to be a bit more careful, as it lulls you into a false sense of security. You have to remember that if you DO ask for the list of objects, you WILL get them. So, you have to remember. In rails, you know up front that you have to be careful, so its not quite as nice, but you aren't coddled. So, I do like Django models, it works in a more scalable fashion than Rails' ActiveRecord:Base. This leads me down the road of drawing comparisons between Ruby and Python. But thats the subject of a whole nother post.

Well, well, well, Typo 5.3 was broken. Typo 5.4.1 works again, finally. Welcome me back. I have much interesting information from the world of Django. I will be posting some interesting ideas in the next few days

Django is a good framework, but some things it just gets wrong.

Let me explain.

Django does not have STI, they claim this is because STI is a bad idea. Ok, fair enough, they have stated their position, and given an alternative.

MTI.

Right, so, lets look at this.

When you request a set of objects that are supported by MTI,
what do you get?

A heterogenious list of objects each having the right class?

No, you get a homogeneous list of objects which all have the BASE CLASS.

They say, that is because you are saying that you are defining that all these objects satisfy the contract that the definition of the base class defines. BUT, the issue is that if you call a method
of one of these objects IT IS THE BASE CLASS! Irrespective of whether the subclass overrides one of these contracted methods or not. Thats not requiring satisfaction of a contract, thats BREAKING OO.

You CAN make an amended Manager class which will automatically find the correct subclass and return that instead.

Oh, wait, if you do, all sorts of things stop working. Because the
system expects managers to return base classes and if they don’t
they start failing. Not failing with an error mind you, just spinning their wheels in infinite loops as they attempt to resolve objects back to base classes.

So, instead, you have to remember to litter your code with explicit casting. Yes, you can make your casting relatively painless by creating a ‘resolve()’ method that will hunt through the subclasses looking for the right one, but come on! we all know this will end in tears.

So, MTI, nice try, but epic EPIC fail.

Sometimes, getting something pure 99% right is worse than getting something simpler but impure 100% right.

I am working on a project that is using Django.

We have decided to use ‘South’ which is a migration framework which tries to do for django what rails has out of the box.

This is the first posting of many in what will be a series of rants against django, python, stupidity and pride.

First off, lets look at south.

Django models explicitly define the field structure of the table that is going to hold the objects. Now, I quite like that. It means that if I want to find out what fields a model has, I can look at the object definition. Rails does not have that. fields are defined in the db, and, only in recent rails versions is a comment added to the beginning of your model files detailing the structure.

Now, along comes south. and because the structure is explicit, it tries to do something neat. It will attempt to auto-generate the migration for you by introspecting the previous database structure and comparing to the current one. When I encountered that I thought it was lovely, neat, useful, clean.

BUT IT DOES NOT ALWAYS WORK.

It recognises when you ADD things but not when you take them away. So, if you remove a field, when you generate the migration, it sees it, updates its own copy of how the structure should look, but does not emit the code to remove the field from the database.

Ok you think, thats ugly, but not too bad right? The structure of your objects is still correct, you just have an unused column in your table? yeah? huh? huh?

NO.

Your models are broken because even though the structure of your objects is declared explicitly in your model code, when Django instantiates the object from the database, it IGNORES the defined structure in the model, and instantiates the object with all the fields from the database table. And then continues to use those fields as if they are meant to be there.

What TOSH.

Next time….. “Django templates, or ‘how to go quietly, or not so quietly insaner’”

hehehe, now I have your attention….

A friend posted a link to a computerworld article

Reading that, I could not help but point at the screen every few paragraphs and shout “YES”.

Dead on. A must read.

Lovely article about schedules….

Here

His comment about two work days is useful. but I can’t help feeling that is problematic.

1) managers seeing their creatives drifting in at noon when ‘I have been at my desk since seven AM godamnit!’

2) In a startup, doing that is one thing, where there is potential reward, but in a normal work situation, doing that additional time, and probably getting no personal benefit from it, because your manager thinks you are only doing 1/2 a day…

Possibly scenario, the project gets into time crunch, and the management send down an edict that all creatives MUST be in by 7am (thus expanding their work day and hopefully, solving the project time problem)

There needs to be clear understanding as to why and when this is appropriate. It can’t just be something the creatives do on their own backs.