How can you be in two places at once when you're not anywhere at all*?
Don't crush that dwarf, hand me the pliers.
I could have sworn I said the same thing on the other side of the record. . . . !thgir er'ouY !tfel eht no sdneirf tog t'nia ouY !rissseY . . . It's OK, they're speaking Chinese.
Jesus, what I would have given for co-workers who actually could supply me with input about where my code was bad. I was stuck with a ton of co-workers who sent back code reviews saying only "looks good".
Agreed! On the team I'm currently on, my coworkers assume if they don't understand something in the code, then the code is either (a) good but above their ability, or (b) obviously crap that needs to be tossed, and they side toward (a) or (b) based on who wrote it.
My code tends to fall in the (a) bucket with these folks, so I can't get anyone to actually spend the time trying to understand the code and really get a good idea of what I'm doing (or trying to do). Instead, I get glazed eyes and a "looks good", even when it isn't. It's frustrating.
One of the things I struggle with is how to handle a team that has a very wide range of skill levels. It's been documented that the best programmers are over an order of magnitude more effective than the worst, and that experience doesn't correlate with skill. (So those bad programmers won't get much better.) How do you partition tasks among the team such that your weakest programmers still contribute positively, and don't just end up with marginal "chore" tasks continually? Difficulty: Upper management is watching, and if we don't use our existing resources effectively, we won't get additional resources. And no, we can't trade our existing resources for ones that actually work.
Is it "Programmer's Ego" on my part to recognize a skill chasm like this and try to hoard the toughest bits for myself? I don't write perfect code, I know that much. But if it takes me 2 hours to explain how to do something to someone that would take me 10 minutes to do myself, how do I get any benefit from partitioning the problem?
Maybe the asshole women got jobs in different fields? A friend of mine works in medical labeling, and by some of the stories she tells, she's worked with a few female assholes. Not just prickly people, but borderline abusive.
One former boss (which she referred to with such names as "Crazy Psycho Bitch") was particularly bad. At one point, this manager tasked my friend with helping the manager's kid do his Spanish homework. (My friend is bilingual.) HR got called on that one. Then there was the whole show up late / leave at 4, but expect unrealistic deadlines from your direct reports, and generally running things like a slave driver. And when other managers try to poach time or otherwise pressure team members, she'd dog-pile on rather than protect her team and negotiate for resources.
That's not eccentric. That's not prickly. That's just being an asshole.
I couldn't tell you, since that's not actually my department or platform. I'm working on the C6600 family DSPs, actually. I just heard about the PandaBoard from a coworker just before Christmas.
Man power spent fixing bugs. This is perhaps the most obvious, but it is unpredictable since you, by definition, don't know how many bugs you're going to have. However, you should be able to look at your defect rate versus time to get some idea.
Man power spent writing tests. This is completely under your control, since you can decide simply to not write tests. Or you can decide to write copious tests. Or, anything between.
The cost of lost sales due to poor quality. If you ship a total turd, your existing customers will start shopping elsewhere, and they won't send new customers your way. If you ship high quality product, though, that too ought to spread via word of mouth.
The opportunity cost of lost sales due to product delays. If you ship sooner, you may get some critical customers that you'd miss if you shipped later. Of course, this breaks two ways:
One is that you delayed your product by being stuck in the "infinite polishing" phase. You have to be careful to avoid gilding the lily.
The other is that the development process itself got bogged down under the weight of its own bugs. Joel Spoelsky mentions what Microsoft called the Infinite Defects Methodology in which coding to get features took precedence over fixing bugs, and the product was delayed significantly by the weight of its own bugginess.
As you can see, it's not really a simple "testing saves money". But, laying all the pieces out there and showing how what you propose affects all these aspects might go a long way to getting at least something in place for a testing methology.
Well, one could also start with a more narrow notion of "regression tests." Specifically, whenever somebody fixes a bug, they should also write a set of short tests that should try to expose the bug they just fixed and add them to the suite. After all, they need to ensure they fixed the bug, right? Don't worry about retrospectively writing tests just yet for everything that already works (or mostly works). If nothing else, such an approach would protect any regressions among the existing set of bug fixes. (ie. "I fixed that, why did that bug come back?")
Aside from that, for any new code that goes in, presumably the person writing the code has at least some quick and dirty tests to make sure the new functionality works at least a little, right? What cost is there to checking those in? It may not be the most rigorous test suite, but it's something.
I do think that for you to appreciate TRON, you have to make the mental leap that there's a digital Narnia on the other side of the wardrobe^H^H^H^H^H^H^H^laser. If you can't make the leap that there's this alternate reality / world behind something that to so many seems mundane--a computer--you'll never connect with the plot.
I'm an electrical engineer with quite a bit of computer architecture experience. I'm also someone for whom computers have always held a fair bit wonder, despite that knowledge. I am acutely aware that nothing TRON-like could be going on under the hood. But, computers captured my imagination from a young age, and I think that goes a long way toward both TRON and TRON: Legacy working for me. If you look at a computer like you look at a Cuisinart--a boring, if capable tool that's a narrow means to a narrow end--then yeah, I can see how you might not connect with TRON. But, if you allow yourself the ability to imagine and dream a little, and have just a little of that child-like wonder where computers are involved, then just maybe it might work for you.
Well... starting a little 1.2L diesel engine is a bit different than starting, say, a 5.7L V8, for example. But, the battery in said V8 isn't 4 times the capacity the battery in the Lupo, I'm willing to bet.
I've seen this covered time and time again. In a modern vehicle, if you know you're going to be idling more than 30 seconds or so, it's better for fuel economy to shut it off. The Car Talk guys even mention it (little over halfway down).
Supposedly, with older carbuerated vehicles, you could waste a fair bit of fuel with frequent starts. Modern fuel injection systems don't have that problem, unless you have seriously leaky injectors.
Your concern has less to do with the engine as it does everything in the passenger compartment. In my case, the temp gauge lifts off the peg within a minute, usually, and the heater starts putting out warm air shortly thereafter. My car doesn't get comfortable for a few minutes, though, because of the heat capacity of the interior.
That's really an orthogonal problem to whether the car stops the engine at longish red lights. If there's sufficient heat stored up in the coolant, the heater can continue to transfer that to the passenger compartment. And, you could moot the whole point if the feature has a "warmup" program that forces the engine to run for the first 5 - 10 minutes. You probably want that anyway just to make sure you fully heat up the exhaust path, both to get the catalyst going in the catalytic converter and to prevent water vapor in the exhaust from condensing and rusting out your muffler. Most cars I've driven already have a "cold idle" that raises the idle speed for the first few minutes the car is running. This would be a natural extension of that existing behavior.
I'm not sure why everyone thinks that their car will be narcoleptic straight out of the gate.
On a separate note, though, I would want an override for this feature if my car has trouble starting. But, just like my traction control override, I'd almost never enable it.
That sounds rather similar to the typing class I took in high school. I'm guessing by your handle that I came along a few years after you. Ours was maybe 75% on Selectric IIIs, and 25% using WordPerfect 5.1 on PS/2s.
The main focus, though, was pretty much what you laid out: Secretarial Skills 101. When to use 50 columns vs. 60 columns for a letter, how to block-structure a letter, etc. And the course was called Typing. It was taught by the Business Department in my high school. (3 teachers that taught classes such as Business Math, which focused on the kind of math you'd encounter at a bank, Basic Accounting, and so on.)
Separately from that, we had two programming courses that they offered: BASIC and Pascal, both on the Apple ][e. Those were taught by an entirely different teacher in the Math Department.
Even then, they didn't call the programming course "Computer Science." They just called them Computer Programming I and Computer Programming II, because that's what they were: Programming courses. They didn't teach you any theory of computation or anything. Rather, it just taught the syntax of BASIC or Pascal and how to write some simple programs.
I think the sun4m was to throw folks off. I actually have a Sun 386i that runs SunOS 4.0.1 (the version of "SolarOS" listed in the movie). I *think* the sun4m systems started with 4.0.3.
The way I read the graphs is: XP and Ubuntu win on almost everything (Ubuntu loses once on Flash on iPlayer but that's hardly surprising), maybe only by a small margin by they do, and Windows 7 takes twice as long to boot as they do. The article doesn't recommend bothering to upgrade to Windows 7 if you already have XP on it, and suggests that Ubuntu would be just as good.
...and later you say...
All this article confirms is that, basically, all the OS's are roughly the same now. A bar chart here or there but on average there is no winner.
It's not too surprising that all three landed very near each other. I imagine the process of putting a netbook-specific version of the OS together largely consists of cutting or tweaking or what-have-you until the performance gets in an "acceptable band" (or teaching the OS how to do this for itself when presented a small machine), and then stopping. So, this article basically shows that all these OSes are indeed in the "acceptable band." Windows 7 seems like it had the hardest time coming down into that band and landed at the slower end of the range. But, the OS does seem to scale itself back on the smaller machine reasonably well (even in its "full" edition), it would seem.
Now, let's look at *value*: Assuming you can get them all for the same price, they all provide roughly equal value (it could be argued that 7 is worse value but only by a small way).
Now you're in tricky territory. I personally would get the most value out of an Ubuntu desktop. But, then, I've been using Linux for 17 years. For my folks, though, who have been using Windows for the last 15-20 years? I suspect they'd get more value out of XP even if they had to pay for it. They would get value out of the uniformity between their desktop's behavior and their netbook's behavior and benefit from not having to learn a new system.
My Nokia N900 will get in a state where it won't update, and invariably it's because/tmp filled up. (Some mental giant thought it would be good to have X log all interaction events to a file in/tmp. Gotta figure out how to turn that off.) Could an insufficiently large/tmp have been the problem?
Oh, I see, you were suggesting the capacitor goes in the charger to spread the load on the house's or charging station's wiring and local power grid. I get it now. Sorry. On a related note, a distributed array of capacitor banks would also potentially allow for better load balancing on the grid in general, if the charging station could also drain back into the grid. That could help us move toward sizing power plants closer to average load, rather than peak load.
I had been thinking of something else: Integrating some amount of capacitor storage in the vehicle to allow quick charge transfer from the grid to the vehicle, to hide the longer inherent charge time of the battery. For example, if the battery actually requires 3 hours to perform all of the chemical conversion associated with charging, but capacitors buffer some of the charge in the meantime, then to the user it looks like the batteries charged in minutes. Really, it was just buffered. But, to turn 3 hours into 6 minutes would require unrealistically huge capacitors, as you point out.
A more realistic use of ultracapacitors in an EV would be to buffer the much smaller amounts of charge associated with regenerative braking and the like. The capacity required there, though, would be much lower.
Anyway, it seems like you could charge a large battery array quickly by treating it as a bunch of smaller batteries charging in parallel. Still though, the rate just seems mind boggling, and the heat issues are what really get me wondering. Suppose you dump half a megawatt over 6 minutes into the car at even 99% efficiency--ie. only 1% of the energy converts to heat. That's 0.1 hours * 500 kW * 1% = 500Wh in heat energy. That would be about like running this guy on low for an hour, except it's compressed into 6 minutes. Toasty!
Such a "cheating" solution would pose a significant risk should a short occur inside the charger though.
Well, that's not all. To significantly shorten the charging interval, the capacitor array would need to store nearly as much energy as the battery it's covering for.
Suppose, due to current regulation, the battery's charge rate is linear over the vast majority of the charging interval. (I'm pretty sure w/ these various lithium battery types, that's not too far from the truth.) If the capacitor array only stored half as much as energy as the battery, then it could only "hide" the second half of the charging interval. If it takes "t" minutes to fully charge the battery, then at 0.5 * t, you'd have a half-charged battery, and enough charge in the capacitors to finish the job.
So, if you have a capacitor array beefy enough to take a 3 hour charge (180 minutes) down to 6 minutes, that means you're hiding over 97% of the charging time. If your capacitors can store that much energy, then why do you have the battery?
Now, I suppose if these hypothesized capacitors are "leaky", it makes sense for them to buffer the charge but not be primarily responsible for its long-term storage. They would also be handy for absorbing transient power, such as the spikes you get from regenerative braking.
Externalities are effects that change the value of goods for persons not engaged in a transaction, of which regulation is an example. (I want clean air and water; I don't care about your process for manufacturing widgets. Widgets are not my concern, but I get my clean air and water, and your widgets are more expensive, a negative externality for you.)
In the absence of the regulation, the pollution is a negative externality that affects the people not interested in the widgets. The widget producer has imposed an external cost on people not interested in widgets. If those people push back (ie. require the widget producer himself to absorb the cost through regulation or other means) so that the cost of cleaning up the pollution is included in the cost of the widget, then that cost is internalized.
Using your example: If you start and end with clean air and clean water, there's no transaction with a cost to externalize to the widget producer. If you achieve that goal by regulating the widget producer, you've merely prevented the widget producer from externalizing a cost. You haven't externalized one of your costs onto him. You didn't have a cost to externalize. "Keeping the air clean" is not a transaction.
Therefore, calling the regulation an external cost to the widget producer in this case is incorrect. An externality is something that doesn't show up in the final price of the good or service. Forcing an externalized cost back into the price internalizes the cost. The force itself isn't not an externality.
By introducing or maintaining government regulators, however, you open the doors for regulatory capture, and the operating market is the competition for influence over regulators, rather than the open market.
Slashdot Mirror
I could have sworn I said the same thing on the other side of the record. . . . !thgir er'ouY !tfel eht no sdneirf tog t'nia ouY !rissseY . . . It's OK, they're speaking Chinese.
Those are the worst puns I've xenon here.
Feeling a little rusty at conversation?
Agreed! On the team I'm currently on, my coworkers assume if they don't understand something in the code, then the code is either (a) good but above their ability, or (b) obviously crap that needs to be tossed, and they side toward (a) or (b) based on who wrote it.
My code tends to fall in the (a) bucket with these folks, so I can't get anyone to actually spend the time trying to understand the code and really get a good idea of what I'm doing (or trying to do). Instead, I get glazed eyes and a "looks good", even when it isn't. It's frustrating.
One of the things I struggle with is how to handle a team that has a very wide range of skill levels. It's been documented that the best programmers are over an order of magnitude more effective than the worst, and that experience doesn't correlate with skill. (So those bad programmers won't get much better.) How do you partition tasks among the team such that your weakest programmers still contribute positively, and don't just end up with marginal "chore" tasks continually? Difficulty: Upper management is watching, and if we don't use our existing resources effectively, we won't get additional resources. And no, we can't trade our existing resources for ones that actually work.
Is it "Programmer's Ego" on my part to recognize a skill chasm like this and try to hoard the toughest bits for myself? I don't write perfect code, I know that much. But if it takes me 2 hours to explain how to do something to someone that would take me 10 minutes to do myself, how do I get any benefit from partitioning the problem?
Maybe the asshole women got jobs in different fields? A friend of mine works in medical labeling, and by some of the stories she tells, she's worked with a few female assholes. Not just prickly people, but borderline abusive.
One former boss (which she referred to with such names as "Crazy Psycho Bitch") was particularly bad. At one point, this manager tasked my friend with helping the manager's kid do his Spanish homework. (My friend is bilingual.) HR got called on that one. Then there was the whole show up late / leave at 4, but expect unrealistic deadlines from your direct reports, and generally running things like a slave driver. And when other managers try to poach time or otherwise pressure team members, she'd dog-pile on rather than protect her team and negotiate for resources.
That's not eccentric. That's not prickly. That's just being an asshole.
I couldn't tell you, since that's not actually my department or platform. I'm working on the C6600 family DSPs, actually. I just heard about the PandaBoard from a coworker just before Christmas.
I had a similar reaction when I saw that comment. Of course, I guess that's understandable, given that I work for TI. ;-)
Now I just wish I could get a version of my Nokia N900 with a 4430 instead of the 3430 that's in it now. Ah well...
Lost money can come from multiple places:
As you can see, it's not really a simple "testing saves money". But, laying all the pieces out there and showing how what you propose affects all these aspects might go a long way to getting at least something in place for a testing methology.
Well, one could also start with a more narrow notion of "regression tests." Specifically, whenever somebody fixes a bug, they should also write a set of short tests that should try to expose the bug they just fixed and add them to the suite. After all, they need to ensure they fixed the bug, right? Don't worry about retrospectively writing tests just yet for everything that already works (or mostly works). If nothing else, such an approach would protect any regressions among the existing set of bug fixes. (ie. "I fixed that, why did that bug come back?")
Aside from that, for any new code that goes in, presumably the person writing the code has at least some quick and dirty tests to make sure the new functionality works at least a little, right? What cost is there to checking those in? It may not be the most rigorous test suite, but it's something.
Oh boy, won't this be fun? Artist's conception...
I hope they've put some deep thought into this....
I do think that for you to appreciate TRON, you have to make the mental leap that there's a digital Narnia on the other side of the wardrobe^H^H^H^H^H^H^H^laser. If you can't make the leap that there's this alternate reality / world behind something that to so many seems mundane--a computer--you'll never connect with the plot.
I'm an electrical engineer with quite a bit of computer architecture experience. I'm also someone for whom computers have always held a fair bit wonder, despite that knowledge. I am acutely aware that nothing TRON-like could be going on under the hood. But, computers captured my imagination from a young age, and I think that goes a long way toward both TRON and TRON: Legacy working for me. If you look at a computer like you look at a Cuisinart--a boring, if capable tool that's a narrow means to a narrow end--then yeah, I can see how you might not connect with TRON. But, if you allow yourself the ability to imagine and dream a little, and have just a little of that child-like wonder where computers are involved, then just maybe it might work for you.
Well... starting a little 1.2L diesel engine is a bit different than starting, say, a 5.7L V8, for example. But, the battery in said V8 isn't 4 times the capacity the battery in the Lupo, I'm willing to bet.
I've seen this covered time and time again. In a modern vehicle, if you know you're going to be idling more than 30 seconds or so, it's better for fuel economy to shut it off. The Car Talk guys even mention it (little over halfway down).
Supposedly, with older carbuerated vehicles, you could waste a fair bit of fuel with frequent starts. Modern fuel injection systems don't have that problem, unless you have seriously leaky injectors.
Your concern has less to do with the engine as it does everything in the passenger compartment. In my case, the temp gauge lifts off the peg within a minute, usually, and the heater starts putting out warm air shortly thereafter. My car doesn't get comfortable for a few minutes, though, because of the heat capacity of the interior.
That's really an orthogonal problem to whether the car stops the engine at longish red lights. If there's sufficient heat stored up in the coolant, the heater can continue to transfer that to the passenger compartment. And, you could moot the whole point if the feature has a "warmup" program that forces the engine to run for the first 5 - 10 minutes. You probably want that anyway just to make sure you fully heat up the exhaust path, both to get the catalyst going in the catalytic converter and to prevent water vapor in the exhaust from condensing and rusting out your muffler. Most cars I've driven already have a "cold idle" that raises the idle speed for the first few minutes the car is running. This would be a natural extension of that existing behavior.
I'm not sure why everyone thinks that their car will be narcoleptic straight out of the gate.
On a separate note, though, I would want an override for this feature if my car has trouble starting. But, just like my traction control override, I'd almost never enable it.
It makes as much sense as calling driver's ed "automotive engineering."
That sounds rather similar to the typing class I took in high school. I'm guessing by your handle that I came along a few years after you. Ours was maybe 75% on Selectric IIIs, and 25% using WordPerfect 5.1 on PS/2s.
The main focus, though, was pretty much what you laid out: Secretarial Skills 101. When to use 50 columns vs. 60 columns for a letter, how to block-structure a letter, etc. And the course was called Typing. It was taught by the Business Department in my high school. (3 teachers that taught classes such as Business Math, which focused on the kind of math you'd encounter at a bank, Basic Accounting, and so on.)
Separately from that, we had two programming courses that they offered: BASIC and Pascal, both on the Apple ][e. Those were taught by an entirely different teacher in the Math Department.
Even then, they didn't call the programming course "Computer Science." They just called them Computer Programming I and Computer Programming II, because that's what they were: Programming courses. They didn't teach you any theory of computation or anything. Rather, it just taught the syntax of BASIC or Pascal and how to write some simple programs.
I think the sun4m was to throw folks off. I actually have a Sun 386i that runs SunOS 4.0.1 (the version of "SolarOS" listed in the movie). I *think* the sun4m systems started with 4.0.3.
Avast! They even get their own button on the pirate keyboard!
Well, it's actually a growth rate of about 210%, unless you consider a growth rate of 100% to be flat year-to-year....
It's not too surprising that all three landed very near each other. I imagine the process of putting a netbook-specific version of the OS together largely consists of cutting or tweaking or what-have-you until the performance gets in an "acceptable band" (or teaching the OS how to do this for itself when presented a small machine), and then stopping. So, this article basically shows that all these OSes are indeed in the "acceptable band." Windows 7 seems like it had the hardest time coming down into that band and landed at the slower end of the range. But, the OS does seem to scale itself back on the smaller machine reasonably well (even in its "full" edition), it would seem.
Now you're in tricky territory. I personally would get the most value out of an Ubuntu desktop. But, then, I've been using Linux for 17 years. For my folks, though, who have been using Windows for the last 15-20 years? I suspect they'd get more value out of XP even if they had to pay for it. They would get value out of the uniformity between their desktop's behavior and their netbook's behavior and benefit from not having to learn a new system.
My Nokia N900 will get in a state where it won't update, and invariably it's because /tmp filled up. (Some mental giant thought it would be good to have X log all interaction events to a file in /tmp. Gotta figure out how to turn that off.) Could an insufficiently large /tmp have been the problem?
Oh, I see, you were suggesting the capacitor goes in the charger to spread the load on the house's or charging station's wiring and local power grid. I get it now. Sorry. On a related note, a distributed array of capacitor banks would also potentially allow for better load balancing on the grid in general, if the charging station could also drain back into the grid. That could help us move toward sizing power plants closer to average load, rather than peak load.
I had been thinking of something else: Integrating some amount of capacitor storage in the vehicle to allow quick charge transfer from the grid to the vehicle, to hide the longer inherent charge time of the battery. For example, if the battery actually requires 3 hours to perform all of the chemical conversion associated with charging, but capacitors buffer some of the charge in the meantime, then to the user it looks like the batteries charged in minutes. Really, it was just buffered. But, to turn 3 hours into 6 minutes would require unrealistically huge capacitors, as you point out.
A more realistic use of ultracapacitors in an EV would be to buffer the much smaller amounts of charge associated with regenerative braking and the like. The capacity required there, though, would be much lower.
Anyway, it seems like you could charge a large battery array quickly by treating it as a bunch of smaller batteries charging in parallel. Still though, the rate just seems mind boggling, and the heat issues are what really get me wondering. Suppose you dump half a megawatt over 6 minutes into the car at even 99% efficiency--ie. only 1% of the energy converts to heat. That's 0.1 hours * 500 kW * 1% = 500Wh in heat energy. That would be about like running this guy on low for an hour, except it's compressed into 6 minutes. Toasty!
Well, that's not all. To significantly shorten the charging interval, the capacitor array would need to store nearly as much energy as the battery it's covering for.
Suppose, due to current regulation, the battery's charge rate is linear over the vast majority of the charging interval. (I'm pretty sure w/ these various lithium battery types, that's not too far from the truth.) If the capacitor array only stored half as much as energy as the battery, then it could only "hide" the second half of the charging interval. If it takes "t" minutes to fully charge the battery, then at 0.5 * t, you'd have a half-charged battery, and enough charge in the capacitors to finish the job.
So, if you have a capacitor array beefy enough to take a 3 hour charge (180 minutes) down to 6 minutes, that means you're hiding over 97% of the charging time. If your capacitors can store that much energy, then why do you have the battery?
Now, I suppose if these hypothesized capacitors are "leaky", it makes sense for them to buffer the charge but not be primarily responsible for its long-term storage. They would also be handy for absorbing transient power, such as the spikes you get from regenerative braking.
In the absence of the regulation, the pollution is a negative externality that affects the people not interested in the widgets. The widget producer has imposed an external cost on people not interested in widgets. If those people push back (ie. require the widget producer himself to absorb the cost through regulation or other means) so that the cost of cleaning up the pollution is included in the cost of the widget, then that cost is internalized.
Using your example: If you start and end with clean air and clean water, there's no transaction with a cost to externalize to the widget producer. If you achieve that goal by regulating the widget producer, you've merely prevented the widget producer from externalizing a cost. You haven't externalized one of your costs onto him. You didn't have a cost to externalize. "Keeping the air clean" is not a transaction.
Therefore, calling the regulation an external cost to the widget producer in this case is incorrect. An externality is something that doesn't show up in the final price of the good or service. Forcing an externalized cost back into the price internalizes the cost. The force itself isn't not an externality.
A very good point also.