If you put 20 poets into a conference room and ask them to solve world hunger, I guarantee that their collective output will be a poem. Or 20 poems. Put 20 project managers into a room and you’ll get a 50-page multi-generational plan. Twenty executives? A one-pager that commits to putting 20 project managers into a room.
Plop an engineer into that meeting with the 20 project managers and the output of the team changes — for the better. I don’t know a single engineer who has the patience to put up with process heaviness or indecisiveness-framed-as-thoughtfulness. And not a one would think that you can’t engineer your way into a shorter, more efficient meeting.
Most people don’t realize there’s a whole parallel industry devoted to the App Store charts. Apple could get rid of it by removing one button.
What would go in place of that “Top Charts” button? Maybe “Favorites,” with a custom-generated list of popular and well-liked apps tailored to the user. Maybe promote the “Staff Picks” section to its own spot. Hell, let’s dump “Genius” and put in both.
Maybe Apple could make that Favourites button work using actual on-device behaviour.
Apple could use something like amount of time each app is running, but I think that might favour particular classes of app. Just because you don’t use an app for very long doesn’t mean it isn’t a great app. Case in point for me would be something like forecast.io (or Dark Sky if you want an actual app). I don’t use forecast.io for very long, but I do use it often.
Apple could use number of launches, but I think that just has the opposite bias.
Instead, my preferred metric would be the number of days the app was launched since installation. If you’re launching the same app every day, it doesn’t matter how long or how often you launch it, you clearly find it useful.
Gather these metrics for each user, then find users with similar results (e.g. using a Self-Organising Map), and recommend apps that score well for others that you don’t have. Bingo. Personalised app recommendations based on the apps people really use.
I think at WWDC Apple will announce an SDK for the current Apple TV
The control method will be an iOS device
In the fall, Apple will launch an upgraded model that supports an optional wireless controller
The entertainment options will be unchanged: no channel guide, no pass through, no DVR functionality. Apple will instead focus on stealing more and more attention away from pay-TV until the content owners are as desperate as the music companies were a decade ago.
Ben’s suggested price: $99 or $129.
This article was part of a great series on the future of TV. Go read it now.
Transformer Book Trio is a tablet running Android (an unspecified version of Jelly Bean, to be a bit more precise); when docked, it becomes a Haswell-equipped Windows 8 Ultrabook.
To quote Nicholas Negroponte in Being Digital, these technologies will evolve into “a digital butler… [it] recognises callers, disturbs you when appropriate, and may even tell a white lie on your behalf. The same agent is well trained in timing, versed in finding the opportune moments, and respectful of idiosyncrasies.”
The thing is that for this to be true, the butler has to be yours, not Google’s.
I read Being Digital back in the late nineties, and I buy into most of Negroponte’s vision, including the digital butler. I just don’t think I trust Google to deliver it - even if they charge for Glass itself.
Today I’m at the Amazon Web Services Summit at The Business Design Centre in Islington, London.
Pretty busy, good vibe. My primary goal today is to talk to customers, understand their needs, and work out details of how Smart421 can take advantage of some of the new offerings like OpsWorks in our new Service Factory proposition.
Had an interesting conversation last week with a good friend about AAPL’s slide over the last few months.
His position: It’s still too expensive. Why? Way higher than most of the big boys. In my friend’s view, they’re just not doing enough to justify a price this high.
The thing that blew my mind is that he wasn’t talking about market cap. He was talking about the price of a single share. He was comparing the $400 a share in AAPL to e.g. Tesco’s £3.93, and saying ‘it’s not worth that much more’. Never mind the fact that the share price is meaningless in valuing a company until you know how many shares have been issued, nor the vast amount of cash that apple has in reserve, the emotional reaction was ‘it’s too much money’.
This got me thinking. I’ve thought about buying AAPL before. I do believe on them as a company, and I think they’re undervalued at the moment for a whole host of reasons. So, why haven’t I bought?
Maybe I’m not as immune to emotional reactions as I’d like to think…
So, I’ve just spent the best part of 2 hours renaming a model in 3sixty. Turns out, this is really hard.
In Java, everything is strongly typed. Renaming classes is something that can happen largely automatically. Even with hibernate et al involved, it’s relatively straight forward. The IDE will find most of the changes for you, leaving you with just a few rough edges to clean-up.
Because Ruby is a dynamic language, it’s pretty well impossible for an IDE to find all these references safely, so you’re pretty much on your own.
I’ve tried to do this before with search and replace, and found that risky, particularly if your model is named something like ‘User’, which might be dotted around your application for other reasons.
What I’ve done this time is this:
Renamed the table in the database (using a rename_table migration).
Renamed the model class and spec, including any internal references to the model name.
Run my tests. Fixed what failed. (which was a lot).
Run my tests again. Fixed what failed (which was still a lot)
… rinse, repeat until I run out of work.
Rename the controller, helpers etc.
Run my tests. Fixed what failed (still a lot!)
… rinse, repeat.
Test manually. Carefully.
This seems to have worked, but it makes me wonder if there’s a better way.
Stack Overflow points to a refactoring plugin on github, but that scares me a little. I might try it next time, just as an experiment.
I think the real lesson here though is not to make this mistake in the first place. Thinking carefully about model and attribute names seems to be an order of magnitude more important in ruby than it is in Java. Just an added consequence of the dynamic nature of the language - just like the need to have a good test suite.
