" /> Bill de hÓra: May 2006 Archives

« April 2006 | Main | June 2006 »

May 31, 2006

links for 2006-05-31

May 29, 2006

Mob 2.0

I think I'm gonna run out and buy a few O'Reilly books. To protest.

links for 2006-05-29

May 27, 2006

links for 2006-05-27

May 26, 2006

Web Based

Web based - works for me.

Using IM for grid computing

Tim Bray:

"My problem is that I’ve been a Unix guy for twenty years and a Web guy for ten. My feeling is that if something says it’s a service, the right way to talk to it is to get a hostname/port-number combination, call it up, send a request, and wait for a response. My feeling is that a good way to have processes work together is for them to exchange streams of text using standard input and standard output. My feeling is that if I’m going to be stressing out the performance of an app on a grid, I don’t want too many layers of abstraction between me and the messages. My feeling is that server failures are going to have to be handled in an application-specific way, not pushed down into the abstraction layer."

XMPP. Especially the Erlang* server, ejabberd, as it can be managed with ejabberdctl the same way you manage Apache with apachectl. And it's fast. Want to create a compute/result farm for all things trivially parallelisable? Use a chatroom to coordinate the workers. Want to listen to interesting arbitary activity on a heteregenous networks? Use PubSub to subscribe to RT data feeds. When I look at the OGSA stack I'm fairly sure XMPP is to Grid and JINI as HTTP was to WS and CORBA. Give it a few years - instant messaging is where real commodity grid action will take place.

MapReduce. Tim mentions hadoop. I susoect hadoop got spun out of Nutch cos it was where all the action was at, and the basic spidering - index - respider - reindex cycle was being given short shrift. But mapreduce sure likes the Linda in() and out() operations, as you see them in the implementation Gelernter and Carrerio outline in How To Write Paralel Programs.


* as in, yeah, we do SMP.

May 25, 2006

Architecture of Participation

Tom Raftery:

"One of these events - the upcoming Web 2.0 half-day conference is the target of a cease and desist letter (below) from the legal team of O'Reilly publishers. Basically O'Reilly are claiming to have applied for a trademark for the term 'Web 2.0' and therefore IT@Cork can't use the term for its conference. Apparantly use of the term 'Web 2.0' is a 'flagrant violation' of their trademark"

It'll be interesting to see how this plays out, given Tim O'Reilly's OSS, copyright and patents leanings. The leter appears to have come from CMP and not ORA, although it mentions O'Reilly in passing. Raftery is one of Ireland's most popular tech bloggers - every web developer in the country will know about this by Friday lunchtime.

links for 2006-05-25

May 24, 2006

Is The Desktop UI Metaphor Dead?

Don Norman:

"Oh," people rush to object, "the Google search page is so spare, clean, elegant, not crowded with other stuff." True, but that's because you can only do one thing from their home page: search.

This should be no surprise, given it's a search interface. Norman has more:

Why are Yahoo! and MSN such complex-looking places? Because their systems are easier to use. Not because they are complex, but because they simplify the life of their users by letting them see their choices on the home page: news, alternative searches, other items of interest. Yahoo! even has an excellent personalization page, so you can choose what you wish to see on that first page.
It's surprising to hear this argument from man who championed the Information Appliance - "where the computer disappears into the tool and becomes invisible". As with building architecture perhaps most people's needs are too unsophisticated to warrant the attentions of usability experts and information architects.

Popular thinking is that the big portals are complicated noisy monoliths, and not simple, easy to use applications.

The issue with web portals is that you only tend to care about doing one thing at a time - everything else at that point is a distraction. Portals by their nature tend to assure it's all noise, all the time. Web portals are an extension of the desktop idiom to the web. They are trying to cram many items, activities and chunks of information into an an area smaller than a tabloid newspaper's frontpage. Portals then are like a cluttered desktop where the entire surface is overtaken woth papers, diaries, reports, posts-its and gadgets being charged.

Historically portals have not existed to benefit end users - they're a relic of AOL and Compuserve walled gardens, going back to the day when well paid people had meetings about "stickiness". Maybe portals and homepages are less neccessary when you can try to guess what you're after with a search. Nonetheless Google's does have a portal, which is here: http://www.google.com/ig.

What is overlooked is that Google's search engine rose to dominance when search engines had all but turned into portals with varying levels of irritation. With that 'simplistic' interface they have cornered search, the most important Internet activity after email (and with GMail they have made signficant strides in "searchifying" the classic email interface). The users clearly voted with their mice. But that detail would not suit Norman's argument, which is essentially the Google search UI draws users despite being a bad design. You can feel the "does design matter?" debate looming. If experts think Google has bad design, then the answer is surely either "no" or a qualified "do you mean design as in pretty?".

Is Norman out of touch? No, but it's telling that he focuses on the search page, but not the results page. There's arguably no need to bother with a dedicated page for maps when you can start the search with the word "map" or search for address locations and have the map option appear alongside the results.

Perhaps the hunt and peck approach of searching (along with gaming) is becoming the dominant computing metaphor, replacing nearly 3 decades of user interfaces based on the metaphor of an office desktop (ironically the metaphor itself being pushed into irrelevancy by desktop computing). If so, usability experts will need to reconsider what they deem to be best and appropriate.

Using TinyMCE in Django's admin

After a few failed attempts, I managed to get TinyMCE running inside Django's Admin. This is nice for editing html fragments and suchlike. Here's what to do.

First, download TinyMCE and unpack it into the media folder in Django. For example, if the path to your Django Admin is:

   /usr/local/python24/site-packages/django/contrib/admin/media

then put the TinyMCE js folder (in the distro this tinymce/jscripts/tiny_mce) here:

   /usr/local/python24/site-packages/django/contrib/admin/media/tiny_mce

Here's a grab from Windows showing what you should end up with:

tinymce-in-django-admin

Configure the TinyMCE pane. In the django/contrib/admin/media/js folder, add a textareas.js file that will initialize and configure TinyMCE. Here's another grab from Windows showing what you should have:

tinymce-in-django-admin-config


I used the AddWYSIWYGEditor configuration from the Django Wiki for this. It's a minimal setup that grabs all textareas on the page and applies TinyMCE to them. You can download the configuration from here as well: textareas.js.

That's Django Admin set up.

Now let's configure a Model class to use a rich edit area. Here's a model called StaffBio that isn't configured to use TinyMCE:

    class StaffBio(models.Model):
        name = models.CharField("Name", maxlength=128,db_index=True)  
        position =    models.CharField("Position", maxlength=128,db_index=True)  
        bio = models.TextField("Biography")
        fote = ImageField("Photo", null=True, 
               blank=True, upload_to="E:/home/dev/storage/StaffBio/fote")
        pageorder = models.IntegerField("Appearance on bio page",
                  choices=SITEORDER_CHOICES, db_index=True)  
        jobcat = models.CharField(maxlength=1, 
                  choices=JOBCAT_CHOICES, db_index=True, default='P')
        
        def __repr__(self):
            return self.name
    
        class Meta:
            ordering = ['name', 'jobcat', 'status']
            verbose_name = "Staff  Bio"
        
        class Admin:
            fields = (
                ('Content', {'fields': ('name','position','bio','fote', 'jobcat', 'pageorder')}),
                ) 
            list_display = ( 'name', 'jobcat' )
            list_filter = ['status', 'jobcat']
            search_fields = ['name']

In Django's regular admin setup it will look like this:

staffbio-poor

To configure it, we need to add one line to the Admin class - a 'js' array field - like this:

    class StaffBio(models.Model):
        name = models.CharField("Name", maxlength=128,db_index=True)  
        position =    models.CharField("Position", maxlength=128,db_index=True)  
        bio = models.TextField("Biography")
        fote = ImageField("Photo", null=True, 
               blank=True, upload_to="E:/home/dev/storage/StaffBio/fote")
        pageorder = models.IntegerField("Appearance on bio page",
                  choices=SITEORDER_CHOICES, db_index=True)  
        jobcat = models.CharField(maxlength=1, 
                  choices=JOBCAT_CHOICES, db_index=True, default='P')
        
        def __repr__(self):
            return self.name
    
        class Meta:
            ordering = ['name', 'jobcat', 'status']
            verbose_name = "Staff  Bio"
        
        class Admin:
            fields = (
                ('Content', {'fields': ('name','position','bio','fote', 'jobcat', 'pageorder')}),
                ) 
            list_display = ( 'name', 'jobcat' )
            list_filter = ['status', 'jobcat']
            search_fields = ['name']
            js = ['tiny_mce/tiny_mce.js', 'js/textareas.js']

The js field allows you to set javascript for the admin screens. The array itself contains links to the textareas.js file and to the base tiny_mce.js script. One thing to note here is that each link is relative - as of May 2006, Django admin will automatically prepend these links with whatever the value of ADMIN_MEDIA_PREFIX is in your settings.py file (this tripped me up initially).

And that's it. When you go back to your admin and refresh, you'll have a rich text area courtesy of TinyMCE.

staffbio-rich

No doubt the admin is workable with Kupu or FCKEditor if that's your preferred html editor. For me, TinyMCE made sense as it was easy to set up and there was a existing configuration on the Wiki.

The next thing I want to do is install TinyMCE as the default Django Flatpage editor; that will require patching the existing admin module, and probably adding a flag to settings.py to enable/disable it. It would be nice too if the setting was global instead of having to markup each model's Admin class. The only way I've seen to do that to date is to create a new model field called RichTextField that brings in the js editor by default. But that mixes up content authoring concerns with modelling concerns by subclassing forms.TextField, which is why I decided not to go that route. I think hacking the Admin module to be wysiwyg configurable is cleaner, the problem is deciding what js tool to bundle. In the long run I imagine admin will ship with Dojo editor since Dojo is what the Django guys have settled on (and Dojo editor can deal with the back button as well which is *very* cool).

links for 2006-05-24

May 23, 2006

QOTD

Sean McGrath

One would think that putting a custom logo in the top left hand corner would be sufficient for most folks. After all, this is largely what we do with word processor documents, presentation slides and so on. We do not try to hide the fact that we are using standard templates/applications for these things.

Not so for web sites it seems.

links for 2006-05-23

  • "it automatically resolves browser dependencies which is good. Java programmers are used to writing their code to certifiably Java-compliant runtime"- Not quite convinced...

May 22, 2006

No Free Lunch

Tim Bray is disappointed about the reaction to Java's imminent open sourcing. The depth of antipathy held towards Java by some of the OSS crowd is... well, that Blackdown thing sure left a scar.

And if you've ever had the pleasure of typing in a JSR API from the spec, because of Sun's bizarre licences, well, what are you supposed to say to that? Except be thankful those days are coming to an end.

The ASF likes Java, despite typing in a fair share of APIs in their time. I went through the ApacheCon, agenda today, and there's tonnes of it going on in the Burlo next month. It's wall to wall OSGi, MyFaces, Portlets and Any old Java CMS*, with the odd PHP and httpd.conf bit tucked in. And Maven too.

I guess the main thing is to mush on before the LAMP crowd accelerate away from the JVM entirely.


* The ASF have a good few CMS type things written in Java, none of them seem complete or obviously "in front". What's up with that?

And does anyone else think JSR170 is the Java API for ZODB?

May 20, 2006

links for 2006-05-20

May 19, 2006

links for 2006-05-19

May 18, 2006

JournoFormats

Adrian is so close to microformats, with his tag set for online journalism it's scary. Here's his original tag set from the article:

    <time gmt="HH:MM:SS">
    <expire when="YYYY-MM-DD">
    <currency date="YYYY-MM-DD" units="USD">
    <city>
    <profanity level="X">
    <date real="YYYY-MM-DD">

Here's the microformat:

    <div class="time whenYYMMDD gmt">
    <div class="expire whenYYMMDD gmt">
    <div class="currency usd">
    <div class="city">
    <div class="profanity Lx">
    <div class="realdate whenYYMMDD gmt">

In Django using a uF should mean the files can stay stored as flatpages. A case of having your blob and eating it too.

QOTD

Cote':

Instead of focusing on keeping the cost of the whole relationship with the customer at a minimum, most development methodologies focus on making the cost of that first copy as low as possible.

Happy Shiny Metadata

In the software-candy-mountain, I have this lovely notion of metadata that is intrinsic to content and metadata that is not.

The former are universals about the content; which is to say they're true statements for all systems the content might go through - ever. The latter metadata is contingent on systems and people processing the content (workflow state comes to mind as does stuff like "nofollow"). I think it's really quite elegant and would include two personal favourites - a notion of control directives and workflow as being contingent and belonging squarely inside a system boundary; and support for external parties producing statements about content that they are not the source or owner of.

Meanwhile, in the desert of the real, it's impossible to split metadata consistently this way. There are very few (any?) non-contingent 'facts' about content. Universal truths are for mathematicians and priests.

links for 2006-05-18

May 16, 2006

Get Some

Graeme Rocher:

"Every major open source project needs backing from the big players in the industry and Oracle have made a commitment (Thanks tug!) to get behind Grails which is fantastic news."

"(e) has major commercial backing"

May 15, 2006

links for 2006-05-15

May 14, 2006

links for 2006-05-14

May 13, 2006

Dead Planet

I think I'd subscribe to planet.journals.ie if it added some value on top of aggregating Irish weblogs. Which is to say, I don't see the point of an Irish Planet, compared to an Apache or XML one*, whereas I'd probably find an Irish Technorati useful.


* For those being aggregated. Anyone running a Planet has ad revenue to generate value.

Frameworking

Eric Meyer is flummoxed by frameworks:

"But I just don't get all these new-fangled programming frameworks. Is something wrong with me? Seriously. I have this grumpy, churlish feeling that I suspect is rather similar to the way SGML experts felt when they saw HTML becoming so popular, and that scares me."

I just don't know. I'm trying to remember a time when there weren't frameworks - back when CGI supported "rm -rf" maybe. Still there are many sites made out of flat files, hand edited.

There is a point when the framework will either get in the way or show its true value. I think it's the point when you need to produce some new behaviour with code as opposed to rearrange things on the screen. Sometimes you need to build a porch, not paint the wall or add some new flatpack thingie to the middle room.

[ I'm finding that with Movable Type these days, I wish it was a framework instead of a product - there are things I want to do, but altering it seems tricky. It doesn't strike me as "for alteration". It'd also mean I have to learn passable Perl - not MT's fault, but as Perl has always gone whoosh right past me, I'm not hopeful about staying on MT.]

Eric's problem is that if you want total control, you will have to do a lot of work. In the web/bloggy space alone - i18n (maybe), tagging, commenting, archiving, slugging, login, preview, managing, spam filtering, templates, rpc, feed generation, scheduling jobs, who knows what else. You'll also have to make sure that things can be added later in a sane way. True, there is nothing worse than a bad framework, except maybe a bad programming language, but you'll be left in the dust otherwise, either reinventing what others can assume will "just" be there, or writing out all your content again in a way that can be processed by software. Total control implies total effort.

Speaking of content rewriting. Recently, I've been porting a website of flat files (spread over half a decade or so). I've been doing this to test a web framework - frameworks that only function in greenfield or closed situations are not especially interesting. The really interesting tools are often ones that introduce simplicity and order in already complex and highly entropic systems, as oposed to avoiding them and declaring victory. Also (more importantly) the goal is to make the content flexible and available for future needs. Now, the flat file thing itself is great - 100% scalable, precomputed, self-archiving, and so on. But that's not the issue - it's that these files have been written out by hand, where each was cut and pasted from an older one.

The most interesting thing about this site is how the flat files have changed over time. The older pages are different from the recent ones, you can see the copy errors, mutations and evolution take place, but any two side by side in time are almost indistinguishable, exhibiting very subtle alterations.

From a certain viewpoint the site more or less looks like a grand canyon, each internet year producing a new seam.

It's remarkable that something like a website can have a geology, layer after layer of frozen accidents. Integrators will be used to seeing that in non-web systems. But the difficulty is you can't terraform this kind of site - reskinning means editing every single page. Despite the fact that each html file can be read in, they're different enough as collection to mean that they can't easily be uniformly processed. To understand what it would take uniformly process them means analysing all of them, which is to say, if we could spec the code in advance they'd be a priori uniform.

Part of what I've been doing is normalising the files and reverse engineering the latent templates. Now, this kind of work would drive many people insane, but because I deal a good bit in legacy systems (as in I'll admit they exist and need to be linked up), it feels like a workout, a free chance to learn something about how systems old and new need to work. There's no magic shortcuts here, but it's not all eyeballing either - there are also tricks and techniques you can use to determine how variant the collection is - sort of data mining for common structure.

This kind of work also can also drive the framework insane, which is exactly why it's valuable. A good framework will deal gracefully with stress resulting from variation, which means dealing with the structural, syntactic and semantic exceptions, and not insist the data is just so. The green field is wafer thin. In the trenches you need to know if and when the tool will fail you, or whether it will be a force multiplier.

Ok, so we were talking about frameworks. Here's the thing, if you want to be able to terraform, to alter the presentation of content after the point of creation, you need a web framework. Now that framework can be as simple as a few scripts to inject some text into a one up, one down, three across html layout, or as complex as as high end CMS, but it's still a framework. What the web framework does is provide a rendevous point between some code and some content. As soon as you want to do something like reskin, output html and rss side by side, or associate a comment with a post, you're in framework territory. Which is to say to capture behaviour over data in repeatable form, you need code and a place to run it*. Frameworking is programming.

Some things can be made simpler via declaring the relation between some code and some data instead of writing out the code directly, (CSS is a good example of this) but not all things. Contrariwise for uniform processing you need to write out the content in a uniform manner as possible, which places pressure on content writers and designers to conform to the code. Historically, that pressure has been deemed to be excessive, which is perhaps why Eric Meyer sees frameworks as straightjackets.

On the bright side for the content focused - authors, designers, folks who are more like Eric Meyer or Jeff Croft, and less like me, "modern" web frameworks seem much more interested in catering for people who aren't programmers and have broader use cases than automating drudge coding work or making it easy to bind to a database. That's clearly the case with frameworks like Django and Plone and seems to be where the various web developer communities are headed. And that's a good thing.


* I had something in here originally about code then being an existential quantifier over a data structure (or an operator over a type), but I suspect it would have ruined the post :)

links for 2006-05-13

May 12, 2006

links for 2006-05-12

May 10, 2006

Laoise de hÓra

Born 9th May 2006, 3:58am. 8lbs 4oz.

laoise de hora


Hello, world.

links for 2006-05-10

May 08, 2006

links for 2006-05-08

May 06, 2006

links for 2006-05-06

May 05, 2006

links for 2006-05-05

May 04, 2006

links for 2006-05-04

May 03, 2006

MADD

MySQL, Apache, Django, Debian.

It sucks. I know. But if Tim Bray has one, I want one too!

Hey, over here! Shiny!

From the funniest ex-hacker: The Markup Wars.

alt-tab

Bruce Eckel on Python IDEs: "As far as Python goes, the argument for an IDE is not so compelling. Most people I know just use regular editors. I think the reason is that Python is less verbose.The example I often give is to read each line from a file, which I can do in Python without thinking about it. In Java, it's a research project to open a file."

Ruby people speak much the same about TextMate. Yes, it's true the brevity of the language means a text editor will get your further, but that's not a good reason to pass on a powerful IDE.

A good while back I gave up on one true ring theories for editing source and haven't looked back. Typically there's 3-5 "IDEs" open on my machine. Right now, in my taskbar, there's ultraedit, emacs, wingide and ecli