My First Training In Sydney

Recently my work provided me with my latest challenge. I was to head to Sydney to train a group of people for two days with a coworker. As well as this the week following I would be required to stay in Sydney and act as an onsite consultant. I was to help out the group we had trained the week before develop an app in a week for AMP’s Amplify event.

This work trip was to be the first time I had been to Syndey. My coworker and I arrived on Wednesday the 29th of May to discover that the city was hosting an event they like to call Vivid Sydney. As someone who has lived in Adelaide all of their life, Sydney is HUGE! I was very surprised to find out that the local time was 10:30 pm due to the fact that there were so many people about. I don’t doubt that Vivid Sydney had something to do with it, but it really did seem to me as though Sydney was just that busy.

While in Sydney I was training and/or consulting a group of AMP employees who were learning to work with MobileNation. I am a key member of the MobileNation development team at CentricMinds, however recently I have found myself using MobileNation as a platform for mobile app development more often than developing the MobileNation product itself. Both are enjoyable tasks, which is a good thing as I was required to actively do both during my week of consultancy.

The team of AMP employees I worked with were very clever. They picked up the product very quickly and as a first time trainer, I found it very easy to communicate with them on both a casual and technical level. Our goal was to develop at least one app in a week. By the time Tuesday the 4th of June had finished, we had increased our goal to developing 3 apps as well as a simple welcome app and had links to the others.

After tonnes of effort put in by the whole AMP team and a lot of late nights for me. Friday had come around, the day of the main Amplify event. Thursday night I had stayed up till past 1am to ensure that all of the production versions of the apps were working. On Friday morning the guys decided to test the apps with their iPhones and we hit a bit of a snag. I had tested the apps on my iPad 3 and my Samsung Galaxy S3, but I was unable to test with an iPhone. It was at this time I went through the following states of mentality:

  1. Denial “But it works, see?”: I got out my phone and my iPad, tested the apps once more and showed the others that they were in fact working as expected.
  2. Accusation “It must be X, it can’t be my code”: I blamed “powerful caching” and requested that everyone clear out their browser cache and restart their devices.
  3. Acceptance “OH S**T! It doesn’t work”: Once people had successfully thwarted their super caches, they were still reporting errors, specifically only on iPhones.
  4. Self Doubt “What have I done?”: I was preparing for the fact that I had failed, that the work I was so sure was working, was in fact not. And that I would likely have to be making up excuses all day. Something along the lines of “if we had more time …”.
  5. Curiosity “What actually went wrong?”: I decided to actually look at the app failing myself. Yes that’s right, until now I hadn’t actually looked at it on an iPhone. this is what I should have done from the start. I asked to borrow someones phone and noticed that it was an issue with a calendar within the app.
  6. Problem Solving “But if you do this, it fixes itself”: While fiddling with the broken calendar I noticed that if you attempt to change dates by sliding either left or right it actually corrects the error. The app prevents the date change from occurring, but causes the calendar to redraw with the correct data.
  7. Recollection “I’ve seen this before”: It was about this point where I realised that I’d seen this issue the night before during my testing. And that I had only fixed it in the issue in the production version of the app. I had purposely not fixed it in the preview as it was not going to be seen.
  8. Realisation “I’ve got it!”: Of course, that decision I had made at 1am that morning to not fix the preview project had come back to bite me. I discovered that the QR codes that we had printed for the apps were all pointing to the preview versions of the apps. Thankfully, only one of the apps required fixes for the published version.
  9. Nervousness “I hope this works”: Having found the cause of the issue, I was able to duck upstairs and update the preview version of the project with the fix from the published version. This is a process I like to refer to as “open-site surgery” as the app was now technically live, if I had made a mistake it would be game over.
  10. Happiness “And there was much rejoicing”: As it turned out I had no reason to worry, the change was a simple one and once it was done the app started performing admirably. The best part is that I was able to do this before the stand started getting attention from the Amplify crowd.

In the end we had 4 working apps and I developed another in an hour during the Amplify event which brought it to a total of 5 apps being developed between approximately 3 people in one week (read: 4 days).

The Amplify event was awesome. I saw a 3d printer printing a model of Yoda’s head. I was a “sleeping beauty” who was awoken with knowledge of the GFC and I saw a T-Rex break through a Jurassic Park poster with virtual reality. Throughout the event the App In A Week stand got a lot of interest and people were most excited about the app that I had just fixed up earlier that morning. It was a great success for the AMP team I worked with and also an awesome demonstration of the power of the MobileNation platform.

I’ll leave you with some images I was able to take when I wasn’t busy programming.
~ NodeReaver