they were trying to be a broker for sales, not rentals and equipment sharing.
they were trying to be a broker for sales, not rentals and equipment sharing.
"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
what kind of god awful project managers were involved in this?
Read the linked articles. He admits they should have hired a project mamager who had dealt with that kind of project, and shgould have kept a tighter rein on the software developers.
Selling 20-30% of the news slots to click-bait farms and advertorials was a start at turning things around.
Making the Tech and Politics news pages unreadible by adding humongous pictures
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.
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
Which leads me to "Issue 3959", wherein writers asked for this on 2002-04-10 20:39:19 UTC
Here's the overview of Bug 3959
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/
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.
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.
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.
I've been writing technical documents since the early 1970s.
You can't expect one piece of documentation to serve everyone
A - Ordinary users don't give a shit how the stuff works, they want it to do something for them
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"
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
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.
Way back, in the dim, distant past of the bucolic walled gardens that preceded the Internet as we know it
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?"
Tools like this basically do: (step 1) build abstract representation of text - (step 2) rebuild it into a new text using random substitutions.
Those are easily spotted by their near-miss of English. It's called "content spinning" and it is easy to spot.
Coccidiomycosis is all over the southwest, it's not incurable, and it's no flipping mystery why the incidence is increasing
2/3 of the people who have antibodies against it thought they had a slight cold or had no symptoms. A large chunk of the remaining 1/3 have a mild cough and mild to moderate fatigue
It's been known for decades (since before I took Mycology in the late 60s) that certain groups were more prone to have severe cases: African Americans, Asians (especially Filipinos), Women in their 3rd trimester of pregnancy, People with weak immune systems, including those with an organ transplant or who have HIV/AIDS
Moving a group of people out of an area where they are extremely likely to get a disease that will make them sicker makes economic sense
A vaccine was under development during WWII, but the project stopped when the war ended. There have been noises about reviviing the project, but no funding.
It's not just "let's get started, folks". There are intra-song cues and signals coming from the conductor's baton that must be detected - instructing a small group of instruments or voices to start and stop independently of the rest of the group, instructions to hold and fade a note, instructions to chop off a long finale
However, when it comes to the very moment of starting, or the change of tempi, my start will always come too late.
Every conductor has a different style. The signal to start your part of a song that has already begun may be a small flick or pointing of the baton in your general direction, barely interrupting the overall tempo of the conducting, or if you have a dramatic conductor it can be a two-handed "picador going over the horns" gesture
Because the baton may be signalling to someone near the OP - in front or behind - but not the OP, the problem is discrimination as much as detection.
Also, it's not always a down beat. Changes of volume, extended notes and the final cut off of a long final note may be sweeping or tiny gestures sideways or straight towards the choir or orchestra.
Very few conductors will make big changes in tempo from what was practiced. No good will come of it.
In short, it might be more practical to start on the second note and drop out on the next to last note, paying attention to the parts of the production that immediately precede your bits so you are ready for it.
"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM