Betterrev - A Better Webrev

One night after the GS Collections talk, I was speaking to Martijn and the conversation touched upon Betterrev, an Open Source project he was working on. Keen to repay Martijn for supporting the LJC Book Club and putting on an awesome DevOxxUK Conference, I offered my assistance.

Before I knew it, I was a member of the AdoptOpenJDK Bitbucket team and told to meet at the jClarity office the following week to do some hacking! Having only dabbled in Open Source before, it was both daunting and really exciting to be diving straight in. However ever since then I've been learning bucket loads and this post will recount many new discoveries xD

What IS Betterrev?

"A friendly, hosted wrapper around webrevs"

In layman terms, Betterrev is going to be a website for managing changes on the OpenJDK project. Currently developers have to use the Webrev tool for generating a report on their changes and submit it manually to the right people. To make a "Better Webrev" which automates a lot of this work, Martijn and others in the AdoptOpenJDK group started Betterrev :)

Currently the goal is to have an alpha version running before Java One. This version would automatically detect Pull Requests against the Bitbucket OpenJDK repositories and generate Webrevs against the Oracle OpenJDK repositories. 

These "webrevs" would then be wrapped up into "Pull Reviews" in Betterrev, which has an automatically managed lifecycle. This gives everyone involved the ability to:

• Automatically inform the correct people when a change requires their attention.
• Analyse, in one place, all the different changes and their statuses.
• Automatically be informed of completion/rejection of changes.

All in all, this will be another step to making improvements to Java quicker and easier to do! :)

Getting Used to git

Having never used Git properly with multiple developers before, I had to get rapidly up to speed with foreign concepts such as "upstream" and generating "pull requests". Luckily I had many people to learn off, my thanks to Kaushal and Mani for all their assistance!

The main concepts I got my head around were:

Forking - Creating & Maintaining

Creating a fork really is as simple as clicking a button on the BitBucket/GitHub. The trick I missed is that to maintain your fork, you need to keep "pulling" changes from the original repo. This can be as simple as adding a new "upstream" remote:

git remote add upstream https://bitbucket.org/adoptopenjdk/betterrev.git

To update yourself with the latest changes, simply execute a pull on upstream. Within IntelliJ, this can be triggered with ease. Doing it inside IntelliJ also has the added advantage of letting you use a GUI to manage any potential merge conflicts! :D Once you are happy with it, you can push the changes back to your origin repo on GitHub/BitBucket.

Pull Requests

When you want to get your changes accepted back into the repository you forked, you can generate a Pull Request containing your changes. What is really interesting is how easy they are to create and manage!

Other users may comment on your Pull Request and suggest changes. Should you act on these changes and commit amendments, BitBucket automagically detects them and offers to merge them into your Pull Request! This is freaking awesome! XD

Code reviews - teasing out laziness

On the subject of code reviews, it is awesome working in an environment brimming with technical talent. Being able to get expert feedback on your code is truly invaluable.

Nigel once said to me: "pairing doesn't make you twice as smart, it makes you half as dumb!" Similarly I've found that code reviews make you half as lazy. Late one night I got a bit too happy copy and pasting things in CSS. Come the next code review Martijn called this out and simply commented: "the C is for cascade" ;)

Things like are seemingly minor but very important to catch and call out. Technical debt always finds a way of ruining your day!

Whiteboard to reality

One aspect I found really rewarding was rapidly turning whiteboard drawings into a real running prototype!

Whiteboard Brainstorming & Initial Sketch

Locally running implementation

Given that there isn't really that much there but the sense of accomplishment was neat :)

Playing with bootstrap

Putting that screen all together required me to learn a few new things. Twitter Bootstrap is a nifty tool but I found out there isn't really a "box" tool. Those grey borders had to be manually hacked together with CSS old school style. However learning about the 12 column grid and glyphicons was kool though :)

On the logic/serverside, there was lots to learn in the Play 2 framework. Using Scala within HTML Templates was very novel, Scala code is pleasant and straightforward, if not a little foreign!

Next steps

So now it is just a question of investing more time and helping out where possible!

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?

A 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!