First to enter the foray of consumer-friendly wearable computing, the Pebble is the product of a highly successful Kickstarter project, raising over 100 times its goal. You know that though. What you don’t know, is how it works in the real world and whether it can replace your (probably empty) wrist.

What it does

Once you’ve got your pebble paired with your phone it will display one of the three default watchfaces (a word clock, a basic ‘analogue’ watch and a tacky-looking digital one). The Android app now has the option right out of the box to show notifications from your calls, texts, calendar, email & any other 3rd party apps. This works best with android 4.3+ so it can use the official notification API.

One slight hiccup with the notifications is that if you use an app like Hangouts for SMS, and have both SMS notifications enabled and Hangouts notifications enabled then you’ll end up getting double notifications (one set from Hangouts and one set from Pebble’s SMS setting). This can be fixed by disabling SMS notifications and simply using the notifications from hangouts as your SMS notifications. This isn’t difficult to do, but there are plenty of times where this can happen: I use Today Calendar, Mailbox & Hangouts so Calendar notifications, emails and SMS notifications have to be turned off or I get double-ups. Not a dealbreaker by any means, but not something your average user would do (More on that later).

The apps it comes with out of the box are fairly sparse: Alarms, Music, Notifications, Watchfaces & Settings. Alarms is a fairly basic setup: create/ edit alarms, change the snooze time. Notifications lets you see a stream of dismissed notifications. Watchfaces & Settings let you do some basic configuration of the device, including set up shortcuts to apps when you press and hold either the up or down button from the ‘homescreen’ (your current watchface). These are pretty useful: especially when you set one to open the music app.

The music app is almost worth buying the Pebble for. Yup, I did just say that: Neither of my headphones have play/ pause buttons on the cord, and so it is really neat to listen to a podcast and quickly pause it to talk to someone. Or change the volume. Or skip a section. I can even just plug my headphones in to my phone, press play on the Pebble and be listening to a podcast without even getting my phone out of my pocket.

This does come with a drawback of the native music app; it ties the controls to a single app (In my case I have it linked to Pocketcasts) which allows it to open the app if it is not already, and then start playing music. If you have Pocketcasts set as the app to control, and you’re listening to music on Spotify and you try to skip a track, the Pebble will send the command to Pocketcasts not Spotify. There are apps (MusicBoss) that you can use to improve the behaviour and make the pebble. I listen to podcasts most of the time so I just leave it on Pocketcasts and I’m happy.

Pebble 2.0: What I’d like to see

With the introduction of the Apple Watch and more Android Wear devices next year, Pebble will have to step up their smartwatch game to remain relevant. With no input method the Pebble remains to be a status display with hotkeys for your phone.

What I don’t think Pebble will do:

• Color screen
• Touch screen
• Android wear OS
• Higher price (Not much over ~$250)
• One day battery life

Each one of these would bring the Pebble to a playing field where it is directly comparable to other smartwatches, which isn’t where Pebble will want to be: they need to separate themselves, and the easiest way to do this is to tout their far superior battery life (10 days guys! 10 days!) and “no-fuss” attitude.

However no voice input will be a dealbreaker for the massive smartwatch market (Still not convinced on this wearable business) as many people will just see that one can and the other can’t and put their money where the features are. What Pebble could do is build in a bluetooth headset into the watch (Think Motorola Hint) so that the heavy lifting of voice recognition is done by the phone, not the watch. If they pulled it back even further and made it push-to-talk the battery life could possibly still stay at a ‘Pebble acceptable’ time.

‘Always on’ voice recognition driven by the phone could be a marketing nightmare because it would depend fully on the chipset in the phone that it is paired with - ie no iPhones and only a couple of Android phones (Motorola is the only company that seems to be doing this well as far as I can remember) - meaning that the general public won’t be seeing the features they’d hoped for.

Should your mum get one?

Unless your mum is a massive nerd, then no. The pebble still has some weird connectivity issues that can’t be solved by simply pressing a ‘reconnect’ button - every few days it gets sad and disconnects itself so thoroughly I have to go into the bluetooth settings on the watch, remove my phone from the list of known devices and then try and reconnect. That sometimes works.

All in all I don’t see watches ever taking over your computing experience like phones took over from laptops and desktops. There will only be a place for them on the wrists of the fanboys and geeks.

(I do look forward to hearing about the latest watch benchmarks..)

Writing an app on android that uses a database is a bit of a pain - I spent a fair amount of time creating a wrapper around the default interface that makes it behave a bit more like Arel and so I don’t have to worry about too much SQL. Maybe I’ll post it sometime..

I thought debugging the database would be impossible without writing a part of the app that dumps the data onto the screen, but it turns out..

This answer on StackOverflow basically tells you how to pull the database using the adb command into a SQLite .db file that can be read with an app like this (Or some better alternative, please?)

Basically to set it up you should run this (Assuming you have brew installed and adb correctly in your path)

# The bundled version doesn't have zlib
brew reinstall openssl
# So we can use the openssl commands anywhere
echo "export PATH=/usr/local/opt/openssl/bin:\$PATH" >> ~/.bash_profile

Save this as db_pull in your $PATH or working directory.

#!/bin/bash
app=$1
adb backup -f ./data.ab -noapk $app
dd if=data.ab bs=1 skip=24 | openssl zlib -d | tar -xvf -

This can be used like so: db_pull com.example.app. You can find the .db file in the folder that gets created and open that with SQLite Browser.

After upgrading to Yosemite I found myself blinded by the whiteness of the menus, dock folders and launchpad folders. Too much white for my liking - so I switched to the new dark mode, which makes most of the components black:

• Menu bar
• Dock
• Menus
• Dock folders

But leaves these white:

• Notifications
• Launchpad folders
• Other app UI

Previously my terminal was set up like this:

This is the Pro theme with a slight transparency and a custom PS1 variable - just add this to your .bash_profile:

export PS1="\[\033[0;36m\]\h \[\033[0;37m\](\W) "

Yosemite Style

I decided that for Yosemite the background should be blurred and have the same transparency as the menu bar, so I inspected a screenshot and found it to have 70% opacity. To mimick this look I went to:

Terminal > Preferences > Profiles > Window > Background

Set the background to black, the transparency to 70% and the blur to 100% for ‘dat Yosemite style:

And that’s that. I think the blur on other parts of Yosemite’s UI may be a wee bit more complicated, or at least ‘stronger’. The guys on ATP think it’s more complicated.

(Note: Mike the MacBook)

So, I have a computer science test on Thursday and have been getting annoyed at triggers. Triggers are basically a wee bit of sql that ‘watches’ the database for a certain action, and then executes a block of sql when the action is performed.

The action can be an insert, update or delete and the trigger can be run before, after or instead of the statement that set off the trigger.

For example the following statement is triggered when there is a new row inserted into the testtable table and it will duplicate two attributes (attr and attr1) into a second table called result, once for each row that has been inserted.

create trigger testtrigger
  before insert on testtable
  for each row
    insert into result values(new.attr, new.attr1);

This is all very nice for one statement, but what if you need a couple, or some conditions? You can turn the single statement into a begin ... end block to run multiple sql statements:

create trigger testtrigger
  before update on testtable
  for each row
    begin
      if new.attr = 'somevalue'
        insert into result values(new.attr, old.attr);
      else
        insert into result values('constant', 'mismatching data types');
      end if;
    end;

This snippet will run before an update on testtable and will execute one of two different statements depending on the new value of attr.

When the trigger started on insert or update, a tuple new is set to be the new row that is being inserted (Sometimes you need to call it :new). On update you get new and old to work with.

Gotcha

When you’re running this in some clients or interactive prompts, the interpreter will mistake the first semicolon as the end of the statement and fail. To fix this you just need to add:

delimiter //

create trigger mytrigger ...

//
delimiter ;

around your statement.

And that’s basically all I learnt about triggers. I don’t know why you’d want to do this kind of stuff in your database when you would do it with your database application.. but whatever.

So, the iPhone 6 sports a revolutionary new 4.7” display. This upgrade was completely unexpected. I personally didn’t expect Apple to enter the ‘phablet’ market - instead thinking they’d keep with their model of targeting the average consumer, which is now someone who wants a slightly larger phone.

The increased screen size is definitely a big improvement. Games can worry less about your fingers covering up all the action and videos can be watched in their full 4.7” glory. However the phone is too big. It has the same footprint as my Galaxy S3 - from 2012 - a phone that when you take a step back from and look at the whole device it actually has a fairly small screen. Samsung even squeezed an extra .3” into the S4, while keeping the same footprint.

This led me to wonder how the iPhone stacked up against the other flagships of the last few years, in terms of the ratio of screen area to the area of the device. After some trips to GSM Arena and some spreadsheet-foo, I’d come up with an answer:

Calculating the screen area was a bit tricky, in the end I calculated the number of pixels along the diagonal length of the screen and used this and the screen size to calculate the pixel density of the screen. Knowing the pixel density I could easily convert the horizontal and vertical resolutions to lengths and then calculate the area.

I chucked all this into a spreadsheet and bam, graph! The dark lines show the ratio of the screen size to the physical phone size, and the lighter grey line shows the device’s screen size. As you can see no iPhone model has a particularly large screen relative to the size of the device, which is obviously because of the massive chin for the home button and matching ‘forehead’.

So basically I just made this to illustrate that the 2013 Moto X is a really compact phone, with a nice sized screen. And the LG G3 is the phone you want to get if you don’t have time for bezels.

So I got a bit off-topic in my last post about standards, and how I think we need more of them to make all the cool new gadgets function together - maybe not work nicely, but at least function.

So naturally, I’ve been thinking about what I’d like to see standardised.

1. Wireless file transfers

Airdrop is pretty cool, so is Samsung’s S beam. Both are limited to a handful of devices (S beam is actually based on the standard android beam, but is extended to tranfer faster over an ad-hoc wifi network)

Sending a file to someone shouldn’t be difficult, but at the moment you’re stuck with email, a physical drive or a cloud storage (relevant xkcd). Being able to share a file to any device without cables or 3rd party apps would be excellent.

At the moment the easiest way to transfer a file to my phone from my laptop is either Dropbox or a home server. Neither are particularly convenient - I think most android phones should have a ‘USB mode’ and can act like a pen drive, hovever my last two phones and tablet couldn’t do this (all Samsung - correlation?)

2. Cloud storage (& other web services)

So, everything’s moving towards the cloud. You can pick up a Chromebook for a few hundred dollars and cast away ties to any local filesystems. However, your data has to be in Google’s servers. Hmm. Any app that you use either needs it’s own server or use Google’s.

I would be great if basic cloud save functionality was standardised, so that you could pick the service that data is stored in, decreasing the monopoly that Google will only get a tighter grip on when (not if) Chromebooks take off. This could mean that for some app, when you sign up you just say “put my data in ACME Cloud Storage, please!” and away it went, without the app developer having to hard-code interfaces for every cloud provider on earth.

This idea could be extended to social networks and other web apps, similarly to how android handles intents - if you have a network ‘installed’, you can share information to it from any other webapp. Again without the developer having to write tedious amounts of code.

3. Instant Messaging

Similar to #2 this would mean that different services would have at least some kind of common functionality - I don’t know.. like messaging people or something - and then each provider could have more awesome features on top, but at least you wouldn’t absolutely have to have multiple services just to talk to people. Imagine if email only worked between the same host? Gmail would be the only one left (I mean, who uses anything else?)

I don’t know quite how any of this would be implemented, but that’s another problem!

Can you iMessage me? Wait I have Android. You can’t. Damn. Facetime? Nope. This isn’t just an Apple thing? send a file on Android with NFC? Oh you don’t have S beam? As phones turn into more and more powerful mini-computers they seem to be still lagging behind when it comes to compatibility. It still matters if someone has iOS, Android or Windows Phone - not every app has been written three times.

There are three awesome things that are still functionally standard across all platforms:

• SMS
• Email
• Phone calls (I know, who uses that!)

And this is what holds mobile technology together. There is no relying on a platform to come up with a solution and then change it (Twitter), because if you don’t like something you can always use a different app any of the three that fits your needs better. (Well, I presume you can on iOS – wait you can’t :’( sucks for you I guess.)

This is the main reason why I favour Android over other mobile OSs - it lets apps fully replace part of my phone, letting them completely integrate into the OS. You wouldn’t notice that I don’t use the stock camera, messaging app or launcher. They all just slide in together like a crazy jigsaw.

Now I will admit it is a bit of a pain having to set these little things up, and I understand Apple’s want to fully control how iOS works - if you download an average messaging app and can’t send texts, who do you blame? Apple.

Although, imagine that you went and bought a shiny new Surface 3 and then found out that Internet Explorer was stuck as the default browser. Every link you open INTERNET EXPLORER! Why would you do that to yourself? You masochistic freak.

Even OS X allows you to change the default browser (to Chrome), mail app (to Mailbox) and search engine (to Google). Although by the looks of Yosemite the latter may be locked to Bing.. I don’t know how I’ll manage. Seriously Apple - if you do this and don’t give me the option to change it, I will consider switching back to Ubuntu for a whole 5 minutes.

It’s my technology - I should be able to add and remove bits as I see fit. ie:

I should have superuser privileges.

Hello! I’m Will. Currently studying software engineering and generally making a nuisance of myself building random things that I think should exist.

This blog is here because it’d be nice to have a place to put stuff that I make and talk about it a bit.

I guess I’ll actually write something interesting later - time for a run now!