Tuesday 4 December 2012

Can Flex/Flash ever be considered a RESTful client?

One of the most relevant discussions in software development today is what will be the future of client technology? There are several platforms that as a business you might wish to deliver content to:

  • Web
  • Desktop
  • Mobile/Tablet
  • E-Mail report delivery
  • The next big thing....

You can potentially solve the problem by using HTML 5 with JavaScript to deliver to all platforms. However, this may lack the native feel you might want your application to have. This isn't really the point of the post, my main point is one considering the architecture of server side components. Given that it is likely that we will want to deliver content to multiple systems over time, my goal would be to make the client as thin as possible and have the majority of the business logic on the server side. There are exceptions to this and it does depend how rich you want to make your client side solution.

REST is rapidly becoming a natural choice for the situation where you want to deliver content to multiple clients. Flex is in some circles considered a legacy technology, and in others a lot of people have bet their business on it. The issue with Flex and the compatibility with REST is it has only two modes of operation: Success and Failure. It is possible to dig further into the failure to find the exact HTTP status code. The problem is on failure you can't access the body of the message, so if you're sending a reason for the failure back to the client there is no way to capture this in Flex. The problem is discussed briefly here. If you have to start wrapping everything in success to get at the underlying error, you defeat one of the purposes in having REST in the first place. Another forum post on Adobe informs us that this is a browser/plugin issue, as the Flash player cannot actually read the body of the response.

Given this constraint can Flex ever be considered a REST compatible client? Does it have a place in a world where the expectation is many thin clients for content delivery?

Friday 5 October 2012

Highlights From Java One 2012

Highlights From Java One 2012

When my talks were first accepted for Java One 2012, I never imagined I would feel like this at the end of the week. Currently, I'm a mixture of so burnt out I can barely walk yet so full of adrenaline I don't want to sleep. As a technologist this week has been the highlight of my career. This post will detail a few of the highlights of the week for me.

Keynote and Lunch with James Gosling

If someone had told me I'd be sat having lunch with James Gosling after participating in the Java One community keynote I would have branded them insane. However, that's exactly what happened today. With my friends in the London Java Community we had a panel session discussing a flag ship initiative we have been working on known as Adopt-a-JSR. The keynote was so far from corporate it was refreshing, it was all about community for the community. 


We saw key technical companies participate in the initial panel, us and then a crazy robot chasing down Oracle executive Georges Saab on stage. Then something special happened, James Gosling entered the stage. He was talking about his new development at Liquid Robotics. The best part about his appearance was James was back amongst a community of developers that have a high degree of respect for him and his work with Java. I found his presentation a highlight of innovation that is ongoing in the industry. After the keynote I headed over to Stephen Chin's Java Desktop lunch. We were sat at the same table as James and discussed details of the UI that he had built and demonstrated during the keynote and discussed some of the problems that data heavy systems would cause web based applications. What a great note to end Java One on.

Java FX

Java FX has been technically the most exciting product of Java One for me. It really starts to represent the revival of Java on the desktop. Although Swing has lived on over the last few years, how many people have really wanted to do this? Java FX simplifies a developer's ability to rapidly create flexible and maintainable user interfaces. Scene Builder also provides an abstraction away from code, so you can now have a design team that builds the basic CSS and component layout and the development team adds the functionality on top. 

At Java One myself and Ben Evans presented our toy project visualising garbage collection in Java FX.   One other highlight of the week was when I met Jim Weaver near the exhibition hall. He asked me if I'd like to come over to watch him give a demo. Within about 15 minutes I was stood at the front of the demo grounds giving a presentation on I'm new to Java FX and this is what I've built. Thanks Jim! That said it was great fun and all the Java FX team are really fun people to hang around with. 


My challenge for our next JUG meeting is to get a Java FX example running on the Raspberry Pi. Hopefully the Pi will arrive before then, if not I'm really looking forward to sharing everything else about Java FX back in the London Java Community.

Adopt a JSR

Adopt-a-JSR is a global initiative that was kicked off in London to help make the JCP (Java Community Process) relevant to Java developers and increase their participation. Adaptavist's Dan Hardiker had the following to say about the project:
Jax - What in the development world (project or otherwise) is really interesting you at the moment?
Dan - The Adopt-a-JSR programme ran by our own LJC, is one of the most important initiatives I've seen in a long time. It puts developers back in the driving seats helping to steer decisions on important areas of the language they live and breathe.
From attending Java One it was clear to see that although we have managed to reach senior members of the community there are still many members of the Java community that are not aware of the program or the aims. A second interesting point was that many of the developers attending our sessions are not members of Java User Groups. In order to address these points we are going to look at how we can be wider reaching to developers that are not members of JUGs. Recording sessions and broadcasting them to the wider community is going to be part of the strategy we look at to address this.

JSR-310 - New Date Time API

In the background to Java One we have been working hard with Oracle and Stephen Colebourne to address the final design decision of JSR-310. A lot of hard work is going into this JSR behind the scenes and at the end of some fairly heated debates we are looking to be on track for Java 8. If you're reading this and you still want to help, we are making a push for people to help us with the following:
In our continued efforts to evaluate and improve the Threeten Date/Time API for Java 8 we were discussing the effort of porting code from existing APIs. Does anyone have open source examples of code which they wrote against the existing java.util.Date or Calendar that you felt was overly complicated? I have some code myself, but I'd really like to hear from you if you have stuff that's open source and available for hacking on.
If you can help please feel free to drop me a tweet @JavaJimLondon.

Embedded

One final point that really excites me is robots! There has been a taster of Java running on embedded hardware, we've also seen some really cool demonstrations of Java FX running on embedded hardware and a Raspberry Pi. This is what I'm going to be playing with over the next few months, along with Java FX to try push the bounds of what is possible.

Thanks

A big thanks has to go out to Sharat for organising a fantastic Java One, this year really had a community feel about it. Thanks to all the speakers and the content committee, it's been awesome!

Sunday 30 September 2012

Highlights From Java One: Day 1

Java One - San Francisco



Today was my first day at Java One, and my first international conference. It has been an immensely fun day with loads going on.

8.15 AM - First talk of the conference - ours!

The first session we attended was our talk titled "The bluffers guide to terminology". The talk walked through terminology that complicates our industry, and made observations on how business, technical and academic domains are complicated enough without additional terminology. We walked through the different sections explaining terms and simplifying them so everyone could understand. For 8.15am the audience were very engaged, and it was clear that this was something everyone could relate to. We concluded that you have to be very careful when picking terms to represent your domain model objects in software development. You need to think about having a suitable abstraction that is clear as to what it represents in the domain, but doesn't complicate the domain further.

Winning an award

For the last 18 months, myself and colleagues from the London Java Community have been working on two key initiatives - Adopt a JSR and Adopt Open JDK. Today we were awarded with a Duke's Choice Award for the hard work we have put in inspire the community to be more involved in contributing to the future of Java. It was very exciting to see the LJC's name on the big screens at the Java One keynotes. Although winning an award was not something we set out to achieve, it is an honor. It has inspired me to carry on pushing on the initiatives we started and to use Java One as an opportunity to encourage global participation. It's also got me thinking about a future initiative, but for now that will remain top secret.


Technical Keynote

I'm still processing some of what was in the keynote, but my initial reaction is how excited I am about Java on the desktop. Having experienced the pain of Swing and context switching between .Net and Flex as alternatives, I can really see a future for Java on the desktop. That wasn't all however, we actually got to see Java FX running on a Raspberry Pi and other embedded devices. There's actually an embedded version of the Java One conference scheduler deployed around the hotels! This has really steered my interest for the conference as I'll be looking to attend a large number of Java FX talks this week at Java One. We also have our talk on visualising the Java GC model on Tuesday, which will go into building an application from the beginning in Java FX what we have learnt about the technology and how to use Java FX as a teaching and visualising technology from a slightly different perpective to grids and graphs.

Party

The day ended with collecting the Duke's Choice Award and a party in the street next to the hotel. Most of us have now returned to try and shake the jet lag before a packed day tomorrow.

Wednesday 12 September 2012

JavaFX Help: Too much animation at the same time!

I am currently working on building a Java memory model teaching tool in JavaFX, the project is available on GitHub. Whilst building the user interface I ran into a performance issue, which is easily worked around using JavaFX. This post gives the detail to the problem and how to easily resolve it.

In the memory model we have several memory sections made of memory blocks. In our application we represent each memory block with a StackPane. This has a Rectangle object at the bottom and a Text object on top of this to represent the current generation that block is in.

A block has three states it can be in:
  • Free - nothing has been allocated here yet.
  • Alive - the block holds some active memory.
  • Dead - the memory in the block has now died and is awaiting garbage collection.

We have potentially several threads that are running against the model allocating and killing memory. The challenge is animating each of the state transitions on the UI. A picture shows the animation in action:


The code segment that we used for the transition is as follows (there might be a better way to do this):

     FadeTransition fadeOldBlockOut = new FadeTransition(Duration.millis(10), view);  
     fadeOldBlockOut.setFromValue(1.0);  
     fadeOldBlockOut.setToValue(0.0);  
     fadeOldBlockOut.setCycleCount(1);  
     fadeOldBlockOut.setAutoReverse(false);  
     fadeOldBlockOut.play();
  
     FadeTransition fadeNewBlockIn = new FadeTransition(Duration.millis(1500), view);  
     fadeNewBlockIn.setFromValue(0.0);  
     fadeNewBlockIn.setToValue(1.0);  
     fadeNewBlockIn.setCycleCount(1);  
     fadeNewBlockIn.setAutoReverse(false);  
     fadeNewBlockIn.setDelay(Duration.millis(1));  
     fadeNewBlockIn.play();   

This code was added to the view object. However, once you get multiple of these firing the application will quickly start to hurt itself to keep up with the transitions required. Having read Java FX Pro 2 I quickly realised that I had taken the wrong approach. Large amounts of updating graphics, especially timeline style animation, does not belong on the main application thread. Thankfully JavaFX has an easy paradigm to resolve the issue.

I created an Object that implements Runnable, which would take the memory block I want to animate in the constructor and perform the logic above:

 class CustomMemoryBlockViewTransition implements Runnable {  
   private final MemoryBlockView view;  
   public CustomMemoryBlockViewTransition(MemoryBlockView view_) {  
     view = view_;  
   }  
   @Override  
   public void run() {  
     //...  
   }  
 }  

Once you have your Runnable defined (you can also do this as an anonymous inner class) you can simply call the Platform to run the animation at a later point. The Platform keeps a queue of activities submitted and will execute these in order.

 Platform.runLater(new CustomMemoryBlockViewTransition(this));  


Open Crete: Days 2 & 3

Having broken out in to the lobby on day 3 I thought I'd summarise the last few days of the conference and some of the ideas I have been developing based on the conference so far. First an image from down at the sea front, a great spot for thinking - and a surprisingly decent wifi connection :-).


Day 2: Discussion of Mobile Platforms 

Day 2 began with a talk run by Richard Pollock on Objective-C vs Java runtime. The discussion took one of a iOS vs Android platform. One of the main points discussed was the background tasks and the implications of those on both operating systems. I found out about some fairly compelling points from the Android camp around running services that then multiple applications can subscribe to, along with writing code to expect to be terminated at any time. iOS has limited support for background tasks, and you have around 7 options that are event based for a limited range of operations that can potentially run in the background. We got into some specifics surrounding grand central dispatch and how this is a lower level threading than the model presented in Android. All round it was a talk which lead to a great consideration about our own business that we run at StackThread Software

Richard and I took a breakout for the next two sessions to discuss our own business model. This was driven based on the sales of our recent iPhone application Diabetes+. We put the application on sale 2 weeks ago at the price of $3. In 2 weeks we sold 15 copies (with £75 of Google advertising) - a really disappointing amount given the effort that has gone into the application. We made the application free as an experiment for a few days, on the first day we sold 270 copies! Within days we now have 550 copies that users have downloaded and are using for free. This is the equivalent of the units we would usually ship over 2 months of our other paid applications. So what did we get from making this free, nothing except more users to support - one could argue that actually word of mouth might be a good thing. What were really hoping for would be more reviews - which also did not happen. In our breakout we discussed targeting the Android platform, we decided it would be a fun technical challenge - but again would be governed by the apparent race to zero price for applications. We concurred that the best way to distribute applications at the moment seems to be to make it free and have in application purchases. In the end we have decided to pursue a new application that we have had on the back burner which is a Spring MVC project hosted on Amazon Web Services with a JavaScript and HTML 5 front end. Although we will support our current applications in the App Store, there isn't any motivation for us to build further applications unless on commission to do so. The rest of the day was spent unit testing and building out on the prototype we had shelved.

Day 3: Enterprise Git

A situation that is close to my heart within enterprise development is source control. In the last 5 years I have been responsible for migrating systems from CVS to Perforce and rescuing diverged branches of over 6 months (taking a few weeks to resolve). 

The conversation opened with the following considerations, which we would discuss even if not answering completely:
  • Does Git work in an environment with 80 developers, and a few million lines of code?
  • We have no collectively clue about Git in large enterprises.
  • How does having a workflow help with development using Git.
  • Does GitHub impose a desirable work flow?
Marc gave us an overview for those less familiar with git to note how the local repository or "my repository" works for developers. Pointing out the familiar concepts of local check ins and branching. The intro also covered the single point of truth and how this works with GitHub, how SHA takes into account the file meta data as well as the content.

It quickly became apparent that few of us use this in our enterprise jobs, with the exception of Kirk! 

What was new for most of us was rebasing rather than merging, something that I heard of but wasn't sure what the difference was between this and a merge. If the original branch hasn't moved on a merge is effectively the same thing. However, when the main branch has moved on it was almost universally agreed this is a better pattern. 

Git enables better collaboration, especially in teams that are distributed. It also works well for teams that focus on pairing and working together.

We decided that Git is suitable for enterprise for the following reasons:

  • Branching is free and easy. Developing features and merging over large teams is easier than in competitive tools. For teams that run the feature branch model this would significantly improve their development experience.
  • An in house git hub would also help to improve cataloging of systems and applications and encourage employing good standards for sharing code. Although this isn't a source control problem, it might be a step in the right direction for code reuse.
  • Integrate with Jenkins and Gerrit, define a workflow that is suitable for the team and enterprise.
We then put Marc on the spot and pair programmed an example of rebase on the command line. 

Day 3: To OO or not to OO

Interesting debate on whether OO is the right abstraction for modelling today's problems. Conversation went to both extremes of what makes OO good and poor. Discussion was along the lines of where does the business logic best fit and is OO too theoretical to be applicable to modern day business problems. Where does functional programming fit into this?

My personal opinion on the outcome of this was that you need to have a balance on your team between practically biased and theoretically biased individuals. There is no correct answer to what is the best approach to take and it should be aligned with what best fits the businesses current problem. A lot went on in the conversation and I'm sure I'm still developing more ideas on this topic over the next few days.

With most of the delegates heading out for excursions this afternoon, I am looking forward to spending the rest of the day working on our JavaFX talk for tomorrow and the DateTime talk.










Monday 10 September 2012

Book Review: Pro JavaFX 2


I'm a server side Java developer with 10 years experience, and 2 years experience in Adobe Flex. With Flex taking a recent slating in the press, I decided it was time to broaden my UI experiences to JavaFX and HTML 5 with Java Script. Because I know Java well, and having previous experiences with Swing, I chose JavaFX and this was the book I chose to help me learn the basics.

The first thing to note about this book is it's written by the key people behind the JavaFX technology. The advantage of this is the reader is immediately learning how the platform was designed and intended for use.

The book is split into 10 chapters, each with comprehensive code listings on how the examples and components are built. The chapters are outlined below, along with how I found them useful in the work we have been doing building a basic Java Memory Visualizer in JavaFX.

Getting a Jump Start in JavaFX

The book begins with a brief history of JavaFX, and discusses the original version and the introduction of 2.0. The book goes immediately into an example, building an application using a Java Class extending Application. There's also enough to get started in this chapter with getting Netbeans set up and ready to go to build your applications. There's a lot of content here, so don't let this put you off. There's some important code segments that you will probably need to flick back to along the way. My only observation at this point would be remember that there is still the option of using FXML to simplify a lot of the code that is in this chapter - so this chapter should be viewed as a primer.

Creating a User Interface in JavaFX

We're back out of the deep end now and will be walked through the scene and layouts of creating a typical user interface. This chapter is critical to when you come to build your own UIs. If you want to grab a chapter to help you get started quickly this would be the one. One minor criticism would be this would be a good chapter one, but I can appreciate why leading with an example is good. It really depends on your learning style if you want to read this chapter first. After some theory there is a whole host of examples for you to try and figure out, all with both screenshots and code samples. This is a real codex of information, for me I found reading the first part and trying the second part with my own examples worked best.

Properties and Bindings

Binding is a simple concept, but there are some subtleties that need to be appreciated when building JavaFX applications. The first part of the chapter is split into titles of Understanding X, which makes it easy to refer back to later. Once again, everything is backed up with an appropriate example that demonstrates the power of bindings. This chapter is similar to the previous, the first part of the chapter is easy to read for theory but the latter is example heavy. I'd use the latter part of the chapter as a reference to come back to once you start writing your own code.

Building Dynamic UI Layouts in JavaFX

We used the concepts that are in the Reversi example for the foundations of our Java Memory Visualizer to manipulate memory cells that are on the screen. This example is again in the format of extending Application, but building out components on there. We built our application using FXML based on the information from this chapter. There is enough in this chapter to build your own board game, or if you are building any binding state UI I'd recommend reading this chapter.

Using the JavaFX UI Controls

I personally haven't read this chapter in great depth as I view it as a reference chapter. It looks like this is the codex for building your own controls.

Collections and Concurrency

In chapter 6 we're really going back to basics, so in my opinion this is not a chapter you can shelve for later. For the collections part, if you are familiar with Flex, ObservableList reminded me of ArrayCollection. The concurrency section introduces the threading model that is used in JavaFX, and that it is single threaded like most other UI frameworks. The JavaFX tasks are then explained for removing logic from the main application thread to avoid bloating your application re-render. Personally when we approached this, due to the nature of the simulation, we used plain old java.util.concurrent.

Creating Charts in JavaFX

Great overview into building charts in JavaFX and shows off the power of what is capable in the API. Examples and screenshots are available to get you started with what you are trying to build.

Using the Media Classes

Because of the type of work I do it's likely I'll never get to do any of the fun stuff in this chapter. I've saved this one for a rainy day, although on a quick parse it does look like a chapter I will genuinely come back to.

Accessing Web Services

An awesome chapter with practical examples of how you would integrate your JavaFX client with real world technologies. This sample walks you through creating a REST API call to twitter, using JAXB to create an appropriate response and display the information. If you are looking at using this for EE work this would be a good chapter to read. 

JavaFX Languages Markup

In this chapter we see some other languages using JavaFX (Scala and Groovy). The finally we get to the section on FXML. The sample is fairly simple and somewhat limited, it would have been good to have seen more of this earlier. 

Summary

This is an excellent book to have if you are trying to do anything with JavaFX. Although the online documentation is getting better, this book provides an awesome introduction to most components, tricks and tips that you would need to get started in this space. My only criticism of the book is a lack of FXML examples and that it only really appears at the end of the book. This shouldn't take away however from some of the excellent explanations and examples in this unfamiliar space. It's also worth noting that with a bit of playing around it's very simple to convert the samples over to using FXML. 

5/5 - I bought this with my own money and don't want it back :-). 

Open Crete: Day 1

A picture says a 1000 words!


Arriving on Saturday was definitely a great idea, as most of Sunday was spent sleeping or taking in these fantastic surroundings. The conference kicked off last night with a informal get to know each other at a local restaurant called Irene's Taverna.

Open Crete is run as an unconference, that is the participants very much direct the success and the output of the conference in the end. No sessions are planned up front, and the first part of this morning was grabbing some sticky notes and proposing sessions. I have proposed 3 sessions (which are pretty much inline with my talks coming up at JavaOne):

  • Why is the community important to Java? Adopt-a-JSR, OpenJDK and JUGs.
  • JavaFX Memory Visualisation.
  • An overview of the new DateTime API (JSR-310) in Java 8. 

We kicked off with two sessions this morning, which covered the future of Java. The general feeling was that modules is going to be a massive section missing from the next release of Java. It was acknowledged however that most of us have not seen the proposed profiles solution. After modules we discussed the impact of Lambdas. Although people are in general excited about Lambdas and what they can do, there is a concern that they will be perhaps used for the sake of using them and in some cases ignored because they are not understood. After discussing some consumer trends, we chatted about the future of Java given that there is currently no substantial mobile presence. The big feel is that laptops will soon become a "developer only" style tool - because regular consumers can get away with carrying an iPad. What does this mean for Java's future? Who is really behind driving Java forwards? 

The session definitely left food for thought as we break for afternoon of activities, and I am looking forward to considering the above in more detail as the week unfolds.

JavaFX Cleanly Closing an FXML Based Application

Whilst developing an FXML based JavaFX application for JavaOne I had to overcome the problem of cleaning up Java background threads running in the controller on a ExecutorService.

If you had chosen to use the builder patterns rather than FXML this is a fairly trivial task, as you are likely to have direct access to the controller from your main class which extends Application. However, when you use FXML you will more than likely be declaring your controller as follows:
 <VBox xmlns:fx="http://javafx.com/fxml" fx:controller="com.jclarity.anim.memory.MemoryController"> ...  

When you launch the FXML you are likely to do something along the lines of:

 @Override  
 public void start(Stage stage) throws Exception {  
    Parent root = FXMLLoader.load(getClass().getResource("MemoryMainView.fxml"));  
    Scene scene = new Scene(root, 600, 500);  
    scene.getStylesheets().add(getClass().getResource("Memory.css").toExternalForm());  
    stage.setScene(scene);  
    stage.setTitle("JavaFX Memory Visualizer");  
    stage.show();  
 }  

At this stage you launch the FXML and never grabbed hold of your reference to the controller. This now means when you override stop() you can't delegate this to your controller. The solution I found to this was to separate out the code above to ensure that you keep access to the FXML loader. If you have access to the FXMLoader you easily do the following in the stop method:
   @Override  
   public void stop() {  
     ((MemoryController) fxmlLoader.getController()).haltSimulation();  
   }  

I separated the code as follows:
 private FXMLLoader fxmlLoader;  

   @Override  
   public void start(Stage stage) throws Exception {  
     URL location = getClass().getResource("MemoryMainView.fxml");  
     fxmlLoader = new FXMLLoader();  
     fxmlLoader.setLocation(location);  
     fxmlLoader.setBuilderFactory(new JavaFXBuilderFactory());  
     Parent root = (Parent) fxmlLoader.load(location.openStream()); 
     ...
    } 

Friday 7 September 2012

Book Review: The Well Grounded Java Developer


I have been a Java developer for over 10 years, with 5 years of this in the financial software industry. In my opinion this book is one of the best Java books on the market currently. There is something in this book for everyone, if you are new graduate it helps to consolidate your skills in Java. If you're an old hat, this book has a refreshing approach to more complex topics, such as Understanding Performance Tuning which Dr Heinz Kabutz brands as: "The first book since Jack Shirazi’s Java Performance Tuning that has captured the essence of how to make your system faster." in the foreword. I think the two chapters understanding performance tuning and modern concurrency are a must read for all developers, and are delivered superbly for all levels.

The book is split into 4 parts, starting with an introduction to Java 7. Anyone who has been asleep for the last year should definitely be reading this section. It presents all the major changes with examples, and is easy to follow and read. 

Vital techniques then takes a deep dive into dependency injection - critical to writing testable and maintainable code. The section shows by example an introduction to the critical topic. It also introduces JSR-330 annotations, which as an early adopter of Spring I hadn't looked at in detail myself. The spin then goes into concurrency, and this chapter I finished! Having had Modern Concurrency in Practice on the bookshelf, 4 attempts at reading it and bottoming out around page 50 - I have to say this was refreshing. Modern Concurrency is a great book, but this chapter synthesises the complexity in simple and easy to understand diagrams and explanations. Class files and byte code is another section that many Java developers lack a detailed understanding of - this book adequately covers this topic. It also introduce the opcode detail of invoke dynamic and how that will be useful for developers. The final chapter in this section dives in to understanding performance tuning, which takes a very pragmatic and evidence based approach to finding out why your application might be running "badly". I like this section a lot because it's written from experience, some of the same problems I have run into in my career could have been avoided by reading this chapter first. It also goes into detail about garbage collection basics and structures, a topic which is usually a guaranteed interview question. Also if you thought that Objects were always allocated on the heap, check out page 181 for something you might have missed :-).

At this point your brain might be fried, if so another read of it will make everything clearer. There's hints and tips in the sections for stuff you can skip and that's really useful for the first parse. The next section is slightly easier going and introduces polygot programming on the JVM. If you haven't come across many functional languages this starts with introducing the key concepts and how the compare with traditional Java approaches. We then get the detail of how this all works and we're ready to go with trying out our first functional languages. We get a overview introduction to Groovy, Scala and Clojure. I didn't read these chapters in too much detail purely because of the work I'm doing at the moment. However, I did like the presentation format of is this right for my project, some of the higher level concepts (with solid examples) as well as interoperability with Java. To me this is going to be my holiday reading to see what is going on outside the core space, providing a primer that will be enough for me to go off and do my own research and experimentation.

The final part is about craft, craft is perhaps the one thing that is missing from day to day developers I come across. Craft makes you stand out, it makes you professional and caring about the product that you will deliver. This is one skill you can't get a qualification for, it grows from experience, learning from other and striving to deliver the best you can. The section introduces some key points and approaches you can apply starting today. The chapter on test driven development is another hidden gem in this book, having worked at establishment where testing is finding the problem in production this introduction brought about a new approach to the way me (and my team) now go about writing code. This approach gives you the building blocks of learning these valuable techniques and gives you some hints and tips into different tools you can use to support you with this. Writing good code is all well and good, but how do you ensure it works well with other people's changes and passes coding standards? The continuous integration chapter details how this works using Jenkins as the example. Of course no section of building would be complete without a mention of Maven, I'll let you decide if that's a good or a bad thing :-)!

The book wraps up with web development and looks at why Java is not necessarily the best tool in the box for this, followed by how to stay well grounded now you have been armed with a book!

I have bought and read many technical books in the past and there are only two technical books I've ever read cover to cover, Spring in Action was one of them this is the other. The book focuses on Java 7, which although out for a year is slowly creeping into production systems. The book serves as a good primer to the new changes. 

Note:
I wouldn't consider this a very beginner book, if you are looking to learn object oriented programming from the beginning I'd recommend reading another book first. It's not criticism of the book, but if that's what you're looking for I'd consider this book as the second book you buy.

Thursday 21 June 2012

FrAgile Development

On June 12th I gave a lightning talk on FrAgile Development at Skills Matter in London, you can watch the video here. It was by far the most controversial talk I have given to date. Before I instantly get flamed by Agile fans the talk was not to criticise the methodology, but was a play on words and/or what can start to happen if things go wrong. The best part about the talk was the range of reactions that the audience took from the talk, which I will summarise at the end.

For the purpose of this post the FrAgile Developer writes in red, the voice of some reason will be in blue. Imagine them as an angel and a devil sat on the developers shoulder.

The slides went through some bad practices that I've seen (and participated in whilst learning and not knowing any better). During research it seems others have also thought of Fragile development as a concept and c2.com was a great reference point.

Ctrl CV Design Pattern


Refactoring is expensive, and copy paste is the quickest possible way to reuse code without impacting something thats working fine. You don't need to retest what was done before, and if there's a test why not copy and rename that too. The junior developer might be tempted or even guided to do this, and I've seen things like this in front office and UI development. The point of this was to suggest that the laziest solution is generally not good for the product or maintenance in the long term.

Extend Everything


At university you learn about these object things and extending them. Sounds good, so let's extend everything that means we will be able to use that useful method in this other class. This often leads to Spaghetti like code, where everything becomes tightly coupled together. Changing one part of the system can have an adverse impact on a completely different part. Thinking about composition as well as inheritance is an important lesson to learn early, ensuring that a class only actions the intended behaviour and is kept as orthogonal as possible.

Ignorance Driven Development


We don't have a product owner who is willing to be accountable for guiding the product, and they're never going to know what they want until they see it. Ok let's build something that we think they'll want and see how we go. This is often a sign of an organisational issue and though this can be a successful approach you can end up spending a lot of iterations on prototyping complex systems to find that functionality at the heart of it is really wrong. Tying down the basic requirement, even if just the initial scope should be the goal otherwise you risk a never ending sprint or product iteration.

Rabid Prototyping


Dude we've got this really complicated problem where we need to write a highly complicated algorithm to solve it. I've been working for the last 8 hours and I've come up with this sophisticated algorithm to return a single timestamp. As developers we can often be tempted to dive down a single path rapidly throwing stuff together and over complicating problems. Often the key is taking a step back or considering the options in a pair. In this case where a huge algorithm is written, it could have been simpler and made more sense to refactor to a different data structure, for example.

The Burnout Chart


How many hours have your worked this week? I'm up to 120 hours!
At the end of the day that's not a sustainable.
My day never ends, so it doesn't count!
This is a cultural issue that can be costly across a company. Things like this effectively bully developers into staying late and doing working longer or harder than they are comfortable with. In this kind of environment it's a race to who burns out or breaks down first.

Heart Break Pairing


This relates to either when a pair breaks up, or where someone is a lone wolf developer. In the break up case it makes more sense for the pair to take some cooling off time rather than arguing across the shop floor. In the imaginary friend case it's really difficult, as no one is actually available to pair or code review.

Potential Solution


After the above, without good guidance, there are many ruts developers both junior and seasoned can fall into. How can we avoid it? If you're based in London you can look to improve your skills by considering your career as a craft where you take pride in the solutions you build and deliver. The LSCC (London Software Craftsmanship Community) and the LJC (London Java Community) provide excellent platforms for this.

If you're not local to a large community group there are some excellent books that can get you started, for example The Well Grounded Java Developer is an excellent starting point. Work with your team and more experienced developers to learn from them and improve. This is by far one of the best ways to learn and improve.

The feedback from the talk was really positive and a range of people took different things from it. Some thought that methodologies are too ideal, and not indicative of the real world. I fear this is probably true for many developers, and bad habits come as a given practice. Others had seen problems like this themselves in different teams over the years, and could look back on these experiences and have a good chuckle. Others were interested in how they could improve and went away looking for books and resources to do so.

Sunday 10 June 2012

Our 3 Planned Talks for Java One

Having written about my career history and how I came to be speaking at Java One, I thought it would be useful to briefly outline what the three talks are and what we hope people will get from attending them.

Community Driving the Future of Java: Adopt a JSR - BOF4540


This BOF is an open discussion on the Adopt a JSR program, which aims at encouraging Java Community members to get involved with Java Specification Requests. We are going to highlight our journey through from starting with a lightning talk right through to working with Stephen Colebourne to help validate the design of JSR-310. We will do a small introduction on what we have worked on to set the scene and then the main focus of this talk is to discuss what people think about the Adopt a JSR and if there is more we could potentially be doing to help move this initiative forwards. If you're planning on coming along to the event, I'd recommend that you take a look at the following first to get the most out of it:
The event can be attended by Java developers of any level, and it would be specifically useful for members of other JUGs working on Adopt a JSR to come along to the BOF. We are hoping to have other senior LJC members in the audience with a wealth of experience when it comes to Adopt a JSR. For specific JSR-310 discussion the follow on session below will be useful too.

JSR 310: What’s Taking So Long? - BOF5127


Following on from our BOF on Adopt a JSR this BOF is on the work we have contributed to the design and testing of JSR-310 and the ThreeTen project. We want to use this session to explain and work with delegates on the complexity of developing an API that is capable of ISO-standard calendar systems, whilst making it extendable to support more complex calendar systems. It will be a great opportunity for us to dig under the covers of the new API and explain some of the decisions made. We will be joined by Roger Riggs of Oracle and we are hoping Stephen Colebourne will be along to join in the discussion. This talk is suitable for Java developers of any level who want to know more about how JSR-310 will change the way we work with dates in Java.

To get the most out of this session the following would be good pre reading materials:

London Java Community: How to change the world - CONF5130


The final talk we have had accepted is based on our experiences of working as a group of developers contributing to the Java Community Process. The London Java community has more than 2000 developers and is rapidly growing, all with their own (frequently differing) opinions and ideas. Our aim has been to provide a single voice for many developers and has had many challenges along the way, but also some successes. This conference session will give you direct access to a panel of developers that have been working for the London Java Community in this capacity:
Come along and find out what we have been working on, what problems we have faced and how we have worked to gain success. Hopefully you will get the answer to "Is it worth it?".


Saturday 9 June 2012

Journey to Speaking at Java One 2012

Late Thursday night I received some fantastic news that Oracle had accepted 3 of my 4 submitted talks for JavaOne 2012. For me this is a milestone in my career and has been thanks to many people in the community over the past 5 years. This blog post is going to be a short tour through the last 5 years of my career, thanking certain key people along the way who have helped me to this landmark achievement.

In 2007 I graduated the University of Warwick and moved to London with a job ready to start in September. The toolbox was armed with a very broad range of practical and theoretical skills from my MEng Computer Science degree. At this stage of a graduate's career they are eager to dive right in and write as much production code as possible, I was no different. I was lucky enough to have a manager who was able to point out the craft of Software Development and how design and consideration of building products would have a significant impact in my long term career. These one hour meetings in the pub were the most valuable meetings I could have had. 

I wanted to learn more and looked for online resources. The first thing I picked up that September was a Podcast called The Java Posse - still going today and definitely worth a listen for developers of all levels. JUGs (Java User Groups) were mentioned, and I took a look to see if there was one in London and at this point was shocked that there wasn't an official or unofficial JUG I could find. As I was about to move to New York I didn't follow up on this further, continued to listen to my podcasts and built on learning to build scalable and maintainable systems within investment banks for the next 2 years.

Sometime towards the middle of 2009 I met a contractor who was active in the Java Community, he mentioned the London Java Community and another Java Community based in London. Little did I know that when I looked in September 2007, Barry Cranford a few months later had formed the London Java Community. My initial response to a recruiter running a community was apprehensive, then in late 2009 I attended my first event The Unconference and this changed everything.

I met Barry and realised this wasn't the same breed as the recruiters who phoned me up on a daily basis. It was a normal guy, a little nervous about speaking to many developers (not that you would know this now) and had worked tirelessly with friends in the community to arrange the conference. The diversity in the community right from the beginning was top of the game, everyone was welcome irrespective of background. I felt right at home, people talking about Java on a Saturday - this was amazing. Barry is to thank for starting one of the most active and successful JUGs. 

I suddenly recognised a familiar face, after a few gulps of coffee I realised it was a someone who had given me one of the most technical grillings I have ever received to date! When I say grilling I mean pushed me in an interview to bring the best out of my technical ability, and thankfully it was a successful interview. Ben Evans is one of the Java kings in London and has pushed me both technically and to contribute to the community ever since, informally a great mentor and a fantastic friend. I also met at the same time Martijn Verburg who has one of the best insights into best practices and strong development skills across the community. My work with Martijn was further in the future with the LJC JCP, and he too has been a great mentor and contributor to us making Java One.

My JUG membership for the next year was somewhat of a social one, working to greet and connect people in the community and helping to facilitate the running of the events with the LJC associates. Whilst this was fun I was looking for something that would get me more involved in the community and ultimately give me a platform to start speaking to larger audiences about Java technology and the surrounding ecosystem.

In July 2011 I started working with LJC JCP, and specifically helping to design the framework for adopting a JSR in the community. The targeted JSR was JSR-310, as Stephen Colebourne was based in the UK it made it easier for us to establish relationships. Initially as with all JSRs the main challenge is explaining the concept to other developers to maximize the input from community members. Later in 2011 I met Richard Warburton who has helped add some real power behind our Adopt a JSR efforts. The work we have done with the community and the efforts here will make up the main body of our talks for Java One. Although I had publicly spoken before, these were the first talks on Java with the community and these were well received. Following on from this we have also worked on helping with the TCK and helping validate the redesign of the API.

I'd like to thank all the people mentioned in this blog post and those that are not mentioned that have helped out along the way too, over 5 years and a short post I'm sure I have missed some people. For people who are looking to get involved in conference speaking or getting more involved and improving their Java skills I'd highly recommend working with people in your local Java User Group, as many of us in the London Java Community can testify anything is possible. Looking back on what I was thinking in 2007 I never thought the first time I was at Java One would be when I was speaking there!