Tuesday, 19 July 2016

Cross Platform Swift - Language of the future, today?

I'm very keen on the idea of cross platform Swift just now.

Swift is a great language which manages to be easy to use while being powerful, two traits that most languages just can't claim.   As such, I am already seeing a surge in the interest of this language, and once the Foundation settles down and writing Swift for other platforms (especially Android) becomes easier, I can fully imagine that it will become an effective cross platform tool that will basically make the likes of Xamarin redundant.

In the mean time there is a way to go, but I haven't seen such enthusiasm for this since Java.

Check out the following links:

Altconf: Cross Platform Swift - https://realm.io/news/altconf-boris-bugling-cross-platform-swift/

Swift in the Google Play Store - https://medium.com/@ephemer/why-we-put-an-app-in-the-android-play-store-using-swift-96ac87c88dfc#.9tgt30q7h

There's already a couple of web server implementations.  I have already had great success with PerfectServer.org and the above Altconf video talks about Frank.  High performance micro-services written in Swift?  Yes please.

 The language has a great future, but it makes me wonder about the value of another really interesting project: J2Objc, a transpiler that takes Java code and spits out Objective-C.  Google already used this to achieve 60% re-use across iOS, Android and GWT.  But are its days numbered?

That's enough gush for now, I'll keep on eye on the progress of Swift as a cross-platform language and report back as news comes in or when I get around to doing experiments.

Friday, 9 October 2015

Popup Micro Communities, aka The death of Facebook by a thousand cuts.

I’m involved in seven at the moment.  Four of them are entirely work related, one of them is related to a political group I’m involved with and two of them are just for fun.  But what the hell am I talking about?

Over the last 15 years the way people do software development has evolved.  Moving away from archaic waterfall based software development methodologies, Agile extolls the importance of a face to face chat over a heavy dependence on documentation.  Of course, the internet also means that your software development team may distributed anywhere in the world, so how do you communicate and collaborate effectively with remote colleagues?

One of the earliest examples of online collaboration was through wiki software.  A shared, open space on the internet where users (with the right permissions) are allowed to freely edit content on web pages without requiring any HTML skills or having to upload files to a server.  These days wiki is highly refined with the likes of Atlassian’s Confluence allowing extremely fine-grained control over content access and real-time notifications when content is updated.  However, managing a wiki can soon become a full time job, its adhoc nature quite often resulting in a chaotic mess of information and is, of course, still no replacement for a face to face chat.

But people have been talking on the internet since its beginning with one of the most popular chat mediums in the early days being IRC, Internet Relay Chat.  IRC is built on the concept of chat channels, which these days people might prefer to think of as “chat rooms".  When you join an IRC server you would join one or more channels, most chat servers allowing users to freely create their own channels.  Once you had created your own channel you could control who had access to it, change it’s topic and various other settings.  Its protocol is surprisingly simple, based on the exchange of plain text, much like mail exchange protocols like POP3 or IMAP, that anyone with the patience and knowledge could engage with using a simple telnet connection.  However, the common user would normally connect to IRC with one of a myriad of applications, the most popular probably being mIRC.

Some of the greatest collaboration around software development has already occurred on IRC, but it’s not a great medium for sharing content and documentation in a way that people can refer to at a later date, the content of chats being fairly transient and file exchanges occurring in a peer to peer fashion.  Collaboration efforts over IRC would usually be combined with some kind of wiki.  IRC and wikis were inherently public and insecure, so creating community around these technologies would usually involve a company hosting their own wiki and IRC software which would require hardware and people resources to maintain.

It’s pretty clear the folks at Atlassian had a clear vision about how online collaboration could and should work. JIRA has to be the world’s most well know “ticket management” system, allowing people to create tickets (known as issues) in order to track user requirements, user stories, tasks and defects and more.  The Atlassian stack is well integrated so once configured you can have updates to JIRA appear on Confluence pages or even in the chat rooms on Atlassian’s own version of IRC known as HipChat.   HipChat is like IRC but accessible using Atlassian’s own software or via their website.  It also adds file sharing and allows users to share files in the context of a conversation easily while being able to see the historical transcripts of conversations that have happened.

These days it’s really easy for anyone to spin up an instance of an Atlassian stack giving them a wiki, real time chat, and ticket management but there are alternatives out there.  Rather than adopting a whole stack groups may only need a small portion of the stack initially so may decide to sign up for just a HipChat or Slack. 

Slack is an alternative to HipChat and, sorry Atlassian, I feel it has a superior user experience.  In some ways it is even more like IRC that HipChat, but with a user interface that is unobtrusive and a pleasure to use and like HipChat allows contextual file sharing.  

Whether you choose HipChat or Slack, or something else, once a team decides they need to add something else to the stack, it’s relatively easy for them to go out to the web and sign up for a wiki, or a task board, or issue management and then integrate it with whatever chat system they’ve decided to use. 

However, software development isn’t the only reason to use a HipChat or Slack. 

Even though Slack is relatively new, both companies have a strong reputation for reliability and respecting privacy, where as users of Facebook are becoming increasingly concerned with Facebook’s ever changing privacy policy and the fact that content shared there is only lightly secured.  For instance, post a picture to Facebook in to a private group, then right click on that picture, copy the link, and open that link in a browser you’re not signed in to (or send it to a friend not in the group) and you might be surprised to find that you can still access the picture.  Also consider that Facebook reorders content using secret internal algorithms which judge how relevant your content is, and that it is constant analysing content and the users who interact with it in order to sell that data for marketing and advertising purposes.  Facebook groups feel like a natural place to create a community, but the nature of Facebook’s post and comment approach means that Facebook groups become little more than soap boxes where only the loudest get heard.  True collaboration on the Facebook platform is not possible and the chance of private data leakage is high.  And I haven’t even talked about advertising.

So when groups of people - (ex)colleagues, friends, families, political groups, etc - want a place to collaborate, chat in real time, share files, and so on, tools like HipChat and Slack are a perfect replacement for the Facebook group. They are generally free to use and your content is safe and secure, because the reputation of the companies hosting these tools depends on that.

Thus the Popup Micro Community is born and the death of Facebook by a thousand cuts begins in earnest.

Monday, 23 February 2015

One week sprints could work for you - but probably won't.

I've been working using the Scrum methodology of agile, or some derivative of it, for many years now.  Over that period years I've worked at several different places who have all had a particular sprint length already established when I joined the team.

The one I enjoyed the most was the one-week sprint.  When you say this to people they usually balk, but the context for the one week sprint was just right.  Our product was single platform and we only interacted with people outside of the engineering team once a week in order to demo and plan for the following week.   The same day we would have our team retrospective and because it was Friday we'd either go to the pub or go home early.  Four solid days of development and one day off for admin type stuff, it worked really well and we were incredibly productive.

But the one week sprint can only work well if you have the right conditions:

  • The team can work in relative isolation with the scrum master as a conduit, getting answers to questions quickly.
  • The team feel empowered to make executive decisions.
  • Your team is single platform with little or no external dependencies.
  • Sprint starts on the Monday and finishes on the Friday.  
For me the one week sprint falls over pretty quickly when:
  • Your team is multi-platform.  For instance, developing mobile and server functionality concurrently.  The additional collaboration required means none of the devs can knuckle down and get work done.
  • Inter-team dependencies.  The more people you know, the more likely you are to get random interruptions, which break train of thought.
  • Your team is not co-located. If you have anyone that contributes to the sprint in different locations, then your ability to collaborate is severely hampered.  You'll use Skype, email, conference calls or some other tool and will then likely be asked why you're having so many meetings and using email to communicate.
  • Your scrum master is unable to to shield the team from distractions (for whatever reason).
  • You can't end your sprints on a Friday.  Stopping and starting during the middle of the week is counter productive for a couple of reasons.  Firstly, the Monday and Friday are natural delimiters for working.  If you have unfinished work on a Friday, devs will naturally ponder it, or at least feel a foreboding about it, over the weekend.  As a result they are not winding down and will burn out.  Secondly, having has the weekend to completely switch context Monday will naturally end up being a day of getting back up to speed.  Anecdotally, devs are most productive on Tuesdays and Wednesdays, maybe Thursdays.
  • Any of the above combined with an open plan office.  Open plan office is basically a forum for open discussion, people shouting across desks, people wandering around making noise and generally being distracting.  Give your devs a quiet area to work.  Joel Spolksy highlighted this about 15 years ago.  If you wonder why you see your devs working with headphones on "when they should be collaborating" this is why.

So I've been trying to work out how to determine the best sprint length, but there really isn't a formula.  That said, it is easy for me to say that unless your conditions are perfect, as described above, one week sprints aren't going to work for you. Personally, I would like 4 days of solid, relatively uninterrupted time to make quality progress. In this case, start with two week sprints.  This gives your devs time to work, but also builds in contingency for collaboration. Use retrospectives to let the team express their desire for shorter or longer sprints and listen to them.  Work around your engineers rather than forcing them to work around other parts of the team that are not actually producing something.

Sunday, 8 June 2014

Sleep - it's important.

According to the BBC, scientists in China and the US have used advanced technology to study the brain during sleep, determining that a good night's sleep is important to learning.

For a while I have been guilty of under-playing the importance of sleep and I have to admit that I don't do as much of it as I should ... until the weekends anyway.  This is obviously not doing me any favours as I like to learn.

The main problem I have is that I don't like to sleep.  Or at least, I don't like going to bed until I am literally dropping off.  I can easily sleep for 8 hours once I get there, but usually I have to get up for work, meaning I only get between 4 and 6 hours sleep a night during the week, if I'm lucky.

However, I've noticed since losing weight recently and taking more exercise (running mainly) that I am feeling that tiredness sooner than I was.  In the past 3 to 5 hours sleep a night was not unusually with occasional bouts of insomnia.  That hasn't happened in a while.

There are a few main problems which I think contribute to my current sleeping patterns:

  1. Caffeine.  I like to drink caffeinated drinks, my current favourite being Pepsi MAX.
  2. Work addiction.  I'm lucky enough to do my main hobby as my day job.  This means I'm pretty much working all the time.  I'll go to work and code, then come home and code some more.  I love it.
  3. Society(?).  Usually I have to be in an office between 9am and 5pm.

To solve these problems I am going to have to make some changes.

The obvious one is to stop taking caffeine. That'll stop me from being over-stimulated at the wrong times of the day and hopefully allow my body to sleep when it's tired, not just when I get in to a state where I am dropping off.  I'll have to switch from drinking caffeinated drinks to water, though I don't really like water as I find it boring.  That said, I suspect there will be additional benefits to not drinking

The work addiction is just a matter of discipline.  At a certain time in the evening I am going to have to put the computer away and do something else.  Read a book, watch some TV, play a game, anything.  This should get my head in to a mode where it is starting to relax instead of trying to solve problems.

There's little I can do to change the working day, but I wonder if this is something society should be looking to address.  My job involves technology and I don't work a shift in a factory, so why do I need to be in an office at particular times of the day?  I do know that I have to work as part of a team and working face to face is far more effective than working remotely, a conclusion I have come to after 15 years of trying various working methods.

So that's where I am just now.  I'm going to make a conscious effort to get more sleep and improve my ability to learn, as well as get the other health benefits associated with sleep.

Do you get enough sleep?  If not, what do the think the main reasons are and what do you plan to do about it?

Friday, 23 May 2014

Should I use Google or Amazon for my new awesome app?

That's the question I've had to ask myself recently.  The findings and conclusions below are based on plenty of experience of Amazon AWS and somewhat outdated experience of Google App Engine )with a bit of a recent refresh of knowledge for the purpose of putting together this blog post).  Feel free to correct me in comments if I've made any mistakes.

Overview: Google is a PaaS (platform as a service), Amazon is an IaaS (infrastructure as a service).  This means more flexibility when designing a solution architecture with Amazon, but at the expense of having to do additional system administration. However, BeanStalk gives you a pretty close equivalent of GAE with minimal admin overheads.

Services: Fairly similar range of offerings, though Google doesn't appear to have an equivalent to Amazon's SQS (message queuing) - this may not be relevant for your app, but there are benefits to building large scale applications, loosely coupled using message queues for passing information.

Cost: Pretty similar though Amazon has a better range of options for reducing cost as the app scales.  Amazon are regularly reducing their prices on their AWS products.

Software Development / App Restrictions: Since you're deploying in to Google's PaaS, they restrict how you can write your application (e.g. no Threading, white list for Java classes) to maximise compatibility with their platform.  This needs to be considered during development as "normal" things Java developers are used to may not be available.

Data Access: With Google, if you don't use their RDBMS, then you have to use their "datastore" which gives you an interface with which to query the data.  The same is available with Amazon's DynamoDB.  However, DynamoDB supports joins and aggregate functions where as the Google's datastore does not.  Neither appear to provide an out of the box user interface for accessing data in their RDBMS service (which is basically MySQL so not exactly difficult anyway).

Data Security and Privacy: Both companies appear susceptible to a recent ruling with regards to data in the US.  If data protection at this level is a concern then neither Google or Amazon may be appropriate.  See: http://www.thewhir.com/web-hosting-news/search-warrants-apply-worldwide-data-held-us-service-providers-judge-rules

There are UK alternatives if that's a problem you or your customers (e.g. bytemark.co.uk).

Maturity: Both are fairly mature now, but AWS has been around a longer.  The relative maturity of AWS over Google is reflected in the extensive administration console user interface.  Both provide command line tools and APIs, but Amazon's user interface is more complete (IMHO).

Support: Both offer support with varying turn around times and channels.  Amazon appears to be cheaper:

- https://cloud.google.com/support/
- https://aws.amazon.com/premiumsupport/

Amazon have regular official seminars, webinars and meetups (usually in London, but I've heard of some in Edinburgh too) to discuss their AWS features as well as an annual conference.

Google has Google I/O which is an expensive two days (since it's in San Francisco, I've been though and it is good ;-) and covers a range of stuff not necessarily specific to their cloud platform.

Conclusion: I don't see much point restricting yourself with Google unless there is a strong requirement for it (e.g. it allows for better integration with something Google specific).  The additional system administration of using Amazon AWS is outweighed by the flexibility and can be mitigated by using BeanStalk (initially) and automation (as the app grows and scales).

Monday, 9 September 2013

Kickstarter and iOS Apps

Some Kickstarters are about creating mobile apps and others use mobile apps to give some extra value as part of a stretch goal or add-on.

Getting your Android app to your backers is relatively simple - you just point them at a secret URL and let them side load it.  But for iOS apps, that's not so easy and you can't assume that all your users have a Jailbroken phone - I'm a developer and I don't have a jailbroken phone.

If you promise an iOS app to your backers and you intend to charge for your iOS app, there's a few important notes to consider:

  • If you gift an app to someone, even if you created it (or are the legal owners of it), you can't do this for free.  You'll be charged the full amount and then Apple take their cut before giving you the money for it (a couple of months later).  Apple don't want you cutting them out of the financial loop at any stage and even though it's your app, you're playing in their sandbox.  That's a bit like expecting retail stores to take delivery of your stock and distribute it to people who pre-paid through some other channel.  
  • You can't gift apps across App Stores.  Someone in the US can't gift an app to someone in the UK.   Well, that's not strictly true.  If the sender has an iTunes Store account for the destination country and has a credit card registered to an address there then you can select the destination store and gift it directly.  There are some countries which you can gift to direct from the US store, but it's not clear which countries can be gifted to directly from other stores.
  • You can't gift free apps.
  • You're limited to 50 100 promotion codes per version of the app.  If you artificially roll your app version too many times for this purpose your app will be kicked out of the App Store.
So what strategies can you use?

One option is to make the apps Tier 1 price for a day, generate all the gift codes and then up the price to whatever is required on subsequent days.  However, you still have the problem of cross-store gifting.

The most common approach is to make the apps free for a short period, notifying backers well in advance, and then change the app to a paid app later.

Finally, consider not charging anything for your app, period.  Or rather, adopt a freemium model.  A lot of the the top grossing apps are free with in-app purchases, so it's food for thought.  Deliver what your Kickstarter backers are expecting and put it on the App Store for free, but make sure to let them know it's not exclusive, and then add new functionality that people will want to buy later.

Sunday, 25 August 2013

Enterprise Android

Well, in a strange twist of fate, when considering my last post, but I find myself on an Android application for a UK financial institution.  It's a fun project, mostly, but working with Android in an enterprise environment has its challenges.

We have a continuous integration environment based on Jenkins and our build uses Maven.  However, we have a number of dependencies which are not available via Maven central so currently have to install a few jars in each environment we build in.  Not pretty, but we are hoping to get our own repository set up soon.

We have two projects, one that builds the app and one that contains UI tests.

In the main project we have unit tests based on Robolectric and in the UI test project we have tests that use Robotium.  Since we are using Eclipse as our IDE (at the moment) Maven causes us a little pain.  The m2e plugin combined with the m2e-android plugin struggles with dependencies - it can't separate the testing dependencies from the ones used by the app itself and ends up including them all.  As a result Android will try to dex a lot of classes that it doesn't need to, including its own library which causes all kinds of problems.  Our solution was to have separate Maven profiles which you change via the Maven preferences depending on what you want to do; unit testing or running the app (or UI tests).  Generally, I leave Eclipse in "unit testing" mode and run the app from the command line.  However, if I want to run our UI tests then I do have to switch and if you forget to do a proper clean of your environment (I call this "the dance" or "the ritual") it can result in some unexpected results.

Of course, none of that is required outside of Eclipse, so we are waiting for the right time to move to IntelliJ IDEA or Google's own Android Studio based on the same technology allowing us to simplify our build somewhat.

On Jenkins we have three jobs in a kind of pipeline, each job triggering the next:

  • Build for Junit
  • Build (and run) UI tests
  • Build a clean APK
Of course, it's not a proper pipeline because if someone commits while the Junit job is running then the subsequent builds end up using the committed code rather than what was used to execute the unit tests.  I am hoping we will switch to something like Bamboo which should, I believe, allow us to do this properly.

Additionally, there isn't a reliable way to run UI tests at the moment, especially headlessly, so all that job does is compile the UI test project code.  We are planning to use a Mac Mini in the office with a device attached, but will need to unlock the device(s) and login in to the company's WIFI on a daily basis, so that's not going to be very efficient.

We also have a fourth job for doing releases.  With a single click (and after entering a couple of parameters for version numbers, etc) we can build a version of the APK with its manifest properly configured with a new version code and number.  The APK is then published to our Confluence so that interested parties can install and use the application, though anyone who knows where our Jenkins is located is welcome to install the dev version of the APK at any time.

Fragmentation has only been a minor issue so far.  We of course have to design for a number of device sizes and resolutions which is tricky enough, but have noticed some strange behaviour on (wait for it) Samsung devices, especially the S2 running TouchWhiz.

We are also using ActionBarSherlock to provide ActionBar functionality for older devices, but have been glad to hear that the new support library supports it explicitly.   Maven support in Eclipse has been painful particularly ActionBarSherlock has been sherlocked by Google?  It seems so.