I’m using the Internet Archive/Wayback Machine to compile a Visual History of Redmonk.net.
It’s not complete yet - the Archive runs about 6 mos behind.
January 2008 Archives
Just wanted to follow up my post of the other day with a comment I just posted over on The B List.
Just as Dreamhost offers a one-click install of Wordpress, I could see it offering one-click installation of an application on a pre-installed/configured framework system. If the process of uploading/configuring a module or theme can be made easy for the end-user/developer, then I think there’s hope.
I was browsing my own archives, and came across this post from Dec. 17th, 2004:
A random idea I had the other day: create a distributed client system like SETI, where the processing time is being donated to third world or developing countries where processing power is hard to get. I don’t know what the data sets would be, nor how it would all be setup, but it’s an idea. - Random Idea: distributed computing for the third world
I still think it’s a pretty good idea.
Tim Bray has a ongoing (ha) series of predictions for 2008, generated as a response to this request from Sun.
Recently, Tim posted Problems With PHP, which left me thinking and ambivalent, and found me composing this response in my head at midnight.
PHP - Easy but Ugly
Tim says:
Yes, … • It’s enabled huge numbers of people to create decent Web sites without having to learn too much or try too hard; a very good thing. Also, it runs pretty fast. Plus, it’s been used to build some of the most instructive and useful apps out there, like MediaWiki and WordPress.
PHP has huge adoption among ISPs and shared hosting providers for this very fact. People can create “dynamic” (remember when that meant “my site has a form!”) websites very easily with little work on the provider’s part.
This, in my opinion, has been the secret to WordPress’s success as well. Your average user, with just enough FTP experience to hang themselves and a helpful provider, can get WordPress up and running in about 15 minutes (10 to request the db and 5 to install WordPress). Adding plugins requires only a minute to download one and ftp it up to the site, and a minute to enable it in the admin.
… and No • On the other hand, speaking as an actual computer programmer, I really dislike PHP. I find it ugly and un-modular and there’s something about it that encourages people to write horrible code. We’re talking serious maintainability pain.
No argument from me. PHP ain’t pretty. And it’s isn’t particularly easy to write re-usable code, PEAR notwithstanding.
But, I keep coming back to the fact that PHP is so dang easy to work in. And reload-on-refresh (see below) means that changes get reflected immediately, making hacking really really fast. WordPress is pretty easy to extend, it has a ton of useful hooks for plugin developers to hang interesting stuff off on — and they have!
Meanwhile…
The other language I’ve really taken a shine to is Ruby. Not Rails so much, which I still find to be too full of magic for comfort. As an old-skool web guy I still prefer seeing some metal from time to time. But I really really enjoy Ruby for shell-scripting tasks - I’ve written several file validators at work and I can whip them out and re-iterate, adding features and such quite quickly. Ruby took just enough from Perl to make it fun (it had me at var =~ /re/). I’ve even branched out into small web apps using camping, but I confess to even a slight bit of unease at the behind-the-scenes shenanigans it plays.
Now, as great as Ruby-the-language is, I don’t see anyone writing an app like WordPress in Ruby, and I don’t see it getting the adoption that PHP has for a while, if ever. Why? Well, for the reasons I outlined above.
1) PHP’s greatest ugliness is also its greatest strength: You can mix PHP and HTML right in the same file, and most users do. It’s awful from visual and maintenance viewpoints. BUT you can point any recent Apache at that .php file and it will spit out pretty much whatever HTML you told it to. It’s stinkin’ simple.
With the possible exception of the ill-fated mod_ruby, I don’t know of a common way to do the same with Ruby. You have ERB for PHP/ASP-style code delimiters, but even ERB is typically used with an app framework of sorts (see the next point).
2) Reload-on-refresh: Hit reload on your browser window showing that aforementioned .php file, and it will re-run the script. Any changes you’ve made will be reflected in the page. Now this has all kinds of scalability issues, I know, and there are ways around it. But the default is reload-on-refresh, and many apps - including WordPress - work great this way.
Again, with the exception of the defunct mod_ruby, the way to put Ruby on the web is via Rails, or to a much lesser extend, camping. Both make use of persistent applications, which means that to load new code the application has to be restarted, which also usually means killing a FastCGI process via a shell command or automated build/deploy process. [*Update #1]
While perfectly acceptable for applications with no user extensibility (BaseCamp, HighRise, Twitter, etc.), apps like WordPress are expected to be modified by non-highly-technical users via templates, plugins, etc. and they’re not all going to have shell access or the knowledge of the command-line necessary to keep a persistent app running, or reload it when needed.
3) Persistent apps are unloved by shared hosting providers: Dreamhost, my hosting provider, is an awesome host. They even provide Ruby and Rails pre-installed on their servers. But getting a persistent app up and running while avoiding the memory-and-process hunter killer bots is really frustrating.
Outro
Well, there’s more I could say that would not necessarily add any clarity to my points. Perhaps I can end with a request.
My Ruby knowledge is limited, I’ll confess. I’ve written some Rails code, but got frustrated trying to find a place to host it and gave up on the whole Rails thing. Some of what I’ve described in this post may be wrong, and I hope those of you who know better will set me straight gently. But what I want to know is:
Could an app like WordPress, easy for users of medium technical knowledge to run and customize, easy for developers to extend, and easy for hosts to provide, be written in Ruby? If so, how?
For the DiSo project, Chris and I decided to start with WordPress because it had all the attributes I’ve described. We want to branch our into Ruby at some point, and I consider this discussion to be extremely important to that process.
Update #1: Tim pinged to remind me - idiot! - that Rails will happily reload code while in dev mode. Sorry for the oversight.
Update #2: Weird, I wonder if the Dreamhost guys saw my post, or if they saw Tim’s post, or if it was just a massive coincidence.
This started out as a post to the diso mailing list, but drifted. ;-)
Open Source, Product Design, and DiSo
Wherein Steve looks at two small reasons why Facebook “works” and what that means for the inside-out social network.
I wanted to put out some thoughts this morning about an aspect of DiSo that we haven’t touched on a lot. This is, in some ways, a response to Chris’s most recent post, The problem with open source design. But this isn’t really about design per se.
Of course, it was 3 am and I was up to get a drink, and decided to check Google Reader… I saw Chris’s post and was awake for another 40 minutes thinking about it - open source, DiSo, and product design.
Facebook and the “Big Lebowski” Effect
My wife just signed up on Facebook because she got an invite from a friend. It happened to be up on the screen when I went to check Reader, and I had to admit, once again, that Facebook really “hangs together” well. One reason Facebook works is because (as the silo that some of us are eager to get out of) there is a real focus internally on visual and funtional consistency, on design. Unlike MySpace, Facebook does not allow for personalized home/profile pages, so users know what to expect on most any profile page - an attractive interface with common components in .
I call it the “Big Lebowski” effect (“That rug really tied the room together.”). DiSo is facing a fundemental challenge here: as a decentralized system, how do we provide the sense that it is “tied together” by something? This is important to real users and should be important to us.
Chris has a tip:
Be clear about the problem you’re solving. Nothing spells disaster for a design process more than fishtailing. If you don’t know what problems you’re trying to solve and you don’t have razor-sharp focus on it, chances are you’ll be open to whatever feedback you can get your hands on, grasping for some notion of what the hell you should be working on.
Facebook and the Shared Experience
That “tied together” feeling also creates in Facebook a shared experience between its users that adds to the sense of comfort and community. Members use a common interface and share applications, a flood of news updates, application messages, and “pokes”. It can get overwhelming, and requires constant “care” to keep up. But everyone is doing it, and the churn is another shared experience that keeps members coming back.
Ideally, DiSo will give users more control over their social interactions, but as we work to solve the thorny “distributed” issues, let’s not forget the “social” ones. My wife has her own Wordpress blog and thinks DiSo is a great idea - but to be really useful to her it has to maintain that fun, social quality while adopting the distributed/self-determined model.
Recommendations for moving DiSo forward
Ok, I’m on thin ice in the practical “what to do about it” section, but here are some ideas (in no particluar order). I’d love to get feedback, and we’ll be discussing this on the list as well.
- DiSo needs some visual/process design: Some facets will be influenced by the host platform (i.e. Wordpress) but others should be consistent across platforms so that uses begin to be able to identify DiSo-powered sites by more than a 80x60 pixel badge. ;-)
- A common profile page: subject to some theme-matching CSS, there should be a common profile page generated by DiSo. “My DiSo Profile” should be hosted on the user’s blog but should be recognizable to any DiSo user as what it is - representative of the author’s connection to the DiSo network.
- Some branding: I don’t want to create another club - quite the opposite in fact. But there is value in being able to clearly communicate what you’re on about and branding gives you a hook to hang that on.
- We need to work on groups in the DiSo-verse. Chris and I have been brainstorming on this and hopefully one of both of us will have some time to write up our thoughts on it soon. Being able to say “I’m a part of such-and-such group” is a powerful statement of self-ideation, and it’s one that I for one want in DiSo.
Thanks for reading - if this stuff is interesting to you, come join us on the mailing list and participate!
