I went along to the Sydney FinTech Startup Meetup for the first time tonight.
It was an interesting meeting as the speakers were all from the Westpac Group, one of the biggest, oldest companies in Australia, which hardly seems appropriate to the Startup scene. However, the guys had a lot to say about how they see the current banking markets and what the bank’s take on innovation and interaction with small companies looks like. From my point of view (as an employee of a financial startup that’s recently hit profitability and is now entering a scaling stage) it was interesting to listen to the challenges that these big companies face and to think about how we might try to avoid the same traps as we grow. Continue reading
The Story So Far
About two weeks ago, I wrote a blog post suggesting that Scala can make Java developers more productive. One of the comments on that post was that I had no metrics and so was spreading “folklore”. I took the criticism constructively and decided to solicit a small survey of Scala developers to try and get some insight.
What I Wanted to Learn
One of the most important things I’ve read about Lean Startups – and it’s important because it can be applied to a gamut of contexts, not just startups – is that, while the execution of the Lean process is Build, Measure, Learn, you actually have to apply this backwards to get good results: first you decide what you want to learn, that will inform what you need to measure, and that will determine what you need to build.
I employed this advice with this survey, asking first: “What do I hope we learn from this”, and using that to inform the content. Here are the questions for which I wanted the survey to provide some insight: Continue reading
Update: The survey has closed and you can have a look at the results here.
Yesterday I wrote a blog entitled ‘A New Java Library For Amazing Productivity‘, which was – in all honesty – a trap: a well-intentioned honey trap with the purpose of trying to convince developers that they should be looking at Scala and evaluating it on the merits of its potential to deliver productivity gains, just as they would with a library or framework, rather than discounting it because it’s a “language”.
One of the comments I received was from Stephan Schmidt who writes the ‘codemonkeyism’ blog. Stephan wrote:
The sad state of our industry: Folklore.
Huge claim: “A New Java Library for Amazing Productivity Posted on February 11, 2013″
No facts or numbers. Continue reading
I’ve found this great Java library that can make developers more efficient in pretty much every source file they write. It has the following features:
- a broad and powerful collections framework
- collection methods that greatly reduce boilerplate
- immutable collections that don’t have mutation methods (unlike java.util classes where e.g. List.add() throws an exception if the list is immutable)
- an awesome switch-like function that doesn’t just match numbers, enums, chars and strings, but can succinctly match all kinds of patterns in lots of different classes, even in your own classes
- an annotation that automatically writes meaningful equals, hashCode and toString methods for classes whose fields don’t change (without using reflection) Continue reading
Interest in DevOps is booming. I feel like I heard it mentioned as the motivation for some decision at least once a week last year, and it climbed its way into the headlines of most of the newsletters I receive from LinkedIn, Twitter, InfoQ, etc.
I thought I understood it. It just means Dev and Ops collaborating closer, right? But as it gained more and more attention, I realised it must be a movement, not just a simple idea, so I set out to discover what DevOps was really about.
This blog is my summary of what I’ve learned from reading about DevOps over the last few months. There are heaps of resources and lots of people making great observations, so what I’ve done is try to distil lots of salient points into bullet-point format to make it easy for people to pick up as much as possible in a short read. Continue reading
I think the term ‘Domain Specific Language’ (DSL) is starting to become over-used and is being applied to things that aren’t really languages at all.
A Tale of Two Designers
When I think about explaining DSLs to people, the examples that spring to mind are languages like SQL, Regular Expressions, maybe even BNF, or CORBA IDL. And if I think about Why these languages exist, I imagine that somewhere, at some time, somebody thought:
I’m going to design a new language that is specifically crafted for solving this particular problem.
I like DSLs. Or maybe it would be more accurate to say I love them. They are powerful, expressive, and allow people who are eager to describe a solution or encode information (be they programmers or otherwise) to escape the complexities of imperative paradigms and Von Neumann thinking, permitting a strong focus on the actual problem.
In contrast to the above, the way in which I’ve most frequently seen the term DSL used of late is from people thinking something more like this: Continue reading
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: