“IDEs are draining users away, but it’s not the classic fat-client IDEs that are ultimately going to kill Emacs. It’s the browsers. They have all the power of a fat-client platform and all the flexibility of a dynamic system. I said earlier that Firefox wants to be Emacs. It should be obvious that Emacs also wants to be Firefox…

“… [N]ow the browsers are starting to sprout desktop-quality apps and productivity tools. It won’t be long, I think, before the best Java development environment on the planet is written in JavaScript.”

I’m more of a vi user these days—it behaves much more consistently over emergency ssh sessions—but as a general advocate of Emacs over IDEs I can see his point. Browsers should want to be like Emacs, or at any rate more like the VM of your choice.

Between browser-as-VM, Firefox, ECMAScript and compatibility frameworks there’s the seeds of an RIA revolution. After all, to what extent will industries gladly rest their financial weight on RIAs, so long as they’re all written in Flash-on-the-browser, and so long as browsers remain so unpredictable and Flash remains… well, Flash?

sp_rename
  [ @objname = ] ‘object_name’ ,
  [ @newname = ] ‘new_name’
  [ , [ @objtype = ] ‘object_type’ ]

So say you have a table called t_est, with a column in it called est_client. You want to rename these to t_job and job_client respectively. Firstly, with some trepidation, you rename the table:

sp_rename ‘t_est’, ‘t_job’

You find, miracle of miracles, that it works! SQL Server warns you about stored procedures breaking, but looking at other dependent tables you find that foreign key constraints have all been updated so you still have referential integrity.

At this point, you might try renaming a column called, say, est_client to job_client as follows:

sp_rename ‘est_client’, ‘job_client’

That’s wrong, of course, as you soon find out: the object_name needs to be qualified to distinguish it from . So you might try:

sp_rename ‘t_job.est_client’, ‘t_job.job_client’

Well, that was successful, but: oh! You now have a column called t_job.job_client, in the t_job table. It looks like new_name shouldn’t have been qualified after all: you should have assumed inconsistency where consistency was implied by the spec. Well, dealing with Microsoft’s tech documentation is certainly a learning experience at the best of times, so chalk this one up to experience. But if you now try to learn from your mistakes and revert the column name, you find you can’t, because:

sp_rename ‘t_job.t_job.job_client’, ‘job_client’

tries to rename the column job_client, owned by user t_job, in table t_job… to job_client. After much headscratching, you finally realise that you can employ double quotes to qualify the column name and make SQL Server treat the dot as a literal dot and not a separator:

sp_rename ‘t_job.”t_job.job_client”‘, ‘job_client’

You sit back, grudgingly satisfied. More time passes. Spring arrives. The owls are not what they seem.

REST plays the same role as open source and open APIs: It eliminates tooling and vendoring as artificial barriers to adoption.

Interestingly, a corollary to this was brought up at Barcamp Brighton this weekend. During Gareth Rushgrove’s talk about REST and Nabaztag, a chap whose name I’ve again forgotten (although I’m sure someone like Fatty will enlighten me) pointed out that much of the push of SOAP is coming from the vendors, because the vendors make their money from selling tools, and REST development needs very few tools, most of which are free.

Undoubtedly there’s a set of problems that REST finds hard, but this truism is extended by SOAP vendors to the hard-to-prove (but also hard-to-contradict) claim that it’s a larger set, or a set more pertinent to enterprise solutions, than the set which SOAP finds hard. It convinces the consumers, because intelligent data mining and storage has always been a difficult problem, and a simple solution like REST feels like underkill for the job in hand. They let you confuse libre and gratis, the vendors point out (I see them sitting on the consumer’s shoulders with tridents at this point): so where’s the hidden cost of this free lunch?

(hat tip to Simon Willison)

Our development is explained on those list postings: I’ll put a diagram and more coherent explanation up here when I get a chance.