Finger Eleven - Them vs. You vs. Me

~ Sometimes so it reminds me… ~ 

Third studio album from Finger Eleven released in 2007, so I'm only 6 years late ;)

Unlike the previous two albums, which I listened to non-stop for 2 years of my life, this album doesn't have many songs I actually like enough to listen to regularly. The sound is still very much Finger Eleven though. My main gripe is that too many of the tracks don't settle on a melodic or heavy tempo which ends up spoiling them.

Anywho, three great songs that have made it into my regular playlist:

Paralyzer
The opening track on the album, it has a steady beat that builds nicely and I enjoy the energy :)

I'll Keep Your Memory Vague
This is an absolutely beautiful song which is my favourite track of the album. It has a brilliant melodic quality and I find the lyrics to be poetic and really emotive.

Sense of a Spark
This track has a nice homage to Stay in Shadow and I like the neat little rift at the introduction.

Live Templates

One of my favourite features of IntelliJ is Live Templates because it enables me to be more productive and makes my work a lot more enjoyable. In this post I want to share with you:

1. An introduction to Live Templates
2. How it makes me more productive
3. Why I really enjoy using them!

What are Live Templates?

In a nutshell, Live templates are short-cuts for writing code. They can be incredibly simple but are also very powerful, allowing developers to quickly and reliably produce commonly used code constructs (such as for loops, covered later).

[A more detailed explanation and documentation can be found here: http://www.jetbrains.com/idea/webhelp/live-templates.html]

To find Live Templates within IntelliJ, open up the Settings (Default shortcut: Ctrl + Alt + S)

Above you can see the setting window and some pre-defined Live Templates. So how do you actually use them?

Gaining productivity

Using Live Templates is incredibly simple and there are many pre-defined ones we can you right now. One of the best ones that everyone one can mostly likely benefit from is the "iter" or for-each Live Template.

Suppose we have the following code:

1. Collection<String> listOfNames = getFriendNameList();  
2. // I want to wish all my friends a Merry Christmas  

Figure 2.1 - Initial code

Normally the next step would be you would start typing out a for-each loop manually. However, what you can do instead is:

1. Collection<String> listOfNames = getFriendNameList();  
2. // I want to wish all my friends a Merry Christmas  
3. iter // type out "iter"  

Figure 2.2 - About to use the for-each live template

Now hit the "Tab" key and...

Hey presto! IntelliJ has constructed a for-each loop for you using your Collection! Note that IntelliJ automatically highlights the collection and you can navigate up and down between multiple collection candidates.

Hitting enter will then allow you to rename your item variable:

Again IntelliJ jumps straight to the variable and you can give it a sensible name. Finally hitting enter will pop you inside the loop, ready for you to start coding:

Here I used the "sout" Live Template to quickly produce the println statement, try this yourself!

This is a really simple example but it highlights how you can use Live Templates to automate the mundane loop construction and launch straight into the important functionality xD

Sidestepping the mundane!

Sometimes a coding task can be pretty repetitive and typing out the same sort of code over and over gets pretty mundane pretty quickly. This is where custom Live Templates can come into play quite nicely!

Let's begin with a simple example, creating a Logger.

Above you can see my custom "logg" Live Template which does three things:

1. Constructs a Logger variable called log.
2. Automatically imports org.apache.log4j.Logger
3. Detects what class I am in and places it in the constructor argument.

Firstly you can see that the code is simply a variable declaration, which is what is inserted when I type "logg" and hit Tab.

Note the fully qualified Logger classpath, this is so that IntelliJ knows to import the log4j Logger. You can see on the bottom right of Figure 3.1 that I have checked "Shorten FQ names" which means the produced code will only have the simple name.

Finally I have used a Template variable "$CLASS_NAME$" to insert the classname. This is done by the "Edit variables" button which pops up the "Edit Template Variables" dialog. You can see I used one of the built in functions to return the classname.

[Read more about Template variables here: http://www.jetbrains.com/idea/webhelp/live-template-variables.html]

Conclusion

Live templates are fantastic and enable developers to spend less time writing scaffolding code and more time focused on the actual business logic and functionality. Although I only really found out about them relatively recently, I have woven it into the way I work and enjoying them ever since :)

For all those that use IntelliJ but haven't tried out Live Templates, I hope I have pipped your interest!

Agile In A Day - Training Summary

Yesterday I was luckily enough to go on a day course on Agile, which covered a multitude of topics and gave me a nice refresher on the topic.

Experiential Learning

Although it sounds like another bad buzz word, the concept of "experiential learning" was employed throughout the day. I actually really enjoyed it and I would definitely agree that the whole "learning by doing" concept.

Do Less... And Do It Better?

One of our first lessons was around one of the core tenants of Agile: uncovering problems and adapting to change faster. Our exercise basically illustrated that doing less work all at once meant you:

1. Had less work to throw away if it all went wrong.
2. Could find better ways to do the rest of the work.

Obviously doing things better doesn't magically happen, the techniques for continously improving is kind of what Agile is all about. The main technique/framework we focussed on was Scrum.

Scrum

A famous diagram I recall from my university days, sadly I have never really done Scrum in anger :( The biggest take away I had was the emphasis on "knowing what 'done' looks like". All your tasks in your product backlog should have concrete acceptance criteria, which ideally should be an automated test.

Another revelation was on the actual Daily Scrum meeting. Contrary to my experience, these meetings are actually supposed to last 15 minutes max and any problems should be discussed offline. Being strict with time and strict with your processes is very important in Agile, perhaps more so than in waterfall?

Finally we were reminded that Scrum is a framework which is abstracted from Software Development. You can in fact use Scrum for any project in any discipline! How you actually "turn backlog into product" is completely up to you, Scrum is a doughnut and it is up to you to find the jam to fill it with (your own processes/methodologies, e.g. TDD).

Understanding Requirements

We were shown some really useful techniques for gathering and understanding requirements:

• 5 Why's - This is basically trying to get to what someone really needs, going beyond what they think they want to do to get it.
• Clarification - Focussing on quantifying requirements and trying to put metrics against them so everyone understands what needs to be done.
• Suggestions - When you understand what the real need is, at this point we can use our expertise to figure out the most effect way to deliver that need. At this point you want to remember things like KISS and YAGNI ;)

Retrospectives

One of the greatest takeaways I had from the training was the whole concept of linking retrospectives. So in every retrospective you follow these rough steps:

1. What did we say we would change in our last retrospective?
• Did the change go well?
• Are we going to keep/disregard this change?
2. What went well this iteration?
3. What went badly this iteration?
4. Name a few things we can change for the next iteration.

The whole idea of actually coming up with actions, recording them and trying to measure their effects is very refreshing. Whilst my experience of retrospectives is limited, actually trying to quantify changes beyond vague pieces of advice is stupidly obvious to me now.

Conclusion

As with any lesson, it is only useful if you put it into practice. Doing Scrum/Agile in isolation just doesn't work, although I can keep being disciplined in using XP techniques. Got to do more Test Driven DESIGN like I mean it!

Launching Into Lambdas

Over the last few months I have had loads of fun learning about "Closures" or "Lambdas" in Java 8. For anyone else interested, here is a collection of resources that maybe handy! :)

Java One 2012 - Jump Starting Lambda
http://www.myexpospace.com/JavaOne2012/SessionFiles/CON5089_PDF_5089_0001.pdf

This is a really in-depth presentation that goes a lot into the motivation behind Lambdas. It contains pretty much all the information you need to get started but I'd perhaps go for a shorter/simpler presentation if you want to get started quicker. Maurice's talk below is great for this! xD

DevOxx UK 2013 - Collections After Eight by Maurice Naftalin
http://www.parleys.com/play/516436e9e4b09b60aec89cf2/chapter8/about

I was actually lucky enough to attend this talk and it was my first real exposure to Lambdas. The actual talk should hopefully be up on Parleys soon but the slides are available. Really recommend this as Maurice explains things beautifully.

Steams API Cheatsheet
I'm going to have to put together one for this! For now, Maurice's talk above has a lovely slide "Some Steam Methods" (just after the middle) which contains a brilliant table explaining the stream methods and the lambdas they take.

For now my best tip is to download IntelliJ IDEA 12 which has absolutely brilliant lambda support. ALT+ENTER is your friend! A great way to learn lambdas is to understand how those anonymous inner classes you right can be "lambda-rised" by IntelliJ!

GitHub - Lambda tutorial by Graham Allan
https://github.com/AdoptOpenJDK/lambda-tutorial

Graham has spent some time to put together an awesome tutorial for Lambdas, available on GitHub! Martijn has contributed to this and given it the thumbs up so it must be awesome, right?! :P

GitHub - Playing Parallel Stream + Simple Benchmarking
https://github.com/arkangelofkaos/CodeDojo21_RandomNumbers

Here is one of my late night, post Code Dojo hacks I threw together. I experimented a little with Parallel Streams (hurray for simpler concurrency), doing a very simple and most likely flawed benchmark on the performance of different sorting algorithms.

GitHub - Using Collections Streams
https://github.com/arkangelofkaos/CodeDojo22_Checkout

Another Code Dojo inspired hack, except this time it actually makes sense and it really highlights a real use case for Collection Streams. I didn't complete the code for everything we did in the Kata but I think it covers the core of it well.

Tomb Raider

Having ploughed on after my initial few hours playing Tomb Raider, I managed to clock this great game last week! Here is my view on it, which in short is: "awesome value, looking forward to an improved sequel" XD

As soon as you start playing Tomb Raider, you are stunned by the sublime graphics. Everything from the magnificent vistas to the subtle fire effects are done beautifully. Lara looks amazing and how she gradually gets roughed up as the game progresses is really well done. 

Cleverly crafted pixels abound in the violence as well, which is somewhat biblical. Among the more gruesome ways to get Lara killed is getting impaled through head or rather sickeningly crushed by rocks. There seems to be an amazing variety of death scenes and they are all disgustingly well done, kudos to the development team for the amazing effort, you should all be locked up ;) 

Just to note that the sound effects for these scenes and in fact the whole game are done very well. There is a satisfying attention to detail and throughout the music of the game makes for a good backdrop.  However it can be a bit annoying at times, making situations feel more urgent then they are. All part of the game I suppose!

As I mentioned before, the voice acting is superb in this game. Lara in particular is fantastically well done by Camilla Luddington. Over the course of the game you really hear her develop from a terrified girl to a fiery Boudica figure feared by all.

The supporting cast are all fairly interesting as well, although the villain is very stereotypical madman. Plot in this game is very thin and fairly predictable, nevertheless it is still enjoyable. The documents you can collect provide a really great insight into the history of the island. Hearing the authors read out their stories is surprisingly enjoyable and empathic.

Where the game really falls down is the mediocre combat. On normal mode the game is very simple, Lara is simply a wrecking ball. Enemies are very repetitive and even "boss" fights aren't that interesting.   Once you unlock some of the finishing moves, they can be very satisfying. To keep things more challenging and fun, try to headshot/stealth kill as many enemies as possible. The extra XP from doing so is also very welcome :)

Speaking of which, developing and upgrading both Lara's skills and weapons is done through a simple system of Experience Points and Salvage/Weapon Parts. As you go through the game, the system expands and you get a real sense Lara is becoming cold blooded and really deadly. All in all the whole system is implemented really well and adds an interesting role playing element to the game.

Playing through Tomb Raider, I was very much reminded of the gameplay of Assassin's Creed. The "Survival Instincts" mechanism which highlights your goals and enemies reminded me a lot of Eagle Vision. What could have differentiated the game better would have been better use of "Survival aspects". Lara never actually has to eat or sleep beyond the start of the game. It would have been nice to have had MGS3 style stamina gauge included.

Platforming is a big aspect and it is simple and fun. The reset mechanism for when you die works very well, putting you right back into the thick of the action. However the "optional tombs" are amazingly short lived. Aside from the frustrating and repetitive trek to the puzzle chamber, you can finish them in next to no time at all. However they are an interesting change of pace and some of the puzzles are fiendish.

In conclusion, I enjoyed playing the game but it isn't special. You get a fantastic amount of quality time out of the single player game as well as there being multiplayer (although I haven't tried it yet). A fun first entry in the rebooted series, I look forward to raiding tombs again with Lara Croft on the PS4! XD

OpenJDK Test Fest (23rd March 2013)

Better late than never, I'm writing about my very first hack-day working on OpenJDK testing :)

Introduction

After LJC Conf 2012 I got interested in the Adopt OpenJDK project. Sadly it was only in early 2013 when I finally managed to get fully set up for the project. (Building Java has gotten a lot easier!)

A big issue for the OpenJDK project is that currently there are little to none open tests. Whilst Oracle and others have many prioritory tests for the JDK, they are unlikely to be released anytime soon. Hence there is a big push to improve the quality of exisiting tests and increase test coverage.

What I hope to cover in this post is:

1. Getting started testing OpenJDK (using JTReg)
2. Guidance on testing OpenJDK
3. Next steps (how you can get involved!)

Getting Started - Seed project

OpenJDK tests are primarily written using a tool called JTReg. The reason behind this that the very first tests pre-date JUnit and TestNG. Sadly this does make writing OpenJDK tests a bit of a pain...

To get started easily, I recommend you utilise the seed project I set up here:
https://github.com/arkangelofkaos/OpenJdkTesting

Within it you will find a copy of JTReg and a few very simple tests to show you the basics. I highly recommend you go through the JTReg tutorial (available here).

Guidance

During the hack-day we were given a list of "Ten Golden Rules" for testing on OpenJDK, here is my take on them:

1. Think before you code! 
• Have a specific goal, target specific methods.
2. Make tests understandable
• Fill in the summary tag
• Be clear and make your test goal explicit
3. Make tests "small and simple"
• Use setup and teardown as necessary.
• Keep tests idempotent. 
• Not cleaning up is not only impolite but can cause errors for other test cases!
4. Test only one thing!
• 1 assert per test = easy to understand and simple :)
5. Fast tests only! 
• Quick tests required as they will be run over and over.
6. Absolute repeatability
• Tests ONLY fail if there is a bug in the code under test.
• One pitfall is using Thread.sleep to handle concurrency issues
• Understand what your goal is (draw it out!)
• Use proper concurrency tools to enforce an execution order (e.g. countdown latches)
7. Independent tests
• Tests should not rely on other tests or be affected by execution order.
8. Provide diagnostic data on failure
• Use messages on assertions and throw sensible exceptions.
9. Ensure portability
• Do not hardcode environment details into the test.
10. Silence is golden
• Only speak up if the test is broken. Don't pollute the output. 
• However, sometimes a little additional output is very helpful for debugging.

As always with any software rules, the rules depend on the circumstance. Sometimes you will need to break these rules but it is important we understand why!

Conclusion

Java needs our help to stay relevant and increase the pace of upgrades. This means testing needs to improve and we can contribute to this through OpenJDK. If you are interested, I highly recommend you grab the seed project, join up and give it a go!