"It has never been spread out, yet," said Mein Herr: "the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.
I assure you: the problem isn't unfurling a map of that size, the problem is folding it back up again correctly.
I presume this would be handled between the "equal protection under the law" clause in the 14th Amendment and Congress' right to regulate interstate commerce under Section I article 8.
In many cases Congress has passed laws that supercede state laws. Don't like it? Ride your representatives to insert judges that don't make law from the bench and believe in State's Rights.
What Spolsky says about the culture differences is right on the money. First some background.
I spent years as a Unix developer and admin. I've written kernel patches, tinkered in the arcana of NFS, written more Bourne (csh, bash) shell scripts than I care to remember, written a few X apps, learned Perl well enough to write books on it, presented at USENIX, wrote medical and finiancial applications using not much more than libc, programmed Unixes from AT&T SysVR3 to Linux, installed the GNU tools from mag tape in 1988, learned gawk from a wire-bound photocopied manual distributed with that tape, have set up UUCP by hand, and fixed more than my fair share of filesystems with fsdb-like tools. My Unix Wizard hat is dusty, but was honestly earned.
My later career has taken me to Windows shops. I'm currently earning a living writing C and C# for an almost completely DOS and Windows-based company. I've spent a couple of years spelunking MSDN documentation, Google groups, and 3rd party library API's. To that end, I've created a few applications for database interrogation and updating by end-users, web-based applcations, and plenty of GUI-based throwaway applications. My Windows hat is still just a propeller beanie, but I'm working on that.
So having a foot planted firmly in both worlds, I gotta tell ya -- he's right.
When I first approached Windows programming I wrote a lot of things that were used by myself, and that was it. Nobody else wanted to use the software I produced; admins and typical "end-users" alike both ignored them. Honestly, these programs did good things: they were relatively bug free, they scratched an itch that end-users had, sometimes they cured what caused the itch, and were all very Unix-like. Unix like? STDIO based textual interfaces, very easy to plug into other programs, command-line driven, and heavily documented.
The phrase that makes Spolsky so right is the importance of the end users's experience. They're completely different.
With Unix I'm fundamentally thinking of "how am I going to write a program to manipulate data X with data Y?", in Windows I'm thinking of "how would a user expect to cause data X to be manipulated with data Y?". True, in Windows I'm faced with two problems: 1. user interface (to meet their expectations of experience) and 2. actually solving the problem at hand. Over the years though I've found that problem #2 is always easy -- it's just bits, it's problem #1 that makes a successful product or a useful tool.
Once I got used to starting with the user interface (while behind the scenes designing the functionality of the task), my Windows applications really took off. People wanted to play with them, touch them, use them. Sometimes they suffered from the "wrong tool for the job" problem (as many monolithic apps do) but that's okay: they were easy to use, didn't require any explanation, and people just learned to make the tool do what they wanted.
One of the design creeds of Windows seems to be that people are flexible. They don't want to read, learn, or memorize anything but they're willing to take the few tools at hand and bend it every-which-way to get it to do what they want. Unix takes the toolkit approach (design a specific tool for a specific job, with generalized I/O) which makes people read, learn, and memorize, but often provides them with exactly the right tool for the job.
It's not so much the culture of the programmers as it is the culture of the consumers.
But would a cylon homing beacon be of any use? Once they've jumped to a new star system, any radio transmission would be relegated to travelling at light speeds, so it would be years before any sensor would pick up the origin of the beacon (assuming that Galacica has now jumped to unexplored space, and its doubtful such a small device could produce just a high intensity signal).
Perhaps it's not a beacon, and only a monitoring device. Just before the jump, it could broadcast a forwarding address of the new destination. If the signal propagates at lightspeed you only have to know where they were and when they were there to pick up the signal.
In other words, if I broadcast a signal from Earth now, I can pick it up again at the Sun in 9 minutes, or at Jupiter in a little under an hour, or at Pluto in 4 hours -- ain't FTL great? With FTL drive you'll never miss another TV show again. And re-runs forever!
Once you know this, jump to their new location, lather, rinse, repeat.
I live in a northern climate, so I understand what you're talking about.
Your neighbors are the *best* solution. A gadget solution would be one that would shut off the water and leave it off in the event of a power failure or freezing temperatures.
It should be overridable, of course. But if the power failed (or the temp dropped), the water would stop flowing in from the meter. This would almost completely eliminate the damage if the pipes did freeze. It's not the burst pipes that's the problem -- it's all the water. The incoming pipe from the meter would be fine -- it's normally installed below the frost line anyway.
An improvement: since this would have to be mounted near the incoming water meter (from the city or well) it could also have a drain capability. Picture a "T" shaped device, meter on the left, house on the right, drain out the bottom. Power goes out, it could close the meter-side and open the drain-side allowing the water in the house pipes to drain out a different path to a floor drain (or a tub).
"I predict that within 100 years, computers will be twice as powerful, 10,000 times larger, and so expensive that only the five richest kings of Europe will own them."
Make sure that everyone knows what your intentions are for future bonuses. Presenting this as a holiday bonus might give the impression that you're going to do this every year (are you?). Presenting this as a profitibility bonus might mean that every time there's a profit, people will expect a bonus (will you?).
Give everyone a good frame of reference so they know what to expect. The last thing you want to do is wind up having people *rely* on the bonus and get disappointed with the Jelly of the Month (the gift that keeps on giving, all year!).
Mod the parent up, please. These yabbos skipped the games that involve getting out of your chair. Game designers must take note of Real Life restrictions like gravity, endurance, timing, strength, and physical dexterity. Not to mention capturing the feeling of fear when you're about to be pummeled with a heavy dodge ball thrown by a strong person who really doesn't like you...
In addition to the parent's list, I'd like to add:
Agreed. As I started to read the article those were the first sounds ("I LIVE!" "BEWARE, COWARD!") that came to mind. Being an 80's arcade boy here's the others I thought of and I'm sure everyone can recognize:
The withering Pac-Man death noise and music after the second (?) maze, Frogger's background music and the satisfying "clack" when the frog gets home, the whine of the mutants in Defender, and the satisfying silence when the screen's clear in Asteroids.
No, the sound chips weren't always the best back then but all of these are firmly wedged in my psyche.
...opinion from a Michigander, where you're never more than 3 miles from a natural lake or river anywhere in the state: This is the most useless, stupid idea I've seen in a while.
I'm not sure about the UK, but over here rivers aren't usually given to any kind of easy access. In urban areas factories, docks, and various other kinds of buildings litter the shorelines. In more rural settings, rivers are bordered by swamps, ravines, and steep banks.
On the other hand, *lakes* people go well out of their way to build access ramps to. Then again, if you've got a water-car on a lake...your navigation options are somewhat limited.
And thinking of *driving* out of that river or lake over the embankment across a field to get back to the road? Think again. Just whose land are you driving across to bridge the gap? Private land? The owner'll have your head on a plate for eroding the bank and potentially causing floods. Your own land? If you own the land, what's the point of all this anyway? Public land? The first Department of Natural Resources officer that catches your driving on state land away from a trail will jail you, impound your car, and subject you to severe fines.
Speaking of the DNR, the first time the car leaves an oil slick (or transmission fluid, grease, brake fluid, engine coolant) in the water or on the bank -- public or private land -- you'll start piling up fines that make the price of the car look small by comparison.
The OSS community has exactly ZERO motivation to "get the product to market".
That's not entirely true. Failure to bring a usable OSS product to market in a timely manner (Mozilla, Perl 6, Wine, Hurd) will result in ridicule for the development team and the product becomes a target for scorn even within the pro-OSS community.
There's no sales droids or PHB's waiting for the product, but droves of expectant users. When and if the product is delivered the programmers get their rewards (attaboys, good press, professional recognition, jobs).
So the OSS community has very strong motivations for success and against failure. They're just not directly monetary.
I disagree: if you walk into your job acting like an ivory tower egghead, then yes. The the key is to realize that you really know *squat* about the business you're starting in, and take some time to learn
And by that some token, with these qualifications you should be willing to accept a true entry-level salary and simply expect your salary to increase on a steeper ramp than someone without your background.
Walking into a new job with lots of education, but no joureyman experience, please set your expectations accordingly.
You can't [...] listen to the radio (unless you have battery-powered radio, or in your car; but remember, gas is hard to come by, and batteries only last so long).
Speak for your own radio. I was tired of listening to the radio in my truck, but searched for a portable radio for which I had proper batteries in vain. I certainly wasn't going to join the mobs rushing to buy batteries at the Kwik E Mart. After a bit of thinking, I went rummaging through my kid's room and found...his crystal radio kit. I threw the antenna wire over a small tree in the yard, attached the ground to a copper ground rod (installed by Ma Bell). I could then listen to 4 stations (2 of which had music) while resting in my hammock reading a novel.
On later reflection, I had the necessary diode in a spare parts drawer and could have built a much better one if I felt inclined.
Of course. After I was done posting I realized that at that point it was the grandfather (not the father) of the post I was writing that was the troll...
The parent troll speaks like someone who flew into Detroit, visited Flint, stopped by Grand Rapids and hit nothing in between.
The Upper Peninsula has gorgeous old-growth forests and is wonderful backpacking country: you can walk for hours without seeing any signs of civilization and the stargazing is great. Michigan has more shoreline than any US state (except Alaska) which include the world's largest freshwater dunes, great swimming beaches, and limestone cliffs. There's also good canoeing and kayaking all over the upper Lower Peninsula.
If you're in the Midwest, pop by Dearborn, Michigan. (Southeast corner of the mitten.)
Lots and lots of technology history everywhere you look. Even if you skip the automobile stuff (which I do) there's at least two day's worth of stuff to look through. Very little stuff is re-creations.
Edison's lab, the Wright Brother's shop, more steam-powered machinery than you ever thought possible, every wheeled mode of transportation imaginable, gadgets, gadgets, gadgets, R. Bucky's Dymaxion house. Through the end of the year they've got quite a bit of James Bond stuff on display.
In my experience XML isn't hard to parse at all. Basically, you just have to recognize tags (basic regexp) and match opening ones and closing ones (use a stack, Luke).
SHHH! Don't say that too loudly!
The XML Police that exist in several communities will come down on you like flies on manure. "You can't parse XML in regexps! That's not really parsing! You need to use the standard-flavor-of-the-month XML libraries for your language (which of course, may need dozens of prerequisite libraries)! What about CDATA? DTDs?! Encodings!? OH THINK OF THE CHILDREN!"
<stage_whisper>But in my experience, most of the time, you're right</stage_whisper>
Line of sight methods (lasers of almost any kind) wouldn't work. Even during a pitch, there's lots of crap to obstruct a clear view of the ball, even looking up from the plate's vantage point there's dirt to contend with. Then there are problems with wet/scuffed baseballs and refraction of the light.
Two thoughts I've had. First is making the plate itself a low power radar unit of sorts. The biggest problem would be differentiating the debris over the plate (batter, bat, catcher's equipment) from the ball itself.
The second was embedding something in the ball to reflect radio signals of the right frequency. Place a few transmitters/receivers around the plate and do a little triangulation. However, doctoring a baseball no matter how little, seems... wrong. FOX tried that with a hockey puck and the fans (I'm one) screamed bloody murder.
Personally I'm against the idea of having ball/strikes called at all by machines. It's a human game, let the meatbags play...
Seems like getting a players measurements and keeping them on file somewhere would be a trivial matter. I'm sure not many major league ballplayers get taller or shorter during a career. This would eliminate the uncertainty in that dimension of the strike zone.
The QuesTec operator would then just have to punch in the player's number as he steps to bat and the system would know where the zone should be.
Slashdot Mirror
Someone mod the parent up please. A *lot* of people got burned putting in IMDB information only to have it suddenly go private on them.
I assure you: the problem isn't unfurling a map of that size, the problem is folding it back up again correctly.
C|N>K! Where are my mod-points when I need them. Mod the parent up!
I presume this would be handled between the "equal protection under the law" clause in the 14th Amendment and Congress' right to regulate interstate commerce under Section I article 8.
In many cases Congress has passed laws that supercede state laws. Don't like it? Ride your representatives to insert judges that don't make law from the bench and believe in State's Rights.
But I Am Not A Lawyer.
What Spolsky says about the culture differences is right on the money. First some background.
I spent years as a Unix developer and admin. I've written kernel patches, tinkered in the arcana of NFS, written more Bourne (csh, bash) shell scripts than I care to remember, written a few X apps, learned Perl well enough to write books on it, presented at USENIX, wrote medical and finiancial applications using not much more than libc, programmed Unixes from AT&T SysVR3 to Linux, installed the GNU tools from mag tape in 1988, learned gawk from a wire-bound photocopied manual distributed with that tape, have set up UUCP by hand, and fixed more than my fair share of filesystems with fsdb-like tools. My Unix Wizard hat is dusty, but was honestly earned.
My later career has taken me to Windows shops. I'm currently earning a living writing C and C# for an almost completely DOS and Windows-based company. I've spent a couple of years spelunking MSDN documentation, Google groups, and 3rd party library API's. To that end, I've created a few applications for database interrogation and updating by end-users, web-based applcations, and plenty of GUI-based throwaway applications. My Windows hat is still just a propeller beanie, but I'm working on that.
So having a foot planted firmly in both worlds, I gotta tell ya -- he's right.
When I first approached Windows programming I wrote a lot of things that were used by myself, and that was it. Nobody else wanted to use the software I produced; admins and typical "end-users" alike both ignored them. Honestly, these programs did good things: they were relatively bug free, they scratched an itch that end-users had, sometimes they cured what caused the itch, and were all very Unix-like. Unix like? STDIO based textual interfaces, very easy to plug into other programs, command-line driven, and heavily documented.
The phrase that makes Spolsky so right is the importance of the end users's experience. They're completely different.
With Unix I'm fundamentally thinking of "how am I going to write a program to manipulate data X with data Y?", in Windows I'm thinking of "how would a user expect to cause data X to be manipulated with data Y?". True, in Windows I'm faced with two problems: 1. user interface (to meet their expectations of experience) and 2. actually solving the problem at hand. Over the years though I've found that problem #2 is always easy -- it's just bits, it's problem #1 that makes a successful product or a useful tool.
Once I got used to starting with the user interface (while behind the scenes designing the functionality of the task), my Windows applications really took off. People wanted to play with them, touch them, use them. Sometimes they suffered from the "wrong tool for the job" problem (as many monolithic apps do) but that's okay: they were easy to use, didn't require any explanation, and people just learned to make the tool do what they wanted.
One of the design creeds of Windows seems to be that people are flexible. They don't want to read, learn, or memorize anything but they're willing to take the few tools at hand and bend it every-which-way to get it to do what they want. Unix takes the toolkit approach (design a specific tool for a specific job, with generalized I/O) which makes people read, learn, and memorize, but often provides them with exactly the right tool for the job.
It's not so much the culture of the programmers as it is the culture of the consumers.
Perhaps it's not a beacon, and only a monitoring device. Just before the jump, it could broadcast a forwarding address of the new destination. If the signal propagates at lightspeed you only have to know where they were and when they were there to pick up the signal.
In other words, if I broadcast a signal from Earth now, I can pick it up again at the Sun in 9 minutes, or at Jupiter in a little under an hour, or at Pluto in 4 hours -- ain't FTL great? With FTL drive you'll never miss another TV show again. And re-runs forever!
Once you know this, jump to their new location, lather, rinse, repeat.
I live in a northern climate, so I understand what you're talking about.
Your neighbors are the *best* solution. A gadget solution would be one that would shut off the water and leave it off in the event of a power failure or freezing temperatures.
It should be overridable, of course. But if the power failed (or the temp dropped), the water would stop flowing in from the meter. This would almost completely eliminate the damage if the pipes did freeze. It's not the burst pipes that's the problem -- it's all the water. The incoming pipe from the meter would be fine -- it's normally installed below the frost line anyway.
An improvement: since this would have to be mounted near the incoming water meter (from the city or well) it could also have a drain capability. Picture a "T" shaped device, meter on the left, house on the right, drain out the bottom. Power goes out, it could close the meter-side and open the drain-side allowing the water in the house pipes to drain out a different path to a floor drain (or a tub).
"I predict that within 100 years, computers will be twice as powerful, 10,000 times larger, and so expensive that only the five richest kings of Europe will own them."
Give everyone a good frame of reference so they know what to expect. The last thing you want to do is wind up having people *rely* on the bonus and get disappointed with the Jelly of the Month (the gift that keeps on giving, all year!).
Mod the parent up, please. These yabbos skipped the games that involve getting out of your chair. Game designers must take note of Real Life restrictions like gravity, endurance, timing, strength, and physical dexterity. Not to mention capturing the feeling of fear when you're about to be pummeled with a heavy dodge ball thrown by a strong person who really doesn't like you...
In addition to the parent's list, I'd like to add:
* Jacks
* Marbles
* Skeet shooting (moving targets, non-trivial weapons, IRL)
* Billiards/Pool
Agreed. As I started to read the article those were the first sounds ("I LIVE!" "BEWARE, COWARD!") that came to mind. Being an 80's arcade boy here's the others I thought of and I'm sure everyone can recognize:
The withering Pac-Man death noise and music after the second (?) maze, Frogger's background music and the satisfying "clack" when the frog gets home, the whine of the mutants in Defender, and the satisfying silence when the screen's clear in Asteroids.
No, the sound chips weren't always the best back then but all of these are firmly wedged in my psyche.
...opinion from a Michigander, where you're never more than 3 miles from a natural lake or river anywhere in the state: This is the most useless, stupid idea I've seen in a while.
I'm not sure about the UK, but over here rivers aren't usually given to any kind of easy access. In urban areas factories, docks, and various other kinds of buildings litter the shorelines. In more rural settings, rivers are bordered by swamps, ravines, and steep banks.
On the other hand, *lakes* people go well out of their way to build access ramps to. Then again, if you've got a water-car on a lake...your navigation options are somewhat limited.
And thinking of *driving* out of that river or lake over the embankment across a field to get back to the road? Think again. Just whose land are you driving across to bridge the gap? Private land? The owner'll have your head on a plate for eroding the bank and potentially causing floods. Your own land? If you own the land, what's the point of all this anyway? Public land? The first Department of Natural Resources officer that catches your driving on state land away from a trail will jail you, impound your car, and subject you to severe fines.
Speaking of the DNR, the first time the car leaves an oil slick (or transmission fluid, grease, brake fluid, engine coolant) in the water or on the bank -- public or private land -- you'll start piling up fines that make the price of the car look small by comparison.
I'll just wait for my flying car, thank you.
ObFuturama Reference: And will they broadcast pop up ads into your brain while you sleep?
The OSS community has exactly ZERO motivation to "get the product to market".
That's not entirely true. Failure to bring a usable OSS product to market in a timely manner (Mozilla, Perl 6, Wine, Hurd) will result in ridicule for the development team and the product becomes a target for scorn even within the pro-OSS community.
There's no sales droids or PHB's waiting for the product, but droves of expectant users. When and if the product is delivered the programmers get their rewards (attaboys, good press, professional recognition, jobs).
So the OSS community has very strong motivations for success and against failure. They're just not directly monetary.
I disagree: if you walk into your job acting like an ivory tower egghead, then yes. The the key is to realize that you really know *squat* about the business you're starting in, and take some time to learn
And by that some token, with these qualifications you should be willing to accept a true entry-level salary and simply expect your salary to increase on a steeper ramp than someone without your background.
Walking into a new job with lots of education, but no joureyman experience, please set your expectations accordingly.
Speak for your own radio. I was tired of listening to the radio in my truck, but searched for a portable radio for which I had proper batteries in vain. I certainly wasn't going to join the mobs rushing to buy batteries at the Kwik E Mart. After a bit of thinking, I went rummaging through my kid's room and found...his crystal radio kit. I threw the antenna wire over a small tree in the yard, attached the ground to a copper ground rod (installed by Ma Bell). I could then listen to 4 stations (2 of which had music) while resting in my hammock reading a novel.
On later reflection, I had the necessary diode in a spare parts drawer and could have built a much better one if I felt inclined.
Of course. After I was done posting I realized that at that point it was the grandfather (not the father) of the post I was writing that was the troll...
The parent troll speaks like someone who flew into Detroit, visited Flint, stopped by Grand Rapids and hit nothing in between.
The Upper Peninsula has gorgeous old-growth forests and is wonderful backpacking country: you can walk for hours without seeing any signs of civilization and the stargazing is great. Michigan has more shoreline than any US state (except Alaska) which include the world's largest freshwater dunes, great swimming beaches, and limestone cliffs. There's also good canoeing and kayaking all over the upper Lower Peninsula.
If you're in the Midwest, pop by Dearborn, Michigan. (Southeast corner of the mitten.)
Lots and lots of technology history everywhere you look. Even if you skip the automobile stuff (which I do) there's at least two day's worth of stuff to look through. Very little stuff is re-creations.
Edison's lab, the Wright Brother's shop, more steam-powered machinery than you ever thought possible, every wheeled mode of transportation imaginable, gadgets, gadgets, gadgets, R. Bucky's Dymaxion house. Through the end of the year they've got quite a bit of James Bond stuff on display.
Henry Ford Museum
Lloyds of London has been operating as a shipping underwriter since the 17th century. Although I doubt they've been accident-free that long. :)
The XML Police that exist in several communities will come down on you like flies on manure. "You can't parse XML in regexps! That's not really parsing! You need to use the standard-flavor-of-the-month XML libraries for your language (which of course, may need dozens of prerequisite libraries)! What about CDATA? DTDs?! Encodings!? OH THINK OF THE CHILDREN!"
<stage_whisper>But in my experience, most of the time, you're right</stage_whisper>
Line of sight methods (lasers of almost any kind) wouldn't work. Even during a pitch, there's lots of crap to obstruct a clear view of the ball, even looking up from the plate's vantage point there's dirt to contend with. Then there are problems with wet/scuffed baseballs and refraction of the light.
Two thoughts I've had. First is making the plate itself a low power radar unit of sorts. The biggest problem would be differentiating the debris over the plate (batter, bat, catcher's equipment) from the ball itself.
The second was embedding something in the ball to reflect radio signals of the right frequency. Place a few transmitters/receivers around the plate and do a little triangulation. However, doctoring a baseball no matter how little, seems... wrong. FOX tried that with a hockey puck and the fans (I'm one) screamed bloody murder.
Personally I'm against the idea of having ball/strikes called at all by machines. It's a human game, let the meatbags play...
Seems like getting a players measurements and keeping them on file somewhere would be a trivial matter. I'm sure not many major league ballplayers get taller or shorter during a career. This would eliminate the uncertainty in that dimension of the strike zone.
The QuesTec operator would then just have to punch in the player's number as he steps to bat and the system would know where the zone should be.