Saturday 10 August 2013

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!

No comments:

Post a Comment