spread the dot jenett.radio.randomizer - click to visit a random Radio weblog - for information, contact randomizer@coolstop.com

Writing Online

on my (ab)use of Radio Userland
 Wednesday, June 05, 2002

Those damn flies

Unlike some people, I don't find collapsed outlines to be easily comprehensible. I've looked at Frontier several times over the years, and keep not using it for this reason. It's not obvious where things are, or what does what. I'm more comfortable with the blank sheet of paper that is AppleScript or Perl. I still don't know where to go, but it's easier for me to read what others have written.

In any case, the weblogNeighborhood tool is not setting the style of some sites to bold, despite those sites seeming to have met the criteria necessary. The tool bolds the site if the site contains the results of the headLinks macro. More specifically, if the site contains a link element thusly

<link rel="subscriptions" type="text/x-opml" title="Subscriptions" href="http://radio.weblogs.com/0001015/gems/mySubscriptions.opml">

then the harvester bit of the tool can follow that link and examine the subscriptions list. If the harvester can follow that link, it will then flip a boolean (true or false) value stored for the site in the radio.user.weblogNeighborhood.neighbors table. Then if the value of radio.user.weblogNeighborhood.neighbors.urlOfTheSite.flharvested is true, the saveReportHtml routine will bold the site when it writes the HTML.

But it's not doing this consistently.

Note the differences here, here, and here, in how the weblogNeighborhood tool highlights some sites and not others. Sam Ruby, Jenny Levine, and Jon Udell, among others, should all be highlighted.

Others may not have been harvested because they don't have the required <link> element in their HTML page, or if there was an error reading or parsing their page, or if they were in the last level traversed.

Or?

12:28:51 PM # Google It!
categories: Writing Online

Writing Instructions

Brent Simmons writes “... it’s good for engineers and architects to write docs because it makes the software better.”

....

Engineers, architects, writers, and others should collaborate on documentation. The collaboration should be based upon engineers and architects serving as subject matter experts for the writer.

....

Engineers can’t do it (at least not for their own projects). They know too much.

[ARTS & FARCES internet]

They're both right. One of the reasons why programmer types don't write good documentation is that they, like someone giving directions to his house, assume too much familiarity on the part of the reader. Writing documentation, and having it used by someone else, reveals the missing steps. It also reveals the way to better software.

Remember that class in BASIC on the TRS-80 in high school? The computer does everything you tell it to, exactly as you say, but if you don't tell it, it can't do it. You cannot skip steps.

11:48:16 AM # Google It!
categories: Learning, Writing Online, System Administration