Saturday 21 July 2018

Not dead, only pining for the fjords

Although it's been a long time since I last posted here, the project isn't completely dead.  I'm still interested in it, I still don't think it's good enough to publicize to my civilian (i.e. outside the software profession) friends, but I'm still trying to get it up to that standard.

Over the time since the last post I have kept on quietly chipping away whenever free time, energy and ideas came together in the right way, and there is some progress to report, specifically:

  • The iOS app has been brought up to date with the latest XCode relatively recently, and is no longer in danger of dropping out of the App Store due to its age.
  • No specific work on the Android app, but it's still available in the Play Store.
  • The Australian Taxation Office wrote to me that they proposed to withdraw my ABN (i.e. registration as a business) due to inactivity, but accepted evidence I sent them that there was activity even if no revenue at this stage.  This is important to the project because an ABN is required to sell non-free apps in the iOS app store for an Australian-based developer like me.
  • I've decided that the Google App Engine platform isn't the future in relation to the web application for editing .tqz files consumed by the mobile apps, and have started work on a new Django-based application, some of which can be seen at http://tl-experiments.7e14.starter-us-west-2.openshiftapps.com/ (source at https://bitbucket.org/tim_littlefair/openshift-django-1, but I'm definitely going to have to do something about the current awful project name).
  • I've also done some work on using Google Places Search API at the to populate an initial set of places when a user starts on a .tqz file (source at https://bitbucket.org/tim_littlefair/trailer-google-places-recommender).
One issue I am dealing with at the moment is Google's recent move to require billing to be enabled on applications using their Maps and Places APIs.  Although they still provide very generous free quotas, I'm a bit nervous of providing them debit card details because I don't want to have to keep checking that the project isn't running up costs in excess of its projected revenue (realistically, expected revenue is zero for the foreseeable future).  For this reason, I'd prefer not to provide a payment method until I am absolutely forced to.  The Python-based -recommender code mentioned above still seems to work today despite the fact that I haven't enabled billing or provided a payment method for the credentials it uses, I'd be interested in hearing from other developers whether Google are actually backing their declared intent in this area up with action to deny service on credentials which don't have billing fully enabled.

Beyond that nothing to report except that the motto of the project is still 'whatever it gets' (see the third paragraph of the previous post from November 2013).