Schedule A

A few years ago now, Guido van Rossum endorsed Django by saying it was his personal favorite. At the time I had read the docs once and kind of tried it, but something rubbed me the wrong way. There was just too much structure, which for whatever reason didn’t fit what I was trying to do at the time. I didn’t really understand why Guido preferred Django.

About a year ago I started working with Django to make more complicated applications. It so easy I started producing little productivity web apps for my own purposes. I discovered Django was very usable for rapid development, but I still didn’t have the perspective understand how Pythonic Django was.

Currently I am working on a major project in Pylons, a loose framework based on WSGI. This experience has given me something to contrast Django with and now I see why Guido would describe it as Pythonic.

Though it has been mentioned that there is some magic in Django, I find when it comes to the important things Django is very explicit. In contrast to Pylons, Django is explicit in request, response, template context and helpers. In Pylons these objects are treated as global.

A view/controller, which in Django is just a callable instead of having to be a method of a class, receives the request as an explicit argument. The view’s job is to return a response object. Django provides shortcuts to make this as easy as rendering a template, but fundamentally Django takes a request and returns a response. In Pylons these objects are global, which makes concept like what if I call another view/controller while I am render a given view/controller unsettling. It is unclear what magic is going on behind the scenes.

More importantly in Django you have explicitly define the context you are passing into your template in one place. You can create a special context which includes some data from the request, but even this must be done explicitly. In Pylons the context is global and comes with baggage–various pre-defined objects which are handy to have in a template, but not really knowing how they get there makes things feel more magical. It also mean you have to look in many places to see what names are available in the context for a template. The interface between template and view/controller is probably the most important to be clean and clear, especially if you consider that the people writing the templates should probably be distinct from the people writing the code.

Finally sometimes you need to do more complex things in templates, and you need some help. In Pylons help in a template comes from h, which represents a projects lib.helpers module. This is a relatively un-namespaced holding area for every bit of helper code you might want. In contrast Django makes you explicit declare you are adding special template helpers (new tags and filters) to a given template. That means in a given template (or template hierarchy) you can know which helpers you are using. This is a place where Django could be even more explicit and use name space even more name spacing.

Fundamentally all of this plus clearer url dispatch means that Django is both more explicit and more able to handle re-usable apps. Since explicit is better than implicit, that would make Django more Pythonic. Now, I think would agree that Django is my favorite as well.

Or why I dislike MasterCard® SecureCode™.

My girlfriend and I had a simple goal, to pay too money much to watch 19+ showing of a movie in nice comfy seats. Cineplex has a new class of service called VIP, which is , well very European. You get to pick your seats, drink alcohol, and eat food which is claimed to be slightly better. All and all VIP movies are interesting, and work really well for couples. I guess the “echo” generation is coupled enough for this kind of thing to work.

We thought we would buy the tickets online. It would be easy, we would avoid the lines and even get to pick our seats. Only problem is they make is that Cineplex don’t make it all that easy. I will admit that sane payment systems are difficult to write, but I think it is worth the effort.

First you have to create an account on their website, which isn’t so bad, and you only have to do it once. Next you can actually pick your seats in the cinema, which awesome, except their seat holding algorithm is flawed. Next comes payment. Since I don’t bank with a bank that provides online debit I am left to resort to my Master Card. I buy things online all the time using my Master Card, and normally it is really easy, but other times I see a little logo which reads “Secure Code” and a little part of me dies inside.

Security codes are awesome, except when they are used so rarely that the user you are trying to verify doesn’t ever remember them. For my Master Card I have a PIN I can’t change, this Secure Code, and my trusty signature. That is two separate things to remember, and I only need to remember my Secure Code maybe 25% of the time online.

The other problem with Secure Code is its implementation. Something magical happens and the merchant’s site passes control over to a site I might guess is generated by my bank. Then if I am really lucky control will be handed back and the transaction will continue. More often I fail after about 3 tries, being too suborn to admit I forgot the code, and I end up in the merchants failure case which in the case of Cineplex, is nothing. I don’t get bounced backed. I can’t try again. Don’t pass Go, don’t collect $200.

I could start over from the beginning, but when I get back the Secure Code page it says I have already failed! No chance to try again. Here I am reserving seats, and my bank already knows the transaction is doomed. I am thankful for the security, but I want to watch a movie here. Meanwhile Cineplex thinks the seats I just failed to buy are still taken, so every time we try again our previous favourite seats are unavailable. Even waiting didn’t seem to open up the seats back up. Which implies you could probably reserve a whole cinema who out paying for any seats if your tried hard enough.

In the end my girlfriend was able to buy us tickets. She also didn’t remember her Secure Code, but she admitted it sooner.

We made it to the movie and enjoyed our leather seats and drinks. But I am left wondering why did it have to be so hard.

Businesses which make giving them money easy, make more money and have happy, loyal customers. Look at Amazon or Apple, they are pros. I have probably spent well over $200 on iTunes since they removed DRM from the music library, and I barely realize it. The experience is instantly getting the music I want to hear, not trying to figure out how to pay for.

My iPhone tethering story begins a few months ago when someone from Fido called me to ask me if I would be interested in a super convenient 3G USB modem to connect my laptop to the cellular network for a cost of about $30 a month. I asked him why would I do that if I have an iPhone data plan already which give me 6 GB for $30 a month, which about 2 orders of magnitude more than I actually use a month. I thought the only reason was it would be against my contract, but the guy from Fido told me it wasn’t against the term of service, and if I googled it I could find a YouTube video explaining how to turn on tethering on my phone. That is, despite not being officially supported, tethering wasn’t precluded.

I found a Fido employee telling this strange to say the least, but I looked it up and I found there are urls you can go to with your iPhone the which will attempt to install a small configuration file on your iPhone. All you had to do is say it is trust this one small piece of unsigned code, and bang, you get the ability to turn on tethering. You don’t even have to jail break your phone! The trick is that the iPhone OS as of version 2 (I think) supported tethering natively, it just happens to be disabled. My iPhone OS was at version 2.x, I had tethering, all was well in the world.

Then came the update to iPhone OS version 3.x. I was excited to get some shiny new features so I bought in, hook line and sinker. Shortly after installing I noticed my ability to tether was gone. I looked around for some fixes, but there were none which worked. The update prevented the installation of unsigned configuration files under certain conditions, and the dream of tethering with Fido was dead.

I was willing to wait until the next hack. Something would appear that would let me use the device I bought from Fido in a way which they didn’t disallow. But then something surprising happened. Tethering starting to work again.

It is hard to me to be sure why tethering started working again, but based on the time it happened, I have an interesting theory. At the beginning of October I took a trip to The Netherlands to attend my brother’s PhD. defence. While in The Netherlands, I kept my data roaming off, but used my international roaming a bit. I synced to the local 3G network there. When I got back to Canada I noticed that tethering was working again. My theory is that being on a far more permissive network like the one in The Netherlands allowed the unsigned piece of configuration to take hold again.

So there is an easy fix to the Canadian iPhone OS 3.x tethering woes. Fly to The Netherlands. It will only cost several hundred dollars.

From now on, I am not going to update my iPhone unless I know there is a tethering solution. I wish didn’t have to worry and my carrier just allowed me to tether. Hear that Fido… I just want to be able to tether.

Tether.

Parts of the following post maybe considered illegal under some implementations of copyright law.

After a fair amount of public pressure, the Canadian government is holding open consultations about copyright all over the country and online. There is a lot to be said on the topic copyright by people far more involved then myself. One of those people is Lawrence Lessig. When Professor Lessig talks about copyright he often discusses that mash up, the act of mixing existing pieces of media together to make a point, is fast becoming an important tool of expression. This can be compared to quoting text, something which is deeply fundamental to how we communicate today.

You might be skeptical about such an idea, but in the recent reaction to the leaked proposed new UW logo one can see how important it is becoming. The leaked logo appeared on Facebook and the reaction was large. It featured many statements of opinion and some debate, but the part people will remember, the part most people had the time to look, at were the hundreds of mashed up images. Let look at one featuring the draft logo.

Which compare to the classic coat of arms, the new logo is a bit… flashy?

It is very different

Which isn’t necessarly a bad thing. But it is kind 80s.

They wanted something modern, but we were left with lasers.

Lasers and robots.

Or you can combine 80s and lasers.

Or more abstractly.

Then it was beyond the internet itself.

Finally one of the best way to communicate the issue some had with the logo was probably the development of this cheer.

From uwlogo

Whatever you might feel about the logo, the point is there was a reaction, and the way in which people expressed themselves was through mash up. All of these images could be said to be breaking UW copyright. Under difference circumstance and certain copyright law an organization like UW could sue to get the expression censored. In a world where copy bits creates this new kind of expression we have to re think our copyright laws. Imagine if quote text was illegal. How well would our society function? Additionally my republishing of these images is done without the express permission of the creators. If anyone wishes me to remove their work, just let me know.

This huge reaction, mashed up images and all, even prompted the University to rethink their new logo. I want to suggest this form of expression needs protection in any new copyright system.

As I mentioned in my last post, Jess and I are moving to London, Ontario. Moving, of course, is everyone favorite activity. With moving usually comes an attempt to downsize the amount of stuff one has, and we are no different.

We are looking to sell various forms of electronics, appliances, and a bit of furniture.

The details can be found on my stuff stuff page. Or you can shop by pictures on one of my Picasa web albums.

source

Jess and I are moving to London, Ontario.

Jess will be doing her Masters in Molecular Biology at the University of Western Ontario. I will continue to work for McAfee in Waterloo. Commuting will be tough, but I am planning on some interesting strategies to try to make it work.

We are both very excited to be going on a new adventure and living a new place. We will miss our friends in Waterloo and are looking forward to visiting. In two years when Jess’ Master is complete, we intend to come back to Waterloo, but really only time will tell.

We are planning on having a house cooling party of sorts on the 8th of August. We also have a collection of stuff which we don’t really want to move. Some which we plan to sell, some of which just needs a good home.

I came cross a post today by James Bennett on “magic” in general but more specifically in Python, Django, and Rails.

I tend to think that most critiques which invoke the term “magic” are simply expressing part of the Python philosophy which says “explicit is better than implicit”. Just because something is better though, doesn’t mean it is always the right answer.

James gets to an important point:

“To put it concisely, I think that’s what a lot of critiques of “magic” really boil down to: the notion that just because you can do something doesn’t mean you should.”

He goes one to say that this realization is an important part of becoming a good programmer. I have to wholeheartedly agree. This concept was first crystallized for me when I was reading Inside COM by Dale Rogerson and I read the phrase:

“Just because you can put peas up your nose doesn’t mean that you should”

Both because the phrase communicated a important idea and because it has excellent imagery, I have used as my email signature for the last few years. Truly they are words to live by if you are developing software or not.

Consider the following Object Oriented code:

class Foo
{
    private int bar;

    public int getBar()
    {
        return this.bar;
    }

    public bool setBar(int i)
    {
        this.bar = i;
        return true;
    }
}

When learning the art of writing code, especially if you start in a language like Java, you are told to keep your data private and always use accessor methods to get or set it. But why is that? I was never really told why (maybe I just didn’t ask enough). Consider the alternative in Python:

class Foo:
   def __init__(self, i=0):
      self.bar = 0

Python being dynamic whatever attributes you set on the instance in the initializer (__init__) dictate what is available in the instance. In this case the data is public and can be accessed though foo.bar if foo is an instance of Foo.

When I started coding in Python suddenly everything was public and all the getter and setter methods were gone replaced with methods which actually did a logical unit of work. Part of the reason for this openess was a C philosophy of trusting the programmer. If someone uses your class and messes with the private data in a bad way, the program will crash, and it will be their fault. The best way to fight back against that would be to write a simple well documented API. Practically, for my uses thus far this have worked well.

Back to the accessors in Java, C++, and C#. Why are they such a must? The first step in the progression tends to be that by keeping your data private, you protect your interface from abuse. Specifically your clients will be less likely to write incorrect code. Having public data is also leaky: clients can write code based on implementation details like the int bar in Foo which an implementer may want to change. Using private data the compiler can enforce this encapsulation.

But really you want the client to have access to the data, that is why you write accessors in the first place. Writing the accessors allow you to control access to this private data. The value of a member variable can be restricted valid ones, and values being read can be validated before being returned. This excellent when it is needed, but most often the trivial accessors are all that is needed. Simply setting the value and returning is all you need. In that case wouldn’t it just be easier to use a public value? It would, but this would define a difficult to change interface. An interface you might want to change when you discover in the future you really want to restrict values for this data.

The interface is the key. The is why writing accessor in the first place is encouraged and the difference between Java and Python. The reason Python doesn’t need accessors.

If you use public data in Java, the client would access the data with foo.bar, and that defines the interface If the implementer were to change it to suddenly require an accessor all of the client code would have to be recompiled with something like foo.getBar() in place of foo.bar. By always using accessors, whenever it is decide that accessing private data needs to be controlled the implementer can add it, no client changes needed.

Great right? Except you have to write all of the accessors (most of the time). Really if the data is so important as to be publicly accessible what is the harm in writing accessors? None really. But in Python you don’t have to.

This is because in Python foo.bar is actually a flexible interface. In the case plan public data, it gives you access to it. But if the need arises and you need to protect the data you can using properties:

class Foo:
    _private_bar = 0 # accessible but understood as don't touch.
    def _get_bar(self):
        return self._private_bar
    def _set_bar(self, i):
        #Do something interesting like ensure i is an int
        self._private_bar = i
     bar = property(_get_bar, _set_bar)

Now foo.bar implicitly calls _get_bar and foo.bar = 5 implicitly calls _set_bar. In Python implicit is bad, but here it preserves the interface which is good. If clients are used to accessing bar, they still can while you make the logic behind the access arbitrarily complex, only when needed. I think that is a good thing.

Beyond language features I thought this was interesting because it show how important syntax is when designing a language. How any construct is an interface, and the semantics of that interface can effect how easy or how difficult it is to do something in the confines of that language. A flexible interface increases power, but unclear semantics decreases readability.

It has been just over a year since the trip started and I am finally finished writing about it. It took much longer than I thought to write about the trip then I had assumed. Part of that is writing, even as poorly as I do, takes a lot of time and effort.

It is difficult to reflect on the trip now, it seems a world away as I sit in a cubical. But I am certain this record of the trip will be an personal treasure for me in to the future. As time pasted my ability to recall the events of the trip lessened, and this probably effects the quality of the last entries. On the other hand you can’t spend you time in the moment writing everything down. You will miss a lot. Especially when traveling with a lovely companion. It is a balance, and I am glad to have these records of my trip. Every last picture, these blog entries, and my old warn out shoes from walking around the world.

I can say looking back, like everything hard I have done, it seemed easy. All of the logistics, and troubles worked themselves out and I am left with wonderful memories. These days I feel as if I do less because I am more fearful of things being hard to do. In the past though be it running events great or small, or even traveling the world, all you really need is the unshakable belief that something is possible and before you know it the struggle will be a memory.

Our plane may have landed in Glasgow but we immediately took the train to Edinburgh, with a plan to return to Glasgow before we made our final trips home.

Edinburgh is an amazing city. It’s summer also features non-stop festivals much like Glasgow, except there is an enormous castle on top of an enormous hill in the middle of the city. When visiting Edinburgh as a backpacker, try and get into the Castle Rock hostel. It is in an old manor right across from the castle. The rooms are spacious and beautiful even when there is 8 people to a room. The staff is really nice and very accommodating. Our original booking only had us there one day, but we were more than willing to pay a cancellation fee to stay there another night. The castle was just outside our window.

Edinburgh is the other city we took advantage of the for-tips tours that we started in Amsterdam. The guide had really interesting things to say such as the crag that the castle was built on was really hard stone which created a weathering shadow when the ice age glaciers last came to shape the land. The whole core of the city was build on this huge rock and the gentle ramp in the glacier shadow of it.

Beyond enjoying the general ambiance of the living city of Edinburgh we made our way to the Scotland Museum of Science and Technology where Dolly’s stuffed body is on display. There was even an exhibit on Canada. Well Northern Canada at least.

With our trip winding to the inevitable end, we took the train to Glasgow, which is far more practical and less dramatic city. We stayed in a University Residence together which was actually a lot of fun. We did some shopping and saw Angus, Thongs, and Perfect Snogging, which seemed like a good thing to do because I don’t think the move has been release in North America at all. It is from the same director as Bend it Like Beckham.

Check out all the Scottish pictures including my shoes after traveling the world and what might be one of the finest shots from the trip in the last album:

Edinburgh and Glasgow