Chatswood

The brouhaha over third-party Twitter clients continues with the news of the release of a beta version of Tweetbot for Mac. Just 4 days ago the alpha version was withdrawn with Tapbots citing as a reason the "finite limit on the number of user tokens we can get for Tweetbot for Mac".

This was a fair move by the developers - any Mac user could download the alpha, sign in and obtain a limited Tweetbot for Mac token. If they subsequently decided they were not interested in buying the application they can discard it without releasing the token they use. It was a problem with only one resolution - withdraw the app and preserve the tokens.

Today Tapbots came back with a beta version and some new rules:

new users can install the beta but they'll not be able to add a Twitter account;

users of the alpha version can use the same Twitter account they used before;

users of the alpha version cannot add extra Twitter accounts;

users of the alpha who revoke their access token on the Twitter site cannot add their account again.

All of this makes perfect sense from the point of view of token preservation. Unfortunately in this post-announcement landscape these once common items are now a scarce resource. They've become the fossil fuels of the technology world, and like fossil fuels they're limited and easily wasted. They used to be very disposable - a quick look at my Apps section on twitter.com lists 34 tokens on one account alone, and that's after a prune earlier this week.

Efficient Token Usage

Like many people I have a number of Twitter accounts, and on each of my clients I like to have all of my accounts signed in. This was never a problem before but now it just exacerbates the issues faced by app developers. They have a limited number of access tokens that can be used with their apps and users like me with multiple accounts end up using more tokens than other people.

To make an app commercially viable developers need to squeeze as much money per token as possible. One way to do this would be to increase the cost of their apps to cover the average number of accounts per user. Alternatively they could keep the initial purchase price the same while limiting the number of accounts that can be signed in through the app. Power users could then be offered the option to use in-app purchases to effectively buy extra access tokens.

During a recent episode of Hypercritical, host John Siracusa mentioned that he had received feedback from readers of his OS X Mountain Lion review commenting about the failings of full screen mode in Mountain Lion (and previously in Lion), particularly with respect to multiple monitor support.

I see where these comments have come from and have sympathy. When I first installed Lion I was eager to get stuck into this new world of full screen apps. Pressing the little button on the title bar unleashed a magical zoom animation. Some apps just stretched the existing interface, but others (such as iPhoto) changed their interface to better suit the full screen experience. It was very exciting for about 5 minutes, but it wasn't long before I shared the frustrations aired by Siracusa and his readers:

No, I wanna use the other screens, I wanna put stuff there, I wanna see my other windows there, I wanna see my web browser there, my Twitter feed there - whatever the heck I have over there. And you can put palettes and stuff from the application that you made go full screen, you can put them on the other screens but you can't use them for other applications. It was like, it was almost like it was being mean to you, it's like "I know you want to see your Twitter client, but I'm putting linen over that whole screen - nah!" and that pissed people off.

I admit that I was that reader initially and I found the lack of flexibility when using multiple displays was exceptionally frustrating. The app running in full screen mode would take over the primary display but the secondary display would only contain that boring linen background. Yes, it was possible to place extra palettes or inspectors on the secondary display but there didn't seem to be any way to truly take advantage of the additional real estate.

It sure would have been nice if users could have placed two independent apps side-by-side. Or if developers could have created UI layouts that took advantage of full screen mode with multiple displays, akin to the way full screen editing was available in many previous versions of Aperture. John, being the sensible guy that he is, tried to reason it out, and I think he almost nailed it1 when he said that full screen is for people who need to concentrate.

One use case I think he glossed over though is the fact that full screen is also for people who are working on portable machines. People who are working on one (possible small) screen and need to squeeze every last pixel out of their displays. It's not for the power user who wants to work with multiple apps at once (or with a multitude of windows/palettes/inspectors from a single app). That's what regular OS X is for and has been all along.

Recently I've been experimenting with text-editor-du-jour Sublime Text 2 in parallel with coming late to the Rails party. Sublime Text 2 has a great plugin ecosystem that seems to be growing by the day and one plugin (or package in ST2 parlance) that I find indispensible is SublimeLinter.

As a developer I've always written code in an iterative fashion - write a couple of lines, compile, edit those lines to fix the bugs, compile, write a few more lines, and so on. In my career this has occasionally been problematic, as I've sometimes had to work with unwieldy and inefficient make-based build systems that unnecessarily rebuilt large swathes of code instead of a single source file. In recent years I've been spoilt by some excellent IDEs (such as Eclipse/STS and Xcode) that have been kind enough to alert me to syntactical errors before I invest time in a build.

While playing with Rails I found that I was regularly coming across syntactical errors only when it came to testing out the application. It wasn't the horrible build systems of yore, but it wasn't exactly the convenience of a nice IDE. So I hunted around for a linter that I could integrate with ST2 and quickly came across SublimeLinter. A couple of seconds later (thanks to the ridiculously useful Package Control) and I had it up and running and I was getting lots of notifications about errors in my Ruby code.

Unfortunately I soon realised that I was getting too many errors, to the extent that I was getting errors on perfectly valid code. The code ran fine in my Rails app, but still SublimeLinter was bitching and moaning about it. I had a look around the SublimeLinter documentation, and noticed that they recommended using the full path to the ruby executable if using a Ruby interpreter provided by rvm. On OS X this comes down to the fact that the default Ruby is 1.8.7 whereas most people will be using code written against Ruby 1.9.X, which they've usually installed themselves.

Thankfully SublimeLinter makes it easy to customise the Ruby interpreter to use, so if you're having trouble with syntax errors in your Ruby code, just chose the menu item Sublime Text 2 -> Preferences -> Package Settings -> SublimeLinter -> Settings - User. This will open up the user preferences file for SublimeLinter and you can enter the following snippet (substituting in your own username of course, and remembering to merge the JSON with any settings you may already have in there):

{ "sublimelinter_executable_map": { "ruby": "/Users/username/.rvm/rubies/default/bin/ruby" } }

I'm stuck between a rock and a hard place. I have a beautiful home of timber frame construction where every internal wall is a stud wall. What this really means is that every wall is a candidate for being stuffed full of cables. My biggest home-improvement desire is to get every room wired with Gigabit Ethernet, but if possible I'd like to get every type of cable under the sun in there. If it's possible to generate enough heat from those cables to remove the need for central heating then I'll consider that to be a bonus.

The problem is that all those lovely wall cavities are hiding behind plasterboard that my wife does not want me to remove. I'm convinced that I could do it in a surgical manner - in and out with minimal disruption and a nice new shiny coat of paint in every room. She's convinced that I'll leave gaping holes running down the walls that never get patched up, and that the painting won't get beyond the colour-picking stage. She's probably right.

Enter stage left: 802.11n WiFi

With the right hardware 802.11n WiFi could very easily have been the answer to my (or my wife's) prayers. The theoretical maximum is 600Mb/s - it's not quite Gigabit Ethernet, but is still capable of delivering a large amount of data quickly. Theoretically. With the right hardware.

At the minute I only have one weak spot in the home network - the link between a Gigabit network upstairs and a Gigabit network downstairs in the office. I invested in the latest Apple Airport Extreme base station that I paired up with a 2nd generation Time Capsule. The Airport Extreme was configured to establish a 5GHz 802.11n network using the wide-band settings.

I had hoped to see a pretty fast link between the two base stations, but unfortunately the data rate reported by the Extreme was just 180Mb/s. Testing the network for "real-world" performance resulted in just 93.43Mb/s (using zPerf as a test tool). This isn't a bad speed, but I do tend to fling a large amount of data around the network. It also gets extremely frustrating to be limited to Fast Ethernet speeds when I know there's a Gigabit network up there just waiting to be saturated.

Enter stage right: powerline networking adapters

I'd considered powerline adapters in the past, but had always balked at the relatively low speeds they offered. Having discovered just how poor the WiFi connection was I decided that the newer 500Mb/s models might be worth a blast - even at 50% of the theoretical maximum I could still get 2.5 times the performance of the WiFi link. When an offer for Maplin powerline network adapters came up they were hastily purchased. Once received I got to testing, and the results were extremely disappointing.

I know that the 500Mb/s is an ideal scenario and many things will conspire to reduce this figure in the real world. Old wiring, interference from other devices and use of extension cables amongst other factors. Our home is fairly modern, and has wiring that is only 8 years old. I tried to improve things by avoiding extension cables, and plugging directly into the mains sockets at both ends, but to no avail. The best rate I could get was a paltry 53.21Mb/s. WiFi it is then.

Not wanting to return the product without trying to find a use for it, I decided to try using the powerline adapters to connect my ADSL modem/router from downstairs to the upstairs network. We only get 5.5-6Mb/s from our ADSL connection so 50+Mb/s is plenty of bandwidth. Unfortunately since doing so, I noticed regular breaks in the connection from the home network to the ADSL router.

App.net is a hot topic of conversation at the minute in the intersection between the Twitter and Apple worlds that I like to inhabit1. Just over a month ago, Dalton Caldwell wrote a blog post entitled "What Twitter Could Have Been". While this initial post could be viewed as a bit of a complaint or a moan, it was also something of a catalyst. He soon followed up with a post that may go down in Internet history: "Announcing an Audacious Proposal".

In this post Dalton essentially proposed building a new Twitter. A Twitter that was funded directly by the users instead of by the advertisers. He and his company established a KickStarter-style campaign to raise $500k by 13th August in order to fund this new social network. As of the time of writing, there are just under two days remaining, and there is only $69,200 left to be raised.

I've decided to back this project because, like Dalton, I'm concerned about what I perceive as a "degradation" of Twitter. It's not a degradation for many people - in fact Twitter is probably going from strength to strength in the eyes of many of it's users. But I'm an atypical user. I'm not on Twitter to follow celebrities, to track mainstream news, or to keep up with my friends. I'm mainly on Twitter to receive tech news, to use innovative apps, and to communicate with other people in the tech industry - the industry that is both my livelihood and my passion.

For me, Twitter is degrading. For me, it is becoming less vital, and is in danger of becoming unusable to me. I may be over-reacting, but Twitter's recent rumblings about third-party clients has not inspired confidence. I use TweetBot for iOS (and now for Mac) fanatically. I don't want to go back to Twitter's first-party clients, partly because Twitter are not putting in the effort to maintain them, and partly because I don't want to use apps that are really just conduits to the advertising model that will become essential to Twitter's survival. Like many others, I would be happy to pay for access to Twitter, but we're not being offered this opportunity.

So Why App.net?

I don't know if App.net can work but I'm happy to put my money where my mouth is, and give it a chance to succeed.

I'm keen to join a social network at the beginning and help it grow. I joined Twitter in 2009 and while I've enjoyed my time on it, I sometimes feel like I missed the halcyon days when it was a closer, more tight-knit community.

I'm happy to pay to be part of a smaller community with a more focussed group of users. Part of the problem with Twitter is that there is no barrier to entry. Yes, this is me being a little bit elitist but I feel that it is a valid point. Every day on Twitter I am being subjected to random followers who have no interest in what I have to say. I hope that the App.net community will be more focussed and less likely to resort to such behaviour. I'm also hoping that the App.net ecosystem will be subject to more moderation - where "spam followers" can be reported and ultimately warned and/or banned.

I'm hoping that the requirement to pay a fee will weed out a large number of the people who try to use Twitter as a conduit to spam. Twitter is like email, in that there is very little barrier to entry to start spamming. It's effectively free to send emails or tweets as spam if you can cover your tracks. Twitter spam is a huge problem in my eyes. I'm subjected to daily @reply spam. I'm hoping that the requirement to pay for the service will reduce the number of spammers who will target App.net, or at the very least make it easier to track and remove these spammers.

I'm interested in a service that transcends Twitter and, because it is paid for by the users, will listen to those users in implementing the features that they need, or want. If done right, it will be directed by the needs of the people who use the service, not the people who wish to sell advertising on the service.

Huge Responsibilities

App.net is an ambitious venture. Just getting to $500k does not guarantee any level of success. And while the developer community, or the hacker community, or the whatever-we-are community can drive the success of many things, even we can't make it succeed through goodwill alone. The threshold may be met, but unless we embrace the resulting service, building the apps, tools, and sites to make it succeed, then it will be doomed to failure.

We're also putting a lot of faith in the ability of Dalton Caldwell and his team. The fact that funding comes directly from the users means a lot, but this is still not some kind of democracy where every paying customer gets a vote. We're not shareholders. We don't belong to a board of directors. We are putting our hard-earned cash on the line, and trusting App.net to make the right decisions, to implement the necessary features, and to implement them on time.

So let's all pull together. App.net who will build the infrastructure. The developers who will build applications to use the infrastructure. And finally the community who will use the applications. We all have a responsibility for the success or failure of this venture.

Mountain Lion has been running really well on almost all the machines I've installed it to, with just one exception - my (employer's) 17" MacBook Pro. This is unfortunate, as it's the machine that I spend the most time on - if it's not running smoothly I feel the "pain" all day, every day.

Specifically I was experiencing severe cursor lag when using the mouse (or trackpad) on an intermittent basis. It wasn't caused by any one application that I could isolate, but some apps did seem to trigger it more frequently. I couldn't see anything under Activity Monitor to indicate what the problem could be - there were no CPU or I/O spikes. I resolved to just sit it out waiting for the inevitable 10.8.1.

Then I experienced a bout of constant lag. At first it seemed like a curse, but I realised that I had a recently booted system with few applications running - this is as close as I get to laboratory conditions. A quick glance at the process list showed that only one was running a little high - Dropbox1. It was only consuming 17% of a single core, but it still seemed a little high. When I finally got the cursor under control I was able to quit Dropbox and the lag ceased immediately. I'm guessing it might have been something to do with the methods by which Dropbox monitors the filesystem for changes.

A quick inspection of the Account pane under the Dropbox preferences revealed that I was still running the 1.4.7 version, rather than the Mountain Lion-compatible 1.4.12. This wasn't all sloppiness on my part - as usual Dropbox have said that the clients should auto-update, but, also as usual, Dropbox's auto-update facility is woefully behind the time.

All good fables need a moral, so here goes: "If your Dropbox client hasn't updated itself, then you might want to do so manually."

Earlier today I was unable to find one of my IMAP folders. I immediately felt a flush of panic as this folder was entitled Archive, and is where I keep a large number of important emails (site registration details, software license keys, etc). I have a backup, of course, but it's still a little bit alarming to think that a folder has just disappeared.

The panic was short-lived as I soon noticed that under MAILBOXES section in Mail.app a new meta-folder had appeared called Archive containing sub-directories for iCloud and my IMAP server. All my important archive material was present and correct. I'd recently upgraded from Lion to Mountain Lion, and I assumed that this was a new feature.

As any good Mac nerd would do, I quickly tweeted about it, and then sent a message to John Siracusa as a little extra info following his monster Mountain Lion review. I was surprised when he retweeted it, but as can expected when retweeted to 24,000 people, I soon got a few replies.

A number of people have suggested that this is not new, and was present in Lion as well. I can't speak for other people, but I know that across 4 machines running every version of Lion (from 10.7.0 to 10.7.4) I did not once see this behaviour. I was able to reboot into a Lion installation and view the same setup and saw the previous behaviour.

Viewing the same setup in Mountain Lion looks like this:

Maybe this did appear in some form in Lion, but definitely not for my particular setup. I'm still calling it a new feature, even if it's only new for my specific set of conditions.

I was having a few PHP problems post-Mountain Lion upgrade. Specifically I couldn't get any sites working that utilised mcrypt with PHP.

Executing php at the command line told me the following:

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/Cellar/php53-mcrypt/5.3.13/mcrypt.so' - dlopen(/usr/local/Cellar/php53-mcrypt/5.3.13/mcrypt.so, 9): Library not loaded: /usr/lib/libltdl.7.dylib Referenced from: /usr/local/Cellar/php53-mcrypt/5.3.13/mcrypt.so Reason: image not found in Unknown on line 0

Oliver Drobnik over at Cocoanetics wrote a very detailed guide on how to get by without the Xcode Command Line Tools package, and how to remove them if you want to save a bit of space. He makes some compelling arguments as to why you don't need them around (tl;dr - they all live inside the Xcode.app package and you can access most of them using the xcrun command) but he also missed a very good reason to keep them installed on your system. While Oliver did point out that the tools are needed for "compiling stuff outside of Xcode… [y]ou know, bare knuckles, command line geekery", this completely neglects an extremely useful source of software that you don't need to engage your bare knuckles to take advantage of.

The Homebrew package management system provides third-party UNIX tools to supplement or replace those tools provided by Apple. There is a huge list of available software ranging from simple tools like wget to complex software like MySQL. For example, if you wanted to install an up-to-date version of bash you just type: brew install bash

Homebrew will consult it's formula for brewing bash, fetch the source archives, fetch any patches required, compile and install to /usr/local. Oh, and it'll also download and compile any dependencies you might need. Considering it has to compile the software you ask it to install, one key toolchain in this system is the Xcode Command Line Tools - without these installed Homebrew won't be able to compile the code it downloads.

I'm fed up with receiving spam. I generally don't get much of it because I tend not to publish my email address in too many places, and I use unique email addresses with every online store or service that I sign up to. This allows me to shut down an address when it starts receiving spam.

The other advantage of this system is that it allows me to see at a glance where the email address was obtained from. I can then take the appropriate action and inform the source that spam is being sent to an address that I trusted only with them. I wrote about this at length a few weeks ago when Last.fm and LinkedIn had their subscriber databases compromised. My biggest complaint with these companies and services is not the lack of security, it's the lack of responsiveness.

I've been getting a bunch more spam this week to an email address that I used exclusively to sign in to the Boss US website (which was annoying in itself because I only wanted to download a product manual and had to hand over personal details to do so). I contacted Boss (and indirectly their parent company Roland) almost 2 months ago when the first spam arrived and received the following response:

Hello Maurice,

We have forwarded your email to our webmaster for them to investigate this.

Sincerely, Roland US Product Support

It seemed like a positive reaction, but unfortunately that was the last I heard. I've given them a chance but they've not taken the opportunity to visibly react. So now I've decided to name and shame Boss/Roland US.

…but I totally told you so.

Just before the 28th of May I emailed Last.fm support to complain about the volume of spam I was getting to an email address that I use solely with their service.1 The spam had been happening for a couple of weeks, but I'd been a tiny bit lazy about getting my complaint in.

I got an email back from their support department saying:

"We are investigating this matter urgently, running a security audit, and looking at alternative ways the spamming of Last.fm users might have occurred."

This was a positive statement, yet also seemed like they were attempting to deflect responsibility. Their customers were complaining, but they didn't believe it was their fault, and thought they could find some other source for the spam.

Interestingly the spam I was receiving was identical to that coming to my LinkedIn email account (another unique address, of course). In fact, it wasn't just identical, sometimes the spam would contain both my Last.fm and LinkedIn email addresses in the To: field.

LinkedIn subsequently confirmed that a security breach had taken place and that the passwords of a subset of their users had been posted to the Internet. Considering the spam I was getting to my email account, this was not shocking news to me. The fact that I was getting similar spam to my Last.fm email address prompted me to speculate that a similar security breach had taken place there.

Last.fm have since confirmed this breach and responsibly have warned their users to change their passwords. I applaud them for that, as many companies I contact with similar warnings never own up to the breaches that have obviously occurred. What rankles me is the fact that their immediate reaction was to deflect responsibility (by trying to find alternative sources of spam), and that they took a long period in which to do so. I reported my spam problem before the 28th May, and there were postings on their forums as early as 16th May2 to which their own product chief responded saying that they would investigate.

These kind of delays just are not acceptable. The online world runs at a tremendously fast pace. There is no room for 2-3 week investigations - they should be taking place within days. The default response should be to assume the worst, warn users, and re-invigorate security before concluding a breach occurred, and not after. The response should not be to look for ways to deflect the problem before taking action.

The beauty of running your own domain is you can create as many email addresses as you like. I use this ability to create a unique address for every service I sign up to. This allows me to track where spam originates, and to block future mail sent to those addresses. Maybe a topic for a future blog post? ↩︎

It's always "fun" to compare the performance of machines across product lines and generations. I decided to run Geekbench across two machines that I use a fair bit these days:

I was impressed at the performance provided by the 17" MacBook Pro. Despite having only 4 physical cores compared to the 8 in the Mac Pro, it was still running fairly close. Granted the Mac Pro is 2 and a half years older, but I still expected a dual quad-core Xeon desktop workstation to seriously outperform a portable machine.

Today it looks like the question over how to handle major software updates via the Mac App Store has been answered.

Mac (and iOS) developers Panic have just announced the details on the release of Coda 2, their fantastic Web editor, the current version of which (1.7.5) currently sells in the Mac App Store for $99.99. Coda is a non-trivial app, one that has taken a lot of developer time and effort to produce. While many of it's users would love to see Coda 2 replace 1.7.5 directly in a free upgrade, it was never likely to happen. On the flip side, it's not appealing to pay the full new price again.

Thankfully Panic have managed to solve the problem by offering Coda 2 as a separate app. They have announced an aggressive 50% discount for the first 24 hours that the app is on sale, making for an upgrade price of just $49.99. After 24 hours the price will go up to $75, which is still a respectable 25% off.