Thursday, 3 November 2016

Managed Android Demo

One launch I am very happy to see - Android Management Experience, was briefly described by wonderful Ron Amadeo of ArsTechnica.

In a nutshell, this is a way to enable managed (work) profile on your Android device, which you can manage remotely — something that your employer's IT desk would usually do if you want to use your personal device for work. Greatest thing about Managed Android experience is that it is effectively a very small, very limited, yet fully functional enterprise mobility management tool for Android: greatly stripped down of features, but working nevertheless.

Another thing which I didn't realise until I tried it - you can even upload private apps via Play Developer Console and distribute these apps within your "organisation" using Android management experience. In short, if you are Android enthusiast this is definitely something worth playing with!

Wednesday, 13 July 2016

Arrivals just arrived to @london_tube_bot

After some more fiddling with @london_tube_bot I figured a feature I really need for myself: as I often run to the timetable, I need a way of quickly checking when is my next train due at my station. Naturally, I decided that I had to add it to my bot. And boy, was it an interesting journey ...

The problem as I see it is that TfL's API inherits their data model, which, in its turn, inherits their complex relationship with different train operators. Did you know, for example, that Kew Gardens is not a station, but, in fact, two stations located exactly at the same place - Kew Gardens London Underground station, and Kew Gardens National Rail station? And yes, if you want to fetch arrivals from this station, you will have to do it separately from these two. More interesting: from TfL's perspective there's no Tube on this station - just Overground and National Rail. That probably makes District Line a commuter train somewhere half the way.

Anyway, here it is, enjoy!

Sunday, 10 July 2016

Telegram bots all the way

So it suddenly became rather cool writing various bots, and I was like, I want to build one as well. There was no good reason for it, and distinct lack of good ideas, but then I got an email from TfL, reminding that once upon a time I signed up for their API key ... bingo! That did sound like a plan.
And this is how @london_tube_bot was born. Right now it is fairly stupid, and can either:
  • Give full status breakdown for all lines (/status/ command)
  • Give an update on specific line (/line <line-name> command)
  • Send a not very helpful help message (/help)

Not really sure if I'm planning to develop it any further, as this was a very simple proof of concept ("because I can") -- but if you are interested, I can publish the code to GitHub at some point.
From the technical standpoint there were a few interesting observations:
  • Telegram documentation is shit. Most of what I learned I did by reverse-engineering the messages they send.
  • OTOH, Telegram API is awesomely simple - I used Advanced Rest Client to do most of my testing to play with it (cUrl would work as well, but former is far more user-friendly).
  • Building a bot on AppEngine is surprisingly easy once you get a gist of it -- I think this is the best platform for doing this at this point, as you get fully-working WebHooks for free.
  • totally rocks - I used it to build Java wrappers (yes, I used Java - just because I didn't feel like learning yet another language at this point) for JSON messages, without even having any dedicated JSON schema document. Works like a charm and requires only minimal manual fixing after classes are generated.
All things considered, I think this were half a day well spent - should I add support for Google Allo once it's out? :)

Friday, 22 April 2016

Formatting time in Android/Java, the right way

I suppose this is very obvious for someone, but I spent a fair bit of time trying to understand what is the right, no, the right way to do time formatting in Java. I know about Joda, and don't really want to use it (because size, and frankly, I don't need all of it's features). I know about SimpleDateFormat and hate it because I have to hardcode my format. What I wanted is the way to use system-defined, user-preferred way to format time - i.e. if user specified 12-hour time, we want to add AM/PM, and if they happen to use Russian layout, that should magically become "ДП/ПП" however odd I would find this. This is, I think, the quickest the way to get it - using standard framework features:

When using this approach, you will get correctly formatted time, e.g. for 23:10 you will get "23:10" in 24-hour time, "11:10 PM" with English locale and 12-hour time, and "11:10 ПП" in Russian. Makes me very happy this is actually achievable without resorting to hacks like this, or, even worse, this.

Friday, 15 April 2016

Notifications, lockscreen and timed silence

So I got bored the other day and though: why my wonderful Samsung S7 Edge just doesn't seem to support an ability to shut up all the notification sounds for a timed interval? After all, this has been supported by Android Marshmallow since forever, and yet they decided to pull it. Then again, my better half was complaining about exactly the same thing as she always switches sound off for meetings and then inevitably forgets to turn it back on again (something I like to complain about).

Prospects did not look good. But then I thought - hang on a sec, there should be an app for that! So I searched Play Store, and searched again, and there are lots of apps, but they look like shit, and most importantly, are hard to use as I have to define a schedule (like, really, would anybody do that?). And I decided this is something I can fix.

I spent like a Saturday afternoon coding and a proof-of-concept was born - an app which can silence notifications for a period of time. Then I realised that user still has to unlock the screen and launch the app, which is not very user friendly, and remembered about fancy Lollipop notifications which has been there since forever. Et voila - Silencer was born.


Don't judge it too harshly as this is just a simple app to solve a simple problem - however, I find it using a lot. When I walk into a meeting, I fire up the screen on my phone and silence all notifications for 30 minutes, without even unlocking it. Try it, might work for you as well :) If you feel this app is desperately lacking something - get back to me and I'll try to add it.

Tuesday, 31 March 2015

Software Engineering process, Google way

By: Simon Wingrove (, Roman Kirillov

We often get questions along the lines of “what is the development process at Google?” – meaning the secret sauce which allows project to magically happen and launch on time. There is an abundance of articles and blog posts which describe how Google does things, and probably some of them are right! The truth is, however, that a process that works for one group of smart people will not necessarily work for another. This is why there’s simply no such thing as “the” development process at Google.  Most teams will adopt the approach that suits them best.
Establishing the process for a team is usually not something that happens “because the manager said so” – frankly, engineers have far more say in the matter.  When our team (Google Play for work) realised it was growing to the point where it needed to formalise its practices, the engineers stepped up and self-organised to make it happen.
The cornerstone of any development process is the goal: what are we trying to achieve here? We want to be able to answer a few fundamental questions at any moment in time.
  • Are we on track to deliver?
  • What features are we currently working on?
  • Can we take on more work now and still meet our deadlines?
Engineers are best placed to estimate the complexity of engineering problems, so making sure we can always answer these questions is an engineer-driven process.
Objectives and Key Results – achievable and measurable goals
Across all of Google we use Objectives and Key Results (OKRs). Every team, product area and even the company as a whole has them. OKRs are defined quarterly by the product and engineering managers, with input from the wider team on specific technical questions.

Monday, 15 September 2014

Geeky car insurance

My car insurer of choice - Aviva - takes an interesting approach to estimating the risk score. We all heard about insurers who want to install an extra little box to your car which will estimate your driving style, yada yada. Aviva actually employed slightly different approach: you install an app on your phone, and then check in at every start and end of journey. Once you've driven 200 miles with the app, your driving style is evaluated and you can receive a hefty discount (up to 20%, really) on your insurance premiums.


This way no one actually tells you to install the box or the app - but if you do that, you can save few extra quid on your car insurance - for some of the younger drivers insurance premiums can be crippling, so this would be a really good deal (and admit it, some although not all younger drivers can benefit of some err ... improvements with regards to their driving style).

What do you think of this approach? Would you install such an app?