Redeploying Rediscover.Work to Save Money Part 2

Migrating to Google App Engine was more straightforward than trying to rebuild my environment and meant I had to change a few things in my setup.

- Unable to update app: Class file is Java 8 but max supported is Java 7: Don't forget Guava, only versions of guava up to 20 are supporting Java 1.7
- The app config version isn't the SDK version, it is like the AWS build version and can't contain '.' periods so version 0 it is.
- Downloading the database is a pain in a server-less environment as AWS only supports binary snapshots. But fear not, a bit of ssh / yum / security group manipulation and the download is done in about 20 minutes.
- Deploy a new SQL instance in the cloud console: Note you need to include the create database or use the advanced options to specify the database to import your SQL to.
- Then hit a brick wall "You can't have any JDBC database with Google App Engine." due to "java.lang.management.ManagementFactory is a restricted class". This is a slight misnomer, it is creating threadpool connection pool resources which is prohibited.
- In steps a non threaded connection pool: http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Plain_Ol'_Java
- Unfortunately Tomcat connection pool was a red herring with "java.lang.RuntimePermission" "modifyThreadGroup"
- Logging to a file doesn't work, (neither does looking at the file system to figure out where you are).
- More security errors: setProperty.networkaddress.cache.ttl
- Moved to Google SQL driver "com.mysql.jdbc.GoogleDriver"
- ERROR: (gcloud.beta.sql.connect) HTTPError 400: Invalid value for: Invalid format: "2017-02-16T20:01:08+00:00" is malformed at "+00:00"


Redeploying Rediscover.Work to Save Money Part 1

After five years working in startups, and more recently in 'stealth mode' startups I have decided to go back to my favourite place to work. This means that I can now share some of my hacking projects more openly.

At the moment one of my side projects which I want to keep alive is Rediscover.Work. It is currently hosted in AWS using Elastic Beanstalk and RDS. This made sense at the time when I was trying to get the site up quickly. Now that the project is no longer funded though it is time to do a bit of belt tightening.

As with any project it is worth looking at different options for how it could be deployed. There were never more than there are now:

* AWS Elastic Beanstalk + RDS. Current running cost of around $96 per month. + Easy install. -  Cost.
* AWS Lambda + RDS. + Simple scaling. - Migration costs are prohibitive.
* EC2 Instance: $9.52 according to the price calculator. + Already have needed tools - More admin to manage instance personally.
* Google App Engine and Cloud SQL: $8.01 according to the price calculator. + Ease of mantenance and app engine security scanning. - Migration to app engine layout.

As I already have all the tools needed to create the EC2 Instance solution and it requires the minimum investment in tooling I chose to go down that route first and see how things played out. In part 2 of this blog I will see how hard it is to migrate to app engine as this seems like a better solution for the long term.


  1. Build dependencies and update dependency versions using

mvn versions:display-dependency-updates

  1. Package the code into a WAR to be deployed on the new shared EC2 instance.
  2. Launch a new instance which will run the site and database.
  3. Start hacking ansible (and loose the will to live due to so many issues with config).
  4. Stop.
Look out for part 2 where I will probably decide to migrate the whole project as managing machines is getting too painful for this time poor old coder.


Wine Tasting at Majestic Camden

I recently attended my first wine tasting which was organised by my private Somelier. We  Definition wines from Majestic which it selects as reference examples of different wines. We also learned how to pair food, and my somelier won the competition to match food and wines. What great taste!

We tried:

Sauvingnon Blanc grown on Granite. Marlbrough NZ heavy yield fast ripening. Acidic. Some regions are full bodied like Chili. This is light, fresh and green, almost tastes like nettles.

Sauvingnon Blanc. San Cere. Loire. FR. darker and heavier flavored due to the soil. Bolder than the first sauvingnon Blanc due to the chalk soil. Easy drinking and balanced with less acidity.

Chardonnay. Chablis, Eon, France. Un-oaken. Stored in stainless steel temporarily before bottling. The oak barrelling would normally reduce the acidity. Light but zesty with more body than the sauvingnon Blancs.

Definition prosecco. Very light and medium dry, excellent with melon and prosciutto.

Pinot Noir NZ. Picking a great one can be tricky from a French range. This one is quite spicy and 
peppery. Some people say it is like grape juice or raisins. I like it.

Malbec Argentina. (Mendoza). Very full bodied. Smoky blackberry. Great with a steak frites.

Tempranillo Rioja ES. A blend of different vineyards. The grand reserve we tried was the older with around 36 months of oak aging. This was the last and heaviest, DOCG.
I'm looking forward to the next level of training!


Living with Android 4.* on Samsung S3

The Due to a screen fade issue with my Samsung S7 I recently had the chance to downgrade temporarily to my old Samsung S3.

The first thing that I noticed was how much smaller the old device is, both in terms of the physical device and screen real estate. Welcome to zooming and scrolling! From a development point of view it is all too easy to think of these two devices as the same format but that could be a mistake. It may be good to consider making the main view different for small handsets.
The second thing to hit me which was more profound was the performance, or lack of. I removed every app I didn't absolutely need. It turns out that still wasn't enough. If you are wondering why your older remain relatives or friends are so slow to message back; this is probably why. It is so tempting, as a developer using the latest handset, to think people will upgrade their handsets. Guess again, according to the official Google developer pages a massive 36.3% of android handsets are running KitKat L19 or lower as of January 2017. If you are building a mass market app this simply isn't a demographic that you can afford to ignore.

There are some tech companies who occasionally do downgrade testing for a large set of their employees. Facebook is one noteworthy example.

Many apps just can't run in usable time, by that I mean that they remind me of using a x286 without the Coprocessor. A particularly bad example was the twitter app which crashed every time that the "share content on social" hook was called to find contextual information.
The question remains, does developing for the latest hardware first make sense if you are trying to reach mass appeal or does making your developers start with the end in mind ensure your app will succeed?