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.
Wednesday, 15 May 2013
Sunday, 12 May 2013
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
Sunday, 5 May 2013
OpenJDK Test Fest (23rd March 2013)
Better late than never, I'm writing about my very first hack-day working on OpenJDK testing :)
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:
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).
During the hack-day we were given a list of "Ten Golden Rules" for testing on OpenJDK, here is my take on them:
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!
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:
- Getting started testing OpenJDK (using JTReg)
- Guidance on testing OpenJDK
- 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:
- Think before you code!
- Have a specific goal, target specific methods.
- Make tests understandable
- Fill in the summary tag
- Be clear and make your test goal explicit
- 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!
- Test only one thing!
- 1 assert per test = easy to understand and simple :)
- Fast tests only!
- Quick tests required as they will be run over and over.
- 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)
- Independent tests
- Tests should not rely on other tests or be affected by execution order.
- Provide diagnostic data on failure
- Use messages on assertions and throw sensible exceptions.
- Ensure portability
- Do not hardcode environment details into the test.
- 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!
Subscribe to:
Posts (Atom)




