Let's see, the big news stories this week: (1) Tiger Woods gets in a fender bender after he gets in a fight with his wife, and (2) the White House party crashers apparently lied about other stuff, too.
Your argument seems to be, "we haven't had a nuclear war since 1945, so the risk of nuclear war must be extremely low."
A lot of Hellman's article (and the whole point about the glider antics) was pointing out how awful the human intellect is at working out risks (as if the current economic mess, or for that matter Las Vegas, didn't spell that out even more eloquently). He is certainly correct to argue that it is even more dangerous to be complacent.
If you've got a laptop, what have you got on it? Probably you've got some kind of address book with phone numbers and physical addresses. You might have a pile of old e-mail stashed away somewhere -- that old email probably has a whole lot of personal information in it that isn't yours. You probably aren't maximally paranoid about securing that stuff either, since you are the only person using that laptop.
Question is, are you a criminal if someone steals that laptop? Hell no.
I'd also ask you to consider how diligent you'd be about informing everyone in your address book that your laptop is stolen.
Actually, when solar power is used in a lot of off-the-grid installations a lot of things like lighting are done in DC (dc lights are widely used in RVs so they are pretty commonly available).
Usually an inverter costs you about 30 percent, and I'd agree that converting back to DC would cost about the same.
Honestly, I can't think of a single project I've worked on where coding standards made a bit of difference. Poor programmers will write lame code that complies with the coding standards, while great programmers will write great code that complies with the coding standards. Pissed-off, alienated programmers can obnoxiously comply with coding standards by writing incomprehensible and fragile code.
I personally like to write software that someone, somewhere, will actually use. How do coding standards actually help that problem?
My own experience has been that detailed coding standards tend to correlate with projects and products that go wildly out of control. My hypothesis on why that happens is that people involved in such projects all subconsciously know that and are desperately trying to control at least some aspect of the product development process. (one of my favorite's was a brief stint at a large, heartless company that makes large aircraft in a somewhat rainy part of America -- "all C functions must return a value, and all function return values must be checked". 'nuff said)
I had quite a few friends who worked for NASA in various capacities. Their stories were remarkably similar. A couple of them were earnestly working on projects that got caught in some kind of political cross-fire and found their project(s) killed. One of the telling comments was that government service still manages people the same way it did in the 1950's.
You can work as hard and on pretty cool stuff for a company like Google (or Microsoft in years past) and make a million dollars or more at the end of five years. Your office will probably be nicer, the food is certainly better, and there are quite a pile of perks (like, I don't know, no drug tests and no silly loyalty oaths) that are quite unimaginable in government service.
The problem is that the people doing the recruiting can't even see the problem: they have probably been lifers and don't have any basis for comparison, and probably don't really believe that Google has a concierge.
I had a consulting gig in Canada set up. Spiffy hourly rate of $165. The problem was that the IRS wanted 40 percent and Revenue Canada wanted 60 percent. That didn't seem such a good deal.
The real problem was that I asked the wrong people and they were clueless. The actual bite ended up being quite a bit less (even counting the nice people I paid to make this possible).
One of the problems is that barrier security has diminishing returns as the size of what you are barricading gets bigger.
You wear clothes. Your house probably has a bathroom door. But Seattle or San Diego are probably too big and too intertangled with the world to use perimeter security in a big way, much less large countries with land borders.
There's lots of other jobs out there where you won't be confronted with this quandary. Your never going to get any credit for pointing out the security problems of your current employer. You run considerable legal risks (and might, in practice, render yourself unemployable in the future) if you try to blow the whistle.
Find another job. Your family will be fed. You will also sleep somewhat better, except when you realize your ex-employer is still out there.
I am a recovering "security professional". After an eye-opening experience long ago where I realized that I knew at least as much as the experts. So I managed to do pretty well for myself during the boom years. Then ran screaming from the Real World and goofed off with a few consulting gigs to keep me from being completely retired.
Those gigs were rarely happy ones. I came to the conclusion that there is no adequate technical solution to the security problem. Arguing that any given platform (Mac OS X, Linux, BeOS, Windows Vista, &c) is more secure misses the point -- all platforms have security holes, and all you need is one to ruin your whole month. Even if you loyally and skillfully apply all relevant security patches as soon as you are aware of them and as soon as they are available you still will have quite a window of vulnerability -- and that window might be shorter on your favorite OS. But how can that matter when an unprotected machine can literally be 0wned in minutes?
From a legal standpoint, a lot of work remains to be done (if you've ever tried to get help from your favorite law-enforcement agency when your server farm has been sacked and pillaged you'll understand). Our criminal-justice systems are caught in a race. They are a snail and the competition has a supersonic jet. The international nature of the internet kind of screws us too -- we've got to deal with Moldovan criminal gangs and elite government-sponsored hacking teams (who almost certainly cover many of their activities by looking and acting like criminals) who are hopelessly beyond the reach of any law enforcement agency. If it were just Moldova it would be one problem, but how many countries are there out there the bad guys can hide behind? Most any country in Africa, most any country whose name ends with "-stan", and damned near any country with scary toilets won't be much help if the people who set up the attacks are living there.
I've been reduced to alternating between Cheneyist tinfoil-hat paranoia and a Bushian "what? me worry?" obliviousness. Neither is very satisfying.
Y'know, I'm feeling I need to play devil's advocate here.
I'm not exactly trusting of the intentions of the fine people doing this, and I'm even less trusting of their ability to implement even good ideas. That's probably not fair but I'm pretty sure I'm not the only one who feels that way.
If you've ever tried to actually deal with law enforcement on a computer crime, you run into pretty wicked problems both of jurisdiction and technical competence. While the latter problem has improved somewhat in recent years, the former problem still exists (and is arguably worse, twenty years ago your trail wouldn't run cold in Moldova or Pakistan or Vietnam).
This means there is a real problem to be solved here. It also seems to me that the problem has technical, political, and legal aspects. That implies any solution is going to be ugly.
Having the Internet be a separate jurisdiction with its own courts and its own police makes more sense than the mess we have now.
I think the major problem is that everyone has massively underestimated the cost and technical complexity of building reliable launch systems. We have even more massively underestimated the technical complexity of building inexpensive launch systems. Yes, there are some smart people working on the problem, both in the private and public sector. Yes, there could be more money spent on development of better launch systems. Yes, NASA has turned into a somewhat lame organization (and at least part of the blame is that smart geeky dudes (almost always dudes) who used to gravitate to working for NASA usually end up working for high-tech companies and retiring young).
Absent some really spectacular breakthroughs in materials science, propulsion systems, and the engineering of complex systems, though, I think we're kind of stuck. There is a glimmer of hope that nanotechnology might get us really high-efficiency fuels that are stable at room temperature and really lightweight and strong materials for building a spacecraft -- or for that matter building and handling a really enormous solar sail. The complexity problem is a lot tougher. Building a big clanking machine that is reliable enough to keep people alive in a viciously hostile environment for years isn't going to be easy. It isn't easy on the South Pole (comparably an idyllic environment as opposed to the surface of Mars, much less interplanetary space). As far as I can tell, the major accomplishment of the folks on ISS is keeping themselves alive. No doubt a worthy prospect but not what we were sold on.
Yes, you could build a space elevator. If you had those cool materials and a cheaper launch system.
The whole idea of Helium-3 mining is kind of loony.
At this point, we can't build any kind of practical fusion reactor, much less one that uses Helium-3 (which probably will be harder because the ignition temperature is quite a bit higher). And it won't be completely clean or efficient anyway because some of the intermediate reactions will still produce neutrons.
So we can't even know if this makes any sense from any economic or engineering standpoint because we don't yet know how a practical fusion reactor would work. But we also need to know how to make much more cost-efficient space launch systems before it is even feasible to mine lunar regolith for trace elements.
So, if we can make efficient launch systems, and if we can design fusion reactors that use Helium-3, it MIGHT be economically feasible to extract Helium-3 from the moon and use it to power those reactors. I'd point out that those two "ifs" aren't small ones, either. So the "environmental debate" is a thought experiment about a thought experiment about a thought experiment. It seems to me that there are much more pressing environmental problems than this, if you even allow that mining the moon is an environmental problem.
I'd also add that mining is typically a pretty low-profit margin business (yes, the absolute profits might be quite large, but the margins are quite low, especially when averaged over time). You need to lose money like an army of Web 2.0 startups for decades before you start making any money (that's even true of things like petroleum and natural gas that are riding high right now). I'd also add that you don't just go digging holes at random looking for gold or molybdenum or helium-3. On earth there are geologic processes that concentrate interesting stuff. I suspect that the moon hasn't had many of those geologic processes, or even very many good geologic processes at all for creating or concentrating useful stuff -- and that means that mining on the moon is even less likely to be economically feasible.
Acually, it wasn't until the fifties that we Americans really had the freedom to travel. There was a fairly long history of denying passports to people who were, um, politically inconvenient before that time. Quite a few people were denied the right to travel overseas because of suspected communist sympathies during the McCarthy era. Until the
1958 Kent vs. Dulles decision
finally put an end to such insanity.
I've never, ever seen a project where the distinctions between "programmer" and "software engineer" were at all clear. Different people understood different parts of the project. A very few people would understand a much, much more than most. At the other extreme there were people who were handed requirements for little pieces of the product (the process was more like throwing raw meat to a caged, yet still scary animal) and would more or less churn them out.
I think the title "engineering" is much too grandiose for what most people who build software ever do, and for that matter I don't think most software projects are really "engineered" at all. This isn't a bad thing, really. For there to be a meaningful engineering process involved in building something, it implies a large accumulated body of best practices accepted by people learned in the art. That is true for some software, most notably programming languages, databases, and operating systems. But I don't really think it is yet true for desktop applications, games, or web sites. Only a tiny minority of us involved in the trade are actually doing engineering.
We might write better code if it was more like a real engineering discipline. I somehow doubt it, though. Software is a little too fluid. Over and over again I've written software to solve a problem that inadvertently changed the problem definition. As soon as users get hold of a new software tool, they often discover things about their own data for the very first time -- some good, some bad. That generates feature requests and more billable hours. The equivalent rarely happens when you build dams or bridges.
Building software, I think, is much more of a creative trade with more in common with composing music or performing in a theater than with designing headlight bezels for panel trucks. At times, I suspect one reason that there is such resistance to this point of view is that we perceive our field as a "hard" technical field, not an artistic one. It is certainly true that any design process, from composing a sonnet, taking a great photograph, or making a SSTO rocket engine involves a fair amount of both technical knowledge and creativity. The artificial division between those endeavors is pretty awkward for those of us who like to write code, though. I also suspect that one reason that job dissatisfaction, burnout, and just out-and-out cynicism is so high in our chosen field is that most people creating software are managed not as artists, not as highly skilled experts like a team of surgeons performing a risky procedure, but as an army of mechanics.
There are orders-of-magnitude differences between individual code productivity (I think factors of a thousand or even ten thousand are plausible). That means that one hypothetical American superprogrammer paid millions of dollars per year is likely still much less expensive than an army of average code grunts from India -- even before you layer in the communications costs of managing a larger team, travel costs, and the difficulty of communicating requirements and changes to requirements to a development team literally on the other side of the planet. A lot of that productivity advanage, I suspect, comes from understanding requirements well. You are less likely to get the ten-thousand to one productivity advantage if your requirements are communicated to you indirectly (like through a bunch of jet-lagged product managers who you meet physically once a month and teleconference with a few times a week).
To go back to the media analogy, we all know that getting into acting, music, or television news requires overcoming almost overwhelming odds. There is no shortage, ever, of starving artists. Yet people expend enormous amounts of energy trying to break into these fields. For average compensations that make churning out MS Access applications look like a great job. I think that's where software is going. There seems to be no shortage of talented people in the media fields (and no shortage of untalented either), yet there really isn't any equivalent to an entry level job.
I know about db/schema.rb. But your entity relationships are strewn in the model definitions. Yes, you could use "rake db:structure:dump" (or "rake db:annotate" that I swiped from one book on Rails), but you still have to remember to do that. This is essentially a minor problem, but every neophyte rails programmer I've encountered gets confused by this, especially when they are coming into an existing project.
As for database-independence, it really depends on the applications you write and the customer. For nearly all of my clients I've been writing one-off applications that have to talk to pre-existing databases -- in that case the database wrapping in Active Record can't buy me very much. As for your comment about a huge multi-table select versus sending an object messages, yes, it is much much simpler to implement that with Active Record's object syntax, but it is guaranteed to be quite a bit slower than a hand-constructed select statement. And that is one case where performance would quite often matter.
If there was clean support for views in Active Record (none of the plugins I've seen make me very happy) I'd be a happier coder.
I like ruby and I like rails and agree that it is very hard not to write ugly code in PHP.
Honestly, great websites and web applications have been written using all three of those products. What the best choice for your website will be depends a lot on what your website is. Each of those frameworks makes certain assumptions about how the world works, and you will be happiest with a framework that is closest to your pwn assumptions -- otherwise you'll spend as much time fighting the framework as writing your website.
Any halfway skilled programmer will be able to do useful work with any of those frameworks fairly early on, but all of them are also very rich environments, so there's always more to learn.
I've written web apps in an ungodly tangle of PHP4 and PHP 5 and Perl and using Ruby on Rails. Currently Ruby on Rails is in favor, but is far from perfect.
Probably most of my frustration with Rails and PHP 5 has to do with Active Record. My big gripes are: (1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails); (2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle; (3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.
lago:~/Music david$ cd/Applications
lago:/Applications david$ du -s iTunes.app/
199896 iTunes.app/
lago:/Applications david$ cd ~/Music/
lago:~/Music david$ du -s iTunes/
33180792 iTunes/
lago:~/Music david$
'nuff said? Maybe. From my point of view, for a lot of applications the volume of data you are fooling with (like the above example) completely overwhelms any software bloat.
Sometimes bloat does matter. If I wanted to make a little fanless machine that would boot off of flash drive, I'd need to use damned skinny software on it because I'd be faced with very limited disk space and I wouldn't want applications using that poor flash drive as virtual memory.
Dependencies matter too. A smallish application with a mess of dependencies (especially if it is at all fussy about those dependencies) is a lot more trouble to deal with than a bloated application that doesn't have that mess of dependencies. Sometimes there is much to be said for statically linking things.
Primate Testing in the United States involved the "use" of 60,000 animals in 2004. Such testing is used
to help ensure the safety of new drugs and vaccines. If you don't believe evolution is scientifically valid, how can one justify this? Why wouldn't we use flatworms?
The FDA, in fact, requires primate testing for many new medical treatments. Should the FDA remove this requirement?
Seriously, this matters much, much more than what teenagers do or don't learn in hi skool biology class. If the Creationist and ID people are right, then we can save quite a bit of money and quite possibly quite a few human lives by forgoing such testing. Plus thousands of furry animals.
Add fake names to your phone directory (this might involve inventing a pretext about harassing phone calls or a possible industrial espionage operation). Bonus points for creative names.
Check the fake voicemail religiously.
If the recruiters call, make sure you call back.
Send a fake resume. Make it good.
When they call for an interview, recruit a homeless person of approximately the correct age and gender. Pay them fifty bucks to stand in for you at the interview. Obvious bonus points if the homeless person is seriously drunk or otherwise incapacitated for their interview.
Repeat as necessary.
If you don't want to drop the fifty bucks, show up for the interview yourself but make sure something is really wrong with you. Drunk is good. In bike clothes after a two-hour ride in the rain is also good.
No-shows at expensive restaurants, always with a good excuse like an auto accident, are also helpful.
That seems like a reasonable assertion. But I doubt it is correct.
At the start of World War II, Germany's biggest trading partner was, um, France.
Both the Israelis and Palestinians would be much, much better off economically if they stopped killing each other. But they don't.
It isn't safe to assume that all (or even most) wars are fought for rational reasons. Or that nations won't be willing to impoverish themselves to prove a point.
1970's: hysteria about radiation from microwave ovens
1980's: hysteria about radiation from power lines (well, really the late 80's)
1990's: hysteria about radiation from cell phones
2000's: hysteria about radiation from wi-fi
I know of no imaginable mechanism that allows gigahertz-frequency radiation at low power levels to break chemical bonds. That's what you'd need in order to have microwave be harmful. End of story.
The problem is that if you are dealing with a relatively rare disease (like a childhood cancer) it is extremely easy to produce a spurious correlation with almost anything. Since you're dealing with an effect right on the edge of statistical noise, and since a lot of researchers are less than diligent about making sure they aren't fooling themselves (they often "know" there is an effect and so they'll keep poking at the data until they get one).
Top it all off with the sad fact that most people (many scientists, nearly all journalists) assume that correlation == cause.
Did you actually read the posts made about Kathy Sierra? They were pretty outrageously vicious. I can't imagine anyone saying garbage like that face to face without there being hell to pay.
Slashdot Mirror
Let's see, the big news stories this week: (1) Tiger Woods gets in a fender bender after he gets in a fight with his wife, and (2) the White House party crashers apparently lied about other stuff, too.
Journalism is already dead.
I think you are missing a point.
Your argument seems to be, "we haven't had a nuclear war since 1945, so the risk of nuclear war must be extremely low."
A lot of Hellman's article (and the whole point about the glider antics) was pointing out how awful the human intellect is at working out risks (as if the current economic mess, or for that matter Las Vegas, didn't spell that out even more eloquently). He is certainly correct to argue that it is even more dangerous to be complacent.
If you've got a laptop, what have you got on it? Probably you've got some kind of address book with phone numbers and physical addresses. You might have a pile of old e-mail stashed away somewhere -- that old email probably has a whole lot of personal information in it that isn't yours. You probably aren't maximally paranoid about securing that stuff either, since you are the only person using that laptop.
Question is, are you a criminal if someone steals that laptop? Hell no.
I'd also ask you to consider how diligent you'd be about informing everyone in your address book that your laptop is stolen.
Actually, when solar power is used in a lot of off-the-grid installations a lot of things like lighting are done in DC (dc lights are widely used in RVs so they are pretty commonly available).
Usually an inverter costs you about 30 percent, and I'd agree that converting back to DC would cost about the same.
Honestly, I can't think of a single project I've worked on where coding standards made a bit of difference. Poor programmers will write lame code that complies with the coding standards, while great programmers will write great code that complies with the coding standards. Pissed-off, alienated programmers can obnoxiously comply with coding standards by writing incomprehensible and fragile code.
I personally like to write software that someone, somewhere, will actually use. How do coding standards actually help that problem?
My own experience has been that detailed coding standards tend to correlate with projects and products that go wildly out of control. My hypothesis on why that happens is that people involved in such projects all subconsciously know that and are desperately trying to control at least some aspect of the product development process. (one of my favorite's was a brief stint at a large, heartless company that makes large aircraft in a somewhat rainy part of America -- "all C functions must return a value, and all function return values must be checked". 'nuff said)
I had quite a few friends who worked for NASA in various capacities. Their stories were remarkably similar. A couple of them were earnestly working on projects that got caught in some kind of political cross-fire and found their project(s) killed. One of the telling comments was that government service still manages people the same way it did in the 1950's.
You can work as hard and on pretty cool stuff for a company like Google (or Microsoft in years past) and make a million dollars or more at the end of five years. Your office will probably be nicer, the food is certainly better, and there are quite a pile of perks (like, I don't know, no drug tests and no silly loyalty oaths) that are quite unimaginable in government service.
The problem is that the people doing the recruiting can't even see the problem: they have probably been lifers and don't have any basis for comparison, and probably don't really believe that Google has a concierge.
Probably the thing you left out is about taxes.
I had a consulting gig in Canada set up. Spiffy hourly rate of $165. The problem was that the IRS wanted 40 percent and Revenue Canada wanted 60 percent. That didn't seem such a good deal.
The real problem was that I asked the wrong people and they were clueless. The actual bite ended up being quite a bit less (even counting the nice people I paid to make this possible).
One of the problems is that barrier security has diminishing returns as the size of what you are barricading gets bigger.
You wear clothes. Your house probably has a bathroom door. But Seattle or San Diego are probably too big and too intertangled with the world to use perimeter security in a big way, much less large countries with land borders.
There's lots of other jobs out there where you won't be confronted with this quandary. Your never going to get any credit for pointing out the security problems of your current employer. You run considerable legal risks (and might, in practice, render yourself unemployable in the future) if you try to blow the whistle.
Find another job. Your family will be fed. You will also sleep somewhat better, except when you realize your ex-employer is still out there.
I am a recovering "security professional". After an eye-opening experience long ago where I realized that I knew at least as much as the experts. So I managed to do pretty well for myself during the boom years. Then ran screaming from the Real World and goofed off with a few consulting gigs to keep me from being completely retired.
Those gigs were rarely happy ones. I came to the conclusion that there is no adequate technical solution to the security problem. Arguing that any given platform (Mac OS X, Linux, BeOS, Windows Vista, &c) is more secure misses the point -- all platforms have security holes, and all you need is one to ruin your whole month. Even if you loyally and skillfully apply all relevant security patches as soon as you are aware of them and as soon as they are available you still will have quite a window of vulnerability -- and that window might be shorter on your favorite OS. But how can that matter when an unprotected machine can literally be 0wned in minutes?
From a legal standpoint, a lot of work remains to be done (if you've ever tried to get help from your favorite law-enforcement agency when your server farm has been sacked and pillaged you'll understand). Our criminal-justice systems are caught in a race. They are a snail and the competition has a supersonic jet. The international nature of the internet kind of screws us too -- we've got to deal with Moldovan criminal gangs and elite government-sponsored hacking teams (who almost certainly cover many of their activities by looking and acting like criminals) who are hopelessly beyond the reach of any law enforcement agency. If it were just Moldova it would be one problem, but how many countries are there out there the bad guys can hide behind? Most any country in Africa, most any country whose name ends with "-stan", and damned near any country with scary toilets won't be much help if the people who set up the attacks are living there.
I've been reduced to alternating between Cheneyist tinfoil-hat paranoia and a Bushian "what? me worry?" obliviousness. Neither is very satisfying.
Y'know, I'm feeling I need to play devil's advocate here.
I'm not exactly trusting of the intentions of the fine people doing this, and I'm even less trusting of their ability to implement even good ideas. That's probably not fair but I'm pretty sure I'm not the only one who feels that way.
If you've ever tried to actually deal with law enforcement on a computer crime, you run into pretty wicked problems both of jurisdiction and technical competence. While the latter problem has improved somewhat in recent years, the former problem still exists (and is arguably worse, twenty years ago your trail wouldn't run cold in Moldova or Pakistan or Vietnam).
This means there is a real problem to be solved here. It also seems to me that the problem has technical, political, and legal aspects. That implies any solution is going to be ugly.
Having the Internet be a separate jurisdiction with its own courts and its own police makes more sense than the mess we have now.
There's probably more to it than lack of will.
I think the major problem is that everyone has massively underestimated the cost and technical complexity of building reliable launch systems. We have even more massively underestimated the technical complexity of building inexpensive launch systems. Yes, there are some smart people working on the problem, both in the private and public sector. Yes, there could be more money spent on development of better launch systems. Yes, NASA has turned into a somewhat lame organization (and at least part of the blame is that smart geeky dudes (almost always dudes) who used to gravitate to working for NASA usually end up working for high-tech companies and retiring young).
Absent some really spectacular breakthroughs in materials science, propulsion systems, and the engineering of complex systems, though, I think we're kind of stuck. There is a glimmer of hope that nanotechnology might get us really high-efficiency fuels that are stable at room temperature and really lightweight and strong materials for building a spacecraft -- or for that matter building and handling a really enormous solar sail. The complexity problem is a lot tougher. Building a big clanking machine that is reliable enough to keep people alive in a viciously hostile environment for years isn't going to be easy. It isn't easy on the South Pole (comparably an idyllic environment as opposed to the surface of Mars, much less interplanetary space). As far as I can tell, the major accomplishment of the folks on ISS is keeping themselves alive. No doubt a worthy prospect but not what we were sold on.
Yes, you could build a space elevator. If you had those cool materials and a cheaper launch system.
I'm just thinking of the applications for household pets...
Dwarf elephants the size of kittens. Basselopes. Maybe even unicorns...
At this point, we can't build any kind of practical fusion reactor, much less one that uses Helium-3 (which probably will be harder because the ignition temperature is quite a bit higher). And it won't be completely clean or efficient anyway because some of the intermediate reactions will still produce neutrons.
So we can't even know if this makes any sense from any economic or engineering standpoint because we don't yet know how a practical fusion reactor would work. But we also need to know how to make much more cost-efficient space launch systems before it is even feasible to mine lunar regolith for trace elements.
So, if we can make efficient launch systems, and if we can design fusion reactors that use Helium-3, it MIGHT be economically feasible to extract Helium-3 from the moon and use it to power those reactors. I'd point out that those two "ifs" aren't small ones, either. So the "environmental debate" is a thought experiment about a thought experiment about a thought experiment. It seems to me that there are much more pressing environmental problems than this, if you even allow that mining the moon is an environmental problem.
I'd also add that mining is typically a pretty low-profit margin business (yes, the absolute profits might be quite large, but the margins are quite low, especially when averaged over time). You need to lose money like an army of Web 2.0 startups for decades before you start making any money (that's even true of things like petroleum and natural gas that are riding high right now). I'd also add that you don't just go digging holes at random looking for gold or molybdenum or helium-3. On earth there are geologic processes that concentrate interesting stuff. I suspect that the moon hasn't had many of those geologic processes, or even very many good geologic processes at all for creating or concentrating useful stuff -- and that means that mining on the moon is even less likely to be economically feasible.
While we are at it, can we have a TLD for the Republic of Cascadia? In the .us domain, they also need state codes for the
State of Jefferson and the state(s) of Lincoln.
Acually, it wasn't until the fifties that we Americans really had the freedom to travel. There was a fairly long history of denying passports to people who were, um, politically inconvenient before that time. Quite a few people were denied the right to travel overseas because of suspected communist sympathies during the McCarthy era. Until the 1958 Kent vs. Dulles decision finally put an end to such insanity.
I think the title "engineering" is much too grandiose for what most people who build software ever do, and for that matter I don't think most software projects are really "engineered" at all. This isn't a bad thing, really. For there to be a meaningful engineering process involved in building something, it implies a large accumulated body of best practices accepted by people learned in the art. That is true for some software, most notably programming languages, databases, and operating systems. But I don't really think it is yet true for desktop applications, games, or web sites. Only a tiny minority of us involved in the trade are actually doing engineering.
We might write better code if it was more like a real engineering discipline. I somehow doubt it, though. Software is a little too fluid. Over and over again I've written software to solve a problem that inadvertently changed the problem definition. As soon as users get hold of a new software tool, they often discover things about their own data for the very first time -- some good, some bad. That generates feature requests and more billable hours. The equivalent rarely happens when you build dams or bridges.
Building software, I think, is much more of a creative trade with more in common with composing music or performing in a theater than with designing headlight bezels for panel trucks. At times, I suspect one reason that there is such resistance to this point of view is that we perceive our field as a "hard" technical field, not an artistic one. It is certainly true that any design process, from composing a sonnet, taking a great photograph, or making a SSTO rocket engine involves a fair amount of both technical knowledge and creativity. The artificial division between those endeavors is pretty awkward for those of us who like to write code, though. I also suspect that one reason that job dissatisfaction, burnout, and just out-and-out cynicism is so high in our chosen field is that most people creating software are managed not as artists, not as highly skilled experts like a team of surgeons performing a risky procedure, but as an army of mechanics.
There are orders-of-magnitude differences between individual code productivity (I think factors of a thousand or even ten thousand are plausible). That means that one hypothetical American superprogrammer paid millions of dollars per year is likely still much less expensive than an army of average code grunts from India -- even before you layer in the communications costs of managing a larger team, travel costs, and the difficulty of communicating requirements and changes to requirements to a development team literally on the other side of the planet. A lot of that productivity advanage, I suspect, comes from understanding requirements well. You are less likely to get the ten-thousand to one productivity advantage if your requirements are communicated to you indirectly (like through a bunch of jet-lagged product managers who you meet physically once a month and teleconference with a few times a week).
To go back to the media analogy, we all know that getting into acting, music, or television news requires overcoming almost overwhelming odds. There is no shortage, ever, of starving artists. Yet people expend enormous amounts of energy trying to break into these fields. For average compensations that make churning out MS Access applications look like a great job. I think that's where software is going. There seems to be no shortage of talented people in the media fields (and no shortage of untalented either), yet there really isn't any equivalent to an entry level job.
I know about db/schema.rb. But your entity relationships are strewn in the model definitions. Yes, you could use "rake db:structure:dump" (or "rake db:annotate" that I swiped from one book on Rails), but you still have to remember to do that. This is essentially a minor problem, but every neophyte rails programmer I've encountered gets confused by this, especially when they are coming into an existing project.
As for database-independence, it really depends on the applications you write and the customer. For nearly all of my clients I've been writing one-off applications that have to talk to pre-existing databases -- in that case the database wrapping in Active Record can't buy me very much. As for your comment about a huge multi-table select versus sending an object messages, yes, it is much much simpler to implement that with Active Record's object syntax, but it is guaranteed to be quite a bit slower than a hand-constructed select statement. And that is one case where performance would quite often matter.
If there was clean support for views in Active Record (none of the plugins I've seen make me very happy) I'd be a happier coder.
I like ruby and I like rails and agree that it is very hard not to write ugly code in PHP.
Any halfway skilled programmer will be able to do useful work with any of those frameworks fairly early on, but all of them are also very rich environments, so there's always more to learn.
I've written web apps in an ungodly tangle of PHP4 and PHP 5 and Perl and using Ruby on Rails. Currently Ruby on Rails is in favor, but is far from perfect.
Probably most of my frustration with Rails and PHP 5 has to do with Active Record. My big gripes are: (1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails); (2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle; (3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.
lago:/Applications david$ du -s iTunes.app/
199896 iTunes.app/
lago:/Applications david$ cd ~/Music/
lago:~/Music david$ du -s iTunes/
33180792 iTunes/
lago:~/Music david$
'nuff said? Maybe. From my point of view, for a lot of applications the volume of data you are fooling with (like the above example) completely overwhelms any software bloat.
Sometimes bloat does matter. If I wanted to make a little fanless machine that would boot off of flash drive, I'd need to use damned skinny software on it because I'd be faced with very limited disk space and I wouldn't want applications using that poor flash drive as virtual memory.
Dependencies matter too. A smallish application with a mess of dependencies (especially if it is at all fussy about those dependencies) is a lot more trouble to deal with than a bloated application that doesn't have that mess of dependencies. Sometimes there is much to be said for statically linking things.
Primate Testing in the United States involved the "use" of 60,000 animals in 2004. Such testing is used to help ensure the safety of new drugs and vaccines. If you don't believe evolution is scientifically valid, how can one justify this? Why wouldn't we use flatworms? The FDA, in fact, requires primate testing for many new medical treatments. Should the FDA remove this requirement?
Seriously, this matters much, much more than what teenagers do or don't learn in hi skool biology class. If the Creationist and ID people are right, then we can save quite a bit of money and quite possibly quite a few human lives by forgoing such testing. Plus thousands of furry animals.
Add fake names to your phone directory (this might involve inventing a pretext about harassing phone calls or a possible industrial espionage operation). Bonus points for creative names.
Check the fake voicemail religiously.
If the recruiters call, make sure you call back.
Send a fake resume. Make it good.
When they call for an interview, recruit a homeless person of approximately the correct age and gender. Pay them fifty bucks to stand in for you at the interview. Obvious bonus points if the homeless person is seriously drunk or otherwise incapacitated for their interview.
Repeat as necessary.
If you don't want to drop the fifty bucks, show up for the interview yourself but make sure something is really wrong with you. Drunk is good. In bike clothes after a two-hour ride in the rain is also good.
No-shows at expensive restaurants, always with a good excuse like an auto accident, are also helpful.
That seems like a reasonable assertion. But I doubt it is correct.
At the start of World War II, Germany's biggest trading partner was, um, France.
Both the Israelis and Palestinians would be much, much better off economically if they stopped killing each other. But they don't.
It isn't safe to assume that all (or even most) wars are fought for rational reasons. Or that nations won't be willing to impoverish themselves to prove a point.
- 1970's: hysteria about radiation from microwave ovens
- 1980's: hysteria about radiation from power lines (well, really the late 80's)
- 1990's: hysteria about radiation from cell phones
- 2000's: hysteria about radiation from wi-fi
I know of no imaginable mechanism that allows gigahertz-frequency radiation at low power levels to break chemical bonds. That's what you'd need in order to have microwave be harmful. End of story. The problem is that if you are dealing with a relatively rare disease (like a childhood cancer) it is extremely easy to produce a spurious correlation with almost anything. Since you're dealing with an effect right on the edge of statistical noise, and since a lot of researchers are less than diligent about making sure they aren't fooling themselves (they often "know" there is an effect and so they'll keep poking at the data until they get one). Top it all off with the sad fact that most people (many scientists, nearly all journalists) assume that correlation == cause.Did you actually read the posts made about Kathy Sierra? They were pretty outrageously vicious. I can't imagine anyone saying garbage like that face to face without there being hell to pay.