London Java Community - Open Conference 2014

I have had an absolute blast attending my 3rd LJC Unconference! As always I have learnt loads and this year I also had the opportunity to help others find out some nifty things as well :)

Discussion - Concurrent Applications In The Modern JVM & Using Akka

The last four letters of my name are still being horrendously neglected

I took the plunge and got roped in by our funnest software evangelist to answer the call of two developers interested in Modern Concurrency and Akka (@Simon - remember it is Edward - not Ed! :P)

When I originally agreed to do this in the morning, I was hoping for a small group of people to show up and we would have some simple roundtable discussion... Somehow at 3pm I found myself in the main room standing in front of thirty or more people!!! Luckily I had "The One" with me and the LSCC Roundtables have taught me how to lead a discussion (much love to Samir, Sandro and Tom for this!)

To start the discussion, I gave a little rant about how manually wiring up multi-threaded code is really hard and the pitfalls we found when using Akka in BetterRev - an Adopt OpenJDK project to change the way we change Java. From there we all talked about our various experiences and there were some great insights from people on a range of concurrency topics/tools. I really enjoyed the session and hope people got something out of it :)

Developing As A Developer - Getting Involved With The Community

The number of first time attendees to the conference was quite high and I got to speak to a bunch of developers that were just starting their professional careers. My advice to everyone was to get involved with the community, even if you by just blogging! Sharing the interesting things you have learnt is a great way to ensure you reinforce that learning and can lead you to learn new things.

One of the funnest and most rewarding things you can do with the community is to hack together. Attending code dojos and hands on sessions gives you the opportunity to learn more about anything from sweet IDE shortcuts to SOLID software design principles. I cannot recommend these enough!

Conclusion

Another year has passed and I'm already excited for the next conference. My thanks to all that gave me such invaluable advice again and to everyone involved in organising and running the conference!

Destiny - Awesomeness

3 months on from the full release of Destiny and despite all of its flaws, I am still very much enjoying this game. There is definitely fun to be had but it is very much dependent on how you approach the game. Finding a bunch of people that you can have a laugh with is invaluable, if you play alone you are missing out on some of the best content!

Moments of "awesomeness" await you, so long as you now how to find it. As I've mentioned before, there is a special move you can unlock that gives you the ability to soar through the air like Superman. This opens up the opportunity to play a hero that is fighting giant aliens to save the world, all the while pretending to be Kal-El... saucesome :D

Check out my channel for more Destiny awesomeness! https://www.youtube.com/user/arkangelofkaos

Destiny - The Titan Superman Move

The IGN First series have continued their coverage of Destiny and I am super excited about the high level Titan moves!

The aptly named "Death From Above" supercharge upgrade is simply bananas. You literally fly through the air like Superman, it is so great! :D The shoulder charge move looks like a lot of fun to use as well. I particularly enjoy the jumping version where you knee the poor victim in the face :)

Screenshots of all this along with the sweet gear/weapon Kinslayer was using can be found below (see full post) :)

Playing as a Titan during the Beta was incredibly fun (find all my PS4 Gameplay videos here), can't wait to try out all of this for myself!

Football In Destiny

Above is a recording of Celark messing around on my PS4, kicking a ball around during the Destiny Beta. Silly as it may sound, it was absolutely hilarious! :D

Whilst exploring the Tower in between all the shooting, we came across a large purple ball. After playing around with it for a while we started an impromptu kick about! At 1m6s we start playing goalkeeper between the Vault posts. Another guardian cottoned onto this immediately and his sudden cautious behaviour whilst he lined up a shot was great :)

Everyone finding out how to perform "slide tackles" lead to more mayhem (2m6s). After a while we decided the ball had to be destroyed. As we knocked the ball off the edge, another guardian jumped to his doom trying to save it (2m34s) :D

After this we were all doubled over laughing our heads off. Moments like these really capture the excitement you can have with great games. This small feature has already inspired a cult following and it is just one of the many fantastic activities this playground we call Destiny is rammed full of. Simply cannot wait to play the full game in September!

Being able to share all of this fun so seamlessly is a surprisingly satisfying feature of the PS4. Although the Beta is over, you can find more of my gameplay videos on my YouTube channel: http://www.youtube.com/user/arkangelofkaos

Ranting About Retrospectives

Following on from Thinking About Code, I have since participated in a retrospective and the introspective process has inspired me to rant :)

Free Your Mind

One of the problems we had in our last retrospective was we were very much unprepared. Many of us did not have proper notes and worst of all there was a negative mindset toward the whole retrospective process. This time around everyone actively prepared and everyone was onboard with the idea of using the retrospective to improve the way we work. A positive viewpoint really works wonders and resulted in a much higher quality of the discussion :)

Bricks Without Clay

As the famous Sherlock quote goes, you can only put theories together when you have data. This principle holds true for any scientific process, including retrospectives. This is computer science we are dealing with after all!

In our case, data is as simple as our likes and dislikes about our work. However as there is a month between our retrospectives, forgetfulness is a major issue. Ongoing observation is the key here, we all need to constantly seek out analyse the way we work. This can be as simple as jotting down notes on what you feel is good/bad as you work. 

Get To The Point

Open ended questions like "what did you like/dislike this month?" are great for getting people to open up but can lead to rambling. In an ideal world you want everyone to distill their feelings beforehand and provide short and sweet summaries. The key is to move beyond raw emotions and use unambiguous statements: "I don't like rambling" is better stated as: "I like people being concise".

Mixing It Up

When undergoing the process of self reflection, it is important to have compare and contrast against others. Trying to view things from an outsider's perspective can throw into light problems/opportunities you would have otherwise missed. In our case, reviewing a piece of code written by an applicant threw up a lot of interesting viewpoints.

Conclusion

Overall I feel that retrospectives are having a positive effect on the team and the change in mentality is very refreshing. We are all looking at ways to better ourselves, both individually and as a team. The next steps are to achieve the things we have talked about, which is always easier said than done.

Thinking About Code

Last night I dragged my colleague Simon to the monthly LSCC Round Table and we had some interesting conversations around the topic: "how to balance time between discussing code and actually coding". The session was enlightening and we ended the night with a lot of food for thought (to supplement all the pizza and soft drinks provided by our wonderful hosts xD).

The original premise for the discussion came from a feeling within our team that we were doing retrospectives too often. Assuming that nothing "bad" has happened lately, was it necessary to hold a retrospective? Would forcing a retrospective simply push people to artificially discuss arbitrary topics for the simple sake of it?

We need more data to make a proper judgement but it is clear that there is more we can do to benefit from our retrospectives. One of the obstacles in our way could be a misperceived purpose of a retrospective: a process through which to fix problems. Whilst this is an aspect of retrospectives, if we look at how others do retrospectives it quickly become apparent that the focus is primarily on gathering feedback. Even when things are going well, there is bound to be something that could be improved, nobody is perfect after all!

Contrary to this, changing simply for the sake of change can be a waste of time. Identifying the right areas/processes to change is hard. In our case it very much feels like we need to prepare better for our retrospectives and do more to facilitate the discussions inside them. There is a wealth of material out there on retrospective facilitation but Tom's blog post on the 7 pillars of agile and spiderweb retrospective caught my eye.

As mentioned, it is very early days for our team as we only had two retrospectives since we changed the format and it would be premature to apply any changes as a knee jerk reaction. Going back to the very core of the issue, we have to ensure everyone understands the purpose of the retrospective. Once everyone has the same mindset, we can start evolving the process from there :)

Credit to http://sebastianlab.com/post/140303165/typing-is-not-the-bottleneck from which I got the typing monkey image :)

Skimmer's Guide - Head First Design Patterns - Welcome To Design Patterns

“The best way to use patterns is to load your brain with them and then recognize places... where you can apply them. Instead of code reuse, with patterns you get experience reuse.”

FOREWORD

I'm reading Head First Design Patterns along with a few others in the LJC Book Club. As we read, I'll produce a series of Skimmer's Guide posts for each significant section of the book. The previous section, on the Introduction, is here. If you are interested, please join the discussion on our Google+ community.

WHAT IS THE ABOUT? 

Continuing from the introduction, we now take a deep dive into the world of design patterns. Emphasis is on the ethos that "someone had already solved your problems" and how we can reuse the experience of others. Design patterns are our way of standing on the shoulders of giants!

Keeping with the Head First method, there are many lessons and even more ways to make the knowledge stick inside your brain. We may only cover the Strategy Pattern and general design concepts but you can rest assured you will remember all of it!

WHAT STOOD OUT? 

Exercise - Coding Ducks! (Strategy Pattern - p.18)

This simple exercise gives us our first opportunity to get our hands dirty :) It is a very straightforward problem and does an excellent job of teaching you the Strategy Pattern. I've pushed my work to Github: https://github.com/arkangelofkaos/head1st_designpatterns_duck

Exercise - Design Puzzle (p.25)

Make sure you have mastered the basics by trying your hand at organising the entity/class diagram in this exercise. Everyone remembers their UML arrows, right? ;)

Exercise - Crossword (p.33)

I know what you are thinking, we are learning and ain't nobody got time for messing around with a crossword! Rather surprisingly however, it is very valuable for seeing if you have been paying attention. Doing it exercises a different part of the brain and in the very least helped me notice I missed a page! Nevertheless it is incredibly frustrating if you're bad at crosswords!

IF YOU READ NOTHING ELSE... 

Shared Vocabularly (p.26)

Communicating is one of the greatest challenges facing developers and learning to succintly transfer thoughts from your head to another person's is invaluable. Part of this is using the right language, which in our case is the language of Design Patterns. Learning all of this enables us to communicate faster as well as code faster!

Object Oriented Principles (p.30)

At the very heart of everything we are trying to do, there must be a firm foundation of solid object orientated principles. Design patterns work in tandem with these tenants, you must learn the practice and understand the wisdom behind it. All of this is reassuringly woven into the theme of the book: from subtly highlighting how "Inheritance is evil" to explicit recommendations (program to an interface!)

CONCLUSION

If you have little to no experience with the Strategy pattern, this chapter is a fantastic way for you to master the art of encapsulating varying behaviour. Even for those with some experience on the topic, the exercises both amuse and tax you, helping to reinforce our knowledge :)

London Code Dojo 30

Monday was London Code Dojo 30 and this time we were back in Barbican with the lovely people at valtech. 

WHAT WENT DOWN

The kata for the evening was based upon Fibonacci numbers... but with a twist! The problem was centred around Fibonaccimal Numbers (link) which use the Fibonacci numbers as a base for representing numbers. So taking 1, 2,3,5 and 8 as a base, we can represent 9 as 10001 or 01101. As you can see, some numbers can have multiple representations and this added to the complexity of the problem. For the majority of the evening I paired with Rob and I found it really valuable getting his insight into the problem! The code we produced for the night can be found here: https://github.com/arkangelofkaos/CodeDojo30_Fibonacci

MY IMPRESSIONS

Nothing beats a good plan

More so then anything else, I came to appreciate the value of having a solid plan. Having a high level design which everyone agrees will solve the problem is incredibly important. Test driving code doesn't magically produce well designed algorithms.

LESSONS LEARNT

Decompose complexity into simple functions

Functional concepts supplement object oriented coding in a fantastically seamless way. When dealing with collections or calculations it is surprising how  higher order functions like map and reduce translate to how you naturally think about the problems.

For instance, to produce all the Fibonaccimal representations of a number, you can use a two step process:

1. Find all unique ways to express that number as a sum of different Fibonacci numbers 
• For example: 3 is [3] and [2+1]
2. Translate each way into the corresponding Fibonaccimal 
• [3] is 100 and [2+1] is 011

These steps are both mapping a number to a list of lists, then each list to a String. This is reflected in the code below:

return sumsCalculator.fibonacciSumsFor(number) // Step 1

                             .parallelStream()

                             .map(toStringCalculator::fibonacciSumToString); // Step 2

Suddenly I've decomposed an abstract problem into two concrete functions which I understand and can test drive!

Perhaps this is the crux behind solving all problems. Reduce the complexity until the solution is series of simple steps. Needless to say, making things simple is not simple... But there in lies the rub :)

Skimmer's Guide - Head First Design Patterns - Introduction

“Our goal was to make the book weigh less than the person reading it... Our focus is on the core patterns that matter...”

FOREWORD

I've recently started reading this book along with a few others in the LJC Book Club. As we read the book, I will be producing a series of Skimmer's Guide posts for each significant section of the book. Introduction to Design Patterns, the next section, is here. If you are interested, please join the discussion on our Google+ community. 

WHAT IS THE ABOUT? 

We start our reading of Head First Design Patterns with a gentle and enlightening introduction to the Head First world. Their approach is really intriguing and it is refreshing how much they are vested in helping the reader learn. Everything is to the point and we are immediately told who this book is and isn't for. Our goal in reading this book is stately clearly: learning that design patters are all about reusing experience and creating flexible code.

Despite the daunting size of this book (it is very heavy), the writing style and format makes it very easy and enjoyable to read. If you have experience with Head First books in the past, the introduction could be skipped although I highly recommend giving it a quick skim in the least.

WHAT STOOD OUT? 

Taster - Table of contents

Surprisingly enough, the novel table of contents work really well as a taster for things to come. Much like the rest of the book, the entertaining writing style brings the book to life :)

IF YOU READ NOTHING ELSE... 

Tricking your brain into retaining knowledge

One of the very first concepts covered in the book, this is the art of learning how to best learn. Absolute must read as the techniques covered are applicable to learning in all walks fo life.

CONCLUSION

Beginning to read this book has been a wonderful foray into the Head First world and has whetted my appetite for more. Looking forward to sinking my teeth into the world of design patterns in the next part :D