Yep! The "first pancake" approach is a good one. And, as other posters have noted, a venerable one. Why? as you point out, you discover a lot as you go, both about the user needs and about how to do them well.
But you can go further with this! Any short-cycle iterative model will give you this sort of feedback every couple of weeks, rather than at the end of every version.
For more info on it, take a look at Rapid Development's discussion of evolutionary delivery. Or try a process that's built around feedback, like Coad's Feature Driven Development or, my personal favorite, Beck's Extreme Programming (XP) (dumb name, but a great process).
Most code is utter drudgery. It's predictable in an informal manner to a very high degree.
Quick tip: If most of your coding is utter drudgery, you're doing the wrong coding.
The potential drudgery I see tends to come from two sources: 1) users tend to ask for very similar things (e.g., a zillion slightly different reports), and 2) tools that are a poor match to the problem domain.
For the first case, users with similar requests, you give the user control and tools to support that control. So instead of wasting your life writing report after report, write report-generating tools.
For the second case, you gotta buy or build better tools. Or, possibly, learn to use the ones you have better. For example, if you're using an OO language, stop using your copy and paste keys. (Why? When you copy and paste chunks of code, you're saying that two things are very similar. Instead of copy-and-paste, abstract the problem using, say, inheritance or containment or delegation. Copy-and-paste yeilds maintenance nightmares.)
Computers do drudgery without complaining, and they do it much faster than you. Make them do your donkey work!
I had enough of this argument. Its simply crap, and is always written by non programmers, or by programmers who are not responsible for delivering the real product.
Hi. I'm a programmer. I've been programming for money since I was 16. I deliver.
I agree that excessive documentation is bad. And that many companies have official policies that, if actually followed, would result in excessive documentation. Know why they have those policies? Because most programmers don't write enough documentation.
(That's ok by me; I bill by the hour, and I charge extra when dealing with a steaming pile undocumented code. And the hours rack up quickly when I have to step through code in the debugger just to figure out what the hell it does. Attitudes like yours have made me hundreds of thousands of dollars over the years.)
If you have done any type of maintenance to code you know the only way to do it is to read the code!
This sounds persuasive, but it's several different kinds of bullshit rolled together. Yes, you do have to read the code to do maintenance. But good docs speed that process up immensely.
Personally, I find that projects with good basic docs generally have good design behind them. Projects that have no docs whatsoever usually have designs that make train wrecks look organized.
-----
When I do maintenance, I like to see five different things:
A few pages of broad overview docs. Something that gives the big picture in a few pages can save me days of work trying to figure out how several thousands classes go together. Note that a five-hundred page overview document is generally worse than no documentation at all.
Single-paragraph descriptions for packages and classes. A little basic info plus known caveats is optimal.
One-sentence method descriptions for those methods whose names don't make it completely obvious, and
Beautiful, readable code, where names are apropos, coding conventions are followed, flow control is clear, and no method/function is longer than fifty or so lines, and
Unit tests, so that I can know what the code is supposed to do, not what you happened to make it do.
Which is basically the kind of code that followers of XP produce. So if you're already doing that, swell; tell your managers to get lost if they demand you document every setName method. But most people don't. And most of the coders I see bitching about how they don't have time to document are the ones who write code that really, really needs documentation.
But, in the end, I am going to spend actual $$ for Idea's IntelliJ - http://www.intellij.com. It's only $200 until 1/10. This is truly the Java editor of the gods.
I'll give you an amen on that.
Although I've tried a lot of IDEs for Java I always stuck with a good text editor and a command line. IntelliJ's Idea is the first one that I thought was worth the trouble.
I paid $400 for my copy and it was entirely worth it just for the refactorings. Heck, the cross-project rename was worth the money you can click on a method or variable and safely rename every use of it, while leaving other symbols with identical names untouched.
As a bonus, it doesn't have a single "wizard", "bean generator", or other crutch for soft-headed developers. It seems to be made by geeks and for geeks, without a single marketing person involved. I'm sure once somebody with an MBA gets control of it the project will be doomed, but for now it kicks major bootay.
As many other people have pointed out, it's not so much the type of problem that matters for whether or not you choose OO technologies.
If you are by yourself, writing a small single-purpose, one-shot, low-state program that requires maximum performance, then by all means write in some procedural language.
If you are working with a large, distributed team, writing a large, complex, high-state program where performance takes a back seat to flexibility, evolvability, and maintainability, then choosing the right OO language can help a lot.
And if you're somewhere in between, the choice depends a lot on your circumstances.
But if you do pick an OO language, please take it seriously and really learn how to do OO design well. I saw a team write a million-line procedural program in Java, entirely missing the point of using Java in the first place. They would have been better off using the Visual Basic they knew and loved. Or they would have been better off going whole hog and actually writing OO code in Java. But their Procedurized OOP killed them.
Switching from a procedural style of design to an OO style of design will take you a couple of years before you're as good in OO as you were in your favorite procedural language. To get a good start, rummage around in Ward Cunningham's Wiki. And check out books like Martin Fowler's "Refactoring". Also consider using something like JUnit or CppUnit and the XP-style test-first programming, which will speed your learning considerably.
Am I to understand that stealing cars is illegal in Australia? How... weird.
Especially weird for a country that is famous for a song about a bum who steals sheep and then kills himself rather than get taken alive by Johnny Law. Yes, that's what Waltzing Matilda's about. And they keep talking about making it their national anthem.
Follow the money. 99% of spams are trying to get money from you; they need a way for you to get them the money.
If they have a web site, a court can compel the ISP to cough up their payment details. Ditto for an 800 number. And if they're using a PO box, you can get the details yourself; according to postal regulations, they're required to give out the true name and address of anybody using a PO box to do business with the public.
Yes, you're absolutely right, it makes perfect sense that I should aquiesce to receiving a couple of thousand of pieces of junk mail each year so that I can save 34 cents every few months.
You seem to miss the point: the only reason that companies send out junk mail is that they can make more money by doing it. If their costs go up, junk mail will be less effective. If you don't buy stuff from junk-mail solicitations, their response rate goes down.
If you're worried about how everyone gets hurt in the long run, go look up the amount of money spent on marketing this year. Imagine how much cheaper your purchases would be if you bought them because they were the best you could find, rather than because you fell for a piece of junk mail.
[...] and my original argument was principally about what constitutes a pragmatic solution to the problem.
In today's fast-paced world, I can see that you may have forgotten what you wrote half an hour ago. But that's no reason not to look.
Your post was titled "Inconsistency" and three of the five paragraphs talked about a perceived mismatch between the desire for free speech and fighting spam. So saying your post was "principally" about your suggestion that, gosh golly, people besides the end recipient should be allowed to sue is a bit of a stretch.
And given that a whole ten minutes of research would have shown you that server admins can and have sued for relay runs, we can presume you didn't get modded up to 5 for the alleged core of your post.
Of course, in real life if somebody keeps following me around and talking to me against my wishes, I'd have a restraining order issued
Now you're getting it. If somebody parked outside your house with a bullhorn to persuade you to buy their Amway products, you could have them hauled off.
The right to free speech is the right for people to communicate without government interference. It is not the right for me to force you to listen.
Why clutter the books with yet another unenforceable law -- which will probably be so badly written that it illegalizes sending email to your mom -- when there are highly satisfactory technical responses? A good junk-mail filter (down to and including a hand-rolled.procmailrc) is perfectly adequate spam control.
You've answered your own question. The number of people competent to hand-roll a procmailrc, let alone install all the other needed anti-spam tools, is a tiny fraction of the total number of email users. And maintaining all of that anti-spam infrastructure to keep up with the latest spammer tricks.
This is a classic arms race, and it's one that the spammers will likely keep winning. Why? Because they care a lot more. A bunch of spam is a time-wasting minor annoyance to you, but their livelihood to them.
Legislation that allows recepients to sue spammers is perfectly enforceable. And even if the legislation only provided criminal penalties, it would still be valuable. For example, the folks from Paetec could have quickly booted the spammers of their network, rather then getting caught up in a multi-year legal battle.
If you're consistently biting off more than you can chew, that's bound to have an effect on your morale. This is made worse by the relatively unintrospective nature of many geeks. Luckily, geek skills of analysis and frobbing can be applied; try treating yourself an optimization problem.
The other thing that occurs to me is that disrupted sleep patterns and depression go hand in hand. If I'm feeling unreasonably melancholy, the first thing I'll do is get my sleep cycle back in sync, either via staying up all night or melatonin.
Re:IntelliJ IDEA: the best IDE around!
on
Java IDEs?
·
· Score: 3, Informative
Yep! I've been using it for the last couple of months, and it's the first IDE that I thought was worth the bother.
Before IDEA, I used things like vi or nedit. Every IDE I tried seemed to be mainly an interface annoyance coupled with a bunch of code generations tools (which personally I think are for dolts). Or instead it turned out to be something that insisted on a particular way of development that had very little to do with how I worked (hello, TogetherJ and VisualAge).
But IDEA has excellent attention to UI: it does what I want about 90% of the time; JBuilder is more like 30%. And its automated refactorings are the bees knees; being able to safely and quickly rename a method across a 1000-class project is alone worth the money. And that sez nothing about the other refactorings or the many other handy tools.
And like the previous poster, I'm not affiliated with IntelliJ; I just think their products kick enough ass that I coughed up my own personal dough for a copy to use at work.
This is harder than you would think. I wanted to send RedHat some dough after I upgraded to 7.1. After more than a half-dozen calls and emails, I gave up. I never could convince them to just charge my credit card; it was always on some grand poobah's list of things to do, but they apparently never got around to it.
If anybody from RedHat reads this and is empowered to take my dough, drop me a line.
"...you should be careful with statements like this."
Why? Because saying the truth hurts?
Since even you admit that deregulation *and* individual responsibility works best, then to ever say the opposite is to betray your real feelings.
Thanks, if I want to say something, I can do it on my own; you don't need to put words in my mouth for me.
The reason I said that you should be careful is that you were making a true statement that could give a false impression, namely that solar is somehow more subsidized or more coddled than other power industries. I agree that all subsidies should be removed eventually, including the hidden subsidy of the ability to pollute. But continuing to subsidize coal and nuclear while pulling the plug on solar's subsidies is foolish and dangerous.
I am very carefull when saying "statements like this". I say them loudly, and often.
Apparently you're more excited about the "loudly, and often" part; perhaps you should try focusing more on being "carefull".
[...]as long as they're not paired with someone they could bully, or someone that's very submissive[...]
At least with XP-style pair programming, pair selection is very fluid. Typically pairs don't stay together more than a few hours.
So if you have a team of, say, a half-dozen programmers, one of whom is a prima donna, the bulk of any individual's time is spent with non-jerks. This, plus some good coaching, should be enough to tame a lot of prima donna behavior without harming your shy people too much.
But if your prima donna isn't behaving adequately after a month or so, I'd chuck 'em. If they're especially competent but unable to work in groups, maybe you can find a place for them in a little box of their own. Otherwise,give 'em the boot.
Hiding those production costs behind tax incentives, grants, EPA loopholes, does not stop the polution, nor clean it up. Only honesty in the real costs of production would drive incentive to clean up the process.
Although I agree that the right long-term solution is for people to always pay the full cost of their pollution, you should be careful with statements like this. The truth is that none of our power industries have to pay the full cost of construction and operation once environmental effects are taken into account.
In the long term, we should remove subsidies and tax pollution across all industries. But in the short term, it makes sense to subsidize solar at least as much as we do, say, nuclear and coal.
My experience with code reviews is that they are helpful when people actually do them. But they've always felt very artificial to me; even though I know intellectually they pay off, they feel like they take me away from "real" work. And I've never done it in a context where all code is reviewed; I've only seen it done where a sample is taken and examined.
When I've done pair programming (in an Extreme Programming context) I feel like I get most of the benefits of a code review, but over 100% of my code. And since the reviewing is integrated into the coding process, I always feel like progress is being made. Indeed, now solo programming feels a little unsafe to me, like swimming in the ocean with nobody around to notice if I get sucked out to sea.
Are you suggesting that, should we one day discover the secrets of the emergent behaviour of the human brain (reducing it, therefore, to "a simple rules system"), that we will suddenly cease to be intelligent?
Now here's your category error. You are assuming that the brain is also a Turing machine and that by some miracle of "emergent behaviour" intelligence arises. But that's obviously not true, as Searle showed, because Turing machines cannot be intelligent!
Wave your hands all you want, but this is a valid point.
Between the complex systems folks and the neuropsychologists they're making great leaps towards understanding how consciousness arises from a quart of goop. It will take decades (and maybe centuries) before they wrap up the details, but there's currently no reason to believe that there's any ghost in the machine.
And as the physical basis of consciousness becomes better and better understood, our ability to simulate it will grow along with it. Whether they end up building a Turing machine that's intelligent or a Turing machine that simulates a brain that is intelligent, either way you end up with a machine that is intellegent. Whether I play a video game on MAME or on its original hardware, the game plays the same.
Sure, Searle has some interesting things to say, but he doesn't show anything. His principal trick is to engage your intuition in a way that makes it "obvious" that Turing machines can't be intelligent. He may be right and he may be wrong, but his argument proves nothing. Indeed, until we have a formal definition of conciousness, he'll never be able to prove that a Turing machine can't be conscious.
And really, other people have use the same trick to make it "obvious" that souls must exist and "obvious" that evolution is impossible. On principal I'm wary of such tricks, and you should be too.
Did you try, say, reading the story that started this? It seems to have exactly the stats you wanted.
Dot-com failures sent San Francisco's unemployment rate up to 4.2 percent in May from a rock-bottom 2.6 percent a year ago -- with 18,000 people added, according to a state report.
In Santa Clara County, the heart of Silicon Valley, layoffs in electronic equipment manufacturing and business services rose for the fifth straight month, contributing to a 3.2 percent unemployment rate in May.
These rates would certainly be the envy of other areas, but to have them jump like this is still a substantial shock. Compounding the problem is that prices are still high; last I looked rents were still at or near peak prices, although there is more availability now.
Although I have no stats for this, it's my impression that almost all of the recent layoffs have been in the tech industry. If unemployment jumps 1.5 percentage points and tech is, say, 10% of all San Francisco jobs, then from the point of view of a geek, the market has been literally decimated.
Given that you a) have one IP address and b) are dealing with a globe-spanning congolmerate with a history of monopoly, I'd say your odds of getting PTRs are about zero.
But for those with more flexible providers and a larger block of IP addresses, there's a nice trick that covers this:
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
And really, the basic theory is sound. As you point out, as computers get faster you can use that speed to make old programs run faster or to make new programs possible at the same perceived speed. Sure, Excel's a pig, but 99 times out of 100 I'd rather use Excel than Visicalc.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
My previous comment was moderated "off-topic" and "troll".
When Jamie calls somebody a Nazi, I think it's fair to bring up the Jargon file's entry about that. And I meant the comment as a funny way of making a serious criticism of Jamie's over-the-top editorials disguised as news pieces. My previous posts on Jamie's stories bear that out. Ergo, no troll, either.
Slashdot Mirror
Yep! The "first pancake" approach is a good one. And, as other posters have noted, a venerable one. Why? as you point out, you discover a lot as you go, both about the user needs and about how to do them well.
But you can go further with this! Any short-cycle iterative model will give you this sort of feedback every couple of weeks, rather than at the end of every version.
For more info on it, take a look at Rapid Development's discussion of evolutionary delivery. Or try a process that's built around feedback, like Coad's Feature Driven Development or, my personal favorite, Beck's Extreme Programming (XP) (dumb name, but a great process).
Most code is utter drudgery. It's predictable in an informal manner to a very high degree.
Quick tip: If most of your coding is utter drudgery, you're doing the wrong coding.
The potential drudgery I see tends to come from two sources: 1) users tend to ask for very similar things (e.g., a zillion slightly different reports), and 2) tools that are a poor match to the problem domain.
For the first case, users with similar requests, you give the user control and tools to support that control. So instead of wasting your life writing report after report, write report-generating tools.
For the second case, you gotta buy or build better tools. Or, possibly, learn to use the ones you have better. For example, if you're using an OO language, stop using your copy and paste keys. (Why? When you copy and paste chunks of code, you're saying that two things are very similar. Instead of copy-and-paste, abstract the problem using, say, inheritance or containment or delegation. Copy-and-paste yeilds maintenance nightmares.)
Computers do drudgery without complaining, and they do it much faster than you. Make them do your donkey work!
Hi. I'm a programmer. I've been programming for money since I was 16. I deliver.
I agree that excessive documentation is bad. And that many companies have official policies that, if actually followed, would result in excessive documentation. Know why they have those policies? Because most programmers don't write enough documentation.
(That's ok by me; I bill by the hour, and I charge extra when dealing with a steaming pile undocumented code. And the hours rack up quickly when I have to step through code in the debugger just to figure out what the hell it does. Attitudes like yours have made me hundreds of thousands of dollars over the years.)
If you have done any type of maintenance to code you know the only way to do it is to read the code!
This sounds persuasive, but it's several different kinds of bullshit rolled together. Yes, you do have to read the code to do maintenance. But good docs speed that process up immensely.
Personally, I find that projects with good basic docs generally have good design behind them. Projects that have no docs whatsoever usually have designs that make train wrecks look organized.
-----
When I do maintenance, I like to see five different things:
- A few pages of broad overview docs. Something that gives the big picture in a few pages can save me days of work trying to figure out how several thousands classes go together. Note that a five-hundred page overview document is generally worse than no documentation at all.
- Single-paragraph descriptions for packages and classes. A little basic info plus known caveats is optimal.
- One-sentence method descriptions for those methods whose names don't make it completely obvious, and
- Beautiful, readable code, where names are apropos, coding conventions are followed, flow control is clear, and no method/function is longer than fifty or so lines, and
- Unit tests, so that I can know what the code is supposed to do, not what you happened to make it do.
Which is basically the kind of code that followers of XP produce. So if you're already doing that, swell; tell your managers to get lost if they demand you document every setName method. But most people don't. And most of the coders I see bitching about how they don't have time to document are the ones who write code that really, really needs documentation.But, in the end, I am going to spend actual $$ for Idea's IntelliJ - http://www.intellij.com. It's only $200 until 1/10. This is truly the Java editor of the gods.
I'll give you an amen on that.
Although I've tried a lot of IDEs for Java I always stuck with a good text editor and a command line. IntelliJ's Idea is the first one that I thought was worth the trouble.
I paid $400 for my copy and it was entirely worth it just for the refactorings. Heck, the cross-project rename was worth the money you can click on a method or variable and safely rename every use of it, while leaving other symbols with identical names untouched.
As a bonus, it doesn't have a single "wizard", "bean generator", or other crutch for soft-headed developers. It seems to be made by geeks and for geeks, without a single marketing person involved. I'm sure once somebody with an MBA gets control of it the project will be doomed, but for now it kicks major bootay.
As many other people have pointed out, it's not so much the type of problem that matters for whether or not you choose OO technologies.
If you are by yourself, writing a small single-purpose, one-shot, low-state program that requires maximum performance, then by all means write in some procedural language.
If you are working with a large, distributed team, writing a large, complex, high-state program where performance takes a back seat to flexibility, evolvability, and maintainability, then choosing the right OO language can help a lot.
And if you're somewhere in between, the choice depends a lot on your circumstances.
But if you do pick an OO language, please take it seriously and really learn how to do OO design well. I saw a team write a million-line procedural program in Java, entirely missing the point of using Java in the first place. They would have been better off using the Visual Basic they knew and loved. Or they would have been better off going whole hog and actually writing OO code in Java. But their Procedurized OOP killed them.
Switching from a procedural style of design to an OO style of design will take you a couple of years before you're as good in OO as you were in your favorite procedural language. To get a good start, rummage around in Ward Cunningham's Wiki. And check out books like Martin Fowler's "Refactoring". Also consider using something like JUnit or CppUnit and the XP-style test-first programming, which will speed your learning considerably.
And regardless of what you pick, good luck!
Am I to understand that stealing cars is illegal in Australia? How... weird.
Especially weird for a country that is famous for a song about a bum who steals sheep and then kills himself rather than get taken alive by Johnny Law. Yes, that's what Waltzing Matilda's about. And they keep talking about making it their national anthem.
So how do you go about finding their addresses?
Follow the money. 99% of spams are trying to get money from you; they need a way for you to get them the money.
If they have a web site, a court can compel the ISP to cough up their payment details. Ditto for an 800 number. And if they're using a PO box, you can get the details yourself; according to postal regulations, they're required to give out the true name and address of anybody using a PO box to do business with the public.
Yes, you're absolutely right, it makes perfect sense that I should aquiesce to receiving a couple of thousand of pieces of junk mail each year so that I can save 34 cents every few months.
You seem to miss the point: the only reason that companies send out junk mail is that they can make more money by doing it. If their costs go up, junk mail will be less effective. If you don't buy stuff from junk-mail solicitations, their response rate goes down.
If you're worried about how everyone gets hurt in the long run, go look up the amount of money spent on marketing this year. Imagine how much cheaper your purchases would be if you bought them because they were the best you could find, rather than because you fell for a piece of junk mail.
[...] and my original argument was principally about what constitutes a pragmatic solution to the problem.
In today's fast-paced world, I can see that you may have forgotten what you wrote half an hour ago. But that's no reason not to look.
Your post was titled "Inconsistency" and three of the five paragraphs talked about a perceived mismatch between the desire for free speech and fighting spam. So saying your post was "principally" about your suggestion that, gosh golly, people besides the end recipient should be allowed to sue is a bit of a stretch.
And given that a whole ten minutes of research would have shown you that server admins can and have sued for relay runs, we can presume you didn't get modded up to 5 for the alleged core of your post.
Of course, in real life if somebody keeps following me around and talking to me against my wishes, I'd have a restraining order issued
Now you're getting it. If somebody parked outside your house with a bullhorn to persuade you to buy their Amway products, you could have them hauled off.
The right to free speech is the right for people to communicate without government interference. It is not the right for me to force you to listen.
Why clutter the books with yet another unenforceable law -- which will probably be so badly written that it illegalizes sending email to your mom -- when there are highly satisfactory technical responses? A good junk-mail filter (down to and including a hand-rolled .procmailrc) is perfectly adequate spam control.
You've answered your own question. The number of people competent to hand-roll a procmailrc, let alone install all the other needed anti-spam tools, is a tiny fraction of the total number of email users. And maintaining all of that anti-spam infrastructure to keep up with the latest spammer tricks.
This is a classic arms race, and it's one that the spammers will likely keep winning. Why? Because they care a lot more. A bunch of spam is a time-wasting minor annoyance to you, but their livelihood to them.
Legislation that allows recepients to sue spammers is perfectly enforceable. And even if the legislation only provided criminal penalties, it would still be valuable. For example, the folks from Paetec could have quickly booted the spammers of their network, rather then getting caught up in a multi-year legal battle.
If you're consistently biting off more than you can chew, that's bound to have an effect on your morale. This is made worse by the relatively unintrospective nature of many geeks. Luckily, geek skills of analysis and frobbing can be applied; try treating yourself an optimization problem.
The other thing that occurs to me is that disrupted sleep patterns and depression go hand in hand. If I'm feeling unreasonably melancholy, the first thing I'll do is get my sleep cycle back in sync, either via staying up all night or melatonin.
Yep! I've been using it for the last couple of months, and it's the first IDE that I thought was worth the bother.
Before IDEA, I used things like vi or nedit. Every IDE I tried seemed to be mainly an interface annoyance coupled with a bunch of code generations tools (which personally I think are for dolts). Or instead it turned out to be something that insisted on a particular way of development that had very little to do with how I worked (hello, TogetherJ and VisualAge).
But IDEA has excellent attention to UI: it does what I want about 90% of the time; JBuilder is more like 30%. And its automated refactorings are the bees knees; being able to safely and quickly rename a method across a 1000-class project is alone worth the money. And that sez nothing about the other refactorings or the many other handy tools.
And like the previous poster, I'm not affiliated with IntelliJ; I just think their products kick enough ass that I coughed up my own personal dough for a copy to use at work.
Just send them money.
This is harder than you would think. I wanted to send RedHat some dough after I upgraded to 7.1. After more than a half-dozen calls and emails, I gave up. I never could convince them to just charge my credit card; it was always on some grand poobah's list of things to do, but they apparently never got around to it.
If anybody from RedHat reads this and is empowered to take my dough, drop me a line.
The reason I said that you should be careful is that you were making a true statement that could give a false impression, namely that solar is somehow more subsidized or more coddled than other power industries. I agree that all subsidies should be removed eventually, including the hidden subsidy of the ability to pollute. But continuing to subsidize coal and nuclear while pulling the plug on solar's subsidies is foolish and dangerous.
Apparently you're more excited about the "loudly, and often" part; perhaps you should try focusing more on being "carefull".
[...]as long as they're not paired with someone they could bully, or someone that's very submissive[...]
At least with XP-style pair programming, pair selection is very fluid. Typically pairs don't stay together more than a few hours.
So if you have a team of, say, a half-dozen programmers, one of whom is a prima donna, the bulk of any individual's time is spent with non-jerks. This, plus some good coaching, should be enough to tame a lot of prima donna behavior without harming your shy people too much.
But if your prima donna isn't behaving adequately after a month or so, I'd chuck 'em. If they're especially competent but unable to work in groups, maybe you can find a place for them in a little box of their own. Otherwise,give 'em the boot.
I think this story may be a troll, and if it is it's a pretty good one! :)
Not a bad theory. I note that the story is more than a month old, too, which would explain why the troll submission wasn't balanced with better ones.
Hiding those production costs behind tax incentives, grants, EPA loopholes, does not stop the polution, nor clean it up. Only honesty in the real costs of production would drive incentive to clean up the process.
Although I agree that the right long-term solution is for people to always pay the full cost of their pollution, you should be careful with statements like this. The truth is that none of our power industries have to pay the full cost of construction and operation once environmental effects are taken into account.
In the long term, we should remove subsidies and tax pollution across all industries. But in the short term, it makes sense to subsidize solar at least as much as we do, say, nuclear and coal.
And you thought you were being funny, didn't you?
My experience with code reviews is that they are helpful when people actually do them. But they've always felt very artificial to me; even though I know intellectually they pay off, they feel like they take me away from "real" work. And I've never done it in a context where all code is reviewed; I've only seen it done where a sample is taken and examined.
When I've done pair programming (in an Extreme Programming context) I feel like I get most of the benefits of a code review, but over 100% of my code. And since the reviewing is integrated into the coding process, I always feel like progress is being made. Indeed, now solo programming feels a little unsafe to me, like swimming in the ocean with nobody around to notice if I get sucked out to sea.
Wave your hands all you want, but this is a valid point.
Between the complex systems folks and the neuropsychologists they're making great leaps towards understanding how consciousness arises from a quart of goop. It will take decades (and maybe centuries) before they wrap up the details, but there's currently no reason to believe that there's any ghost in the machine.
And as the physical basis of consciousness becomes better and better understood, our ability to simulate it will grow along with it. Whether they end up building a Turing machine that's intelligent or a Turing machine that simulates a brain that is intelligent, either way you end up with a machine that is intellegent. Whether I play a video game on MAME or on its original hardware, the game plays the same.
Sure, Searle has some interesting things to say, but he doesn't show anything. His principal trick is to engage your intuition in a way that makes it "obvious" that Turing machines can't be intelligent. He may be right and he may be wrong, but his argument proves nothing. Indeed, until we have a formal definition of conciousness, he'll never be able to prove that a Turing machine can't be conscious.
And really, other people have use the same trick to make it "obvious" that souls must exist and "obvious" that evolution is impossible. On principal I'm wary of such tricks, and you should be too.
Then one of the users can write a CGI that reads the secret files. Since the web server runs the CGI as nobody, then it can read the file just fine.
Although I have no stats for this, it's my impression that almost all of the recent layoffs have been in the tech industry. If unemployment jumps 1.5 percentage points and tech is, say, 10% of all San Francisco jobs, then from the point of view of a geek, the market has been literally decimated.
Given that you a) have one IP address and b) are dealing with a globe-spanning congolmerate with a history of monopoly, I'd say your odds of getting PTRs are about zero.
But for those with more flexible providers and a larger block of IP addresses, there's a nice trick that covers this:
RFC 2317 (aka BCP 20)
This allows the delegation of DNS PTR management even when the block doesn't start or end on octet boundaries.
Faster computers mean that we can increase the abbstraction layers between the hardware and the application to make it EASIER and FASTER to develop complex applications.
>>>>>>>>>
Yuck. Ugly UNIX thinking at its worst. Faster computers should allow you to do more, not devote more resources to administrative overhead.
Unix thinking? Please. Windows has generally been much worse about hardware-hungry.
And really, the basic theory is sound. As you point out, as computers get faster you can use that speed to make old programs run faster or to make new programs possible at the same perceived speed. Sure, Excel's a pig, but 99 times out of 100 I'd rather use Excel than Visicalc.
But even if you're just going to make the old programs over again with absolutely no feature improvements, it often makes sense to burn processor time to save developer time and make the software cheaper. That's why you see the rise of languages like Perl, Python, C++, and Java and the near disappearance of significant assembly work.
CPU effciency is only one of many criteria you can optimize for. And since more than 90% of computers spend more than 90% of their time idle, other things (like usability and development cost) are often more important.
My previous comment was moderated "off-topic" and "troll".
When Jamie calls somebody a Nazi, I think it's fair to bring up the Jargon file's entry about that. And I meant the comment as a funny way of making a serious criticism of Jamie's over-the-top editorials disguised as news pieces. My previous posts on Jamie's stories bear that out. Ergo, no troll, either.