Always Get Better

Never stop looking for ways to improve

by Mike

Malware found in Xcode (xcode-ghost)People rely on their app stores to provide safe and high quality software for their phones and tablets. With iTunes in particular, we trust Apple’s strict review standards will raise the bar for quality and protect us from the shady apps and trojans we might find on file sharing services and third party app stores. What happens when that trust is misplaced?

A bunch of popular apps on Apple’s App store shipped with malware in September. “Popular”, of course, refers to app used by more than 500 million iPhone users primarily in China where the malware originated. Some apps, like WeChat, are also used in the west but by-and-large the affected programs are names written in hanzi most of my readers would not be able to pronounce let alone install to their devices.

What does the malware do?

First off, what can you expect to happen if your phone gets infected?

This post from MacRumours summarizes things pretty well, but the highlights are:

  • Sends device information, phone number and ID to C2 (command-and-control) servers
  • Fake system alerts phishing for passwords
  • Access clipboard (including stealing secrets from your password manager)
  • Hijack URL opening

We’re not talking about phone-takeover threat levels, which is a testament to the sandboxed environment apps run in. These functions are available to pretty much any developer — you’re not supposed to use the device ID but you can get it if you want it.

How Did Malware Get On the App Store?

The first thing that most people are asking is: how did this happen? With Apple’s notoriously stringent app review process, how did apps with this vulnerability get through?

As it turns out, developers chose to download updated versions of XCode from file sharing networks rather than directly from Apple. XCode is a huge download (larger than 3Gb) so downloading directly from Apple can take a long time. In order to save time these developers thought it would be a good idea to trust an unsigned version rather than the one from Apple.

How Did Malware Get Through the Walled Garden’s Gates?

But what about the review process? The UUID-gathering portion alone should have been enough to trigger warning flags, right?

Not so, according to people who know.

Although the App Store performs a cursory check of submitted apps for private API usage, the XCodeGhost files were added as a dynamically loaded bundle to the compiled app bundle — in other words, not subject to the code scanning… pretty sneaky.

How to Protect Yourself

How can you protect yourself when the store you rely on for your apps is poisoned?

Not much. Other than inspecting every single network connection there are not a lot of things you can do to detect this kind of activity on your device.

Installing app updates as they become available is the best thing you can do for your phone. Although an attack on this scale was made possible by the single-provider model of the App Store, it’s also true that having the App Store as the centre of the ecosystem is the best way to quickly push out fixes for problematic apps as they are discovered.

by Mike

I never buy warranties for my purchases – if someone is expensive enough it should go on your home insurance policy. If it’s cheap enough, just replace it – we live in a society of garbage anyway. Getting serviced when things break is more often than not a huge waste of time.

AppleCare is worth the cost
AppleCare is the exception to my “policy”. Like the rest of Apple’s products it comes with a premium price tag, but unlike many company warranty products, Apple actually seems to stand behind their plans – except, apparently, if your device is damaged by water, but we can talk about that another time.

Fixing a Broken Screen

A few months ago (and not long after I first got it) my phone took a fall onto the pavement and the screen shattered. Not sure why I left it so long but on a whim I loaded up the Store app and booked an appointment to be seen by a “genius” at the nearest Apple store.

An hour later I was sitting at their genius bar with my phone being seen by a blue-shirted worker. No questions asked about how it got damaged, no trying to invalidate the AppleCare plan I had on the phone. The dent in the corner was too deep to replace the screen so they replaced my phone and I was out of there in under 15 minutes.

Without the AppleCare I would have still gotten the refurbished phone, but it would have cost hundreds of dollars. It was disappointing to break my phone when it was brand new, but I’m definitely glad I sprung for the protection plan.

by Mike

Over the past year I experimented with working at a standing desk. My setup was a converted “regular” sitting desk with the computer monitor lifted on a set of rubbermaid bins. It wasn’t the most beautiful rig but the ergonomics were right and the screens were at an appropriate level for my height. Unfortunately I didn’t take any pictures of the contraption.

Motivation: Not Wanting to Die

It should come as no surprise that sitting for long periods of time is killer bad for you. When you live a generally sedentary lifestyle, any excuse to get out of your chair is a good one; so my expectation going in was that I would probably be uncomfortable from being on my feet and subtly flexing my knees all day versus sitting.

In reality it wasn’t bad at all. The first two or three days my legs were pretty sore at the end of the day and then my body got accustomed to standing. Many standing desk users suggest putting an anti-fatigue mat down; I never did nor did I find I needed it. The first week I used a few towels to pad my feet from the hard floor but after the initial adjustment I was fine on my own.

Results: More Energy

After sitting at a desk all day I noticed I was always exhausted both physically and mentally after work. I would want to eat dinner and relax on the couch with the kids, maybe watch a movie. I expected to be ready to crash and put my legs up after standing all day, but the opposite happened.

Unlike days spent sitting, when you stand you never stand perfectly still; you’re always shifting your weight from one leg to the other even if you’re not noticing it. At the end of the day I felt wired – I didn’t want to sit at all. I was more likely to go for a walk than to vegetate and zone out after working.

Results: Sharper Focus

After all this I think every company should raise their conference tables and throw away the chairs, or ditch the conference room and go for walking meetings instead. When you’re standing you naturally approach your tasks with more urgency, and have quick brilliant insights. Everything gets done faster because there is less mind-wandering.

For a programmer, this works really well if you are doing a good job at breaking your work down to manageable tasks. A single work unit can be done quickly when there are no other distractions, and standing really helped cut through all those other distractions.

Results: Shorter Attention Span

The major downside I experienced was the flip side of the sharp focus that standing brought. Long monotonous jobs, like data-entry, research, or marathon programming sessions were a lot more difficult to focus on while standing. I would start tasks with a lot of focus but lose interest and need to switch to something else or walk around. This worked well for quick multi-tasking kinds of work, but when something too longer it felt like a struggle.

Mix It Up, Do Both

The standing desk streak was broken when I did some business travel last November. I had to force myself to sit at a desk all day where no standing spaces were available. Turns out, I didn’t hate it as much as I expected.

Nowadays I have a lot of surfaces to work on and I move around throughout the day, switching between sitting and standing positions depending on what needs to be done. The next purchase might be an adjustable desk capable of moving from a sitting to standing layout throughout the day.

I would recommend everyone try working in a standing position at least once. Like me you can try it out quickly without spending a fortune on a dedicated standing desk.

by Mike

Most companies seem to have a group of people who gravitate to either front-end or back-end development. I’ve been struggling to wrap my head around this because it doesn’t seem like a useful dichotomy.

It’s a fast-moving field, do you really want to carve a niche as a Unity programmer? An ActionScript expert? A Sharepoint developer? If you specialize to that degree, what happen

s when your technology of choice moves on?

How many of these have you come across:

“Front-end” developers who don’t understand the HTTP stack.

Companies that don’t have centralized source control.

“Back-end” developers who believe front-end code should be unit and performance tested just like server code – who don’t understand why squeezing maximum performance for one user on one machine would be as challenging as constructing a web app that served thousands of users at the same time.

Web designers who don’t know HTML, CSS and jQuery.

Anyone who takes a laissez-faire approach to security.

Project groups that don’t use Continuous Integration.

Understand More

Everyone has an area of interest where they excel and you should definitely pursue yours. Never forget that yours is a piece of the whole, and the more you understand of the whole the better you will be able to create value with your work.

If Photoshop is your bread and butter, learn how programmers slice your designs into HTML. Understand the technical limitations and get inspired by what the web browser can do for you.

If you’ve been slinging awesome responsive webpages, use your JavaScript skills to learn Node.js and understand where that server data is coming from and how it is stored. Expand your ability to write front-ends that scale as beautifully as they present.

If you are more comfortable in the bowels of a Linux server, download Cocos2d-x and experience the thrill your front-end counterparts get when their math turns into gorgeous sprites on-screen.

Everybody’s Talking

Every time you learn something new you open up a world of people you can network with and understand at some level.

Whenever someone asks how to get into the field, what do you answer? “Just do it!”

by Mike

Like it or not your clients want mobile and if you are a developer without experience in this realm you are behind the curve.

Having been mobile-centric for the past three years of my professional life, I have heard all of the different lines of thought around toolsets and approaches for creating software targeting these devices. Moreover, I’ve lived through a lot of those toolsets and approaches, and have spent time thinking about which worked well and which ones, well… sucked.

It all boils down to this:

Build native apps using the tools and languages provided by your platform.

Yes, this is the same position I held when I wrote about this almost two years ago, but I stand by it. I’ve had a chance to play and build with the likes of Adobe Air, PhoneGap/Cordova, SenchaTouch and Xamarin, but I always end up going back to Java (Android) or Objective-C (iOS) because…

Cross-Platform Isn’t Good for Anybody

Your app is iOS only… are your installed customers complaining about it not being on Android? No! Why would they care?

When talking about a new project one of the first things to come up is the idea of using X tool so we can build to a lot of platforms after writing the code once. I guess the thinking behind this is somewhere along the lines of “if we make our product available to more people, then it follows that more people will obtain it and we will make more money”. I don’t buy this.

Look at it this way – you’re up against a million apps. What sets you apart? How do you communicate that to all of your potential customers? Are downloads from the Windows Store equivalent to downloads from Google Play? Do they use their phones in the same way and monetize the same way? Are the demographics the same?

If everyone was the same, it would still be a bad idea to build your app around a cross-platform framework. Invariably these work in a lowest-common-denominator fashion meaning you get universal support by trading off native features. Yes, your app runs the same on all the platforms, but Android users are accustomed to navigating using their back button, which iPads don’t have. Instead of providing beautiful context-sensitive navigation using activities for Android and NavigationController hierarchies for iOS, you get uniform views.

“Universal” is a Lie

Okay, so most development kits come with a way to plug in your own native code for the device-specific goodness (better GPS, camera gestures, whatever). Now you’re writing native code anyway, and you’re on the hook to support all those platforms. So why would you want to go through the pain of hooking all that into a cross-platform tool instead of going directly to your platform in the first place.

Worse, your universal framework has bugs. I’m sure it’s great software but all software has bugs. When you hit a bug that stops you from moving forward, what are you going to do? When the underlying operating system software changes and your framework hasn’t been updated yet, are you not going to deploy until the author gets around to supporting the new requirements? When you choose a cross platform tool you are choosing someone else’s opinions and priorities and ceding control of your own product.

My recommendation is to pick a release target and excel at it. Will it be in the Apple ecosystem? If so, don’t be afraid to go all in. Learn how iPhone users are going to interact with your software and do everything you can to speak to them, please them, and turn them into paying customers. They don’t want a great Android experience, they want software they don’t even think about. They won’t patiently deal with your buggy software because you were so afraid of missing out on customers that you greedily deployed a boring app just to support some other platform. The “smaller” number of users is still a lot of users!

I get the fear factor, but the cross-platform tools are designed to make life easier for developers, not customers. The developer isn’t buying my product – I don’t care so much if he’s worried about synchronizing features in a future Android port of the app.

Speed is King

I want my app to load fast and I don’t want to wait around for it. You can’t get more performance than a well-written app build from native languages and tools. Don’t be afraid of XCode, Visual Studio and IntelliJ – embrace them and enjoy the barebones software you can build with them.

Thinking in New Paradigms

Suppose you do want to put your app on two different kinds of devices. Now you need to maintain your program logic in two programming languages, adding new features and squashing bugs in both places. That’s not really such a bad thing.

What if you have an ENORMOUS code base with hundreds of thousands of lines of code – how will you ever keep that synchronized between two development tracks? Well, you might a good candidate to actually use one of those cross-platform tools. Or you might be asking yourself if your work load is really appropriate for a mobile experience (something they won’t tell you — not every app belongs on a mobile device).

Apps don’t need to behave the same on different device formats. Every modern operating system has a different focus and enormous capability list that becomes adopted by its users – so evaluate what it is really like to use your app on each device. Especially for UI stuff – do you need backward navigation on Android when there is a hardware button for that? What buttons can you eliminate on iOS in favour of multi-touch gestures?

In the past 5 years I’ve added Java, Scala, Ruby, JavaScript (specifically, Node.js-style callbacks), Objective-C and lately Swift to the list of languages I’ve used extensively and thought deeply about. Each one has challenged me to look at programming differently and apply new practices to older thought patterns. Working withing multiple native environments is not a hindrance, it’s a huge boost to the quality of software you can create.

Streamlined Learning

When you use a cross-platform tool, you have an extra learning curve – that of the tool itself. I don’t buy into the thought that it improves your productivity, but I definitely see where it decreases your productivity. You need to be aware of bugs in your tool (as we mentioned earlier, your tool is great but it’s still software and software has bugs), you need to be aware of the capabilities of your tool including all the new features they add (which, by the way, just expose native features you should have been working with directly all along).

If you can avoid it, skip the cross-platform stuff and go right to your actual platform.

Putting it all together

As a programmer your job is not about writing code, it’s about connecting businesses with their objectives. A good technologist doesn’t get caught up in ideology over which approach they ought to take to build software – they decide which implementation detail will get them to their goal. So if a cross platform tool makes sense for your project, use it. Just be sure that you’re picking the right tool, and not the comfortable (for now) one

by Mike

This is a common situation: I needed to compare two strings with unknown capitalization – “country” versus “Country”. Since these words should be considered equal even though the second “Country” has a capital “C”, we can’t do a straight comparison on the two – we need to do a case-insensitive comparison.

Option 1: strcasecmp
Whenever possible developers should try to use built-in functions which are compiled code and (in general) run much faster than anything you could write. PHP has strcasecmp to case-insentively compare two strings. Sounds like a perfect match!

if ( strcasecmp('country','Country') != 0 ) {
// We have a match!

Option 2: strtolower
Always read the documentation, but draw your own conclusions. One commentator in the PHP documentation suggested developers never use strcasecmp, and use strtolower with regular equality like this:

if ( strtolower('country') === strtolower('Country') ) {
// We have a match

Test the Speed
Both methods accomplish the same thing, but do we really want to skip using strcasecmp()? Which is the better option?
I wrote this short script to run each option for 10 seconds and see which is faster:

And the results:

strtolower: Done 18440869 cycles in 10 seconds
strcasecmp: Done 22187773 cycles in 10 seconds

So strcasecmp has the edge speed-wise, but not so huge that I would care to favour one over the other.

Apparantly strcasecmp does not support multi-byte (e.g. Unicode) characters, but I haven’t tested this. Presumably that would give strtolower an advantage over projects dealing with non-English input, however that is not the case at all in my particular use case so I did not explore this avenue any further. I also didn’t try against non-ascii characters, such as latin accents; including those would be an improvement on this test.

by Mike

Glen Canyon Bridge & Dam, Page, ArizonaI continue to have an on and off relationship with Twitter. It’s been fun to talk with other developers and reach people directly, but a huge part of the network is sorting through the signal-to-noise echo chamber. It doesn’t make sense to sit on Twitter all day trying to respond to everything; work needs to be done too!

Then there’s my reading. I read a lot. And I run into all kinds of cool stuff I want to share, and Twitter is the most natural place to share it, but of course that always ends up with Saturdays where I dump four dozen links in the span of a few hours… I hate it when other people do that, so rather than spamming everyone who follows me I’ve pretty much stopped sharing.

Until now.

Buffer to Spread Around the Outbursts
I found an app called Buffer ( that sits in front of your twitter account and collects your tweets into a “buffer”, then sends them out on a schedule. So you can have a backlog of messages filter out slowly over a day instead of shoving them all out at once.

So my workflow with Twitter now is to monitor it (using Growl, of course) and have conversations where I can. I’ve met some incredible people using Twitter and made more than a few fun connections, and hope to keep building that over time. Whenever I read something interesting I’ll drop it into Buffer, and anyone who is interested can see those links without getting spammed all at once. I think it’s win-win.

Present in More Time Zones
At first night times were lonely when I came out west, since 9pm for me is midnight for friends back home, it got pretty quiet fast. I’ve since made more friends on the west coast, but I came away with a fresh appreciation of how easy it is to get disconnected from our core tribes because of time zones.

Since I started using Buffer I’ve noticed more activity from my contacts in Europe and Australia. Of course I’m asleep when Buffer sends out one of my stored tweets at 3am, but sometimes it’s sparked conversations I’m able to pick up when I wake up in the morning. Although there is a high latency in those communications, I feel more connected than ever to some old friends who I might not have otherwise interacted with so frequently.

In the End, Connections Matter Most
The strongest takeaway theme that seems to be cropping up again and again lately has been the difference between technology and communication. It’s very easy, especially coming from a technical background, to fall in love with a design, a language, a piece of software. The magic comes from the conversations that get enabled by these advances. There’s no reason to put up a web site or build an application if it doesn’t solve some problem – if we build something for the sake of doing it, are we building something that will last?