Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Back for a limited time - Get 15% off sitewide on Slashdot Deals with coupon code "BLACKFRIDAY" (some exclusions apply)". ×

Comment Re: Ownership and Appreciation (Score 2) 142

"the problem with renting special equipment is you also have to have the trained personnel to operate it. mostly you are better off contracting the service of having the earth moved instead of renting the equipment to do it yourself"

This business is NOT about renting bulldozers to homeowners digging a basement. It's about renting bulldozers to a contractor who already knows how to operate them and has all the licensing (or has an employee who does), but doesn't have enough jobs that need dozers to justify buying one that will sit unused most of the time. By doing it as a peer-to-peer agreement rather than one company owning all the equipment and taking all the risk, everyone can make money.

BTW, one of the money-makers my HVAC installer mentioned was that they own a crane and have a licensed operator ... anyone who needs crane service can hire his crane and operator if he's not using it for his own jobs. He's be happy to have a third party deal with the bookings.

Comment It's not going to scale up to wildfire size (Score 1) 80

Oil well fires are stationary points of flame a few tens of meters wide - lots of pressure behind them, but not much territory, and a single point of combustion where the fuel is coming out of the pipe. You can surround them.

Wildfires have flame fronts that are hundreds to thousands of meters wide, irregularly shaped, with a wall of flames and fuel sources that may be 5 to 30 meters high (or higher), and can be moving 60kph or more.

Look at this picture: http://media2.abc15.com//photo...

Tell me where you will put the bomb to blow that fire out.

Comment Code != Literature = Why Writers Need Outline Mode (Score 2) 285

Perhaps for programmers the need is not evident, but for anyone who writes long documents, it's indispensable. It's indispensable enough that I am still using Microsoft Word for anything that has any sort of header/subheader structure. OO and LO are OK for short letters and memos, but if it has more than 2 headings it gets clunky because of the lack of outline mode.

The core difference between writing text and writing code, which apparently the programmers working on OO and LO fail to grasp, is that writers are producing text which will be read by humans, not executed by machines.You can't just comment out the cruft and do a GOTO jump over that module you decided you don't want, then tell them to go back 17 pages to pick up the information in paragraph 3. Writing needs structure and flow to lead the reader through the material in a way that make the content comprehensible. It needs primary and subordinate ideas. Order and levels of importance are important. In Microsoft Word, collapsing the document into Outline mode and seeing the heading and subheading structure makes the flow of the document visible, and more important, the means to change that flow is on the same screen. There is no interruption in the work flow.

http://www.gigamonkeys.com/code-reading/ seems to understand it, going the other direction: most real code isn't actually in a form that can be simply read .... in order to grok it I have to essentially rewrite it. I'll start by renaming a few things so they make more sense to me and then I'll move things around to suit my ideas about how to organize code. Pretty soon I'll have gotten deep into the abstractions (or lack thereof) of the code and will start making bigger changes to the structure of the code. Once I've completely rewritten the thing I usually understand it pretty well and can even go back to the original and understand it too.

Which leads me to "Issue 3959", wherein writers asked for this on 2002-04-10 20:39:19 UTC ... it's ranked as "Trivial" now. It has nothing to prevent implementation except the inability of the code maintainers to accept that writers really do know what they need in their tools.

Here's the overview of Bug 3959 ... https://issues.apache.org/ooo/...

OVERSHOOT wrote upstream: Ah, yes. Issue number 3959. Originally filed April 10, 2002. More than twelve years ago. In that time it has remained in the top-voted issue list year-in and year-out. Others come and go, but 3959 keeps on pissing off users. At last look, there are about ten duplicates requests on file.

Every few years some developer wanders by and tells the people following it that nobody needs outline view, or that there are tools available to do it, or whatever. Often, they close the issue. In effect, "I don't use outline mode so obviously it's not important." The mailing list heats up for a while, the developer either mumbles something about maybe the team should look into it and vanishes or else just vanishes, but the issue is either reopened or left open. I've seen at least four of those cycles so far. We're probably due for another one.

At this point, I suspect that 3959 will outlive (Open|Libre|Star)Office for the classic open-source software reason: if it doesn't scratch a developer's itch, it ain't happening. And apparently, developers don't outline, edit, or otherwise structure their writing or much care about the people who do.

As the wisdom of XKCD proves - http://www.xkcd.com/619/

Comment So this is why I can't get Outline View? (Score 1) 240

This may explain why the incredibly ancient feature request for an "Outline View" in OpenOffice has gone over a decade (Reported: 2002-04-10) with no resolution.


The mental mapping of code for programmers and the mental mapping of text to those of us who write literature and non-fiction is totally different. They can't visualize how an outline and headings and the cues fonts give readers differs from all the "mind maps", "document navigators", and other inadequate replacements they keep suggesting will fill the need.

Comment Re:BD, DT, and wrote TFMs it'snot rocket surgery (Score 1) 211

At the base of Pike's Peak, 6th Thursday in November. Drive the vehicle of your choice. Hogs will be provided.

First person to haul an aggregate weight of 1250K in hogs to the top wins. There is no limit on the number of trips, but all hogs must arrive at the toip for the vet inspection in good health.

Comment Re:Um, no (Score 1) 211

From TFA: The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.

Definitely NO, and even HELL NO! It's to make it possible for them to use the product at the level they were hired to use it at, or for the purpose they bought it for. My auto's user manual is a USER manual, not a service manual and not an automotive engineering textbook.

Comment BD, DT, and wrote TFMs it'snot rocket surgery (Score 2) 211

I've been writing technical documents since the early 1970s.

You can't expect one piece of documentation to serve everyone ... it's like buying a "vehicle" and trying to use it to race, haul hogs, and climb Pikes Peak.

A - Ordinary users don't give a shit how the stuff works, they want it to do something for them ... tell them how to make whatever it is work as a tool for them. Run through the common use cases, screen by screen, showing them how to make the widget-smasher do it's thing.

Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc.

B - Administrative users: They need all of "A", and how to handle the other users. Add, remove and monitor users.

Start with things the way they should work, then give them some basic troubleshooting, maintenance, etc. for the added functions.

C- Service techs, sysadmins, and those who will touch the sacred code: All of A and B (be reference to the appropriat4e manual or section thereof) and then feel free to pile on the technocrapobabble.

Each detailed explanation should start with a very brief "statement of purpose" ... when will this command be needed, or what does the bit of machine do. Why would you use it?

Then explain how to use it, and the expected results if you used it right, the expected results if you screwed up, and how to recover from an error.

You need to explain for each level of user what happens to a transaction, or data, or a part being manufactured, as it passes through the process or the proigram ... chronologically, what touches it and what is supposed to happen?

What will you see if there is a failure?

How do you recover from the failure?

It's not difficult, you just have to make sure that each level of user can get their task done efficiently.

Comment BUSTED! And on AOL! (Score 1) 103

Way back, in the dim, distant past of the bucolic walled gardens that preceded the Internet as we know it ... there was AOL. AOL had walled predator-free gardens within gardens, where only teens younger than 18 were supposed to be communicating.

There were rumors that evil pedophiles were lurking in these gardens, so I made a sub-account for a totally bogus 16-year old boy named Alex. And Alex went forth to play.

All was going well, Alex was quite a popular young man amongst his peers and had lured ZERO pedophiles when he got this e-mail from a fellow writer: "Alex, are you Tsu?"

BUSTED ... not because of subject matter or vocabulary, but because of a @#$&%^ liking for compound, complex sentences and other arcane constructions ... and using them accurately.

Everybody needs a little love sometime; stop hacking and fall in love!