Friday, 13 January 2012

Down The Pub

I'm down the pub with some good friends.
feedme doesn't seem to work.

Wednesday, 13 April 2011

Three Month Schema Change

I've just finished a schema change that took a lot longer than expected. I now understand how I could have done it a lot quicker.

I'm used to working in an Investment Bank where we have a few hours after New York close on Friday and Tokyo opens on a Monday to perform installs and upgrades.

Feedme is online 24/7 and has a few thousand users, so I decided to try and perform a schema migration online. This turned out to be a lot more difficult than I first thought. Probably because I allowed scope creep and ended up rewriting much of the server side of the application.

Drivers

  1. I needed to change the entity groups to move all a user's data into a single entity group.  I could not make updates to a single user in a single transaction (GAE Transactions only work inside single entity groups).
  2. I needed to change the URLs that a 3rd parties used to POST data to my server.
  3. I needed to make some changes to my MVP framework.
Problems
  1. Transactions on single entity groups, means that I couldn't make updates to a users data in a single transaction. So migrating all their data into single entity group could not be done in a single transaction.
  2. Distributed subscriptions could miss updates if I wasn't subscribed on my new URLs before unsubscribing the old ones.
  3. Always online means end users should not notice a break in service, duplicates or missing data.
Finite State Machines
The transaction and distributed subscription issues meant that I would have to perform asynchronous operations optimistically. This would have to happen over transaction boundaries. So I've have to journal  the fact that I'd performed the operation and deal with the results or errors in another transaction. I chose to do this by simply storing a state in each record that I was changing and having a  FSM manage what should happen on future events. I did this on several levels with a hierarchy of FSMs.

Wednesday, 23 March 2011

MVP Observations

As I learn more about MVP I'm beginning to notice a few things:
  • The cycle of events around the MVP triad can happily continue forever, this is because it's a queue, not a tree. I think this has potential for scaling up on AppEngine and down on Android.
  • Events couple each MVP relation. Interactions flow from View to Presenter. Commands flow from Presenter to the Model. Events flow from Model to View.
  • It's so painful to debug without a good view of the event queue.
I have created a monster ... again.

Monday, 7 February 2011

GAE Queue Timing

Setting my C2DM delivery queues to 10000/d was not such a great idea.

  1. I'm actually allowed to push 100,000 messages a day
  2. 10,000 is a bit like 7 a minute, although in theory you could send 10,000 in the first second of the day.

Sunday, 16 January 2011

GitHub

Git has been my favourite tool for a long time. It feels right to respond to code questions with a little gist or even a whole repository.

Here's one I built to roll up some stackoverflow answers and subsequent patch posts.

Friday, 14 January 2011

Bit Twiddling

The Android Notification system is a real blast from the past.

Last time I has to "or" bits into bit fields to make things happen is was writing an embedded controller for a medical pump.

It would be OK if the flags names made any sense, but it's taken me 2 hours reading the documentation and a few testcases to figure out WTF the really mean, come on guys give me a sane object API please.

I've still not got the lights going. It's not like these are memory mapped bits that actually make the hardware do things, that can be the only excuse for bit twiddling IMHO. I'll check the AOSP, I bet some other programmer has to "and" all my bits out one by one to actually make any sense of it.

I do like the attempt at being able to set the LED RGB colour though. I'm going to have to make a colour picker for that.

Tuesday, 4 January 2011

Android Themes and Styles

Changing the attributes of a UI in code always ends up looking ugly. In HTML I tend to factor out these attributes into stylesheets. In Android you can use styles and themes.

Using CSS always takes a little time, as CSS is not one of my core skills, however it always ends up feeling like a simple design. This was also true of my first stab at using Android styles and Themes.

Again android themes and styles have a hierarchical nature so I can tweak existing styles. I can also using logical names for things like colours which change depending on the theme.

I used this approach as hardcoding the colours would not work with the different themes out there. E.g if you've got a bright theme, then text to white will make it invisible. On a dark theme, setting it to black would do the same.

Now that I'm using styles correctly people with different themes will be able to use my app.