Well, I couldn’t leave my first GreaseMonkey user script alone, could I?
As an inveterate tinkerer, I started thinking of ways to make it more flexible. So now, highlightcountries.user.js highlights results of cyclists from three countries: Australia in gold, USA in blue and Italy in green.
This user script is designed to be edited. Highlight as many countries as you like with whatever colours you want and have some fun!
A while ago I railed about an irritating fashion in user service scripting. It included:
All this reminds me of a bloke I new a while ago who was running a business. He said once that he had difficulty training his staff to say, “this is Chris” on the phone instead of “Chris speaking.” He had been to a seminar or course on customer service and believed that use of the this is script clearly demonstrated to his customers that his company was more up-to-date.
I finally found out why yesterday the this is script is favoured: when you answer the phone, the person at the other end is more likely to recall the last word you said than the penultimate one. So, if I answer with “Michael speaking” the other person is less likely to get my name than if I say “this is Michael.”
I guess this makes sense but I am concerned by an implied assumption about the attention span of people who use the phone.
My recent wrangling of LDIF files is a classic case of Data Crunching, as outlined in Greg Wilson’s new book.
Reading an excerpt of this book, I realise that I’ve done a lot of this kind of work over the years. Greg makes it clear that, even if a program you write for crunching some data is Quick and Dirty™ (as we always called it when I was a graduate student), it should be well written, because you never know when you are going to need it again. Or worse, when someone else is going to need to pick it up and use it.
(Actually, I have already refactored my LDIF program into a pure-Java solution that can be used by any of the Java-heads at work. It also uses an vendor-supplied LDIF library, to remove the responsibility of parsing LDIF from my code. And I found a bug in the LDIF library!)
I have recently started using GreaseMonkey seriously, and have written my first user script.
My script does one specific thing: it highlights results on cyclingnews.com by Australian cyclists so I can easily pick them out as I scan through the results pages. (Go Robbie! Go Stuey! Go Cookey! etc. etc.)
If you want to use highlightaussies.user.js or modify it for different colours and countries, have fun!
Update I have editied the script so it works correctly in Firefox on Windows with its CRLF line-endings.
John Gruber found in Mac OS X 10.4 the simplest possible dialog you could ever need.
I had a task at work that required manual editing of LDIF files to repair a problem in an LDAP directory. The editing work was repetitive and error-prone and I could see no quick way to automate the changes.
For one file with 14 entries and another with 93, I had to:
Comments(1)changetype: delete and an empty linechangetype: add, then all the remaining attributes, excluding the ‘problem’ onesAfter that the LDIF files will be used with ldapmodify to repair the directory.
For someone versed in XML and XSLT, doing this kind of work in LDIF file format feels extremely tedious. I couldn’t help myself: I wrote a Python script that parses the LDIF and writes a simple XML file with the same information. Then I wrote an XSLT stylesheet that edits the XML as described above. The XSLT emits LDIF directly, including ‘folding’ lines (as described in the RFC) longer than 78 characters.
I discovered DSML (Directory Services Markup Language) but could not find tools to convert LDIF to DSML. There are tools that interact with a directory using DSML files but they didn’t extract the ‘problem’ attributes (they were operational attributes actually) that I needed to filter on. Also, DSML is much more complex than I needed: my simple XML was enough.
On reflection, I probably should have used Python objects (and later Java objects after I rewrote the conversion program into the standard language where I work). But I was annoyed by what feels like an archaic file format that is not amenable to automated, declarative transformation using (now standard) tools.
Al Smith Jr’s JavaWorld article on developers and architects helps to clarify a distinction that is often muddied. But I don’t fully understand:
Knowing how to solve a problem’s context verses solving the problem itself distinguishes architects from developers.
I think I don’t connect with Smith’s meaning of context.
Reading it made me think of someone, somewhere, who stated that the distinction between managers and leaders is also muddied. I can’t remember who: was it Stephen Covey (of 7 Habits fame) or was it Alistair Mant?
I am always disappointed when the unstoppable evolution of the English language moves on through bad usage rather than clever invention.
My current beef is with journalists who, looking for a different verb that describes how someone says something, use concede as a synonym for say. In an article on “male menopause” in yesterday’s Weekend Australian Magazine, Guy Allenby uses concedes twice: once correctly, and once as a misleading synonym for says.
This is the latest example of one particular poor usage that is becoming more common. In striving to be inventive, Allenby is actually making the opposite kind of contribution to the language.
