A lot has been made in the Australian media about the cost of the NBN. The Liberal party wants to implement a cheaper solution – albeit one that is less future proofed, and may end up costing more when all is said and done (in the way a clunker is cheaper to buy initially). Actually, NBN Co isn’t actually spending taxpayer money on goods (like what happens when the country buys a fighter jet), but is instead borrowing money using Australia’s credit rating that it intends to pay back in full, with profit (typical of a business). But lets ignore the differentiation between buying goods and investing in money-generating businesses for a moment, and look at just the money being outlaid today. The NBN is projected to cost $37.4 billion1.
The government has raised $48.1 billion dollars to date from the sale of 89.1% of Telstra2. It still holds a 10.9% stake valued at $6.6 billion3. That’s $54.6 billion in total value to the government from the capital sale of Telstra.
From the money made from the sale of Telstra, the government can build one and a half NBNs. The good news is we only need one.
So let me ask: is it reasonable to invest two thirds of the money raised in selling last century’s telecommunications network to build this century’s? An investment, that is projected to pay itself back several times over, both through direct revenue and indirectly through taxation on economic growth that it will facilitate.
Plus, maybe we can sell it off in a hundred years and raise money for the next network. Why again do the Liberals want to build a FTTN clunker?
For the last year Geospike has been using jtv-apns, itself a fork of apns. Our needs have grown, and today I announce our own fork of the APNS gem, name ‘gs-apns’.
The gs-apng gem continues the good work of James Pozdena and Paul Gebheim with some key enhancements including automatic message truncation, correct UTF-8 handling, rails-independent JSON encoding, full 256 byte message support, more failsafes and logging.
As my brother succinctly put it “iOS likes to crash”. One such crash that can easily happen when you use background tasks is for your app to be killed for running the background task longer than the allotted time (generally 10 minutes).
The standard practice for avoiding this issue is to end the task you started with beginBackgroundTaskWithExpirationHandler in the expiration handler block of the same call. That works well, but there’s one catch. The UIBackgroundTaskIdentifier isn’t passed into that block, so you need to pass it through yourself. But what if some code modifies the variable you passed-in erroneously? If you are using a local variable, this isn’t a problem1 – but if your background task extends beyond one method it’s common to use a member variable, which could be accidentally modified.
And therein lies the danger. What if, despite all your very careful checking, that variable is modified. Now your failsafe won’t work correctly, and the app will crash. What’s worse, is it will crash in a totally random place. The crash logs give a very specific reason “App has active assertions beyond permitted time”, but don’t tell you exactly which LOC created the background task.
Here’s a better pattern. A safer failsafe if you will. Always declare the UIBackgroundTaskIdentifier as a local variable. End the task in the expiration handler using that local variable. After the task is created, set your member variable to equal the local variable for any additional additional processing (such ending the task naturally when it completes). Now the expiration handler is guaranteed to end the correct task, regardless of what else happens.
This pattern generates a bit of boilerplate code, and lets face it the more you copy and paste the less maintainable things get, and the more chance there is for error. So I’ve wrapped up this pattern into a simple utility class. The method is beginBackgroundTaskWithSafeExpirationHandler and it is designed to never crash with “active assertions beyond permitted time” no matter what you do. You can download the code from the gist.
Heads up: how Rails handles unicode in JSON has changed in rails 3.2.13 and 4.0.
Previously unicode characters would be encoded with \u1234 notation. This encoding was actually a bit buggy, anything over two bytes (e.g. outside the Basic Multilingual Plane) would not render correctly1. With 3.2.13 and 4.0, Rails now just passes through UTF-8. That’s legal under the JSON spec2.
Does this change matter? Probably not, unless you interface with a buggy JSON parser that doesn’t support UTF-8. Also, if you’re using .length to get the bytesize of a JSON message you will now need to use .bytesize instead (previously length would have been equivalent, as it was an ASCII string).
If you need to get the old ascii encoding back, good news, you can! Replace your use of object.to_json with JSON.generate(object, :ascii_only => true). E.g.:
object = {:unicode => "I \u{1F49B} you"}
JSON.generate(object, :ascii_only => true)
=> "{"unicode":"I \\ud83d\\udc9b you"}"
Not only does this encode the unicode characters, it does it correctly even for the extended characters which the old Rails 3.2.12 to_json did not. Awesome!
This is useful for the odd time you have a service that can’t handle UTF-8 encoded JSON. But what if you don’t have control over the code that calls to_json?
"\u{1F49B}".to_json on an old install if you dont’ believe me (.should == "\ud83d\udc9b"). [↩]This month the original iPad would have turned 3. That is, if it were not killed off with the release of iOS 6.
Developers typically don’t support old OS versions very long (it gets increasingly expensive). In the case of iOS 6 though, developers were forced to drop support for the iPad (original) and 3GS in order to support the iPhone5, even if they still supported iOS 5 and wanted to support those devices.1.
Furthermore, due to the way the App Store works, the latest functional version for a particular device isn’t preserved, so the moment you update the app, those users are left high and dry.
This gave the original iPad an effective lifespan of 2.5 years. Less if you didn’t buy it on launch day (who did? they were hard to get). An iPad you bought at launch would today be a few weeks over 3 years old, no spring chicken for tech but generally at that age a laptop would still be functioning fine, and would most likely still be able to run the latest OS. There is an interesting attitude in the community, take this Tech Crunch article.
This feature only works on iPad 2, 3, 4 and iPad mini, iPod Touch 5th gen., and iPhone 4S and 5 – so, nearly everything but your kid’s old hand-me down iPad, and dad’s iPhone 3GS which he thinks still works just fine, thank you very much.
Now I know they’re intentionally being cheeky, but such statements re-inforce this throw-away attitude. Here’s the thing I want to know: why should your “kid’s old hand-me-down” iPad not be able to have software written for it? Or at least, why can’t it download and run software that was written for it two years ago?
Two easy ways to solve this, one is to simply support the device for longer. Microsoft has taken good steps in this direction by guaranteeing Surface support for 4+ years2 3. The second is to allow apps to post their “last working version” for an orphaned device and leave it up there as a YMMV deal.
In the Mac OS X world, the latter is how app developers work. They typically only support the most recent two OSs, or even just the latest – but if you click through, you can get downloads going all the way back. They have simply archived the final working version for that old OS and left it up there. So the 5 year old Mac you have can still download and run the same software it could 5 years ago, whereas your 3-year-old iPad cannot download the same software it could 3 years ago except if that software had not been updated.
The worst thing about these versions not being available any more is that devices like the 3G, 3GS and iPad original had some fantastic software available when they were released. Remember: at the time they were the leading devices in their class. That same software would work today on those devices, except it is no longer available. So the vintage iPad you take lovingly out of it’s mint-condition box today simply isn’t the same one from three years ago. As a techie, that makes me sad, after all my original GameBoy is still going strong! And I can still buy new (for me at least) software for it.
If the iPad is a PC killer, it is certainly one with a short lifespan.
Something a lot of people forget when designing newsletters or email marketing campaigns is that after the subject, the first line of text is the most important. That’s because, email clients like GMail and iOS Mail will display the first line of text right under the subject.
So you don’t want your email to read: “News Update from XYZ Widgets – [ Unsubscribe | Web Version ]” when it could read “News Update from XYZ Widgets – the new widget everyone is talking about”.
Simple solution: update your HTML template, and put a small 1-sentence summary of the topic at the top.
Here’s the before & after for Geospike:
For a long time I’ve yearned for a well presented Unicode table that gave simple ways to look up all the great glyphs that I need in Unicode ☄. If I wasn’t so busy I probably would have written my own ✈.
Well I’m pleased to say someone has created this and done a fine job of it too, unicode-table.com. You can search, view a beautiful large version of glyph, get unicode numbers and HTML codes. It’s also arranged in a geek-friendly bit-table. What more could you ask for? ❄☃
iOS support would be nice I guess – though at least it’s still usable (and works with the iOS clipboard ១ – no mean feat).
Booking Train Tickets in China has always been pretty decent: there are a bunch of official ticket agents around suburbs and towns, changing ¥5 per ticket as a fee but allowing you to book from the clamness of your own street instead of the crazyness in the station.
Recently it got even better. You can now see availability online, and book tickets at www.12306.cn (if you can read Chinese and have a Chinese credit card, or a friend who can help). Tickets booked in this way can be collected at the ticket agents (for the same ¥5 fee), or at the station (for free). They can also be refunded online, until you collect them (after which you can refund them in the usual way).
This is an issue I am having when trying to use a custom buildpack with Heroku. The intent of the buildpack is to update the version of ImageMagick on the heroku dyno which is over 2 years old.
I love the idea of bitcoin. Well, I love the idea of a crypto currency with zero transaction fees, and no government intervention. But the problem I see with Bitcoin is demand.
Like fiat money, Bitcoins are another “make believe” money that has value only because we say it does. Many argue it is superior to government issued fiat money as the its money supply is deterministic and slows in growth over time (rather than at the whims of the government of the day). Read more…