The Two Webs

Dare Obasanjo: The Two Webs:

This is an interesting distinction and one that makes me re-evaluate my reasons for being interested in RESTful web services. I see two main arguments for using RESTful approaches to building distributed applications on the Web. The first is that it is simpler than other approaches to building distributed applications that the software industry has cooked up. The second is that it has been proven to scale on the Web.

The second reason is where it gets interesting. Once you start reading articles on building RESTful web services such as Joe Gregorio’s How to Create a REST Protocol and Dispatching in a REST Protocol Application you realize that how REST advocates talk about how one should build RESTful applications is actually different from how the Web works. Few web applications support HTTP methods other than GET and POST, few web applications send out the correct MIME types when sending data to clients, many Web applications use cookies for storing application state instead of allowing hypermedia to be the engine of application state (i.e. keeping the state in the URL) and in a suprisingly large number of cases the markup in documents being transmitted is invalid or malformed in some ways. However the Web still works. 

REST is an attempt to formalize the workings of the Web ex post facto. However it describes an ideal of how the Web works and in many cases the reality of the Web deviates significantly from what advocates of RESTful approaches preach. The question is whether this disconnect invalidates the teachings of REST. I think the answer is no.

Deleted my del.icio.us account, keeping RawSugar

del.icio.us does not allow me to push my feeds to it, forcing me to spend effort using its service that is better spent elsewhere. The pattern emerged where I would post links on del.icio.us far more frequently then paradox1x or at Philly Future, which, in the end, is counter productive – I already have a publishing platform!

Many of these services have tools that enable you to post on them and have that participation pushed back into your site. Other tools exist to grab your data from these services and pull them into your primary space. That’s not enough.

I predicted earlier that these services will have to acknowledge and leverage what we already do in our own spaces, in our own environments. As each of us start our own blogs – our own publishing systems – what do we gain by posting twice? Three times? Four times? Not all that much when I should be able to post once, in an environment of *my* choosing, syndicate what I want, and be done with it.

RawSugar gives me this capability, saving me a lot of time in sharing what I want to share with a larger community.

I’m happy you kept after to to try it Bill, so I am going to stick with it for now.

“It’s not like you’d find in on Google … right?”

Philadelphia Inquirer’s Kristen A. Graham deserves credit for writing about teenagers and MySpace and not putting out yet another sexual-predator, obscenity, fear-fest as so many others have.

She parses the real issue that few fellow technologists address or want to concern themselves with – how MySpace has empowered millions of children to share their private lives in full public view, the repercussions of which are not yet understood.

In fact, I’ve only seen one post, by Scott Karp, and he was met with a chorus telling him he didn’t get it or that “no one has privacy anyway so who cares”.

One oh his critics attempted to reduce the concern to that of a parent allowing the child to ride a bike, and of course we let our children ride bikes. So why not allow them participate on MySpace? Shoot – we should be encouraging both right?

How great it would be if it were that simple.

When you address privacy concerns on MySpace (or Xanga, or any other social media platform), you MUST address the nature of the web – when you post you are not simply sharing that participation with those who visit your site, but you you are contributing to a store of information that is cached on servers you don’t know of, syndicated to places you have no control over, retrievable, sortable, and searchable again and again and in perpetuity. Forever.

Sure sexual predators are a concern, but threats to living so publicly – in such a scale – permanently – are manifold.

The job we mysteriously couldn’t get. The date who ditched us for some unknown reason. The apartment application denied. The business loan we were turned down for. The incapability of moving on from past mistakes since anyone can now retrieve them and use them for their purposes. That new ‘friend’ of ours telling us about the new shoes that we just have to buy.

Imagine if your credit report was in public view. If you could not get a report of who was requesting it. Think about it.

That’s small fry in comparison to what we are *willingly* doing here.

I’m not some Luddite. I’ve had a web presence since 1996 and a blog since 1998. I don’t know many who have lived so openly on the web. But I do keep somethings close to chest and off my blog, understanding, long ago, the responsibility I had to my employers, my friends, my family, and myself – long term.

I’ve attempted practice, over the years, the good advice Rebecca Blood gives in the article:

“people forget they are publishing when they are blogging. It feels personal, it feels like a conversation – but it’s not.”

In today’s TMI age, it’s a given that that new boyfriend or girlfriend, that recruiter for the job you desperately want, is going to Google you, she said. Then they’ll find out that you’ve written about how you keep multiple sex partners and play endless rounds of Minesweep on company time.

“Whoever you don’t want to read your blog – your mom, your boss – will probably find it. Keep that in mind,” she advised.

You need to wonder why others in the digerati don’t share her concerns… maybe she sounds too old fashioned? Too old school?

Maybe Rebecca Blood just doesn’t get it?

The price we’re all going to pay is huge.

“The only architecture that matters”

lesscode: The pragmatic’s guide to Web architectures :

The Web thrives not because it uses a strict architectural style and a coherent technology stack. It thrives because so many sites pay little attention to REST and choose to focus on their users instead. It thrives because mal-formed HTML pages include GIFs and PNGs and Flash and badly written JavaScript that just works. It thrives because people go on the Web to send e-mail, IM, do VoIP and trade BitTorrent files.

The search for the holy grail, the one technology to rule them all, is as old as technology itself. I’m fine knowing we’ll never settle the score, never know whether Vi is truely better than Emacs, or whether Eclipse shadows them both. But unless you’re a vendor making money on one horse, it doesn’t matter to you.

If you’re a pragmatic developer, you have one tool in your toolbelt that always wins the day. It’s the ability to think, ask questions and make choices. To choose solutions that are best for the problem you’re tackling right now. And to keep learning. Because there will always be some new technology that’s better at solving some use case or another.

The only architecture that matters is the simplest one you can get to solve the problem at hand

An email I was happy to send….

Hello,
Due to down time that my users were subjected to – by a decision one of your staffers made in shutting down access to our database – I have migrated the sites and domains I maintain that were hosted and managed at New Dream Network and Dreamhost to a more robust and secure solution.

Previously, when your staffers worked with me to diagnose and solve a high CPU situation, they showed patience and willingness to find a solution to pass on your other customers. Dreamhost impressed me then. I was very much ready to sing its praises.

That patience and customer care was entirely missing in this episode.

Without warning there was the decision your staffer made to shut us down. He sent an email to me upon doing so. And then for the next 24 hours there was no reply to any emails I sent to you for details.

Adding serious insult to injury was the removal of all access to my database, not permitting me to diagnose the problem, or migrate to a new host with up to-date data. One of your staffers told me it was my responsibility to have a back up. Well duh.

I had come to expect better from Dreamhost.

I hope you can rectify the problems you are experiencing with your customer care. I hear more and more from others similarly dissatisfied.

Please cancel my account immediately.

– Karl

atom2rss: a poorly written Atom to RSS converter

Not to vent, but Blogspot’s default of outputting Atom and no RSS for its users gave me all sorts of headaches. A huge expense in time that that drove me away from more important matters at Philly Future. CivicSpace/Drupal’s aggregator does not handle Atom. That means if you are on Blogspot, a site like Philly Future could not include you. An upcoming version of Drupal’s aggregator will have this capability. Bryght’s hosted Drupal solution does right now. However, I couldn’t wait for Drupal to release an aggregator with Atom functionality, and I’m self-managing Philly Future – so I needed my own solution.

A simple service that would, upon passing it a URL of an Atom feed, produce RSS, be best. That way I could avoid hacking Drupal code. A few folks suggested I use Feedburner, and for a while I did, until I read the terms of service. I was, inadvertently, claming I owned those feeds! Once I discovered this, I removed those feeds from my Feedburner account and found another way. After an exhaustive search on Google, I found a few Python implementations of what I was looking for, but no PHP. The hosted web services that I did find wanted to charge money, or warned they were to stop service at any moment. I had to do it myself.

Not that anyone needs converters like this anymore as most services and aggregators handle both Atom and RSS, but I figured it would be a good thing to release for others reuse, so here it is. Using the required Magpie RSS, the PHP RSS Parser library, it retrieves, caches, and parses the passed in Atom feed, iterates over its items, and outputs RSS. A brute force approach, certainly not perfect, nor complete in terms of the metadata it attempts to convert, but one that has worked for the great many Atom feeds Philly Future encounters.

Motherhood and Apple Pie

lesscode.org: Motherhood and Apple Pie [@lesscode.org]:

The internet is not an accident. The internet was not bound to happen. There was no guarantee that the internet would reach its current state as a side effect of emerging digital processing and communications capabilities. We did not recover complex alien technology.

The internet, that place where all eventual business will be transacted, all content and media will be distributed, all correspondence will be exchanged, all history will be recorded, and all pornography will be is being admired, has a design – and its meant for exactly these purposes.

Many of the principles that led to this design are still with us today, although I would challenge you to ascertain them by observing the mainstream technologies being peddled by leading vendors, publications, and analyst firms. Those who rose to power in a much different environment, where the short-term profits of disconnected, dead-end business software was deemed more important than laying a fertile ground where millions of new ideas (and hence new profits) could bloom.

But the dead-end has long been reached and so these industry leaders have turned their attention to this new place, built on principles and values very different from their own, and have somehow reached the conclusion that this thriving ecosystem must be re-arranged such that they have somewhere to place their baggage. Instead of embracing the people, principals, and technologies that gave rise to this phenomenon they have chosen to subvert its history and to implant the ridiculous notion that it is â€Ŕincapable of meeting the stringent demands of the business community.â€?

Not only have these business radicals claimed the internet as their own but they have also somehow gained the confidence of all the worlds industry in their ability to deliver a new and sparkling internet, one no doubt capable of reproducing the complexities and flaws that plague existing mediums so as to make it feel more like home. They’ve brought their own principles and agendas, asserting them as obvious and correct while ignoring the wisdom we’ve gained and shared and gained and shared over years of collaborative practice and observation of working systems at this scale.

A great essay. I don’t agree with some of his conclusions, but it and especially its source material are must reads.

A little about Cofax and what I do for a living

I’m one of the lead developers (one of three architects) of Knight Ridder Digital’s Cofax content management system.

Cofax, from it’s humble origins in Philadelphia, became one of the major toolsets Knight Ridder used for content management, spreading in usage to over twenty newspapers by March of 2001.

Due to a lack of resources in both finances and personnel, we employed an open source methodology to assist in it’s development. We had zero budget, and and just five developers when we started way back in 1999 and right from the start open source seemed the way to go.

This was done so very successfully, with the current version in CVS being a stable, satisfactory (award winning even) tool for those that used it. Newspapers were excited with the power it gave them to cover the news, designers were happy with the freedom it gave them, and administrators were happy with it’s ease of maintenance and deployment. In fact, there is a consulting company that is actually making money deploying Cofax sites in France. You can too. It’s open source.

In February of this year Knight Ridder Digital migrated to a new system called the SDP. It uses Cofax in it’s core, but also incorporates a number of proprietary technologies developed to meet specific needs.

So in a sense, you can say that Knight Ridder is still using Cofax, but in another sense, it’s using something much more extensive and powerful. Developed to meet a bigger set of requirements and built by a much larger tech team in which I was a member, but unlike Cofax, am not an architect.

I’d love to discuss the SDP with you but my feeling is I should refrain from doing so since it is internal company business. I have kept from talking about it in the past and will continue doing the same. Just understand that it is Cofax deep in it’s core, but utilizing a huge array of new technologies to meet new business needs. It’s implementation is vastly different from Cofax’s as well. Keep that in mind.

I am still the lead maintainer of Cofax and now, finally, have permission to talk about it and discuss it here at my home page and am happy to do so. It’s story is one I think you will find interesting and it incorporates technologies which you will find familiar, but it’s in the combination of those technologies that makes it unique.

I’m hoping along the way to recruit some help with maintaining the project. Within the core Cofax product lies an outstanding CMS if I say so myself.