Friday, 29 June 2012

Scottish Ruby Conference Day 1

Firstly, the conference itself is extremely well organised, great speakers, and in a fantastic building.  However, I'm just going to talk about two main things which stuck out for me, neither of them very positive unfortunately:

1) Women in Computing

Mike Lee (@bmf) talked about this at (what felt like) length during his keynote.  While I generally agree with the sentiment, I'm not sure a rant telling people how to behave is the best way to address the problem.

What is the problem?  Apparently people make assumptions about women in computing.  Worse, guys generally assume women at conferences are not programmers and try to flirt with them.   There was more of the same vane, as well as some comments about people assuming all black guys steal cars.  Women, like the other people at the conference (i.e. men) aren't there to be flirted with and yeah, I agree with that.

Stereotypes are bad.  I agree.  But didn't Mike just create a new stereotype?  That all conference going guys have the same attitude?  I'm pretty sure I don't!  In fact, I think Mike under-estimates people's ability to empathise and I'm sure the people Mike was talking about are the minority rather than the norm.

I totally agree prejudice should be stamped out, and hard, but I feel that highlighting the existence of prejudice is counter-productive as all you do is alienate a different group in that minority group's place and now more people are alienated than ever.  We, people in general, need to get to a state where gender, race, sexual preference, religion really doesn't matter.  I think Mike wants that, but I'm not convinced his rants on behavioural change actually help.

As a result of the talk I actually became overly conscious about even starting a conversation with any women at the conference and by the end of the day I was pretty sure that there were at least a couple of women on their own during the in-between sessions when networking opportunities are at their premium. They certainly weren't surrounded by a gaggle of gorking geeks as Mike seems to think they would have been either.

Conclusion - don't suffer, or allow someone else to suffer, prejudice.  Use education to teach people to exhibit a mutual respect for all people, but don't tell people how to behave.

2) Tell, don't ask.

While watching the talk about Hexagonal Architecture I was initially excited as modularity (especially runtime modularity) is a favourite subject of mine, so I settled in to find out how Ruby approaches this.

For me, modularity a particularly important aspect of software development, especially in larger systems where tight coupling reduces architectural agility.  However, I'll refer you to Kirk Knoernschild for more information, as he's got a great handle on this.  He's also very good at explaining what the problem is and how to fix it.

To be frank, I was soon disappointed.  The speakers slowly got around to talking about dependency injection,  inversion of control and programming to interfaces, without properly mentioning it.  Their Hexagonal Architecture was nothing more than a well-architected modular application... but without [Java] interfaces to enforce a contract.  They referred to these as protocols, which I am familiar enough with from my Objective C experience, but there is no formal definition of a protocol or interface in Ruby.

Hey, but this is OK!  These principals have been around since the 1980s with Smalltalk and that never had protocols or interfaces either.  Correct!  And that's exactly why Java *does*.

Is this the state of Ruby?  At least 10 years behind Java, if not more?

My current feeling about Ruby (especially Ruby on Rails) is that it gives you a lot out of the box and you can build a solution very fast but what is generated for you absolutely needs to be refactored, or will become a maintenance nightmare later down the line.

Conclusion - Ruby sacrifices [runtime] modularity, fine grained contractual interfaces and thus architectural agility in favour of terse, human friendly, rapid application development.

Friday, 15 June 2012

Importance of Passbook in iOS6

While I haven't actually watched the WWDC keynote video I did watch a live blog and I have to admit that at the time Passbook didn't seem that big a deal... but having some time to think and then seeing a demo of it by one of my colleagues today, it suddenly clicks in to place.

Essentially, the next few years will see a distinct rise in mobile payments.  All those store cards you've got; Tesco, Starbucks and so on, will disappear to be replaced by cards on your phone.  In the case of those two examples they already have native iPhone apps to replace your physical card with a virtual one but so far the move has not been ubiquitous probably due to the lack of a unified secure platform with consistent user experience, which Apple now provides in the form of Passbook.

The main focus of Passbook just now is on ticketing.  This allows paper boarding passes, cinema tickets, and so on to be replaced with a virtual version.  Even better, the tickets can become 'relevant' at specified times and places, popping up on your phone.  For instance, you might pre-book to see the latest blockbuster film.  You end up with a ticket in your Passbook (probably after downloading it from the cinema's website, or opening an email with it attached) and then when you arrive at the cinema it automatically pops up ready to be scanned.

However, ticketing is just a small piece of the puzzle.  With NFC on the horizon, it won't be long before you're paying for all kinds of things with your mobile phone, from interacting with vending machines, to buying a washing machine.  Passbook is another step in that direction and in my humble opinion vastly understated.

Wednesday, 6 June 2012

Linked-In loses 6.1m un-salted hashed passwords - WTF does that mean?

... and why does it affect you?

This post is aimed at the layman.  If you're not particularly technical and want to know what this is all about, read on... 

Well firstly, it only affects you if you have or had a Linked In account.  Contacts of mine seem to be deleting their accounts in droves, but more about that later.   Chances are, their account data is possibly still hanging around.  Who knows for sure if your data is really deleted?

But what it essentially means is that someone might have your email address and password, and if you use the same combination of email and password on sites like PayPal, you could find yourself out of pocket!  So even though the warning is to change your password on Linked In - remember to change it on any sites where you use the same email address and password to log in.

Standard practice is not to store your password in plain text, but at the same time they need a way to compare what you enter when you login with what's in their database.   To do this, passwords are "hashed".  Hashing is a form of encryption.  You take some characters and apply an software process to it and produce some other seemingly random characters.  For example if you use the password "manchester" it isn't sat in their database as "manchester" for the world to see, it'll look like this "018a9567ea15470312c40d3e5d6bbcd4".

There are different algorithms for hashing.  The one I used above is called md5 and is not recommended for use in recent times, but is fine for demonstrating this point.

No matter how often you try, the md5 hash of "manchester" will always equate to "018a9567ea15470312c40d3e5d6bbcd4".   But it's a one-way operation... you can't take "018a9567ea15470312c40d3e5d6bbcd4" and reverse the process to find out that the input was "manchester".

However, what you can do is generate any number of md5 hashes easily enough.  So all a password thief needs to do is generate md5 hashes for a known list of inputs and compare them.  Thus, if they see "018a9567ea15470312c40d3e5d6bbcd4" in the list, then they know your password is "manchester".

The passwords were stored un-salted.  Why is salting important? 

Salting adds a layer of security to your password and this is really where Linked In failed.

Salt is a bit of extra data that is appended to your password before it is hashed with the result being stored in the database.  When you sign in to a website, they add the salt to whatever you entered as your password, hash the result and then compare it to what's in the database.  You don't add the salt when you sign in, the server does it for you.

But the important thing is, so long as the salt is secret then the passwords are now near-impossible to decipher.  For instance, using "manchester" adding the secret salt of "mouse" makes your password look like "manchestermouse" and now gives a hash of "63a1d6c2df05dc6919084c7d763b6622"... a totally different result!

Thus, unsalted passwords are nearly as unsafe as plain text passwords.

So in conclusion, you can't do anything about a site's security if it has been implemented poorly, but you can help to protect yourself using a strong password; at least 8 characters with a good mix of letters (uppercase and lowercase), numbers and strange characters like exclamation marks, hyphens, dollar sign, etc.

Another very important tip is to try not to use the same password across multiple sites.  If this is too tricky to manage, use a secure password service like  They have password generators and automatically inject your password in to forms on a web page, while storing your password securely on their servers.  Very convenient and if used correctly, very secure!