February 27, 20:35 | Comments (32)
OpenID will have to co-exist with regular user names and passwords for some time to come in most cases. So as developers we have to come up with good conventions on how to deal with this duality. To do that, it would help greatly if we were able to distinguish an OpenID from a regular user name.
Consider this flow:
With OpenID distinguishable from regular user names, you don't have to use an additional field to complicate the login or signup screen further.
It seems that there is already some support for the notion of specifying OpenIDs as complete URLs and not just their host names. Both Zoomr and Jyte explicitly encourage/require usage of complete URLs:
But there are definitely other cases where just the host name is used. So neither approach seems to have taken hold as a defacto standard. I'd recommend that we move in the direction of full URLs. And if your site only takes OpenID, then you could still reinforce that idea by having login be something like http:// [input field].
February 26, 6:09 | Comments (45)
I'm going to London with Mary for a long weekend in the beginning of March. We've both been there a couple of times and consumed the usual suspects of turismo. Skipping those, where should we go? Which restaurants must we dine? What plays, performances, or exhibitions must we see? Thanks, lazy web. You're the best.
February 26, 5:54 | Comments (19)
I've loved the idea of OpenID ever since I sat down with the boys from Verisign and East Media to hear them talk about PiP and the Rails integration, but I never really got around to playing with it. "How big of a deal is having multiple logins really?", went the thinking. For a lot of people the answer is still "not a lot". But I'm starting to see the light.
Over a few hours today, I read up on and implemented OpenID logins for Highrise. That opened my eyes. Both to how easy it is to get working as an alternate login solution and, more importantly, how decent the flow actually is.
Yes, there's redirection to another site involved, but once you've saved the login for a certain site in your OpenID and you're logged into your provider, you don't even see the redirection. At first that might seem a little scary. Logging into a site without even entering a password? But then again, that's pretty much how I authenticate with my application servers around the world through SSHKeychain and on all sites that gives you Remember me?
Continued...
November 28, 18:38 | Comments (19)
Agile Web Development with Rails is the primary volume on Rails development and the 2nd edition was recently sent off to the printers. It should be available in retail around December 15th. That's pretty exciting in its own right, but what makes it even more exciting is that it'll hit the stores just about the same time that Rails 1.2 premieres in final form.
Now it doesn't take much of a genius to figure out that AWDwR #2 is meant for Rails 1.2. It bridges the gap from first edition of the book and covers all the new goodies Rails has adopted over the past year. You got coverage of migrations, polymorphic associations, multi-format actions with respond_to, RJS, resources, and all the best practices these techniques shine with.
Coordinating a book with any open source project is notoriously difficult, coordinating one with Rails almost inhumanly so. Regular book cycles can easily spend a year from idea to print. Considering the pace of evolution in the Rails world, that obviously wouldn't work.
Luckily for AWDwR, the publisher is no regular publisher and the primary author is no ordinary author. The Pragmatic Bookshelf and Dave Thomas have been committed to the herculean task of tracking the every move of the Rails code base and the intentions of the Rails core team. Every time we reverted our opinion, change defaults, or introduced new API elements that deprecated old ones, Dave has been there to rewrite and update sections of the book to match.
But as extraordinary the primary authoring of the book has been, it's just as impressive to recognize how insanely well-tested this book is by the time it hits the shelves. It's had a beta process stretching months and months and has been reviewed by hundreds of developers. It's been put through the paces over and over again by people with widely different backgrounds and the final product displays an incredibly amount of polish.
Now I'm obviously biased. Rails is my jewel and my name prides the cover of AWDwR, but this is truly the one book that every Rails developer and every aspiring Rails developer should have in their possession. I'm really proud to see this level of documentation available for this little collection of Ruby scripts I started just over three years ago.
And you can even get it all now! The final version of the book, the one shipped to the printers, has just arrived as a PDF. The Pragmatic Programmer site even sells a combo pack where you get the PDF now and the paper version as soon as the ink dries. You'll have to use it together with Rails 1.2 RC1, but by the time the paper version arrives, so should the final release of 1.2.
Finally, I want to thanks everyone who bought the first edition of this book. It's phenomenal success has really helped put Rails on the map. Not only has it cultivated an almost overwhelming range of book developments, but it has also encouraged the economic ecosystem at large to grow faster and stronger.
UPDATE: Just learned that first edition made #3 on Amazon's Best Books of 2006 for the Computers & Internet category. w00p!
November 17, 4:14 | Comments (34)
It feels like we've reached the last twenty minutes of A New Hope. The rebellion has the schematics for the deathstar and their army has charted the course for a final showdown. The battle is far from over, but you, the viewer, are no longer in doubt which way its going to turn out.
Yet to the commanders on deck, I'm sure it looks like they have nothing to worry about. The standardization of the standards is progressing full-speed ahead. We have committees to oversee the committees. So the mumblings of a small band of renegade hackers is hardly going to matter. Don't they know that the battle station is soon to be fully operational?
It's a common and recurrent theme, of course. I'm sure the pushers of EJB and Corba felt equally invincible long after their rebels had captured the blueprints for their destruction. Perhaps that's just how a large sector of the IT industry has to work. There must be a new frontier of bottom-less complexity available to get lost in. Something that needs tooling, big consulting houses, five-year mission statements, and barriers of entry and exit.
Anyway, I just wanted to do a virtual "I'm getting out the popcorn for this one!". It's fun to watch in real time. Especially when the battle is being narrated so eloquently by people like Pete Lacey, see The S stands for Simple, and Duncan Cragg, see The REST Dialogues.
I'm also thrilled that the forthcoming Rails 1.2 is all about making REST as natural to web developers as possible. There's certainly an awful lot of people who could not care less one way or the other. They are the ones at stake. And it's not even that hard. REST is already easy. Throw a little help, guidance, and baked-in convention into the mix and the response to a request for a SOAP interface will soon be a common "you want me to do what?!?!".
