Life @ NCP

Yesterday I cooked fried rice. It was probably the best fried rice I’ve cooked ever, and I’ve cooked a few.

I’ve never had any real education where cooking is concerned; when I was growing up in Singapore, my family had a domestic servant (read: maid) who did all the cooking, cleaning and washing. All the way up until I left Singapore for Uni in Sydney, I never had to cook.

Consequently, any cooking I did was very much the way I was brought up; by the book. Even today, my approach to cooking usually goes like this:

• Find a recipe online
• Measure out each of the ingredients in the recipe
• Follow the recipe to the letter

As you can imagine, this didn’t always result in a dish that resembled the recipe, or tasted the way I had imagined it to be. Often things like “until fragrant”, “until cooked through”, or something which didn’t have a precise time or visual measurement associated with it didn’t work too well.

Yesterday was different. I still looked up a receipe, but not only did I have totally different ingredients for the recipe, I didn’t actually measure them out. Instead I just mixed stuff in and tasted as I went along.

Some years back, there was a popular sitcom on Singaporean TV called Under one roof, about a Singaporean family. In one of the episodes, the mother is trying to teach her daughter how to cook. She used phrases like “just put some oil”, or “add a bit of salt”, much to the chagrin of her scientific-method oriented daughter. The daughter then started measuring how much oil acutally corresponded to “some oil” and how much salt was “a bit of salt”, and found incredible consistency between trials attempted by her mother.

I think well-practised cooks get the same measurements and dosages consistently. Good cooks taste as they go and know how to adapt to different states of a dish. Better cooks have a wider range of ingredients to play with when adapting a dish, and the best cooks are consistent through practice, have a wide range of ingredients at their disposal, and efficiently execute quickly. Consqeuently, they are able to handle much more complicated dishes in the comparable amount of time as the average cook.

You can probably see where this is going. I think well-practised software developers produce consistent, familiar code. Good developers iterate quickly and adapt to customer feedback. Better developers have various techniques to use when adapting to change, and the best developers can do this in a much shorter period of time. Consequently, they are able to handle larger, more complicated projects than the average developer.

I got a glimpse of being a good cook yesterday, but my only tools are salt, pepper, soya sauce and oyster sauce. I certainly cannot produce consistently and am some ways away from amassing a reasonable body of knowledge to adapt to different states of a dish. Soya sauce, salt, pepper, oyster sauce, fish sauce and seasame oil are still the best cooking friends I have. But I’m getting there.

Still a long way to go, where software and cooking are concerned, but here’s a picture for posterity.

It also helps if you add a liberal dose of oil 🙂

Despite my best attempts, this blog post is stilll almost 2 months late. For all the talk about consistency, I was still unable to put pen to paper and get things done.

This happened even though I had numerous ideas about what to write, going as far as to write outlines and code samples but never actually putting it together.

I don’t think it was the difficulty of finding topics, I think it was the dread and expectation of the arduousness and pain I would need to go through to actually craft a piece. That probably wouldn’t end up being that hot anyway.

There is a mantra that’s grown more common among software folks in the last few years. Ship fast, Ship often. It works because you get used to the pain, rather than forgetting it. It works because you find ways to deal with what’s constantly in your face, rather than hours slogging through it each time.

It’s not a new invention. Successful blog writers have long advocated the virtues of releasing consistently with a schedule. And I’ve always thought I’d be good at following a schedule. When I was in school, my annual report card usually had some remark about “high self discipline”. As it turns ot, following what someone tells you to do is not the same as following goals you set for yourself.

Being obedient is not the same as being as being self motivated.

A long time ago, in a galaxy far far away, I was a reasonable runner. I even took part in a 4 x 100 track relays for my class. It was a time when I would run around 6km every Sunday. I would meet Mr. Wee, a friend of mine, at the same place every Sunday morning and we would jog down for breakfast.

We didn’t always make it all the way there (sometimes we even skipped the run altogether!), but we would show up.

Years later, as I’m writing this here in Dublin, all that seems rather far away. I’m not sure when we’ll make it back to Sydney for any extended period of time, and I’m even worse at keeping in touch with the folks from Singapore.

Who knows what the future holds, or where this post actually leading to. I do know I had to get it out, even though no one was really pushing me to. And it cannot end without a solution, because what seems like the hopelessness of a hopeless problem is a poor excuse for not trying to solve it.

So I’ll ship fast and ship often, with a blog every Saturday. Next one will be on ¹⁵⁄₁₁, so stay tuned!

Scala < 2.10.4 does not play well with JDK 8, thanks to invokedynamic being used in some JDK classes (see https://groups.google.com/forum/#!topic/scala-user/Nzc2zUTyays).

If you can use JDK 7, it is probably the easiest workaround. If you have to use JDK 8, upgrading to sbt >= 0.13.5 is also an option, since those sbt versions use Scala 2.10.4 (See http://www.scala-sbt.org/0.13/docs/Changes.html)

Sadly, this can lead to other issues, such as libraries being only available for Scala 2.9.x and not 2.10.x. YMMV. Happy building ;P

This will be a quick primer for public key cryptography in layman terms. I’d like to use the content for a Toastmasters’ speech in the not too distant future, hopefully leading to a Bitcoin presentation.

We often take for granted how easy it is to send messages securely over the internet. From filing taxes to transferring money, “how conveniently can it be done”, as opposed to “how securely can it be done” is the usual question. What does it really mean to be secure over the internet though? What does the green lock you see when you run your browser really mean?

Let’s try and walk through the steps involved in making a bank transfer, and see what could go wrong.

As is the tradition in IT security, we will use the characters Alice and Bob. Alice wants to transfer $100 to Bob. At her terminal, she wants to send a message the equivalent of “transfer $100 from my account to Bob”.

This message has to travel across numerous connections till it finally gets to the bank, where it is read and processed.

How can we prevent anyone else along the way from reading Alice’s message? Apart from buying over all the links to our bank on the internet, one option would be to scramble the message and foil any would-be eavesdroppers. This is known as encryption, and would work, except that Alice’s bank would need to know how to unscramble the message and actually process it.

Encryption is not a new problem, many methods/algorithms exist, but they all rely on a specific “key” that is known beforehand. How would it know beforehand how to get this key? It would also need to make a different one for each account holder, otherwise any customer of the bank could read any other customer’s data.

You can’t really send the key over the internet since that could be intercepted and read. You could go to your bank and negotiate some kind of secret, common key beforehand. That would work, but it wouldn’t be very feasible for all parties you’d like to conduct a transaction with, like say Amazon.

The solution that was eventually adopted used a neat bit of math. Rather than using the same, single “key” that both alice and her bank could decrypt/encrypt with, a type of encryption method exists where each party has two keys. These keys are often called private and public keys, for reasons that will become obvious soon. A message encrypted using the bank’s public key can only be decrypted using bank’s private key, and vice versa. The key thing here is that knowledge of the public key does not allow you to decrypt the message.

In practice, any website that operates over https as opposed to http has generated a pair of keys. Your web browser automatically does the required encryption using the website’s public key. When you visit a https website, the website presents its public key to you and you then use it for encrypted communications.

The more eagle-eyed or technically inclined audience might spot a problem here. Suppose Eve controls one of the computers along the chain. When the initial public key is being sent to Alice, she instead replaces the bank’s public key with one of her own, so that Alice now encrypts her data using Eve’s public key. Eve can now intercept the messages and relay them to the bank, possibly modified to say transfer money to her account.

This can be prevented if we knew beforehand what the bank’s public key actually was, without actually needing the bank to present itself. Some kind of centralised key registry. However, this key registry would need to be dynamic since new websites are registered all the time, and you would need to “know” the public key of this centralised key registry in order to start the whole process in a secure fashion.

In practice, what happens is not so different. A secure website doesnt just present its public key, the public key forms part of a certificate. Just like say a birth certificate, it is meant to certify the identity of the website, so it contains the entity name, organisation etc. The interesting technical part of all this is the certificate is usually certified by a certification authority (remember key repository?). This certification authority in turn is usually certified by yet another certification authority, and so on until we reach a root certification authority. Your browser, when installed, contains files that can be used to verify only these root certification authorities. This is known as a certificate chain, one end of the chain is the website you are visiting, and on the other end a root certification authority that your browser knows about.

So at the end of the day, here’s what happens when you visit a secure website, in somewhat simplified terms:

• The website presents you with its public key as part of the website’s certificate. The certificate has been issued by a certification authority.
• Your browser verifies that this certification authority has been certified, directly or indirectly by a root certification authority it knows about.
• When satisfied that the public key it has received really belongs to the website you are visiting, it then starts transferring data encrypted with this public key
• The receiving website then uses its private key to decrypt the data it receives, and to encrypt its response.

All this takes place when you visit a website such as https://bank.barclays.co.uk . You can even inspect the certificate for yourself.

In practice, the process is actually a little more complicated than I’ve outlined. Certificates can have different standards and levels depending on how rigorously a certification authority has verified the identity of a website; encryption and descryption using public and private keys can be computationally expensive and a shared key is often generated and used for encryption once a secure session has been set up using the private and public keys. However, he ideas of identify verification by a 3rd party and the use of public and private keys for encryption/decryption is largely as described.

I hope I’ve given you a quick overview of what interacting with a secure website actually entails. In my next talk, I’ll try and extend some of these ideas a little further and outline how they relate to a decentralised currency like Bitcoin. To be continued 😛

You’re live! Nice. We’ve put together a little post to introduce you to the Ghost editor and get you started. You can manage your content by signing in to the admin area at <your blog URL>/ghost/. When you arrive, you can select this post from a list on the left and see a preview of it on the right. Click the little pencil icon at the top of the preview to edit this post and read the next section!

Getting Started

Ghost uses something called Markdown for writing. Essentially, it’s a shorthand way to manage your post formatting as you write!

Writing in Markdown is really easy. In the left hand panel of Ghost, you simply write as you normally would. Where appropriate, you can use shortcuts to style your content. For example, a list:

• Item number one
• Item number two
  • A nested item
• A final item

or with numbers!

1. Remember to buy some milk
2. Drink the milk
3. Tweet that I remembered to buy the milk, and drank it

Links

Want to link to a source? No problem. If you paste in url, like http://ghost.org – it’ll automatically be linked up. But if you want to customise your anchor text, you can do that too! Here’s a link to the Ghost website. Neat.

What about Images?

Images work too! Already know the URL of the image you want to include in your article? Simply paste it in like this to make it show up:

Not sure which image you want to use yet? That’s ok too. Leave yourself a descriptive placeholder and keep writing. Come back later and drag and drop the image in to upload:

Quoting

Sometimes a link isn’t enough, you want to quote someone on what they’ve said. It was probably very wisdomous. Is wisdomous a word? Find out in a future release when we introduce spellcheck! For now – it’s definitely a word.

Wisdomous – it’s definitely a word.

Working with Code

Got a streak of geek? We’ve got you covered there, too. You can write inline <code> blocks really easily with back ticks. Want to show off something more comprehensive? 4 spaces of indentation gets you there.

    .awesome-thing {
        display: block;
        width: 100%;
    }

Ready for a Break?

Throw 3 or more dashes down on any new line and you’ve got yourself a fancy new divider. Aw yeah.

Advanced Usage

There’s one fantastic secret about Markdown. If you want, you can write plain old HTML and it’ll still work! Very flexible.

That should be enough to get you started. Have fun – and let us know what you think 🙂