9 fascinating things I learned while coding up the rules of a board game

I recently decided I was going to take the rules of the board game Forbidden Island and write them up as code.

A screen full of code in an IDEI guess that sounds like a weird thing to just decide to do, doesn’t it? It’s actually one part of a bigger goal I have at the moment of teaching myself some practical machine learning. As part of this journey, I heard a great idea from YouTuber Jabrils to set yourself a significant challenge that you’re interested in, and to work towards surmounting that challenge. For Jabrils, his challenge was getting an AI to control a Forrest Gump character to run around a course in a game. For my challenge, I’ve decided I’d like to build an AI that can play Forbidden Island. (And win!)

Obviously, if you’re going to have an AI play a game, you first need a digital version of the game for the AI to play. Continue reading

The Amazing Benefits of Exercism

A couple of months ago, a good friend at work (@rodeoclownII) sent out an email (or blog, or Slack message, or something) about exercism.io. It’s a cool little website for practising programming in various languages (currently about 45) by implementing koans, or small exercise problems.

I’ve been working through the Kotlin problems since the start of the year and I’ve found it super useful, so I thought I’d write this quick blog to recommend it to others.

Why I like exercism.io so much

Actor Anthony Hopkins seemingly performing an exorcism with the words "Back to hell, demon!" Probably unrelated to exercism.io

Just to be clear, we’re not talking about this kind of exorcism.

The most obvious benefit of this site is the opportunity to practise using different elements of the Kotlin language and standard library. Being challenged to solve problems which you might not necessarily come across during day-to-day work can lead you to discover parts of Kotlin that are really useful but which you otherwise might not have found a need to go looking for. Also, the problems are all implemented in a test-driven way, which feels very natural for me as a long-time practitioner of Extreme Programming/TDD. Continue reading

Top 10 Reasons Java Programs Envy Scala (Presentation)

From the archive: Originally posted in October 2011, I was reminded today of this post from my old blog, Graham Hacking Scala. I thought I should bring it over and give it a bit of a refresh…

In October 2011, I presented a talk at the 2nd meeting of the (then) new ScalaSyd Meetup. I talked through the “Top 10 Reasons Java Programs Envy Scala” in an attempt to give Java developers a taste of some little things that could make them much more productive if they switch to Scala.

Interestingly, in almost 4 years, very little has changed. Yes, Java 8 now has lambdas, but the standard collections library still makes very little use of them, forcing you to convert any collection to a stream before lambdas can be used, and pretty much nothing else mentioned in the talk has made its way into Java SE. People are still writing up lists of how to use Java better, but the fact is that a lot of Java best practices are either built into or easier to achieve in Scala.

Anyway, if you want get the real scoop on Java vs Scala and hear what all the Scala kids are raving about:

  1. hit play on the SoundCloud recording below, and then
  2. follow your way through the Prezi below that.

Continue reading

Design Kata: Learn software architecture while having fun

Children practising a karate kata. This article describes design kata, where software developers practise designing software architecture.At Tyro, we don’t have anyone with the title of Architect, Designer or Tech Lead who designs software and then asks other people to build it. Instead, each team of Software Engineers does architecture and design as part of their iteration planning sessions for the stories we’re taking on.

As a Team Lead, the two main goals I keep in mind for each person are: keep them happy and keep them growing. One of the ways I try to ensure this happens is by meeting with each person regularly so we can chat about how to make sure these things are true or at least heading in the right direction.

A topic that’s come up with a few people lately is software design and architecture. Specifically, I’ve had a couple of comments along the lines of: “When we’re designing things, I want to contribute more, but I’m not really sure where to start.” Continue reading

How to Avoid Making Huge Mistakes with Life’s Big Decisions

The Mistake

A condemned three-story house in DetroitWhen my wife and I had been married for a year, we made a decision to purchase an apartment. It remains, to date, the worst decision we’ve ever made.

To start off with, we probably shouldn’t have purchased anything at all. But there was pressure from parents, the peer pressure of our friends doing the same thing, and the constant fear in Sydney-siders of “getting left behind the market”. Looking back now, I see the bigger factors that we’d been married for one year, we were both very early in our careers, we had very little savings relative to our incomes, and we were living in a friend’s place for low rent. There weren’t really any good reasons to buy.

The big mistake, though, was the place we bought. Continue reading

Notes from YOW! 2014: Ed Kmett on ’Stop Treading Water: Learning to Learn’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Ed Kmett (@kmett) started by asking: “What is the cost of using the wrong solutions, integrated over your entire career?” (Slides, Video)

Then he revealed that the topic he’d chosen for the talk was…

“How to be a genius”.

Portrait of genius physicist Richard FeynmanHe talked about a strategy for solving big problems described by famous theoretical physicist Richard Feynman (pictured):

  1. Keep a bunch of your favourite problems in your head.
  2. Every time you hear a new idea -> test it against one of your problems to see if it helps.
  3. If it does, tell people about the breakthrough, and they’ll think you’re a genius.

Note that, in Feynman’s approach, genius is attributed not necessarily to those that come up with new ideas, but often to those who figure out where to apply them.

Developers and Researchers

He noted that developers are in the business of solving problems, searching for solutions, while researchers often have solutions, but are searching for the right problems to apply them to. As a developer, it can be good to keep abreast of what researchers are discovering in hope of finding a solution to one of your favourite problems.

Memory Retention

He discussed human memory retention and the need to revisit topics over time to retain knowledge about them. The brain remembers far better information that is used or revised repeatedly. Knowing this, you can hack the brain by intentionally repeating material that you want to remember. (For example, after going to a conference, you could write a blog about the important points from each talk you went to.)

He chatted a little bit about jargon, saying that if you’re going to use jargon, you should always be willing to explain what it means.

Image credit: Richard Phillips Feynman (1918 – 1988) (unknown)

(My notes from) Ken Scambler on ‘Two Years of Real-World FP at REA’

This evening I went to a YOW Night where Ken Scambler (@KenScambler) spoke about the introduction and evolution of using Scala at REA Group. Here’s my notes…

Functional Scala Benefits

The sprial logo of the functional programming language language ScalaThe benefits of going functional are to get to code that is: Modular, Abstract, Composable.

Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.

To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.

Abstraction should reduce changes to code, because unnecessary detail is not all across the code.

Whole systems can be composed from functional components.

Functional programming is not about picking up a hipster language. It’s about producing better software.
Continue reading

From the Archive: Why Your Company Should Let You Use Scala at Work

From the archive: Originally written in January 2010, this post from my old blog, Graham Hacking Scala, has been consistently popular ever since and I thought it deserved a new lease on life here…

Java at work: an increasingly frustrating experience

If Raffa wanted to use Scala at work because he thought it would help him win, would you make him use Java?A colleague and I were writing a test in Java today and I had one of those “I can’t believe it takes this much work to write this stupid function” moments. If you do any Scala programming but still do a lot of Java programming, you’ll know exactly what I mean. I’ll walk you through a mock of what we were doing and you can see why Scala just pummels Java when it comes to expressiveness. (Early warning: do not use the word “expressive” when trying to convince your manager to let you use Scala at work.) Continue reading

Notes from YOW! 2013: Jeff Paton on ‘Safety Not Guaranteed: How Successful (Agile) Teams Ignore the Rules to Create Successful Products’

I attended Day 1 of YOW! Sydney 2013 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Two people dressed as crash test dummies with their thumbs up. Does following Agile processes to the letter mean your team will be safe and succeed?Jeff Paton (@jeffpaton) is an independent consultant, teacher and Agile coach, and (I believe someone said) the inventor of Story Mapping. He spoke at YOW! about ‘Safety Not Guaranteed: How Successful Teams Ignore the Rules to Create Successful Products’.

Jeff started his talk by announcing that he hated agile development since the moment he first heard of it, but went on to explain that he doesn’t really hate agile now and that an important part of this has been to learn to pay a lot of attention to what he’s doing. Continue reading

A New Java Library for Amazing Productivity

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:

  • Ferrari 458 Italiaa 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