Thursday 21 March 2013

LJC Event - Trisha Gee's Design Talk

Tonight I managed to attend an awesome talk by Trisha Gee entitled: What do you mean, backwards compatibility?

Overall I found the talk to be a fantastic insight into software design and has inspired me to read into a load of other topics :)

Lessons

  • Setting "Design Goals" gives you good guidance without being overly prescriptive.
    • Remember good design is supposed to help you produce good code.
    • An example is immutability, it is good design for achieving the goal of thread safe code. 
  • "Design is a Process, not an Artefact"
    • Design documentation is supposed to enable good change, i.e. UML can highlight concepts that need to be readdressed.
    • However documentation is out of date as soon as it is written, code should be self descriptive and design should stand out.
  • Great API design has "User Empathy"
    • You heard of achieving high performance though "Mechanical Sympathy", well now we have the "User Empathy" too ;) Heard it here first :P

Further Reading

  • Domain Driven Design - aren't we doing this already? I need to read more!
  • Fluent Interfaces - this is more than just method chaining, can this be used outside of building?
  • Strategy Pattern - not something I used much but potentially very useful, too many if statements!
  • Behaviour Driven Development - So this is all the TDD practices I've been learning without knowing it? Awesome! I want to learn this properly!

Feedback

  • Finally some feedback on Trisha's actual talk...
  • The talk could do with a stronger introduction and focus more on design, it isn't really focussed on the MongoDB Java Driver and I don't think that is a bad thing!
  • Really love the Monsters/Safe Houses analogy, gave really good structure to the talk and it is a beautifully simple analogy. 

Friday 15 March 2013

Biting into Bytecode

As a part of my programming goals, I am gaining a better insight to how my Java code translates to byte-code. In this post I will document my findings and figuring out what "warming up" your Java code actually means!

Please note that much of what I have learnt has been distilled from the excellent book: "The Well-Grounded Java Developer" by Ben Evans and Martijn Verburg. I highly recommend the book to anyone looking to better understand Java, the JVM and the Java ecosystem.

Java to CPU - A Journey


Here are the basic steps for how Java code ends up running on the CPU:
  1. The Java compiler (javac) takes Java files (.java) as input.
  2. Class files (.class) are produced which contain bytecode.
  3. The JVM will interpret this bytecode, executing your program.
  4. Bytecode maybe translated into native machine code to run directly on the CPU.
Although that is a very simplistic and general overview, it highlights the key points. An interesting thing to note is that Java is both a compiled and interpreted language! In fact Java is a twice compiled language, once into bytecode and potentially another time into machine code.

So Java code is translated into bytecode before it can be executed... but what exactly is bytecode?

Class Files & Bytecode - Under the Covers


Java is designed to "run anywhere", which means it must be abstracted from the underlying hardware and operating system it is running on. To achieve this, Java uses bytecode!

The most important thing to remember is that bytecode is not machine code but an abstraction of machine code. For me, bytecode reads a lot like assembly code and in essence it is the same thing, except it is non-specific to a machine architecture.

This means that the bytecode deals with fundamental operations such as loading values off the stack and jumping to specific instructions. This all comes together to represent the Java code you wrote (for reference to all the JVM bytecode operations, see the JVM spec).

However the bytecode is not always a direct translation of what was in the code. Optimisations may be made, such as when String concatenation occurs. Under the covers, javac won't produce bytecode to build a new String object directly but instead use a StringBuilder!

The implication of this is that when building simple Strings outside of loops, you don't need to manually create a StringBuilder yourself! So instead of trying thinking you have to write things like this:
String name = getName();
StringBuilder messageBuilder = new StringBuilder()
    .append("Hello ")
    .append(name)
    .append('!');
System.out.println(messageBuilder.toString());
You can instead be happy in the knowledge that javac has your back and you can write this:
String name = getName();
System.out.println("Hello " + name + "!");

Warming Up Code - Just In Time Compilation


As we now know, the JVM takes in bytecode and executes it for us. However what isn't clear is when, how or why that bytecode is turned into machine code. Is this part of the mysterious process of "warming up" the Java code?

I recall when I first tasked with profiling real low latency code and I was told that you had to "warm up" the Java code before you start taking measurements. At the time I understood this has to do with runtime optimisations but I never truly knew what was happening... until now!

When executing methods, the JVM will begin by reading and running the bytecode in it line by line. This is typically a lot slower than if the entire method was translated from bytecode to native machine code. However the JVM won't do this to any method until it is ready to, or rather it will do it "just in time" ;) [Thanks to StackOverflow for patching up my understanding!]

Part of what qualifies a method for compilation is the number of times it has run. Hence we warm up code by calling the methods repeatedly because it will trigger JIT compilation and make our methods run faster up-to 100 times faster!

Conclusion


To summarise, we have found that Java is a language which is first compiled into bytecode,  an abstraction over machine code. This bytecode is interpretted by the JVM to run the underlying program, with the JIT compiler kicking in to translate it into native machine code after a "while".

Probably the most interesting question to come out of this, for me, is how exactly the JVM decides to trigger JIT compilation and the mechanics behind it all. Expect that and diving into garbage collection in future posts!

Monday 11 March 2013

London Code Dojo 19

*update* Added my basic Scala implementation of FizzBuzz here: https://github.com/arkangelofkaos/FizzBuzz

Recently I was introduced to the London Code Dojo by a good friend and on Monday I attended my first code dojo!

What is the Code Dojo?

dojo is a place to practice an art and a code dojo is no different! The purpose of it is to allow developers to practice and learn. The first rule of code dojo is you are there to "do it right"!

Everyone has probably heard it takes practice to make perfect and in theory you need to do 10,000 hours of practice to become an expert in anything! This practice has to be done properly though, specifically it must:
  • Be focussed
  • Be goal-Directed
  • Be stretching (aka not easy)
  • Include continuous feedback
  • Include self-reflection
To get this kind of practice at the dojo, we all participate in a kata. This is basically a coding exercise with very specific rules.
  • The goal is to do things correctly, not to simply get everything done.
  • You must do Test-Driven Development (this is taken to the extreme)
  • You must do pair programming
  • You must commit/revert every 5 minutes!
  • Commits must be meaningful with a simple and descriptive one-line comment.
  • After 20 minutes a quick retrospective is held and new requirements maybe added.

My Impressions & Lessons Learnt

Our Kata for the night revolved around implementing Fizz Buzz, which is non-trivial given the TDD constraints.

The dojo really gave me a baptism of fire. As no one wanted to write in Java,  I took it upon myself to try to code in Scala for the very first time. Simply reading the Scala chapter in my book club book had given me a decent start though :) Apologies to my pairing partners for the frustration!

@sleepyfox who runs the dojo made a great pitch for TDD and how it saves time in developing long AND short projects! From my point of view, I suppose it follows the whole "fail fast" methodology. Mistakes are always made and by doing TDD you ensure you catch mistakes quickly, rather than having to hunt for them.

However I still reckon the age old "it depends" answer applies to whether or not you should use TDD. Part of my 'homework' is to research "Spike and Stabilise" which sounds interesting...

One thing I did get pulled up on was my when I answered too quickly. Remember: "Respond don't react!". Polymorphism is not necessarily always the answer to replacing a bunch of "if - instanceof" statements!

My favourite phrase for the evening was: "If you are 'refactoring' but everything ends up broken, you are actually 'ref**ktoring' your code" XD

The biggest takeaway was the emphasis on ALWAYS being simple, concise and expressive. Doing things in a complicated fashion is easy, any idiot can do it. But being simple is tough, in both your code and your commit comments.

Really learnt a lot from the dojo and look forward to future ones!

Sunday 10 March 2013

Skimmer's Guide - "Chapter 10: Clojure: Safer Programming" of "Well-Grounded Java Developer"

Foreword

Recently I set-up the LJC Book Club (blog here) with Ged Byrne and the first book we chose was "The Well-Grounded Java Developer" by Benjamin Evan and Martijn Verburg.

As a part of the reading schedule, Ged and I are hoping to produce a weekly "Skimmer's Guide". 

This is my first such attempt and hopefully there will be many more to come!




“..Lisp is an acronym for Lots of Irritating Silly Parentheses...”

What did we read about?

Week 6 has brought us to the Clojure chapter which focuses on introducing the functional language to Java developers. The topics range from your simple 'Hello World' program all the way to Clojure style concurrency being used to steal all the money from Ben's account!


What stood out?

Arithmetic, equality and other operators (p. 287)
Simple explanation of the Clojure mathematical operators and introduces variadic functions. In-short using a variable number of function parameters - e.g. (+ 1 2 3) // returns 6

Schwartzian transform (p. 290)
Great example which allows you to learn how to read Clojure "inside-out" and really get to grips with core concepts of functional programming.

Multi-thread ATM (starting p. 308)
Fantastic example of whole concise Clojure can be over Java, as well as explaining how to do concurrency in Clojure.


If you read nothing else this week...

Getting started with the REPL (p. 281)
Get started hacking on the "Clojure console" and learn about mutable/immuntable state in Clojure.
Interoperating between Clojure and Java (p. 299)
Learn how to call Java from the "Clojure console" and get under the covers of Clojure on the JVM.