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.