... but kitchen units measured in millimetres are plain silly.
All kitchen units in the UK have been measured in mm for as long as I've owned a house and been interested in such things (so at least 9 years). A standard unit is 600mm deep and usually 600mm or 450mm wide.
I think it's fascinating that people think the only use for a domain name is for web content.
It's perfectly possible to register a domain name solely for use as an e-mail address, and in fact I have a couple of domains I use this way. I'm not saying it's what's going on here, but just because you see a parked domain page when you type it into a browser, doesn't mean it's not used.
When my company had to come up with a solution to have all of our developers to develop in an environment that absolutely mimicked the production server we used a combination of VMWare to run a version of the Ubuntu. Puppet made creating all of this really easy. It gave us the ability to completely blow away a machine and reconstitute in very little time.
We did the exact same thing for developing proprietary trading software, using KVM on Gentoo with Salt Stack. There are numerous free options for achieving massive virtualization...paying for a VMWare license (which you'll have to do if your environment gets serious at all) is a complete waste of money. Want Enterprise resiliency, vm migration, etc., add a clustered filesystem and Opennebula/Openstack to the mix.
The only reason not to do this would be a lack of in-house expertise, in which case, be prepared to pay well over the market for commercial solutions in perpetuity, and be beholden to their support staff and contracts. Good luck with that.
But it might make it clear that it will fail much earlier and then at a lower cost.
Which *still* doesn't constitute success.
The term "agile development" covers a lot of ground. Much of what people mean by "agile" simply amounts to best practices (e.g. daily commits, unit testing, frequent builds etc.). But "agile" also refers to a kind of iterative and incremental approach to identifying and pursuing business goals in your project (exemplified by Scrum). That turns out to be a sensible and appropriate approach **in many but not all situations**.
Many development projects exist in a business environment where business needs evolve quickly, driven by both endogenous (management decisions) and exogenous (competition and market) factors. Likewise the software project itself, if it is reasonably successful, alters the very business conditions it is designed to address. *Under such conditions* you can't set out to build something in two years with any confidence that it will be what is needed twenty-four months from today. On the other hand, no programmer can be productive if he gets a different set of marching orders every day. You are forced by circumstances to adopt a flexible, iterative approach that allows the programmers to actually complete useful work before its specifications become obsolete, which contains the scope of *change-driven* failure and points your team in the right direction sooner rather than later.
But it is critical to remember that not *all* projects are like that. If you are writing software to control a spacecraft or a nuclear power plant, you don't sit down and bang out a little production code to figure out what it is you need to build. There's a lot more you can and should do to prepare for coding, and the classical engineering principle of discovering requirements as early in the process applies. It applies to the chaotic business situation too, but in that situation many requirements are simply impossible to anticipate.
In any case, the phrase "world's biggest agile project" should give any thinking developer pause. "Huge" and "agile" (in the goal-setting sense) don't go together. It seems to me that the idea of approaching *some things* in a waterfall manner (still using many best practices associated with "agile") and *others* in an interactive, exploratory fashion is the approach they should have been taking from the start.
Except there's nothing to say that a CF process would necessarily yield ridiculous amounts of energy at affordable prices. In fact the first proof of concept, if it ever comes, is likely to be just a barely measurable hair's breadth above break even. And scaling the technology to generate megawatts might well prove to be prohibitively expensive. What if a MW plant required thousands of tons of nickel? There might not be enough nickel in the world to supply a significant fraction of the world's energy supply.
Then there's the flying car problem. There is no doubt that practical flying cars are physically possible. The reason we've never seen one is that it's a fool's investment in the short- to mid-term. Any flying car we can come up with over that time scale is going to be a lot worse than buying a dedicated plane and renting a car at your destination. If there were some immediate niche application for a near-term flying car where it beat a dedicated plane and car combo, we might *all* be driving flying cars in twenty years. But there's no such niche to pay back investors. Even if CF is physically possible, if it doesn't quickly reach a stage where it beats some conventional power source economically (e.g. replacing solar panels in remote applications), it might never become practical.
I was under the impression that the issue of translating LED light into a broad swath of color was an already solved problem (except for some fine-tuning optimization), using appropriately-sized nanoparticles which hand the energy from the photons around, slicing-and-recombining energy from photons into different sized packets and re-emitting the light at a frequency characteristic of the size of the nanoparticle. Cover the LED with a bunch of these in a range of sizes and you get a smooth spectrum.
Works the other way, too: Coat a solar cell with such particles and they take the random-frequency photons from the sun and slice them up into multiple new photons at a frequency good for the solar cell bandgap, and mash the levtovers into more big photons to re-slice to the correct size. (It's not 100%, since some of the photons get away. But it's more than a 2x improvement over a bare cell, which only takes one slice off each photon and throws the rest away.)
If this is correct, this project looks like just a fine-tuning of making the nanoparticles, or finding materials for them that are somewhat more efficient than what was already being used (which was pretty good).
I haven't been following this all THAT closely. Have I misunderstood the current stuff? Or is this just a little incremental tweak along the cutting edge?
Mother Theresa would no doubt have printed a medical tool for removing IUDs.
Which would have been totally useless since most of the countries and places she setup shop didn't have access to birth control to begin with.
India, with its huge population, had a large program making IUDs available at no cost to people in the poorer regions who wanted them.
Mother Theresa's work included providing medical treatment to the poor in many of these same regions. Her clinics were noted for removing the government-provided IUDs of women who were there for other procedures, without seeking permission or even informing the woman that it had been done.
Don't you just pull on the string?
Not if you don't want to kill or sterilize the woman.
I've never seen "licensed" grid tie systems that didn't do what you describe.
And you won't: They can't be "licenced" if they don't do this.
About the only way you can feed the grid legitimately without such a device is by pushing on an induction motor (as happens sometimes in normal applications, like with a mo-gen system for an electric elevator when the elevator is being slowed down.) Induction motors depend on the grid for excitation and won't self-generate unless you've got enough capacitors hung across them (and your load) to make the net power factor capacitive. (This is unlikely but can happen in islanding, so you generally aren't allowed to hang a prime mover, like a water wheel or windmill blade, on an induction motor, and hook it to the grid, without adding such controllers. Generation from induction motors in an outage should only last for a few seconds while they suck the inertia out of some spinning mass and run down.)
Last I looked it cost about $2,000 extra to have a grid tie inverter with sell-back (and high-current load direct-connect with inverter "helping"), compared to an equivalent inverter from the same manufacturer that only fed the load with inverter output but could charge the batteries / feed the inverter with rectified line power when the grid was up.
In this case the $2k-ish bought you an extra box containing:
- a contactor (to jumper the line to the inverter output) and
- a circuit board that controlled the contactor and acted as a peripheral to the brain of the inverter, providing it with phase measurements (to line-up the inverter phase with the line phase before closing the contactor) and a voltage and frequency measurements (to tell the brain when the grid was failing, so it could open the contactor and cut you loose).
Though this was an add-on box, other products with the function built in also brought a similar premium compared to non-sell equivalents from the same manufacturer.
Straight grid-tie devices feed the harvested power to the grid and depend on it for interconnect and timing reference. Yes they don't feed a dead grid - but that means they don't feed YOU when the grid is down, either.
I'm maybe three years out-of-date on this information so the market may have changed.
Mother Theresa would no doubt have printed a medical tool for removing IUDs.
Even if only a third of the people stick around after din-din (and it's usually more), it's still the equivalent of getting more better than a 10% increase in manpower for the price of nine dinners (in bulk) per day per extra head - FAR less than the cost of hiring another head.
Did the math wrong: Make that about 17% more "heads" for the price of six dinners per night for one in three staying an extra half-shift..
FWIW, most "free food" programs encourage workers to come in earlier (for breakfast) or stay later (work past dinner time) or to not spend a long time off the company property over lunch. The extra time at work usually pays for the food costs.
It pays MUCH more than that. A typical thing that happens at startups is the company buys dinner - and the bulk of the engineers chow down and stick around another four hours. Not only do they get half-again as much time, but they get it in a block. For a programmer or other design engineer that means they haven't "lost state" and are even more productive than if they'd just worked three days instead of two.
Even if only a third of the people stick around after din-din (and it's usually more), it's still the equivalent of getting more better than a 10% increase in manpower for the price of nine dinners (in bulk) per day per extra head - FAR less than the cost of hiring another head.
And then there's an adminstrative pathology: The new management comes in, sees how much is spent on the food (but not how much is gained as a result), decides that their predecessors were stupid and the employees were looting the company, and stops the food. So come dinner time the employees go out (or home) to dinner and don't come back. Immediately it's like they lost somewhere between 10% and 33% of their work force without any reduction in payroll costs. (That's not counting how disgruntled some of the employees become.)
I've been at three companies where this happened, and observed several more. All but one of 'em folded shortly thereafter - and the one that survived went through a near-bankruptcy that destroyed the original investors' equity and left it in the hands of the bondholders before it recovered.
It could even keep a local part of the grid up while all others around them suffer power failures.
And that is a BIG no-no. Because it kills linemen trying to fix the outage.
Those transformers work both ways. Your little generator or inverter gets stepped up to maybe 8,000 or 12,000 volts. Then a lineman who thinks the power is down brushes against a wire (or comes within a quarter-inch of it) and is "burned" - to death.
Grid-connected inverters with a "sell" feature MUST monitor the network and shut down if they detect islanding - being cut off from the grid, with one or a collection of generators running autonomously. It's perfectly OK to feed power into the grid when it's up (if you're using UL approved equipment, connected according to code, inspected for compliance, and the utility knows you're doing it according to the rules.) It's perfectly OK to have things wired so your equipment still feed your house if the grid goes down, but it MUST cut itself off from the dying or dead grid and stay off until the grid comes back up and stabilizes at the nominal voltage and frequency.
Homemade hovercraft used to be a big thing since at least the '50s or '60s (and for all I know still are). Typically made by putting a prop on a vertical-axle lawnmower engine and building a simple vehicle body with a fan shroud in the middle.
There was a classic disaster that happened to a LOT of people who did this:
After they'd played around on land with it for a while they'd decide to test how it would perform on water. So they'd take it down to the local park-on-a-lake, fire it up, and drive out onto the lake.
It would work fine
Then the spray it was kicking up and sucking back around the motor on its way to the fan would finally short out the spark wiring. Oops!
Of course they usually hadn't included any floats...
No, flying isn't the correct word.
Story I heard, back in the '60s. (Don't know if it's true, unfortunately. But I think we have some Ann Arborites here who might check the city ordinances.)
Plans had been published for making homemade hovercraft with a salvaged lawnmower engine. Stand on it like a Segway and steer by leaning.
Kid had made one and decided to take it down the LOOOONG, somewhat steep, slope of Hill street one night. (I shiver at the thought of how fast that would be going near the bottom...)
Cops had a radar trap and clocked him at freeway speeds. Issued him a ticket.
He fought it, claiming that the cops had no jurisdiction because he was flying, not driving. Didn't touch the ground. Take it up with the FAA.
Traffic court judge (rightly or wrongly) agreed that this might be true and the cops hadn't proven jurisdiction, so he dismissed the ticket.
City Council banned hovercraft within the city limits shortly thereafter. B-b
No man is an island if he's on at least one mailing list.
