Google driven design - support for client side includes

During a recent project inception I was surprised to see just how many use journeys were expected to start from a Google search - probably more than half.

With that in mind, I have found myself starting to question any approach that involves a super fast initial page load followed up by Javascript calls to populate the rest of the page - "what will Google see?"

According to this old blog post Google's crawler will happily recognise an AJAX request and call on it to pull through the content, and presumably index it as part of the page.

I love it when a plan comes together (even when it's not my plan).

Evaluating Play Framework 2.3 with Java 8

RTFM
Like many software libraries and frameworks, I have found that the best way to get the most out of Play is by putting some time towards reading the documentation.

For example, we wanted to evaluate how test friendly Play is, so we tried to figure out a mechanism for dependency injection of services into our controllers.

The sample code wasn't very helpful for this, as the controllers were implemented with static methods for each action, but thankfully the online documentation offered a section on dependency injection which showed how we can control the obtaining of a controller instance.

Scala bias
One aspect that was less than ideal is the slight Scala bias.  For example, the documentation that I found for dependency injection was titled ScalaDependencyInjection and only had sample code implemented in Scala.  Fortunately a lot of our team's existing codebase is already in Scala, so this hasn't proven to be a barrier.

Java 8
The main Java 8 specific feature that I have made use of so far is for calls to map from a WSResponse to something suitable for the controller to include in an HTTP response.

Thankfully the Play documentation includes sample code for Java pre and post version 8, so we can appreciate what the verbose version would have looked like while still in the process of getting our heads into lambdas and functional composition.

A Java Refresher - some pain points and annoyances

With the recent release of Java 8 my new project team has chosen to take a look into Java as a viable alternative to the existing default language choice of Scala.

(In the interests of full disclosure we did originally opt for Scala, with a few caveats and a recommended reading list for the features to avoid or use sparingly).

I had already started reading Functional Programming in Java 8, but I think now is a good opportunity to look back over the features of the language and consider where there are particular strengths and weaknesses.

This post will only focus on Core Java - not Java Enterprise Edition, Swing or any frameworks.

• Labeled break / continue
• These expressions are the closest you can get to having a goto in Java
• Checked Exceptions
• I haven't quite convinced myself about this one yet, but I have a particular dislike for having to wrap a call with a try / catch block where the catch block only contains a comment like // can never happen
• All too often exceptions are used to control flow for scenarios that aren't truly exceptional
• Reflection
• Generally prevents the compiler from having static access to the relationships between classes.
• On the flip side, static analysis tools can be expected to make use of reflection.
• Local classes
• Did you know that you can declare a class inside any block?  Not just anonymous classes, but even fully fledged named classes.
• instanceof
• Whenever I find myself introducing an instanceof check in my code I feel like there must be a better way.
• Restrictions on Generics
• I think this is well covered by the Java tutorial:  http://docs.oracle.com/javase/tutorial/java/generics/restrictions.html

Runtime gotchas

• Memory allocation
• Out of memory exception - particularly PermGen space, and particularly when reflection or dynamic class loading is involved - before Java 8.
• Garbage collection
• Stop the world - collecting large accumulated garbage while blocking other progress.

Sorry for the lack of substance, but sometimes this blog exists as a checklist of reminders for myself.  I haven't Googled a problem and reached my own blog yet, but I can imagine it will only be a matter of time.

One team's success is another team's "challenge"

I've deleted most of the body of this post, as it was too detailed and might have come across as a rant.

Here is the essence of what I want to express, feel free to wave your hands around in the gesticulation style of your choosing...

Team A shouldn't talk to Team B about their problems handling an accumulated issue with Team C's kit.  (I'll categorise my position as being in Team D in this scenario).

The keywords from the longer version include: evolving technologies, neglected maintenance, versioning of software, Chinese whispers, rumours, this is why we can't have nice things.

Specialisation and interdependence leads to a higher standard of living

The title of this particular post doesn't tie as closely to the content as you might normally expect.  So, no SEO bonus points for me today - tsk tsk, shame on me!

The background to the title is a little memory game which my fourth form Economics teacher used to try to trick our class into committing to memory something which each student expressed as a takeaway from the year.  I tried to come up with a longwinded statement that my classmates might forget when their turn came to repeat back what each previous person had said.  The class was a bit too lenient, so by the time someone missed out half of my statement nobody cared to flag it up as a mistake.

Anyway, with that 23 year old useless information out of the way, let's get on with the interesting stuff.

Working in a large company with separate IT teams becoming dependent on each others' services, there are varying opinions about the who, when and how of implementing new features.

The current proposed approach for one of the services that I am associated with involves allowing each team to have access to the service's source code and apply the changes that are needed for that team.

On the surface this seems to make some sense, as the team making the code changes will have the most knowledge about the needs of the current project.

With the benefit of hindsight, some of the senior developers are coming to the realisation that a dedicated product team with specialist knowledge of the complexity behind the service might be better suited to develop enhancements.  (Actually, we thought this from the start, but anyway....)

In my opinion, the technologies and esoteric configuration details involved for this particular service mean that there is too much overhead involved for it to be efficient for each project team to develop for their own required enhancements.  The follow on overhead is that there has to be some team responsible for maintaining any and all features - so they have to learn all about that anyway.

Without going into too much detail, here is a high level list of the context switches required for my project's team members to work on enhancements to the service that we want to consume from:

• programming language
• specialised JavaScript libraries
• build system
• artifact repository
• continuous integration system
• virtualisation configuration

When I have some free time, I might take a look into what others have been posting for their no projects philosophy, as I expect that may have some crossover.