Twitter’s Tightrope
Twitter’s strength is that it’s cool. Twitter’s problem is that it’s cool. Although my tweets connect me to the whole world, when I use Twitter I’msocialising. This implies privacy: Twitter as a whole might be just a social network, but my Twitter is a network I choose, a network I build: my network. My Twitter is something personal. Socialising is cool. Everyone loves it. Any place, person, book, film, album, or website that gives people an excuse to get to know other people is cool. Services like Twitter are the alcohol of the web: they matter because they give people an excuse to communicate. Like a cool club or a chilled-out coffee shop, Twitter’s popularity depends on people wanting to be there. Advertising is not personal; advertising is maybe one of the most impersonal things in our culture: to advertisers, you are a number; a calculation; an entry on a spreadsheet. Friends care that I like music because it’s what makes me, me; advertisers care that I like music because it means they can sell me music: replace me with a robot who’ll buy CDs, and watch to see if the advertisers care. This is where we come to the Quick Bar. The Quick Bar is not cool. If you’re not already aware, the Quick Bar was introduced in the most recent update to Twitter’s iPhone app. It’s an over-obvious black bar that hovers over the top of the main interface and shouts out random trends and hashtags. Charlie Sheen has featured a lot recently — it’s about as bad as it sounds. The Quick Bar is pretty obviously a way to do two things: get you more involved in Twitter, and show you more ads. Both of these are ways for Twitter to make money: the ads for obvious reasons, and the involvement because the more you use Twitter, the more they know about you and the easier it is for them to target their advertising efforts efficiently. That might sound like a cynical, anti-capitalist assessment: it’s not. Twitter wants to make money, that’s fine: I’m happy for them to do that. I just don’t want their money-making efforts in my face; you can put adverts on the walls of your coffee shop, but don’t float them on top of my coffee. The Quick Bar fails because it’s a poorly thought out, impersonal intrusion on the social network of every single person who uses Twitter’s iPhone app. It’s as though the guy at Starbucks walked up and pushed ads in front of your face while you were drinking your coffee. It’s not just bad, it’s stupid: as a business decision, it’s probably the single worst thing Twitter has done for it’s iPhone users since the iPhone app was launched. Social networks tread a fine line. They offer a way for millions of people to create connections which are both personal and social, then they make money out of those connections in a way that’s inherently impersonal and antisocial. That’s not impossible, but it can be damn difficult, as Twitter is learning. Too little of the uncool advertising, and you make no money: your business fails. Too much of the uncool, and your users leave: your business fails. Tread carefully.
Xoom, of course, will be able to play Flash relatively soon. The iPad 2 will never do it.
The iPad 2: Closed Loops & Cool Engineering
Yesterday the iPad 2 was announced. Maybe you’ve heard?
One of the many things that struck me as I watched the announcement of the iPad 2 was the fact that the iPad is now thinner than an iPhone 4. In fact, when I look at the iPad 2 side on it reminds me of an iPod Touch, which is just thick enough to avoid melting into thin air — and no thicker.
So: a faster processor, good battery life, cameras, and a thinner body. Apple are very good at engineering.
Apple’s strength, though, isn’t just that the company is good at engineering: it’s that they get to be good at engineering for a device that runs their own software. I think a lot of people overlook this when they praise Apple’s designs: iPods, iPhones, iPads, and Macs wouldn’t look anywhere near as nice if they had to accommodate a third-party OS. On Android, the iPad’s Smart Cover would be a third party accessory: can you imagine an third party cover which caused an Android tablet to go into standby, automatically, when the cover was closed?
Apple engineers operate in a closed loop: their hardware and software can work hand in hand because that hardware and software is developed hand in hand. The effortless, cool design of Apple devices isn’t an accident, and it’s not just down to the luck of having Jonathon Ive on board: it’s the result of a very intelligent business decision. That decision? Hardware and software which work together should be developed together.
Android — Apple’s most obvious competitor — operates in an open loop. Google develop the software: manufacturers develop the hardware. This isn’t to say that Android is in anyway a failure (although I don’t think it’s as good as iOS), but look at it this way: at Apple, the hardware and software guys work in the same building. Android hardware and software developers might work on different continents. How can you get the same level of feedback and cooperation when your software developer works for a different company, in a different office, in a different timezone?
Like I said up in paragraph four, the iPad 2 Smart Cover is a great example of this. There’s no way that any combination of separate hardware and software companies could come up with anything like the level of integration found in the cover’s design: it looks simple, but it’s not. You can imagine long hours of conversation between Apple’s designers and developers about exactly how the cover would work: what strength should the magnets be? How sensitive should the auto-sleep feature be? (Should the iPad go to sleep as soon as the cover is closed, or should it wait for a second or two, to make sure that the user “meant” to close the cover?). Those aren’t conversations that Samsung is having with Google.
All of which brings me on to the most important thing: culture.
There’s no doubt that Apple engineers and developers share a common culture, and that’s only possible in a closed loop. Open loop systems, like Android and Windows, don’t get to develop a shared culture because they don’t have enough to share. Windows has been dominant in the OS market for over twenty years, and in all that time we’ve never — not once — seen anything that even begins to quality for the description “Windows iPad”.
Not all closed-loop systems work. Nokia has proved this in the past few years: they make their own hardware and software, but they’ve been run out of the high-end smartphone market by Apple and now they’re reduced to using Windows Phone 7. Good luck with that.
Apple though, is lucky: they do it all. Hardware, software, a culture of excellence and attention to detail that turns out success after success. This is how great businesses are run.
Autoloading From Lib In Rails 3
Rails does a great job of autoloading your files, and in the development environment it “re-autoloads” before every request by default. This means you don’t have to litter your files with require statements, and you don’t have to restart your development server every time you change a file. Changes take affect almost instantly, and everyone’s happy.
The “lib” folder is an exception to this rule (as, in fact, are most other folders outside “app”). This exception is intentional: mostly, it seems, this is to bring Rails app behaviour in line with Rails engine behaviour.
All good, but maybe you want Rails to autoload files from lib. Here’s how.
First, find the “config.autoload_paths” line in config/application.rb and change it to:
This adds “lib” to the autoload path.
Second, stop requiring your autoloaded files by hand. Say you want to autoload CoolExtensions from lib/cool_extensions.rb — then you need to stop using “require 'cool_extensions'” in your app. When you reference CoolExtensions in your code, Rails will automatically find and load lib/cool_extensions.rb.
Restart your development server, and you’re good to go.
From what I can gather, a lot of people understand the first step but not the second. My guess is that if you’ve already required a file, then Rails’ autoload behaviour won’t kick in.
Namespacing Core Extensions In Ruby Gems
If you’ve spent any time developing your own Ruby gems or libraries, you’ve probably added some custom methods to Ruby’s core classes. This post is about the best place to keep these methods.
A Contrived Example With Parrots
Here’s an example of how I might extend a core class, and then use the extended class in my code. Imagine I’m building a gem called “parrot” which takes a string and repeats the string back to the user (it’s groundbreaking stuff):
This looks good: everything are well-organised, my core extensions are kept in their own files (named after the classes they’re extending), in their own “core_ext” folder. If I want to load my extensions to Array, I know exactly where to go: core_ext/array.rb. Also I have a talking ruby parrot, which is cool.
This setup is great 90% of the time, but that doesn’t mean we shouldn’t care about the other 10%: we could run into problems when the parrot gem is used alongside another gem which also extends Array. Put simply, the issue is:
- Both gems extend
Array - Both gems keep their extensions in gem_name/lib/core_ext/array.rb
- Both gems use
require "core_ext/array"to load their extensions - When both gems are used together, that require statement becomes ambiguous
In short, when both gems work together it may not be possible to say for sure which file require "core_ext/array" will load (I’m assuming that the load path is setup to allow each gem access to the other gem’s lib folder: this is normally the case).
I think it’s worth going the extra mile (or extra few lines of code) to preempt this problem. Here’s how I handle it:
I’ve moved core_ext/array.rb to parrot/core_ext/array.rb. By namespacing the file under “parrot”, I can avoid clashes with core extensions in other gems: require "parrot/core_ext/array" will always load my core extensions (and another gem, if they’re taking the same approach, can require "other_gem/core_ext/array" to load their own extensions).
It’s a small change but one that — I think — makes for better-structured code.
The Hitch
The BBC’s Tim Weber on Microsoft’s acquisition of Skype:
The hitch: Microsoft boss Steve Ballmer will have to work hard to integrate Skype, to ensure the voice/video-over-the-internet company is not strangled by his firm’s notorious bureaucracy.
I remember when Skype was bought by eBay: I thought “there goes a great service”, but I’m still using Skype today — so I’m willing to give Microsoft a chance. But I’ve just recently had to use Hotmail, and I’m really hoping none of those UI “innovations” get hammered onto my Mac Skype client.
This is the way acquisitions work:
- Business A builds something cool/useful/profitable
- Business B sees value in business A’s service
- Business B buys business A
Normally this is great but sometimes that something cool/useful/profitable is a product of some unique circumstances at business A, which circumstances promptly cease to exist when business A is taken over (strangled?) by business B. Then the takeover is like picking a beautiful flower and watching it die: once you’ve got what you want, you loose it.
In all honesty, I can’t see Microsoft doing anything more with Skype than eBay did (i.e., nothing). But I’m willing to lower my standards: I’ll be happy as long as a Bing search bar doesn’t pop up every time I make a Skype call to one of my clients.
Twitter’s Tightrope
Twitter’s strength is that it’s cool. Twitter’s problem is that it’s cool.
Although my tweets connect me to the whole world, when I use Twitter I’m socialising. This implies privacy: Twitter as a whole might be just a social network, but my Twitter is a network I choose, a network I build: my network. My Twitter is something personal.
Socialising is cool. Everyone loves it. Any place, person, book, film, album, or website that gives people an excuse to get to know other people is cool. Services like Twitter are the alcohol of the web: they matter because they give people an excuse to communicate. Like a cool club or a chilled-out coffee shop, Twitter’s popularity depends on people wanting to be there.
Advertising is not personal; advertising is maybe one of the most impersonal things in our culture: to advertisers, you are a number; a calculation; an entry on a spreadsheet. Friends care that I like music because it’s what makes me, me; advertisers care that I like music because it means they can sell me music: replace me with a robot who’ll buy CDs, and watch to see if the advertisers care.
This is where we come to the Quick Bar. The Quick Bar is not cool.
If you’re not already aware, the Quick Bar was introduced in the most recent update to Twitter’s iPhone app. It’s an over-obvious black bar that hovers over the top of the main interface and shouts out random trends and hashtags. Charlie Sheen has featured a lot recently — it’s about as bad as it sounds.
The Quick Bar is pretty obviously a way to do two things: get you more involved in Twitter, and show you more ads. Both of these are ways for Twitter to make money: the ads for obvious reasons, and the involvement because the more you use Twitter, the more they know about you and the easier it is for them to target their advertising efforts efficiently.
That might sound like a cynical, anti-capitalist assessment: it’s not. Twitter wants to make money, that’s fine: I’m happy for them to do that. I just don’t want their money-making efforts in my face; you can put adverts on the walls of your coffee shop, but don’t float them on top of my coffee.
The Quick Bar fails because it’s a poorly thought out, impersonal intrusion on the social network of every single person who uses Twitter’s iPhone app. It’s as though the guy at Starbucks walked up and pushed ads in front of your face while you were drinking your coffee. It’s not just bad, it’s stupid: as a business decision, it’s probably the single worst thing Twitter has done for it’s iPhone users since the iPhone app was launched.
Social networks tread a fine line. They offer a way for millions of people to create connections which are both personal and social, then they make money out of those connections in a way that’s inherently impersonal and antisocial. That’s not impossible, but it can be damn difficult, as Twitter is learning. Too little of the uncool advertising, and you make no money: your business fails. Too much of the uncool, and your users leave: your business fails. Tread carefully.
Flash On Tablets: Motorola Xoom vs iPad 2
Preston Gralla on why the Motorola Xoom is “a clear winner” over the iPad 2:
Xoom, of course, will be able to play Flash relatively soon. The iPad 2 will never do it.
Flash soon: is that a promise, or a threat?
The iPad 2: Closed Loops & Cool Engineering
Yesterday the iPad 2 was announced. Maybe you’ve heard?
One of the many things that struck me as I watched the announcement of the iPad 2 was the fact that the iPad is now thinner than an iPhone 4. In fact, when I look at the iPad 2 side on it reminds me of an iPod Touch, which is just thick enough to avoid melting into thin air — and no thicker.
So: a faster processor, good battery life, cameras, and a thinner body. Apple are very good at engineering.
Apple’s strength, though, isn’t just that the company is good at engineering: it’s that they get to be good at engineering for a device that runs their own software. I think a lot of people overlook this when they praise Apple’s designs: iPods, iPhones, iPads, and Macs wouldn’t look anywhere near as nice if they had to accommodate a third-party OS. On Android, the iPad’s Smart Cover would be a third party accessory: can you imagine an third party cover which caused an Android tablet to go into standby, automatically, when the cover was closed?
Apple engineers operate in a closed loop: their hardware and software can work hand in hand because that hardware and software is developed hand in hand. The effortless, cool design of Apple devices isn’t an accident, and it’s not just down to the luck of having Jonathon Ive on board: it’s the result of a very intelligent business decision. That decision? Hardware and software which work together should be developed together.
Android — Apple’s most obvious competitor — operates in an open loop. Google develop the software: manufacturers develop the hardware. This isn’t to say that Android is in anyway a failure (although I don’t think it’s as good as iOS), but look at it this way: at Apple, the hardware and software guys work in the same building. Android hardware and software developers might work on different continents. How can you get the same level of feedback and cooperation when your software developer works for a different company, in a different office, in a different timezone?
Like I said up in paragraph four, the iPad 2 Smart Cover is a great example of this. There’s no way that any combination of separate hardware and software companies could come up with anything like the level of integration found in the cover’s design: it looks simple, but it’s not. You can imagine long hours of conversation between Apple’s designers and developers about exactly how the cover would work: what strength should the magnets be? How sensitive should the auto-sleep feature be? (Should the iPad go to sleep as soon as the cover is closed, or should it wait for a second or two, to make sure that the user “meant” to close the cover?). Those aren’t conversations that Samsung is having with Google.
All of which brings me on to the most important thing:culture.
There’s no doubt that Apple engineers and developers share a common culture, and that’s only possible in a closed loop. Open loop systems, like Android and Windows, don’t get to develop a shared culture because they don’t have enough to share. Windows has been dominant in the OS market for over twenty years, and in all that time we’ve never — not once — seen anything that even begins to quality for the description “Windows iPad”.
Not all closed-loop systems work. Nokia has proved this in the past few years: they make their own hardware and software, but they’ve been run out of the high-end smartphone market by Apple and now they’re reduced to using Windows Phone 7. Good luck with that.
Apple though, is lucky: they do it all. Hardware, software, a culture of excellence and attention to detail that turns out success after success. This is how great businesses are run.
Autoloading From “lib” In Rails 3
Rails does a great job of autoloading your files, and in the development environment it “re-autoloads” before every request by default. This means you don’t have to litter your files with require statements, and you don’t have to restart your development server every time you change a file. Changes take affect almost instantly, and everyone’s happy.
The “lib” folder is an exception to this rule (as, in fact, are most other folders outside “app”). This exception is intentional: mostly, it seems, this is to bring Rails app behaviour in line with Rails engine behaviour.
All good, but maybe you want Rails to autoload files from lib. Here’s how.
First, find the “config.autoload_paths” line in config/application.rb and change it to:
This adds “lib” to the autoload path.
Second, stop requiring your autoloaded files by hand. Say you want to autoload CoolExtensions from lib/cool_extensions.rb — then you need to stop using “require 'cool_extensions'” in your app. When you reference CoolExtensions in your code, Rails will automatically find and load lib/cool_extensions.rb.
Restart your development server, and you’re good to go.
From what I can gather, a lot of people understand the first step but not the second. My guess is that if you’ve already required a file, then Rails’ autoload behaviour won’t kick in.
I'm a startup consultant and software developer based in southern England. Hire me for Ruby on Rails or iOS development work and advice on building a smart business.
