From The Archives: This article is one of the all-time most popular posts from my previous blog Graham Hacking Scala. I thought it worth updating and re-printing it here.
It’s a pretty widely-accepted view that, as a programmer, learning new languages is a Good Idea™ . Most people with more than one language under their belt would say that learning new languages broadens your mind in ways that will positively affect the way you work, even if you never use that language again.
With the Christmas holidays coming up and many people likely to take some time off work, this end of the year presents a great opportunity to take some time out from your week-to-week programming grind and do some learning.
With that in mind, I present “Graham’s Guide to Learning Scala”. There are many, many resources on the web for learning about Scala. In fact, I think there’s probably too many! It would be quite easy to start in the wrong place and quickly get discouraged.
So this is not yet another resource to add to the pile. Rather, this is a guided course through what I believe are some of the best resources for learning Scala, and in an order that I think will help a complete newbie pick it up quickly but without feeling overwhelmed.
And, best of all, it has 9 Steps!
ScalaSyd: Episode 9
We had a great meeting at ScalaSyd last Wednesday night, probably one of the best I’ve been to. These are my notes from the evening, which are in no way comprehensive – they are just the points I found most interesting.
Jed (@jedws) warned us at the start that there were two “pointy” talks with some soft stuff in the middle, but I found the two pointy talkers did an excellent job of conveying their pointy subjects to neophytes. Not an easy task, so well done, guys.
Last week at Tyro we had a fairly serious production issue. Thankfully, the impact was nowhere near as serious as the kind of outages that most Aussie banks have delivered over the last couples of years; our merchants could still accept payments and they could access their reports, but our backend processing was banked up such that their transactions weren’t appearing on reports for about an hour. That might not sound too serious, but our merchants are accustomed to seeing transactions appear in their reports pretty much instantly, so when our monitoring told us we weren’t delivering on that expectation we considered it a serious incident.
There was lots of good news out of this. Dev and Ops rallied as one team. We fixed the problem, and we managed to fix it without deploying a code patch. We learnt about an important performance restriction in our system that was fixed the next day and gave us knowledge that we can use to improve going forward. And we managed to get it solved before the last bus on my route for the night.
The bad news was that it took us a long time to get to the good news: it was about nine hours from the first indication of the incident to when we finally executed the winning solution. Looking back, I feel a bit stupid that we didn’t – that I didn’t – solve it in a quarter of that time. All the information we needed to lead us to the solution was staring us in the face, right from the beginning.
I’ve always been pretty good at debugging. Until a couple of years ago I’d never thought much about why I find it easy, but once I realised that I didn’t know why I was good at something, I had to know. So I dedicated some time to analysing my own internal, instinctive thought process, and from what I’ve observed it can be reduced to this: