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.

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.