Though not a new phenomenon, we think we have a solution.

If pressing a lit elevator button were to cancel the call and simply send the machine to the nearest floor in the current direction, there would be a penalty to pressing it more than once.

The interesting thing about this idea is that it need not be universal. Instead, elevator designers could follow the lead of Jeremy Bentham and create a panopticon-style system in which some small portion of elevators operate this way. It only takes the fear of looking like an idiot to regulate behavior (most of the time).

ChatRoulette Weirdos

As ChatRoulette takes off, it’s becoming plagued by pervs flashing their junk or otherwise being slimy. It’s certainly expected, as the anonymity provided by the web brings out that side of people. It’s just a fact of life on the Internet: if there is an opportunity for a guy to flash his weiner anonymously, he will.

And that’s fine. It’s the way of the world. It’s the way of the web.

But so, my friends, is community moderation.

Enter ChatSnapper

Let’s try an experiment.

1. Follow @ChatSnapper on Twitter.
2. DM or @reply to @ChatSnapper with a link to a screenshot from ChatRoulette (or other online chats) showing offensive (or just weird) behavior.
3. Check posted links and help shine a light on the offenders.

Let’s see if the existence of a rogues’ gallery has any effect on the actions of folks.

If this works, I’ll start calling elevator companies.

ADDENDUM

Alex Bisceglie alerted me to a similar effort: ChatRoulette Cock Map. It includes an app that can track the IP of offenders as well.

The very moment that Alex sent that, I was working on a WebKit browser with screencap and yfrog upload. For now, grab a build at: ChatSnapper – Alpha.

If the name – or functionality – sounds familiar, it’s because at least two other companies have launched (basically) the same service using the same name.

Yahoo! has Yahoo! Buzz along with status message integration into Yahoo! Mail.

The domain, Buzz.com, is owned by AT&T and is… a social network for small and local businesses.

I hereby decree, as a passive armchair quarterback of the internet, that we retire the word “Buzz” along with any associated products, from today forward.

BTW – there is only one true Buzz on the internet.

Amazon was nice enough to give me a link to download Internet Explorer, so at least their user agent sniffing is tuned to perfection!

One criticism I have is the name. Many, many others have criticized the name because of the associations it brings to mind. There was a trending topic on Twitter called “iTampon” that sums it up.

Apple is smart, though, and a Wednesday release means the “iTampon” reactions will be old, lame, and boring by Monday.

No, the reason the name iPad bugs me is more subtle, and more of a long-term marketing problem.

My gripe: the name is differentiated from the iPod by one letter – a soft vowel. It’s an almost meaningless distinction, and crams the iPad into the same cognitive bucket occupied by the many iPod releases.

Why is that a problem? Because the strongest (non-tampon) negative reaction I saw was that the iPad seems like a slightly larger iPod Touch.

If Apple is ok with that comparison, and with these products being differentiated only by size…well, fine.

But I think the iPad will take on a life of its own if it can get footing, and that life will always be anchored, from a marketing perspective, to the iPod.

A more inspirational, open-ended, and differentiated name would have been Canvas. No “i” prefix. New cognitive space. New brand trajectory.

Instead, we’re stuck with (an image of) the iPod that won’t quite fit into our pockets. After the more immature associations fade, that is.

I don’t believe this will be the case. It’s not so much about the pros and cons of e-ink, backlights, or screen resolution.

To me, the Kindle DX is a brilliant device because it forces me to read a f’ing book.

No dock icons blinking. No compulsive checking of Twitter, email, or stock quotes (or Texts from Last Night).

By offering a limited set of functionality and doing less, better, the Kindle forces me to eschew the kind of distractions that make me curl up with a book in the first place.

Apple can create the be-all, end-all Surface or Canvas or Slate or whatever. I will buy it. I will buy the shit out of it. I’m a developer and UX geek (and yuppie hipster scum) – I have to.

I won’t use it to read novels, poetry, or prose. Magazines and news? Sure. Tech books? Maybe, if live docs and errata were part of the mix. But then, that type of reading is work, not pleasure. Not therapy. That’s where the Kindle shines.

I have looked at (an early version of) the Kindle development kit (the KDK) and though I’m tempted to create apps focused on distraction (Twitter client, anyone?) I don’t think I’d run them. Instead, I’m trying to dream up apps that boost the escapism the Kindle already affords me.

So far, nothing beats the core function: making me crave reading as much as my first library card did.

Check it out: Cartilage.

Add it to your Monk set up with the monk command.

monk add cartilage git://github.com/tobyjoe/cartilage.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=cartilage myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I want to add optional memcached support to both Cartilage and Lazybones.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

Cartilage is based on the original skeleton that ships with Monk, by the way.

You can find the project over at GitHub.

Check it out: Lazybones.

Add it to your Monk set up with the monk command.

monk add lazybones git://github.com/tobyjoe/lazybones.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=lazybones myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I am working on skeletons for Postgres and MySQL as well, and adding optional memcached support to all of them.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

It’s based on the original skeleton that ships with Monk, by the way.

The question is obvious for mobile projects because highly variable environments are par for the course. It matters with all non-stationary touch points, though – from door handles on train cars to Android applications to the work we’ll surely be seeing from the new Schematic Touch group.

Asking the question is easy. Using the response may not be. I see mobile apps all the time that are clearly made for users who are stationary, physically stable, connected to a consistent network, and with both hands free for interaction. High demands, right? They conflict with my more common usage patterns, and those apps rarely get launched.

A great example of a more subtle conflict – and one being addressed without much fanfare by many app developers – is iPhone usage in bed and auto-rotation.

Welcome to My Boudoir

My wife and I are incredibly lame. We tend to lie, side by side, reading news on our iPhones before falling asleep at night.

Apps that auto-rotate when the device orientation changes suck in bed. Or on the couch. Or in a reclining seat in first class. Or in a hammock. You get the point.

The problem is that we all flip-flop all over the place in bed (va-va-va-voom!), changing the point of reference for orientation. What makes a lot of sense when we’re upright is a pain in the ass when we’re horizontal.

A Suggestion

I’d like to encourage developers to carefully consider auto-rotation. A lot of devs are starting to catch on to this one as customers complain or make feature suggestions. I thought I might provide an example illustrating a really easy approach to disabling auto-rotation globally in an app. There are more sophisticated and pattern-y ways for the clever.

Don’t get me wrong – auto-rotation can be a great feature. I am all for it. But I have decided the baseline rule should be: If your views auto-rotate, you should provide a (preferably in-app) preference for disabling the feature.

An Example

So how does a developer do that?

Well, the interface is up to you. Let’s assume you have a project with a button that brings up an in-app settings screen.

If you have a UISwitch in there that represents the global auto-rotation state, just save it to the user defaults when you close the settings.

- (IBAction) dismiss:(id)sender
{
	// Update the defaults.
	NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
	BOOL autoRotationEnabled = self.autoRotationSwitch.on;
	[defaults setBool:autoRotationEnabled forKey:kAutoRotateKey];
	[defaults synchronize];

	// Close!
	[self.parentViewController dismissModalViewControllerAnimated:YES];
}

In your app delegate, declare a method to get the current global auto-rotation value.

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	return [[NSUserDefaults standardUserDefaults] boolForKey:kAutoRotateKey];
}

Finally, in each view controller that should obey the globals, ask the app delegate for the scoop.

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	PillowTalkAppDelegate *appDelegate = (PillowTalkAppDelegate *)[UIApplication sharedApplication].delegate;
	return ([appDelegate shouldAutorotateToInterfaceOrientation:interfaceOrientation]);
}

Here is a quickie example project that illustrates the concept: PillowTalk.zip

Here is a patch for the Erlang Portfile that will let you build on pre-GM 10.6.

Save the patch to ~/Desktop/erlang.diff

Patching icu

You might also have to patch icu. To test, run:

sudo port install icu

If it errors, grab the unified diff patch file and save it to your ~/Desktop as “icu.diff” and run:

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/icu

sudo patch < ~/Desktop/icu.diff

sudo port install icu

Patching Erlang

To run the Erlang patch and install the port, just do the following:

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/erlang

patch < ~/Desktop/erlang.diff

sudo port install erlang

CouchDB?

I can get CouchDB to build, but not to run. I think I'll let someone else solve this one. Maybe you?

Still, I like two things about this blog post about their Office web apps.

First, I like that they are officially focusing on (admittedly, a subset of) modern browsers for their very dynamic web apps. Developers and designers at Microsoft are just like the rest of us, after all: they want to do great work and hate clunky platforms and unfortunate constraints. Bravo for continuing the baby steps forward.

Second, I like that they aren’t blocking or filtering user agents. They are offering “unofficial” support to semi-modern and modern browsers. They aren’t showing upgrade notices that make users feel like losers. They aren’t blocking access as some goofy religious mission. They’re just being practical.

From the post:

If you prefer to use another browser you should still give the Web Apps a try. While we cannot officially support all browsers, customers will not be blocked from using them. It is a goal of the Web Apps to have broad compatibility and reach.

I hope (oh dear lord am I gonna say this?!?) others can follow in Microsoft’s footsteps here and be respectful to users.*

* Yes, I also know Microsoft isn’t the first to do this. I’m being snarky.

I killed a good chunk of time at the bus station listening to an episode of FLOSS featuring David Heinemeier Hansson. For those not in the know, he’s the very bright and ambitious gent behind the Ruby on Rails framework.

FLOSS stands for “Free, Libre, Open-Source Software” and is a great way to either catch up on OSS you may not have encountered in the wild or dig into the people behind OSS you already use.

My Rails History

I was a really early adopter of Rails for professional work. Having spent my time with Struts and similar frameworks – the inspiration for Rails – I saw the familiar patterns and liked the quick bootstrapping. The Barbarian Group was, as far as I know, the first advertising/marketing shop to deploy Rails apps – back in the 0.12 days. I wrote an early intro article about Rails in .net magazine and was scheduled, along with the former CTO of the company, to speak at the first RailsConf, in Chicago. (Unfortunately, some sudden staff changes at TBG forced us to cancel.) So, yeah – to paraphrase a t-shirt, Rails had me at, “Hello, world!”

I always loved the full-stackiness of Rails: from the generators, to the testing tools, to the console, to the plugins and helpers. It’s great to go from concept to boilerplate in under an hour. The Rails folks inspired people, divided the fuck out of people, and helped make OSS contributions massively hip. All in all, I’m really glad Rails came about and objectively support most of the hype.

Gripes

Subjectively, over time, I got pretty frustrated with Rails for the type of work I was doing. It’s really great for start-ups and clean room builds, but was always a little inflexible when special considerations popped up. For a long time, fitting Rails projects into larger ecosystems tasted quite strongly of vinegar. There is an amazing amount of flexibility in Ruby, and hot-patching the shit out of Rails is very easy. There’s a point at which you kind of pause and ask if you’re building on the wrong foundation for the job at hand.

For a long time (and maybe today), that kind of question would get you tarred and feathered in the #rails world. I got sick of the quasi-religious bickering between “Rails developers” and “web developers” at large and dropped out. Drama around a web framework? No, thanks.

We still run Rails projects and use it often, but we do so with a certain emotional detachment. We also do our best to be agnostic, which means giving an honest evaluation to the decision of a toolset for each and every project.

When we do pick Rails, we try to focus on the engineering and ignore the drama in the greater community. This has always meant, in large part, ignoring DHH and almost every Rails blogger out there. That choice means I occasionally miss out on some true gems (heh) of knowledge or interesting arguments, but I’ve rarely regretted dropping out of the conversation.

Enter FLOSS

I thought DHH did a killer job on FLOSS. He’s one of those folks who comes across one way in print and another in person. It’s not an inconsistency as much as a lack of nuance in the written form. I’ve never liked the written form of Mr. Hansson but he and Randal Schwartz had a blast during the interview and it was very endearing.

So DHH got me inspired about Rails again. Not converted to the golden path or anything, but a renewed interest in the future of the framework beyond keeping a competency for client needs.

Getting Sidetracked

As an aside, he also made me wonder if he really understands the architectural style he promotes so heavily: REST.

In the podcast, he explains REST to Randall Schwartz (the host) by describing “the four verbs” used to operate on resources. It seems like he’s still confusing CRUD with REST. Oddly, the Rails source doesn’t really make the confusion.

Maybe this explains little mysteries, like the default Rails asset helpers appending “cache buster” query strings to support files (like Javascript, CSS, and images) in production environments. REST is about using HTTP to the fullest – including caching.

It could be that he really understands REST, but chooses to dumb it way down for his audience. That seems a bit risky, though. Developers hate that.

Getting Real?

In either case, I won’t get too wrapped up in the dude. I will say, kudos to adding some much-needed sugar to balance out the vinegar. Rails PR could use some attention and clarity along with a taming of the “opinionated software” side of things.

I hope the conversation around Rails stays creative but keeps growing up – even if DHH wants to avoid being too “professional.”

Yes, creating cross-browser experiences can be painful when support for Internet Explorer 6 (IE6) is required. There are dozens of hacks to get around certain issues, and it is possible to design experiences that are functionally identical on IE6 and more modern browsers. It may mean designers don’t have carte blanche, but that should be fine if their companies or clients mandate full IE6 support. Any good experience designer can work within constraints and still kick ass.

Still, a lot of folks are lobbying their companies, clients, and partners to drop support for IE 6.

My issue is how they’re doing it. The more dickish folks are throwing up an insulting roadblock, patronizing IE 6 users.

A more practical approach is to encourage users to upgrade with prominent, consistent notices. This angle isn’t terrible, but still alienates users and disrupts the experience for those users almost as much as a modified or “broken” IE6 experience. It’s just not friendly, or consistent with the brand message that usually mandates an identical UI across target browsers.

Another Option: Boring but Practical

My suggestion is to take this to the contracts. Redefine the word “support” as it applies to user agents (like browsers). Look at the cost/benefit of all types of support for all types of user agents. This should be a part of your business modeling.

Instead of refusing content to IE6 users or breaking brand guidelines by disrupting their experience with a patronizing notice, why not relegate them into a tier of Content-Level Support as opposed to Design Support?

Good sites already do this with a stylesheet for print: we don’t penalize printers for their lack of a good box model. The same is true of screen readers and most RSS readers. Maybe you can think of IE6 as a perfectly viable user agent for consuming content, but cost prohibitive for rendering top-tier experience design. Serve your print styles to IE6 if you don’t want to offer design support. Or serve a basic white-on-black stylesheet. Or no stylesheet. Pretend IE6 is the Googlebot or JAWS or any other non-graphical user agent. Just don’t punish people or talk down to them.

Channel Your Frustration Properly

You don’t have to be a dick to your less-endowed users. Shift them, officially, to a tier you, your clients, your company, and your partners agree upon and move on. Just make sure you’ve built an economic model that includes the IE6 users and estimates the cost of all possible decisions. Look at the realities of IE6 users of Digg to understand the complexities facing the people your cocky designers and lazy developers want to patronize or abandon.

Justify relegating IE6 with real numbers or choose to give it design support and force your designers to work within the constraints. They do get paid to work, after all. If they can’t create great experience design that doesn’t fuck over the people coding those experiences, fire them. Hire designers who understand browsers.

No matter what you do, keep your users’ needs first. They’re the ones you can’t replace.

A Great Resource

A few months back, I started up a GitHub project to create a baseline CSS file for all legacy browsers. Around the time I got contributions from folks at work, I found out about similar (but completed) projects out in the wild. One such project can be found here: http://code.google.com/p/universal-ie6-css/.

If you are trying to raise awareness, forcing a user to work is generally a bad idea. You have to give users something of high value while minimizing their effort if you want to build a better reputation.

If your goal is conversion, you should be especially careful of the barriers to entry and usage. This seems obvious, but brands consistently require too much of users in their digital marketing efforts.

Augmented Reality in Ads

Industry rags and blogs have spent months reporting on a steady stream of augmented reality (AR) ideas in marketing ever since GE launched their Smart Grid AR site.

A recent entry into the pool is for Always Infinity. The site claims to show you a magic trick.

All you have to do is follow the instructional video and simple two-step process of printing a graphic out on a sheet of paper and holding it up to the camera while it superimposes the magic. What’s the magic in this case? A 3d animation of a rabbit in a hat. It’s cute, but fluff. The real magic trick is making 5-10 minutes disappear with nothing to show for it – including a greater appreciation of their new pads.

This is how most of these campaigns work. I think they’re mostly flops. They’re ideas pulled out of the bookmarks bar of a desperate art director, sold to a client as the next big thing, and supported by an industry press with a shortage of interesting topics.

There were two instances of this particular form of webcam-based AR in recent marketing efforts that were successful. The first was the aforementioned GE project. This was the first big brand use of AR and it seemed like advanced – if novel – tech coming from GE. It was cool and not overtly pushing a product.

The second was a project developed by AKQA for the United States Postal Service (USPS) that let users hold items up to their camera to find the best Priority Mail shipping box. The damned thing had a purpose, and used the tech in an interesting way.

Everyone else doing this stuff has been trying to fit in, adding to the noise. They’ve expected users to find inspiration in the declining novelty of webcam AR, put in the work of printing an image, engage in the theatrics, and eagerly send to a friend.

Instead of patronizing your audience, pushing this gimmick as new to them, why not find a real reward for engagement? Make the payoff ten times as valuable as the work users put in. Only the first project to use a gimmick gets to call the work itself the payoff.

Let me repeat my new rule to the consumer brands out there looking for gimmicks that make demands of people: If it’s easier to buy your product than to engage with your marketing, you’re doing it wrong.

Currently, systems deliver recommendations (like search results, products, or compelling content) based on two types of user input: explicit and implicit.

What You Tell the Robots

Explicit input is what you do to purposefully tune a system. You might opt out of tech news and opt in to sports. You might type in a couple of your key stock symbols. Explicit input is configuration. The cynical idea behind configurable services is that users will interact more with a tool they’ve spent time customizing. This can be true, but it can also alienate non-tinkerer audiences. More importantly, forcing someone to create their own portal removes any kind of authority from the service in question. It exposes the robot behind the curtain.

The Robots are Watching You

Implicit input is what you do without knowing you’re tuning a system. Where you click, what you search for, and what you ignore all contribute. Coming into a magazine site from a particular Google search might change the content you see on the page. Banner ads are usually served based on what you’re reading and what the ad network knows about you. On Amazon, anything you look at feeds into the recommendation system that shows you products that (may) interest you. In fact, I love pranking people by sending links to enema kits on Amazon. It pollutes their recommendations for a while. This is implicit input at work.

The Robots are Watching Everyone

An additional way that sites make recommendations is based on the stuff you tell them you want (explicit input), the stuff you show them you want (implicit input), and the input from other people like you. There are some sweet algorithms out there for determining that people are alike and using the tendencies of members in a group to recommend things to other members in the group.

In theory, the idea is compelling. Unfortunately, most of these algorithms end up turning individuals into caricatures of themselves or of their demographic group. It’s infeasible for a system to know enough about an individual to make consistently great recommendations. No computer will ever be able to recommend a book or a date or a pair of shoes with the same accuracy as a friend. More importantly, they can’t deliver the same accuracy as a casual acquaintance.

Humans can fill in gaps and infer rich meaning from subtle body language, tone, and personal experience. Those factors are noticeably absent in most online recommendation, search, and content delivery systems.

The Perfect System

I don’t think people want to interact much with systems to find information. Weird view, I know.

Some systems are certainly popular (Google) and and very successful (Amazon), but the affinity people feel for those systems is a form of Stockholm Syndrome.

What we all want is to have our grandfather (or an equivalent symbol of infinite wisdom and no-bullshit-taking) sitting on our shoulder, pointing us in the right direction at all times. We don’t need confidence in recommendations (of content, purchases, people) as much as faith. We want to Ask Jeeves, but we want Jeeves to have a clue – not a hundred page slush pile of possible hits.

Bad or boring recommendations lead to a lack of faith in recommendation systems in general and contribute to an overall fatigue. Recommendations need to inspire either confidence or faith. Confidence comes when you’re 100% accurate at all times. Faith comes when I feel like you understand me. Your “you might like…” recommendations are something I care about because I empathize with you. Confidence is for robots. Faith is for humans.

Enter Social Networks

There is a lot of potential in the networks of people we curate online, the reviews we write, the reservations we make, the choices we make on the spot in stores. The data doesn’t say who we are and how we feel, and no machine can step in to fill in the gaps and make the proper inferences.

The best system will have hints of the “#lazyweb” approach to Twitter. I ask my curated audience for advice. Even if I don’t know them all personally, and thus have little confidence in their individual experience and knowledge of my personality, I have high faith in the mechanism. I ask, and I receive. From people.

It’s a model as old as language. Until computers can empathize, algorithms need to shift their focus. Instead of attempting to make recommendations, technology should attempt to facilitate recommendations.

Twitter is on the right track with the new focus on search. I’ve long maintained that the best source of purchase advice is Twitter search. Twitter is a barometer. Nobody searches Twitter to find out definitive, high-confidence information. Instead, we search to get a feel for what people seem to know. We read short statements and either empathize with them automatically or shut them out. We have faith in our ability to read between the lines and derive answers. We use personal brands as clues to authority, bias, and brilliance.

It’s very personal and all too human.

With the insanity around the Yahoo and Bing/Microsoft relationship, I wonder if Twitter – or an app built around it – won’t become the search and recommendation tool we all really want.

Strategists everywhere are pushing companies to add APIs to their online properties. Job postings for web developers and architects invariably require experience working with and developing APIs. It comes up in sales meetings, pitches, and casual conversations with industry folks all the time. I’m often left wondering if the term “API” has lost its real meaning and become sort of a stand-in for a handful of fuzzy concepts.

REST APIs are Buzzworthy

In the API chatter, there’s a huge focus on RESTful APIs. Everyone wants a RESTful API. Web developers love REST architectures because the fixed semantics and stateless mapping of resources to URIs lowers the barrier to entry for integration tasks. Devs no longer have to struggle to understand proprietary architectural touches. No WSDL files need to be parsed. No expensive, scale-resistant state-managing caches need to be added. The URI we use in the browser is the same URI our apps use to read JSON or XML, etc. It’s a glorious thing, REST. I absolutely love the style, and preach the benefits to clients whenever possible.

Another thing I peach, when I can, sounds scandalous at first. That message: If you’re adding a REST API to your site, you’re probably doing something wrong. Maybe.

REST APIs are Everywhere. Right?

All the big sites are exposing REST APIs. Twitter has on. Flickr has one. Netflix. Microsoft SharePoint. Everyone, man. Everyone.

But how many are as RESTful as they could be?

If you see the value in a REST API, the last thing you want to do is create something separate from your “main” site or service. Your site is your “API” if you’re being RESTful. If you force a separation or bolt on a separate chunk of URIs meant for API clients you’re probably wasting resources and muddying your domain.

With REST, you should have a distinct, stateless URI for each conceptual resource you provide and should respond to the appropriate HTTP verbs (most commonly, GET, PUT, POST, DELETE, HEAD, TRACE, and OPTIONS).

For example, if you have the concept of a user profile for someone named “TobyJoe” you should have a single URI that represents that profile and that URI should serve any supported format a client application requests. It doesn’t matter what the URI looks like, but there should only be one way of accessing that conceptual resource. You can serve up XML, JSON, HTML, plain text, SVG, or any combination of formats you want. HTTP and the REST style already accommodate for this using certain HTTP request headers. This problem has been solved since the Web existed (basically). And yet, we see a lot of big sites offering two distinct sets of URIs: one for their “site” traffic and one for their “API” traffic.

Really, it shouldn’t matter if someone is requesting the resource at a URI from Safari, Tweetie, cURL, a Flash RIA, or any other HTTP client. The REST style can cover all the content switching and access management you need and you can have a single set of URIs, a single set of semantics, a single engineering team, and a single set of resources to support. The user experience for your third-party development partners will be improved as well.

Twitter: An Easy Example

So why are there two URIs for my Twitter status feed? One for the Twitter-branded HTML (with great microformat support!) at http://twitter.com/tobyjoe and one for XML at http://twitter.com/statuses/user_timeline/tobyjoe.xml?

It’s the same data, in different formats. It’s the same concept: status messages for tobyjoe. Most of the formats Twitter supports are available at the http://twitter.com/statuses/user_timeline/tobyjoe.{EXTENSION} address. Why not the HTML version with the sweet microformats?

Note: I’m sure Twitter has many reasons for this separation. Legacy clients, their ever-changing architecture and unprecedented growth, organizational investment in this style. They have an amazing team over there. I’m only using Twitter as an example because so many developers are familiar with their API.

Still, as both a user and client developer, I’d prefer to see a single URI (or at least one URI template) for each conceptual resource rather than one URI for “people” and one URI template for “machines”.

It’s Not Always That Easy

I know that there are lots of hurdles with development around live products. I don’t discount the operational challenges. I don’t necessarily chastise folks who stray from REST. I would love to see the concept of the RESTful API default to a slightly different meaning that what I see on the web today. Instead of saying, “We are going to add a REST API to our site!” I’d love to see companies say, “We are expanding the choice of representation formats and verbs for some of our URLs!” Not as sexy sounding, but way sexier.

There is a common pattern in the contemporary interactive digital art world: artists’ tools are getting more hardcore under the hood.

A lot of the current stars cut their teeth (and still make their living) on Flash. I was a very active member of a messageboard in the late nineties geared towards web and interactive design and development – a distinction I share with many of the current stars. The messageboard (dreamless.org) is long gone, but most everyone is still in touch, still sharing code and competing or collaborating. It’s nice to a fairly constant community, even if their tools have changed.

A lot of people moved from Flash to Processing – a great Java-based framework and IDE – as their interests moved away from wide distribution (via the Flash player) towards lower-level access to the hardware. Being able to work (almost) directly with OpenGL, for example, was a huge benefit. Processing provides a set of capabilities that is different than that offered by the Flash player, making it a great supplement for digital artists.

These days, the most adventurous (Flash-using) artists are venturing outside of both Flash and Processing. They are leaving their virtual machines behind, diving down into C++, OpenGL, OpenAL, and raw C code. This is a scary place for a lot of digital artists, who often lack CS degrees. Instead of taking the usual CS approach of learning from the hardware up, touching higher level languages (like Java and Actionscript) and virtual machines (like the Java VM or Flash Player) dead last, artists start at the top and move down, stepping into dark, complex, fault-intolerant waters only when they need access to more powerful APIs or direct hardware access. Knowledge is built pragmatically instead of comprehensively – a fact that keeps their perspective unique and their work fresh.

The top toolset for the hardcore digital artists right now is OpenFrameworks. It’s a great C++ library with a passionate community, not at all unlike, or separate from, the Processing and Flash communities. This summer, The Barbarian Group will be announcing a (possibly open) framework with a similar purpose. Flint is a framework for C++ and Objective-C development, allowing cross-platform development that is still platform-specific (if that makes any sense), and includes support for a certain popular mobile device…

These frameworks are vital for the progression of digital artwork because they take very tedious, daunting tasks and boilerplate code and wrap them up in attractive, semantically-appropriate domain-specific languages. In other words, they solve for the user experience of the digital artist. They help minimize painful context switches and free artists up to focus on the art. Instead of trying to remember all the arguments and gotchas with creating double-buffered windows on different operating systems, the artists can spend time creating textures and thinking of new interaction models.

For a framework to succeed, it has to become almost invisible to the coder. This is true of all assistive technologies, and, in my opinion, all technologies should be assistive.

Check out Robert Hodgin’s newest work, using Flint.

near ")": syntax error

Check to see if you have any models declaring themselves as DataMapper::Resource but WITHOUT any property declarations.

No meaningful error is reported for this case at the moment (with HEAD as of last night) so it’s a weird one to debug – especially if you generate a bunch of model classes ahead of defining their behavior.

describe "Filtered fields" do
it "should filter content on save to cache expensive transforms while preserving source" do
# do it
end
end

Doing this in xUnit would probably cause you to have a camel-induced nervous breakdown.

Though I’m a recent convert to rSpec for my Merb work, I actually prefer to unit test Objective-C with OCUnit. I think it’s just part of that prejudice that tests should be written in the language of the app. Also, the more ‘natural’ it feels to write tests, the more likely folks will do so. In my experience, a great number of Obj-C developers have no interest in writing tests in the first place…

Still, rbiphonetest seems like a great project and I imagine several of the “pure” Web developers on my team who are itching to get into Objective-C will quite enjoy a familiar testing framework.

Like everyone else who prefers clean over clever and true pragmatism over dogma, I prefer Merb over some of the other options out there for day to day Web apps.

That said, I’ve not done any major work with the two yet. I have some of my long-shelved personal apps being rewritten/written on Merb master and DataMapper master, but I am kind of holding off on larger commitments until the 1.0 release.

If you haven’t checked out Merb and Datamapper > 0.9 you should.

I’m even coming around on rSpec, though I still prefer xUnit style testing because the language and flow is the same across all the types of development I do (PHP, Ruby, Objective-C, Java).

I found a Google project that looks promising, but haven’t looked into it.

Do my footwork for me!

Coding blind (no tests) is causing my ulcer to flare up.

The write-safety mechanism provided by attr_accessible doesn’t help in this situation, but having to write a custom to_xml method that steps through each of these already-whitelisted attributes is a bit silly and not very DRY.

My solution is to do something like:

def to_xml(options = {})
    super({:only => self.class.accessible_attributes}.merge(options))
end

Breaking that out, as I do, into a SecureModel mix-in seems like a good move.

I guess it was put online as well as in print (in a tough-to-find import mag). I just stumbled across the link tonight.

The formatting doesn’t seem to be there, but the info is clear enough. ;)

I don’t get a chance to write on tech topics as frequently as I’d like. I should work on that.

I first picked up Aaron Hillegass’ book, Cocoa Programming for Mac OS X, back in 2001, immediately after it was published. I’d been on OS X since the earliest public builds, and loved it. The underlying tech – from the kernel to the app frameworks – was exciting to me as a relative newbie to both the Apple world and desktop app development.

I’ve since owned every edition of the book, and almost every other Cocoa/Obj-C book out there, but have never taken a class on the subject. I did attend WWDC last year, but the topical sessions aren’t the same as an in-depth classroom experience (though they are quite valuable).

One of the benefits of a session at BNR is that all distractions are removed for a week. Students are taken away from their families, comfy chairs, favorite bourbons, loud offices, DVRs and insane clients and locked away at a remote facility for five days. They are forced to learn, taking breaks only for meals comprised of fried food and iced tea so sweet the supersaturated sugars crystallize in plain site.

Another benefit of the Cocoa Boot Camp is that Aaron guides you through his book from start to finish, lecturing and answering questions as he goes. The structure, immediate feedback, and question sessions are worth the cash on their own.

Three of us from The Barbarian Group attended (Ashley Holtgraver, Keith Butters, and myself) and I think we all found the class inspiring, educational and fun. I’d recommend any of the BNR courses to folks without a second thought.

I’ll write a more in-depth review of the class soon.