“Advancing the lever after each exposure makes that exposure seem more distinct and more deliberate.” I too thought this weird when I played with Lars’ example. but you only have to use it once to understand why it’s there.
“Camelot received dozens of complaints on the first day from players who could not understand how, for example, -5 is higher than -6.” You’d have thought Camelot user-test their scratchcards. Clearly not!
“If there’s a single piece of functionality that you feel you can’t provide in raw HTML, you’re doing it wrong.” Yes. Steve is, by and large, right about all of this. This is why front-end development is worthy of being a role in its own right.
“Though most people understand that your environment files are the key to answering some of these problems, how to actually solve them is not well known. I’ll attempt to clarify what to use and when to use it.”
A series of articles on source control best practice.
“Software is everything. It also sucks.” Fascinating article on remedying that idea, about the team that writes software for the Space Shuttle. It’s practically the polar opposite of web development. Some bits of that are probably good; some are perhaps n
“Beat connects you very directly to a single soldier by thumping their recorded heartbeat against your chest… If we are going to continue to fight wars, we need better methods of feedback like this one so the costs are more visceral and real for us.”
“Regular people on the web *love* Snap previews. I know you don’t believe it — I didn’t want to believe it… I know we all feel these people are idiots, but it’s our own geek cultural imperialism that makes us think we know better than non-techy folks.”
02 November 2007
So, the latest version of Nokia/Symbian Series 60 has been previewed. There’s even a swanky video for it:
I’m still thinking about a lot of it. It’s clearly aiming at a slightly different market to the one Apple’s gunning for. There’s an interesting separation between “stuff that needs a stylus” and “stuff you can do with fingers/thumbs”. In reality, I think people veer towards thumbs if possible. Does that mean they’ll ignore the UI elements that are so small they need a stylus? Not sure. I haven’t given that enough thought, as I said.
The best bit of the video, though, is nothing to do with touch. It’s the bit where the model silences the phone ringing on the coffee table simply by physically flipping the phone over.
As an interaction, that presumes a lot. It presumes you leave your phone out, and if you do, you leave it face up. Many people leave their phones out (so they can see them skitter across the table when a call/SMS comes in) but face down, so the screen doesn’t annoy them. (Blackberries, with their persistent flashing light, are a prime candidate for face-downing). At the same time, it embraces that behaviour: when the screen lights up, you hide the screen and the phone silences. I like that.
Of course, you could do that on any old phone with a cheap accelerometer inside it. I wish it wasn’t part of some “premium” touch interface, but part of a lowest-common-denominator combination of hardware and software. Oh well.
Tumblr gets a massive overhaul, becomes Davidville’s only product (and a company, too), and re-ignites my interest. Simple tools, made well. Strangely, it excites me in a way Pownce failed to (despite being a good, solid product).
01 November 2007
Connecting Rails to legacy databases isn’t actually that hard – depending on the database you start out with. Recently, we needed to perform some statistical analysis on a large Movable Type database. Rather than wrestling with endless SQL queries at the prompt, it made sense to abstract out a little and build some kind of modelled front end to the statistics.
The most obvious tool for me to use was Rails; I’m familiar with it, I like the way ActiveRecord works, and it means that I can poke around the database from
script/console if I need to.
The reason this turned out not to be too hard is because whilst Movable Type doesn’t conform to Rails’ opinionated ideas of what a schema should look like, it is still a well-designed and normalised database. Because of this, we can teach ActiveRecord to understand the database.
First of all, we start by creating our models: for our needs, Blog, Comment, Post and Author. We generate them in the usual manner –
script/generate model blog. Once we’ve done that, we delete the migration files in
db/migrate it creates, because we’re not going to use them.
Next, we point
config/database.yml to the Movable Type database.
And then, we build our relationships thus:
class Blog < ActiveRecord::Base set_table_name "mt_blog" set_primary_key "blog_id" has_many :entries, :foreign_key => "entry_blog_id", :order => "entry_created_on" end class Entry < ActiveRecord::Base set_table_name "mt_entry" set_primary_key "entry_id" has_many :comments, :foreign_key => "comment_entry_id" belongs_to :blog, :foreign_key => "entry_blog_id" belongs_to :author, :foreign_key => "entry_author_id" end class Comment < ActiveRecord::Base set_table_name "mt_comment" set_primary_key "comment_id" belongs_to :entry, :foreign_key => "comment_entry_id" end class Author < ActiveRecord::Base set_table_name "mt_author" set_primary_key "author_id" has_many :entries, :foreign_key => "entry_author_id" end
set_table_name method tells the ActiveRecord class what table to look at, and the
set_primary_key method does exactly what it says on the tin. (It also makes sure that #to_param works correctly based on whatever our new primary key is, which is handy). Beyond that, we simply have to specify the foreign keys on our relationships and everything plays ball; we can now access
blog.entries just as we do with a typical Rails setup. It’s now easy to write the rest of our Rails app – model methods, controllers, views – just as we normally would. We’re just using the MT database to pull out our data.
And if you’re wondering: yes, it made the manipulation a lot easier, and a few hours poking at the console began to yield some interesting algorithms to apply.