Developers occasionally move away from coffee and backlit monitors to venture outside. These occurrences are more common than you might think and are often referred to as “lunch time”. Other times developers will leave the comfort of their desks altogether and head out into the world, in order to meet other, like-minded, individuals. Bath Ruby Conference is one such event.
Some of you may know me as, “Lawrence the support guy” or other (less wholesome) sobriquets. However, I’ve also been coding in my spare time for a couple of years. Brilliantly, over the past few months, I’ve been coding more and more around the office too; working alongside our development team and straddling two worlds. Support and development.
With that brief bio divulged I can now tell you about Bath Ruby Conference. My first development conference! Needless to say, I was very excited and wanted to share the experience.
The Bath Ruby Conference Experience
For those of you who don’t know, Ruby is an object-oriented, dynamic, language. It’s one of the younger languages out there and was originally published in 1995. It gained widespread exposure ten years later, with the popular Ruby on Rails web framework; around which vzaar is built.
That all adds up to make Ruby a young language, primarily focused on web development. However, referring to it in such a way doesn’t really do it justice
The best thing about Ruby (and there are a lot of really good things about Ruby) is the community. It’s all about sharing, collaboration and making everyone a better programmer. Conferences highlight that better than anything. Take our first talk of the day as an example: it wasn’t a high-level discussion of how to approach a particular problem, it wasn’t a comparison of tools or methods. It was a talk about a children’s book, designed to get kids coding.
At present Linda has exceeded her $10k by miles, raising $380k for the project over the past year. Listening to her speak was motivational to say the least. It’s great to see someone completely focused on giving kids the ability to make cool stuff, with an audience so enthusiastic about seeing that happen.
That concept – engaging the world around you and helping others engage with programming – is something which became a bit of a theme. And, I must say, a damn good one at that.
Keen to share these experiences, Saron tried help us think about how we learn and the steps we take towards gaining expertise. In particular, how we can help others with that experience.
The short answer: read code. Lots of code. Good code, bad code, and anything else you can get your hands on. More importantly though, do it in a group. Get together with some friends in the same boat, read it together and share your thoughts. It’s not often you can say this but, “it will make you a better person”.
To help everybody achieve that collective learning experience, Saron has also created #CodeNewbies, a Twitter chat which runs every Wednesday at 9pm (EST), to help newbies discuss what they’re doing and receive support from the community.
Another common theme for the day was making everyone a better programmer. Looking at how we think and why we engage with problems the way we do.
It’s probably best if I show you an example, so you can see what I mean. What’s the sum of all the numbers from one to ten (i.e. 1+2+3+4+5+6+7+8+9+10)? The answer: fifty-five!
Ok, so how about all the numbers from one to a thousand? What would you get if you add all those up? A long and boring sum would certainly be one answer. Just imagine: 1+2+3+4+5+6….. +98+99+100….+742… Urgh.. To save your sanity, you’d need a better method.
Finding that better method, as Tom would tell you, is exactly what mathematics is meant to do. In this case, there’s a simple mathematical rule, which was discovered by Carl Friedrich Gauss. You can use to work it out the answer very quickly. It’s just…
…. where n is the number you’re counting up to (in this case 1000).
That, Tom says. is exactly what all good programmers should be doing. Looking for patterns and coming up with rules. Letting logic doing all the heavy lifting and leaving clean, short, elegant code.
This also serves as a reminder to every programmer out there, who had an awful time with maths at school. Maths is cool and will let you do cool things quickly, when you apply it properly. When you remove the fear and the stigma, it is just a incredibly powerful and elegant tool. Check out the slides here, if you’d like to know more.
Of course, as you’d expect from a programming conference, there were some more meaty discussions too. The general focus was looking at how we code, the way we write, and how we can write better. The goal being cleaner, more elegant, more logical code.
This demonstration finished with a look at dependency injection. Dependency injection is, at the risk of being a little tautological, a more flexible method for handling dependencies. Rather than objects creating their own dependencies, they receive them from elsewhere. The idea being that, in detaching an object from its dependencies, you can freely reuse them elsewhere and, as the project grows, end up with more concise, readable code. There’s a good blog, summarising the idea, here. “Here be Dragons”, Katrina’s talk would definitely win any prizes for animation. Katrina showed us some truly terrible code, illustrated with pixel-art, and we all had a good chuckle.
Of course, writing terrible code is something we’re all guilty of from time to time (I’m told this is an understatement). Katrina highlighted it to talk us through common mistakes, some debugging techniques, and some more elegant solutions.
Like Ben, Katrina, and Tom, Sandi focused on methods for writing good code. In particular she focused on what nil is in Ruby and ways of handling it.
nilis an object which adheres to it’s own rules. So let’s say you’ve got a group of objects, which you’re performing an action on. That action’s going to be tailored towards the objects you’re expecting to receive.
Then your method hits a null value and BOOM!
NoMethodError: undefined method 'some_method’ for nil:NilClass
There’s a great discussion of this over at Sandi’s blog, where you’ll find the writing much more concise than this rambling, mixed, summary. She explores the problem further and what it leads to, then offers an elegant solution: a null object pattern. There the blog ends but, at the conference the talk continued.
In it’s simplest terms a null object pattern provides attributes to nil. Giving it characteristics, which will allow it to interact with your methods more elegantly. Here’s an example from Wikipedia, to show you what I mean.
Massive disclaimer: the above example uses conditional logic and I’m not entirely sure Sandi would approve.
Last but not least, I can’t finish up this blog without mentioning the lightning talks. For those of you who haven’t come across the concept of lightning talks before, imagine the conference equivalent of an open mic session. People just volunteer and then talk about a subject of their choosing for up to five minutes. Nothing highlights the creativity, diversity and all-around madness of the community better!
I don’t have time to run through them all, so I’ll leave you with this…
… these guys have written a program containing a synthesizer, in Ruby. Not just any synthesizer either. It’s a synthesizer which you interact with via code… in real time! Their lightning talk involved no talking whatsoever. Just a laptop and some phat beats :-)
And one more thing….
A masshoosive shout out to the guys at Eastern Eye in Bath. The team went out for dinner there last Thursday. I challenge anyone to find a more ornate Indian restaurant!