I’ve been learning Go recently; it’s been fun.
Whilst playing with slices, I put together a little visualiser to help understand their behaviour (the act of building it was probably more useful than the end result).Read on →
We’re sorry, but something went wrong!
I’ve been seeing some strange behaviour on the development environment for On the Game recently. I’ve just spent an hour combing through every line of code that varies from a standard Rails app, and I’ve finally found the issue. I’m putting it here for posterity.
Regardless of my configuration, Rails was always displaying the production page for 500 errors (e.g.
public/500.html) even in development mode.
I poked around for a while and eventually found it to be this:
Enumerable#sum somewhere (don’t ask!), and my implementation didn’t handle arrays of strings. That’s it, that’s why the detailed error page wasn’t being shown in development.
Enumerable#sum is used by the development error page, and when something on that error page itself raises an error Rails will just fall back and show the 500.html and not log anything.
Moral of the story: If you’re seeing this behaviour, check you haven’t (badly) monkey patched something that the error page is using.
“I don’t have enough free time to learn a new language!”, or tool, or framework, etc. I hear this often. I appreciate we all handle things differently, but here’s my take on it.
I remember years ago, some friends and I were talking about money and our savings accounts. They were flabbergasted at how I, a 19 year old at the time, were able to have nearly £10,000 saved (sadly which I’ve since spent!). I explained that it’s easy to save money if you do it slowly and consistently. £50 a week over the course of three years adds up. Obvious, right?
You don’t sit down and decide “I’m going to save £10,000” and then promptly spend one month working yourself to death to put away the whole amount in one go. It’d be nice to have the option to do that occasionally, but that’s not how most of us work. The same applies to learning.
You don’t need to read a 300 page book to learn something. Read a blog post (or an article, mailing list thread, commit discussion). One. Pick a subject and read a single article on it. Do this once a week, every week. That’s it, that’s my secret to learning.
Knowledge isn’t a substitute for experience, but it’ll certainly get you a lot further down the road, faster, than you would get without it.
Take Ruby as the typical example. Ruby on Rails has been around for 6 years now (and Ruby for nearly 15, but not visibly), if you’d have read one article on Ruby a week, you’d have read 312 by now. Three hundred and twelve. Combine that with the occasional Sunday afternoon playing around and I’m confident you’d be pretty proficient by now.
- Haskell, 20 years.
- Erlang, 25 years.
- Python, 20 years.
- Clojure, 4 years. Scheme? 36 years.
Of course, we’ve not all been trying to learn those languages for as long as they’ve existed. Consider this though, in one year you could be proficient in a new language if you commit to just 15 minutes a week, or you could be in exactly the same place you are now still unable to find time to learn anything.
How do you eat an elephant? One bite at a time.
Addendum: but everything moves so fast!
No, it doesn’t. It just feels like that from the inside.
Learn something fundamental and your knowledge will transcend trends. Learning a new language is a great way to do that whilst also feeling cool and trendy. Ruby or Python will help you understand dynamic languages, Scala will make you appreciate how powerful and unobtrusive static languages can be, and Clojure will introduce the code-as-data mindset. All those things will be useful beyond the scope of the language you’re learning.
Stealth edit: Fixed my amazing saving ability.
As one of the last things on my to-do list for Inca, licensing has been delayed and delayed; finally, with me making the announcement on Twitter the other day I felt I should probably get it sorted. I was going to write a nice long post about my thoughts on anti-piracy measures, but the Balsamiq team have already done it nicely.
Instead, here’s a guide to using Rhino Licensing. Your mileage may vary.
Rhino Licensing uses asymmetric encryption–also known as public-key cryptography–specifically the RSA algorithm. In cryptography, asymmetric means there are two parts to each key, one public and one private. You encrypt a value using the one key, and it can only be decrypted using the other key. In the case of license key generation, we store our private key on the server (and never tell anyone it!), and distribute the public key with our application. When the user receives a license key, the application is able to verify that it came from us by using the public key. If someone tries to use a license key they’ve generated themselves, it wouldn’t work unless they had our exact private key.
Other systems that use asymmetric encryption include SSH, SSL, PGP, and among others, Git uses asymmetric encryption for its security due to it using SSH.
The format of the license that Rhino Licensing generates is an XML document, plain and simple. By default, it includes the user’s name, an expiration date, the type of license (trial, standard, floating, etc…), and most importantly the cryptographic signature. Below is an example Rhino Licensing generated license.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
What’s a signature?
A cryptographic signature is a string of bytes used to aid in verification of the source of a document. In most cases–and in the case of Rhino Licensing–the signature is generated by hashing the content of the file using SHA1 (or another suitable hashing algorithm), and encrypting that hash using the private key. The resulting string of bytes is the signature.
When the client receives a file with a signature, it creates a hash of the file (sans-signature) and compares that hash to the decrypted value of the signature. Baring in mind that the signature is an encrypted hash of the file, if either of the public or private keys were invalid or the file had been tampered with, then the decrypted string would not match the hash of the file. When the client generated hash and the decrypted signature match, you can be confident the sender of the message is who you think it is.
The great part about using the hash of the document as the signature is that if the user tampers with the license–such as changing the expiration date or the licensee name–the signature will no longer match the hash the client generates, and BAM, instant invalid license.
One particular aspect I like with this approach is that the licensee name is clearly visible in the license. This simple act can be quite dissuasive when it comes to piracy; after all, who would want their name visible on all the torrent websites out there?
Enough with the waffle, let’s start using Rhino Licensing.
Create your key
The first thing we need to do is generate a public/private key pair for us to use in our license generation. Rhino Licensing uses the RSACryptoServiceProvider for it’s keys, so we can use that ourselves to generate our keys. One of the simplest ways to do that is to knock up a really quick console application.
1 2 3 4 5 6 7 8 9 10 11 12 13
That program will generate a new key for you and write out the public and private parts to two separate XML files (publicKey.xml and privateKey.xml). Keep these two files handy!
You will probably want to change the
1024value in the
RSACryptoServiceProviderconstructor to something larger. This is the size of the key that will be generated. The larger the better really, but larger numbers require longer to generate.
Update your application
Now we’ll update your application to complain if it doesn’t have a license. In your entry-point for your application you need to assert the license. Before we do that, make sure you’ve got your public key handy from the previous step. Rhino Licensing needs the content of this file, so you can either embed it directly into a constant or as a resource. Secondly, it needs to know where to look for a license that the user will have been given.
Assuming a really simple app, here’s a Program.cs with Rhino Licensing:
1 2 3 4 5 6 7 8 9 10 11 12 13
If the license.xml file doesn’t exist, or if it’s invalid, Rhino Licensing will throw an exception. Of course, as we haven’t generated a license yet we’ll get an exception. That’s the client done though, so we can move on to our final step now. Once we complete that step, you will be able to just drop a license.xml into the same directory as your application and everything will work as expected.
Create the license generator
We need something to actually generate a license for your users. If you were being all fancy you could do this as a web-service that gets integrated with your payment provider; however, for simplicity’s sake we’ll just create another console application that spits out a license.
Rhino Licensing has a few prerequisites for a license: A name, an id of the license, an expiration date, and a license type. You can also supply a dictionary of custom values, but we wont be using that in this example.
For a really simple license generator all you need is the above for each license, and the private key. We’ll wrap that up in a simple console app which’ll prompt for the required info:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
That’s it, you’ve got a license generator. Remember, this will exist behind your firewall, the users will (and must) never see your private key.
If you take the output of this application and save it in a license.xml file in your client, your application should stop throwing license exceptions and run normally! You’ve officially just licensed your app.
What have we just done?
- Created a private key generator, purely for convenience than anything else. We should only need to run this once before we start generating our keys. You could run it once per major release to ensure your 1.0 licenses are never compatible with 2.0.
- Updated our client application to validate the presence and validity of a license (and to explode if there isn’t one).
- Created a “server” to generate licenses for us. This is very primitive but could easily be adapted to a web server. You might want to look at the Rhino Licensing LicensingService before you continue.
My part in all this…I presented on two topics at NDC; the first was an introduction to Fluent NHibernate, and the second an introduction and demo of Git. Fluent NHibernate was on the Thursday, and Git the Friday. It was a great experience speaking at an event of this size, and the number of people who seemed genuinely interested in what I had to say (by either turning up to my talks, or approaching me afterwards) was quite humbling. If you’re interested in seeing what I presented, the talks will be on the NDC website before too long.
The videos are becoming available at streaming.ndc2010.no, but they’re suffering from bandwidth issues. If you do want to watch the videos, please stream them until the issues are resolved.Due to me speaking, and also being woefully unprepared, I didn’t get to see as many talks as I would’ve liked — regardless of how well rehearsed and prepared my talks are, it seems I always end up rewriting them an hour before I go on — I did end up catching Lisa Crispin, Steve Strong, Eric Evans, Greg Young, Jon Skeet, Roy Osherove, Michael Feathers, Sebastian Lambla, and Mark Nijhof. I recommend you catch their talks online when they’re published. The quality of the talks at NDC have been significantly higher than I’ve seen elsewhere, and (more importantly) the technical level seems to be higher too; there was very few basic talks (a few introductions, mine included, but no pandering), but the majority were pretty in-depth. This is quite a contrast to the all-too-often “Microsoft technology of the week” presentations you can get at conferences. Of course, a big part of any conference is what happens between (and after) the talks. Meeting other developers is a big part of why I go to these things, after all I don’t get out much normally. The socialising aspect of NDC was excellent, good drinks and food was had by all (I have a good idea they did anyway, at least one place we ate refused to serve us as a group anything other than the same meal for everyone!). I can’t possibly list everyone who I met while I was out there, but it was really good to meet up with some people who I’ve known on Twitter for a long time; specifically Hadi Hariri, Steve Strong, Greg Young, Ben Hall, Seb Lambla, Mark Nijhof, and Rob Conery are ones that stand out to me right now. NDC 2011 will be next year, and it’s looking like it’ll be in May this time. If there’s anyone that’s on the fence about going, I would whole heartedly recommend you do. Even more so, I’d recommend you submit a talk of your own. It’s a great way to test yourself, if nothing else. I’ll definitely be going next year; hopefully I’ll speak again, but if not I’ll still be there. Hope to see you there!
Fluent NHibernateAn introduction and overview to object⁄relational mapping using Fluent NHibernate. See how Fluent NHibernate can help you map your domain with the least amount of effort, how you can remain flexible with your database, and how to drive your design through convention–over–configuration; all without writing a single line of XML. The talk is an introduction to Fluent NHibernate for those that aren’t familiar with it, and assumes some NHibernate experience and is for .Net developers primarily. The goal is to show people how low–impact NHibernate can be with Fluent NHibernate, and how it can actually speed up development in rapid–change environments. I’ll cover an overview of what Fluent NHibernate is, the various parts of it (the fluent interface, the conventions, and the auto–mappings, and the configuration aspect), then expand on how these features can be utilised to improve your NHibernate experience and simplify your development process.
Introduction to GitAn introduction to distributed version control using Git, and how your VCS should work with you and not against you. How DVCS can completely alter your development process, streamline it, and help you produce better software, faster. Covering how local repositories speed up your development, multiple authoritative sources, distributed teams, multiple workflows, and some of the more distinct features of Git. With experiences from an OSS team on how the migration from SVN to Git has helped the project and changed how the team works (Fluent NHibernate).
Last monday (8th of Feb) I did an E-VAN on Git; an introductory talk on Git and DVCS, covering pretty much everything you need to know for day-to-day Git life. I think it went down well, certainly didn’t hear anyone complaining.
The talk was recorded, so if you haven’t already seen it then you can do so at your own leisure.
Just a reminder that tonight I’ll be doing an E-VAN on Git tonight at 7pm GMT.
It’s going to be a pretty basic talk on what Git is (and indirectly what DVCS is), and a demo on how to use most of the features you’ll need daily. There might be some advanced talk at the end, depending on how well I time things.
If you’ve already used Git (successfully), then this talk won’t really be for you; unless you just want to listen to me ramble for an hour and an half.
Looking forward to “seeing” you there. Now, I best finish reading that “Getting started with Git” book I’ve had lying around for months.
Here’s a few ways to think about Git and it’s distributed nature.
- You deal with multiples of repositories, not a single central repository
- Updates come from a remote repository, and changes are pushed to a remote; none of these repositories have to be the same
- Origin is the canonical name for the repository you cloned from
- Upstream is the canonical name for the original project repository you forked from
General pushing and pulling
Pushing your changes to a remote:
git push remote_name
Pulling changes from a remote:
git pull remote_name
Or if you want to rebase:
git fetch remote_name git rebase remote_name/branch
You can change your
always, to make this the default
That’s all there is to moving commits around in Git repositories. Any other operations you perform are all combinations of the above.
Github — personal repositories
When you’re dealing directly with Github, on a personal project or as the project owner, your repositories will look like this:
To push and pull changes between your local and your github repositories, just issue the push and pull commands with the origin remote:
git push origin git pull origin
You can set the defaults for these commands too, so the origin isn’t even necessary in a lot of cases.
Github — receiving contributions
As a project owner, you’ll sometimes have to deal with contributions from other people. Each contributor will have their own github repository, and they’ll issue you with a pull request.
There’s no direct link to push between these two repositories; they’re unmanned. To manage changes from contributors, you need to involve your local repository.
You can think of this as taking the shape of a V.
You need to register their github repository as a remote on your local, pull in their changes, merge them, and push them up to your github. This can be done as follows:
1 2 3
Github — providing contributions
Do exactly as you would your own personal project. Local changes, pushed up to your github fork; then issue a pull request. That’s all there is to it.
Github — the big picture
Here’s how to imagine the whole process, think of it as an N shape.
On the left is the contributor, and the right is the project. Flow goes from bottom left, along the lines to the top right.
- Contributor makes a commit in their local repository
- Contributor pushes that commit to their github
- Contributor issues a pull request to the project
- Project lead pulls the contributor’s change into their local repository
- Project lead pushes the change up to the project github
That’s as complicated as it gets.