The part where they found that hand assembly by nubile vestal virgins wasn't expensive enough, so they decided to mercilessly ravage each virgin after she'd assembled her first pair... was that real?
The point of a company is that it is a system. Productivity is an emergent property, and individual productivity is dependent on putting that individual's talents to best use. True, if you can't figure out how to do this, you should let that person go. But that doesn't mean you should use statistics to run your business like a fantasy football franchise.
AKAImBatMan says: If exists(A) -> exists(B) and exists(A), then we should be able to assume exists(B).
RomSteady says: it it possible to test for exists(B), then we should test for exists(B), even if we believe exists(A) -> exists(B).
I think that you are both right. It comes down to a simple principle of design: contain unnecessary assumptions.
A web app developer, assuming that the browser won't violate your expectations is bad unless there is a compelling reason to rely on those expectations. It doesn't matter whether those expectations are reasonable, because even if the browser developer intended to honor them there many be bugs in the implementation.
For a web browser developer, assuming that developers won't rely on some aspect or implications of the standard that isn't (in your opinion) necessary) is bad. You should strive to meet as every expectation that is demonstrably implied by the standard.
I tend to wide with AKAImBatman's view a bit more, though. In practice the accumulation of "best programming practice" can result in code that is cluttered with exception testing. Developers when coding should deal with concepts rather than implementations, and creators of platforms should make this feasible as far as humanly possible.
Actually, in some places they do say "fourteen March two thousand and nine." Either one is clear. It's using month numbers to represent names that creates problems.
The ISO 8601 recommends that interchange formats for date representations go from most significant to least significant, in which case NEITHER MM/DD/YYYY nor DD/MM/YYYY suffice. It should be YYYY-MM-DD. The UK convention is arguably consistent in that it goes from least to most significant, but then you're screwed when you try to add time because nobody specifies time with minutes before hours.
Well, it doesn't matter, because after you've taken care 3 and 14, you still have the rest of the decimal precision to consider:.0015926...
To be certain not to miss the critical moment, the students would have had to have been celebrating at some point between 137 and 138 seconds past midnight this morning.
I ran a number of AD&D 1st Edition campaigns, but never bothered to pick up the 2nd Edition.
I was very aware of consideral systemic problems wth AD&D, but by in large every DM I knew tweaked the rules to his liking. AD&D is not a game you play like chess or bridge, that really needs tournament rules. As DM, you control the mythos of the universe in which your players play, therefore you control the implicit rules of the campaign. It's a short step from there from making up your own explicit rules. Virtually no DM I knew followed the AD&D rules exactly, and many of us replaced sections of the rules entirely to suit our preferences.As DM you set the rules in order to maximize the enjoyment of your players; if they don't like them, you change them but if one player objects to what other players like, he can find a different game. My philosophy was the a campaign was group storytelling, and I tweaked the rules appropriately. This attracted like minded players.
Recently, my kids were interested in learning about D&D, so I picked up the latest edition. My impression of it is that it is far better by many measures, but worse in others. It'd be a much better system if you wanted to play D&D as a tournament game, if you registered your characters the way bridge players are registered and took them around to different campaigns.
On the other hand, it was much worse from other standpoints. For example the Gygax mythos, which was fine as a starter mythos but rubbish from a literary standpoint, seems wired more deeply than ever into the structure of the game.
The improvements of the recent rules move the game more down the road of simulation. Under the old rules the cure to balance problem was a judicious application of Deus ex Machina; done cleverly enough it becomes part of the story and is not even noticed by the players. You take the player with an unbeatable character and you cut him down a notch, which motivates the player to respond. So from a DM perspective the rule improvements reduced the need to play dirty tricks on the players, but this is not an improvement in fun.
What the rules do do is make playing more complicated. The AD&D 1st edition rules,with all their faults, could be explained to a new player in about fifteen minutes and learned by a new DM in a few hours. This, combined with the ready made but hackneyed Gygax mythose, bootstrapped many a fine campaign.
So, I'm in the market for a simpler system. It doesn't have to be perfect, because perfection isn't really that important. Perhaps I'll go to Ebay, as you suggest, but ideally it'd be something that is designed from the outset to be simpler to play and extend.
So, in principle, assembling a statement from true parts doesn't make what is communicated true.
The main problem I see is distinguishing between diabolically clever malice and normal, boneheaded human tunnel vision. If the perp left a paper trail when he constructed the defamation, sure; but the fact that a statement is outrageously wrong doesn't imply intent.
The thing is, it's possible to architecturally separate presentation from content from metadata in HTML. Furthermore, people do care about presentation. Who are we to say they shouldn't? The problem is confusing the two.
Here's what I see wrong with the puritanical belief that outlawing presentation hanky-panky will keep the flock virtuously focused on content: people will cheat. When they think they can get away with it, they'll enthusiastically engage in all manner of abominations, like sticking their PowerPoints into gopher collections.
The miserable presentation capabilities of HTML actually did a lot more to promote the very idea that content was something independent from presentation and important in itself. After a bit of straying down the path of unnatural vice (font tags, tables for formatting etc), people discovered they could enjoy their presentation -- no more than that, they could enjoy a wide variety of presentations -- within the blessed institution of stylesheets.
Well, multimedia is a orthogonal concern, really. If anything, in the early days gopher was more convenient for multimedia than the web.
The thing about the web, the defining characteristic from the point of view of providers of information, was HTML. And HTML was a pain. It still is but since we assume it's necessary we don't think of it as pain. Back in the day, it was much easier dump all your stuff into gopher, including your multimedia files, than it was to write a whole new bunch of HTML from scratch.
HTML was pretty far from what people eventually wanted the web to do too, which was to be an app platform. A lot of fancy architectin' has gone on to get it where it is today, and people are still screwing around with stuff like flash.
The thing about the PITA of HTML is that it forced people to redo so much of their content into a uniform format, what's more a format that could be spidered by robots. That's the secret sauce. Yeah it's nice that people can follow hyperlinks, but the ability deal with basically one kind of data (marked up docs with hyperlinks in them) that really made the web powerful.
Another thing was that while the early HTML wasn't very much like what people wanted for their documents, and despite abortive early attempts to add things like fonts (not to mention our beloved blink tag), HTML's SGML roots gave it architectural flexibilty. It needed the flexibilty so that the the missing 99% of what really people wanted could be added later without turning it into a hopeless mess.
Repeat after me: there is no border between "day" and "night".
That doesn't mean there is no difference.
If I'm working on a mathematical proof, I'm reasonably sure that what I'm doing can't be called "instinctual".
On the other hand, I was once walking down a city street just before dawn, and I saw an absolutely huge gray animal shambling down the sidewalk; it was gray and furry and about the size of a kid's red wagon. I jumped out into the street -- and act I think can be reasonably called "instinctual" -- from which point I realized that the animal was an absolutely filthy raccoon. The critter was so dirty you could barely make out his mask. He was big and fat for a coon, yes, but not in the fifty to seventy five pound range like I'd thought it had been.
Both these acts are different, yes, and I think they can reasonably be characterized by different names represent opposite ends of some scale. That doesn't preclude the portion of the scale between those acts from containing a whole spectrum of things that in varying degrees "instinctual" and "cogent".
It's insisting that there is is a perfectly sharp dividing line between instinct and rationality that non-human animals cannot cross that leads to inane assertions, e.g. the chimp in question had ot be acting "entirely instinctually". Another set of absurdities come from thinking of instincts as simple, having relatively straightforward internal logic. In the case of my raccoon story, lots of really quite interesting cognitive things were going on. One part of my brain acquired the image of the animal, could not recognize it by appearance or context, and decided to prioritize the situation by telling the rest of the brain it was about five times as large as it really was.
You can't say "rendering is the most important thing" or "speed is the most important thing".
The most important thing is whatever is causing the user a headache at the moment. That is dependent on thresholds, of which for any single factor there will be three (in order): (1) unusable to usable (2) unacceptable to acceptable (3) meaningful improvement possible to meaningful improvement impossible.
If any parameter of quality is unusable, improving that parameter trumps any improvements to quality measures that are usable or acceptable. If any parameter is unacceptable, improvements to it trump otherwise meaningful improvements to things that are acceptable. Meaningless improvements, either because something is better than it needs to be or because the improvement is tiny, never matter.
You have to put all these things together. If IE fails to render a website you need usably, it doesn't matter at all how fast it is. If it renders the site unacceptably, then you aren't going to use it unless the only alternatives are spectacularly slow. If IE and Firefox render the site about the same, but IE renders it twenty milliseconds faster, the difference is literally a blink of an eye, so rendering speed in this case would be effectively the same.
Many of the differences in the data are in the "blink of an eye" scale, and don't signify anything. Most of them seem to be matters of less than half a second, which we'd only care about if the speed was really, really bad all around. We can see this by looking at the outliers in the data.
A quick look over the data makes sina.com.cn seem like the most significant case, with rendering times ranging from 5.48 to 8.03. If you used that site, those speeds would be usable, but not acceptable, and a 2.55 second improvement to an 8.03 second load time would be most welcome. However that is just one case (in which IE happens to lose); given its outlier status in the dataset it's probably not worth making much out of. Other outliers favoring IE could probably be found.
Aside from sina.com.cn, in this data set speed differences would either be imperceptible (google.com, 20ms); the worst case would be well within the acceptable range (apple.com loading in 3.07 seconds), or the difference in load times meaningless on a percentage basis (163.com load times ranging from 14.75 to 15.02).
Given this dataset, the only reasonable conclusion to draw is that there is no practical difference in load times between browsers. If this is so, a user should be interested in differences between browsers in the ability to render content correctly. This is a less straightforward question than speed. I haven't been following IE recently, but there's been a bit of a conundrum historically in that past versions of IE have had lousy standards compliance but many web pages have been designed so that only IE works.
Oh, by the way, we haven't even talked about security. For prior versions of IE, security has been the dominating concern.
I think the audio telephone was one of those ideas whose time had come. It's not as if it sprung from the head of some individual genius, a lot of people were working in that direction; take any one of them out of the picture and the result wouldn't be much different.
Ironically, the telephone was more or less an inevitable outgrowth of work on improving the capacity of long distance cables to carry telegraphs -- a digital medium. In a sense, we've come full circle.
One of the ideas that people were working on is what we'd call frequency division multiplexing: sending multiple simultaneous telegraph signals on the same wire but encoded on carriers of different frequencies. Once you started to work in that direction an audio telephone would be simple, relatively speaking. So somebody would have "invented" it, because plenty of people were working along those lines.
The lone genius inventor is a mythical idea, one that distorts our thinking about stuff like intellectual property. There are genius inventors, to be sure, but surely there were men like Thomas Edison or Nicola Tesla that lived in the dark ages. The reason we've never heard of them is that even a genius needs other people's ideas to build upon.
There's lots of tricky optimization problems where better algorithms could make a huge difference. How much fuel do you load on an airplane given that (a) any fuel you have at the end of a flight leg above the margin of safety is useless cargo and (b) fuel has different costs at different airports? It's probably a safe bet that it's always more energy efficient to transport fuel by ground though.
What about optimizing traffic flow through a city by coordinating traffic lights? If you could minimize the total time cars spend idling in traffic, you'd save vast amounts of energy. But you have to take into account how drivers will change their behavior in order to optimize their personal trips.
The idea that energy prices should be kept high, through a carbon tax, is intended to harness the market's ability to provide approximations of optimal solutions to resource distribution problems by internalizing the environmental costs of energy use.
In a world wracked with hunger, poverty, ignorance, and environmental catastrophe, is writing games what you ought to be spending your time on?
Oh, wait.
You want to know whether you can make money.
Well, it looks like your friend has learned the first lesson of business: most customers are unreasonable. You can't expect them to care about your problems, e.g., keeping a roof over your head and keeping a wolf from the door. Fuming over the unreasonability of customers is a waste of time, and time is money. If you can't keep yourself from doing this, you should consider the first question, above, because you aren't cut out for business.
A corollary of this is that failing to manage customer expectations is like losing track of that bottle of nitroglycerin that you know is on your desk somewhere. This means keeping a careful rein on your salesmen, including your inner salesman. Salesmen have one imperative: sell. When you're a one man band, it's easy to sell because you have control over prices. You simply whip up expectations to the greatest degree you can, then drop the price until the product moves. This can work, provided that you can take your profit up front. For many kinds of software, especially software sold as a service, this is dangerous, dangerous because most of the costs of supporting a sale are downstream.
Your friend kind of screwed up here, because he's got a service based revenue model and he expected customer expectations to be reasonable. That's OK, because another important lesson of business is this: you screw up just as much as anybody else. If you want to win, you've got to learn from your mistakes faster.
I knew a guy who had a really extremely useful product, but it required a great deal of support. Such a product "wants" to be expensive. He could have made a decent living selling it to only two or three customers who'd spend 100x what certain other customers would pay. Once he had that under control he could have dropped the price a bit and got a few more customers, growing his business step by step by taking successive nibbles of the market. Instead, he tried to grab the whole market in one fell swoop by pricing low, and ended up with more support costs than he could handle, spending all his time mollifying unprofitable customers while profitable customers stewed.
Web businesses superficially seem to be a different animal. They often seem to run on no visible means of support, somehow managing to give expensive things away for free. In truth, the basics remain the same: manage expenses and costs so that you come out ahead. Web businesses make money by aggregating lots of small, sometimes infinitesimal bits of revenue that have even tinier increments of cost. You can make a lot of money selling a ringtone for a buck because once you have the customer's money in hand they never call you for support. Google is successful in the search business because the number of transactions they handle are astronomical. They're tough to dislodge from their position because of the massive investment you'd need to get your transaction costs down; start with the cost of changing a single customer's web habits, multiply it by the number of customers you need to succeed, and it's a daunting hole to climb out of.
It sounds like your friends are well positioned to make a good living with this kind of model. First, they have created a product people care about. That's a rare, rare gift. There's lots of money out there attempting to do this with conspicuous lack of success. One of the biggest costs associated with any sale is the cost of getting people to pay attention, so when people care about a product that's money on the bottom line right there, provided you have any revenue at all. If they can find any source of revenue at all, and keep support costs close to nil, they can very likely come out ahead. If they want to get rich, they sell the business to some operator who has
Well, the first step in becoming interested in learning to play an instrument is listening to music. I know my kids weren't all that interested in rock until these games started to get popular, although early on their knowledge was a bit -- let's say idiosyncratic. They'd know who Deep Purpose was, but when I offered to play some Rolling Stones the name drew a blank.
One reason to think these games might be a bridge to musicianship is that players really listen to the music in a way they don't if it's just playing on the car radio. They learn to anticipate the shape of the next lick in order to hit the beats correctly and anticipate the direction of pitch.
I'd imagine that a controller like this would work best with game songs that had been specially arranged so that some note played on the correct string would sound right. This would make what would be an easy song on a conventional controller considerably more challenging, for players who had already mastered the game. Players could improvise a bit a way from the game's licks, e.g. playing the right string with a note 1/3 away from the game soundtrack. There might be new game modes, for example you could hit any note so long as it was on time and on the correct musical scale.
"Thank you sheriff for helping improve my business. Keeping all the young ladies on staff as busy as they can physically manage is great for business, especially in these tough economic times."
Tough economic times?. Doesn't she mean that she is grateful that the sheriff's stimulus had caused her business to expand in hard economic times?
Slashdot Mirror
So...
The part where they found that hand assembly by nubile vestal virgins wasn't expensive enough, so they decided to mercilessly ravage each virgin after she'd assembled her first pair... was that real?
"Jaiku is a social networking, micro-blogging and lifestreaming service comparable to Twitter."
Making a statement like that, prior to 1995 or so, might have been grounds for commitment to a mental institution.
to those who lack understanding.
The point of a company is that it is a system. Productivity is an emergent property, and individual productivity is dependent on putting that individual's talents to best use. True, if you can't figure out how to do this, you should let that person go. But that doesn't mean you should use statistics to run your business like a fantasy football franchise.
And when implementation bleeds into the conceptual level, misery results.
This is getting into the philosophy of ontology.
AKAImBatMan says: If exists(A) -> exists(B) and exists(A), then we should be able to assume exists(B).
RomSteady says: it it possible to test for exists(B), then we should test for exists(B), even if we believe exists(A) -> exists(B).
I think that you are both right. It comes down to a simple principle of design: contain unnecessary assumptions.
A web app developer, assuming that the browser won't violate your expectations is bad unless there is a compelling reason to rely on those expectations. It doesn't matter whether those expectations are reasonable, because even if the browser developer intended to honor them there many be bugs in the implementation.
For a web browser developer, assuming that developers won't rely on some aspect or implications of the standard that isn't (in your opinion) necessary) is bad. You should strive to meet as every expectation that is demonstrably implied by the standard.
I tend to wide with AKAImBatman's view a bit more, though. In practice the accumulation of "best programming practice" can result in code that is cluttered with exception testing. Developers when coding should deal with concepts rather than implementations, and creators of platforms should make this feasible as far as humanly possible.
Actually, in some places they do say "fourteen March two thousand and nine." Either one is clear. It's using month numbers to represent names that creates problems.
The ISO 8601 recommends that interchange formats for date representations go from most significant to least significant, in which case NEITHER MM/DD/YYYY nor DD/MM/YYYY suffice. It should be YYYY-MM-DD. The UK convention is arguably consistent in that it goes from least to most significant, but then you're screwed when you try to add time because nobody specifies time with minutes before hours.
Well, it doesn't matter, because after you've taken care 3 and 14, you still have the rest of the decimal precision to consider: .0015926...
To be certain not to miss the critical moment, the students would have had to have been celebrating at some point between 137 and 138 seconds past midnight this morning.
I ran a number of AD&D 1st Edition campaigns, but never bothered to pick up the 2nd Edition.
I was very aware of consideral systemic problems wth AD&D, but by in large every DM I knew tweaked the rules to his liking. AD&D is not a game you play like chess or bridge, that really needs tournament rules. As DM, you control the mythos of the universe in which your players play, therefore you control the implicit rules of the campaign. It's a short step from there from making up your own explicit rules. Virtually no DM I knew followed the AD&D rules exactly, and many of us replaced sections of the rules entirely to suit our preferences.As DM you set the rules in order to maximize the enjoyment of your players; if they don't like them, you change them but if one player objects to what other players like, he can find a different game. My philosophy was the a campaign was group storytelling, and I tweaked the rules appropriately. This attracted like minded players.
Recently, my kids were interested in learning about D&D, so I picked up the latest edition. My impression of it is that it is far better by many measures, but worse in others. It'd be a much better system if you wanted to play D&D as a tournament game, if you registered your characters the way bridge players are registered and took them around to different campaigns.
On the other hand, it was much worse from other standpoints. For example the Gygax mythos, which was fine as a starter mythos but rubbish from a literary standpoint, seems wired more deeply than ever into the structure of the game.
The improvements of the recent rules move the game more down the road of simulation. Under the old rules the cure to balance problem was a judicious application of Deus ex Machina; done cleverly enough it becomes part of the story and is not even noticed by the players. You take the player with an unbeatable character and you cut him down a notch, which motivates the player to respond. So from a DM perspective the rule improvements reduced the need to play dirty tricks on the players, but this is not an improvement in fun.
What the rules do do is make playing more complicated. The AD&D 1st edition rules,with all their faults, could be explained to a new player in about fifteen minutes and learned by a new DM in a few hours. This, combined with the ready made but hackneyed Gygax mythose, bootstrapped many a fine campaign.
So, I'm in the market for a simpler system. It doesn't have to be perfect, because perfection isn't really that important. Perhaps I'll go to Ebay, as you suggest, but ideally it'd be something that is designed from the outset to be simpler to play and extend.
Well, extrapolating from the trend so far, you'll be losing the next gen shuffle in your ear.
So did FTP servers. Gopher was basically like an FTP service with a tad more metadata.
A web site made up of text files would be pretty dysfunctional.
is by artful selections of truths.
So, in principle, assembling a statement from true parts doesn't make what is communicated true.
The main problem I see is distinguishing between diabolically clever malice and normal, boneheaded human tunnel vision. If the perp left a paper trail when he constructed the defamation, sure; but the fact that a statement is outrageously wrong doesn't imply intent.
I'm not sure that's right.
The thing is, it's possible to architecturally separate presentation from content from metadata in HTML. Furthermore, people do care about presentation. Who are we to say they shouldn't? The problem is confusing the two.
Here's what I see wrong with the puritanical belief that outlawing presentation hanky-panky will keep the flock virtuously focused on content: people will cheat. When they think they can get away with it, they'll enthusiastically engage in all manner of abominations, like sticking their PowerPoints into gopher collections.
The miserable presentation capabilities of HTML actually did a lot more to promote the very idea that content was something independent from presentation and important in itself. After a bit of straying down the path of unnatural vice (font tags, tables for formatting etc), people discovered they could enjoy their presentation -- no more than that, they could enjoy a wide variety of presentations -- within the blessed institution of stylesheets.
Well, multimedia is a orthogonal concern, really. If anything, in the early days gopher was more convenient for multimedia than the web.
The thing about the web, the defining characteristic from the point of view of providers of information, was HTML. And HTML was a pain. It still is but since we assume it's necessary we don't think of it as pain. Back in the day, it was much easier dump all your stuff into gopher, including your multimedia files, than it was to write a whole new bunch of HTML from scratch.
HTML was pretty far from what people eventually wanted the web to do too, which was to be an app platform. A lot of fancy architectin' has gone on to get it where it is today, and people are still screwing around with stuff like flash.
The thing about the PITA of HTML is that it forced people to redo so much of their content into a uniform format, what's more a format that could be spidered by robots. That's the secret sauce. Yeah it's nice that people can follow hyperlinks, but the ability deal with basically one kind of data (marked up docs with hyperlinks in them) that really made the web powerful.
Another thing was that while the early HTML wasn't very much like what people wanted for their documents, and despite abortive early attempts to add things like fonts (not to mention our beloved blink tag), HTML's SGML roots gave it architectural flexibilty. It needed the flexibilty so that the the missing 99% of what really people wanted could be added later without turning it into a hopeless mess.
I'm sorry, I don't buy that one word distinction.
Operant conditioning is a form of "learning". It doesn't qualify actions that result from a trained stimulus as "rational".
Repeat after me: there is no border between "day" and "night".
That doesn't mean there is no difference.
If I'm working on a mathematical proof, I'm reasonably sure that what I'm doing can't be called "instinctual".
On the other hand, I was once walking down a city street just before dawn, and I saw an absolutely huge gray animal shambling down the sidewalk; it was gray and furry and about the size of a kid's red wagon. I jumped out into the street -- and act I think can be reasonably called "instinctual" -- from which point I realized that the animal was an absolutely filthy raccoon. The critter was so dirty you could barely make out his mask. He was big and fat for a coon, yes, but not in the fifty to seventy five pound range like I'd thought it had been.
Both these acts are different, yes, and I think they can reasonably be characterized by different names represent opposite ends of some scale. That doesn't preclude the portion of the scale between those acts from containing a whole spectrum of things that in varying degrees "instinctual" and "cogent".
It's insisting that there is is a perfectly sharp dividing line between instinct and rationality that non-human animals cannot cross that leads to inane assertions, e.g. the chimp in question had ot be acting "entirely instinctually". Another set of absurdities come from thinking of instincts as simple, having relatively straightforward internal logic. In the case of my raccoon story, lots of really quite interesting cognitive things were going on. One part of my brain acquired the image of the animal, could not recognize it by appearance or context, and decided to prioritize the situation by telling the rest of the brain it was about five times as large as it really was.
You can't say "rendering is the most important thing" or "speed is the most important thing".
The most important thing is whatever is causing the user a headache at the moment. That is dependent on thresholds, of which for any single factor there will be three (in order):
(1) unusable to usable
(2) unacceptable to acceptable
(3) meaningful improvement possible to meaningful improvement impossible.
If any parameter of quality is unusable, improving that parameter trumps any improvements to quality measures that are usable or acceptable. If any parameter is unacceptable, improvements to it trump otherwise meaningful improvements to things that are acceptable. Meaningless improvements, either because something is better than it needs to be or because the improvement is tiny, never matter.
You have to put all these things together. If IE fails to render a website you need usably, it doesn't matter at all how fast it is. If it renders the site unacceptably, then you aren't going to use it unless the only alternatives are spectacularly slow. If IE and Firefox render the site about the same, but IE renders it twenty milliseconds faster, the difference is literally a blink of an eye, so rendering speed in this case would be effectively the same.
Many of the differences in the data are in the "blink of an eye" scale, and don't signify anything. Most of them seem to be matters of less than half a second, which we'd only care about if the speed was really, really bad all around. We can see this by looking at the outliers in the data.
A quick look over the data makes sina.com.cn seem like the most significant case, with rendering times ranging from 5.48 to 8.03. If you used that site, those speeds would be usable, but not acceptable, and a 2.55 second improvement to an 8.03 second load time would be most welcome. However that is just one case (in which IE happens to lose); given its outlier status in the dataset it's probably not worth making much out of. Other outliers favoring IE could probably be found.
Aside from sina.com.cn, in this data set speed differences would either be imperceptible (google.com, 20ms); the worst case would be well within the acceptable range (apple.com loading in 3.07 seconds), or the difference in load times meaningless on a percentage basis (163.com load times ranging from 14.75 to 15.02).
Given this dataset, the only reasonable conclusion to draw is that there is no practical difference in load times between browsers. If this is so, a user should be interested in differences between browsers in the ability to render content correctly. This is a less straightforward question than speed. I haven't been following IE recently, but there's been a bit of a conundrum historically in that past versions of IE have had lousy standards compliance but many web pages have been designed so that only IE works.
Oh, by the way, we haven't even talked about security. For prior versions of IE, security has been the dominating concern.
If speed is everything, the following script has it beat:
#!/bin/sh /dev/null
cat
I think the audio telephone was one of those ideas whose time had come. It's not as if it sprung from the head of some individual genius, a lot of people were working in that direction; take any one of them out of the picture and the result wouldn't be much different.
Ironically, the telephone was more or less an inevitable outgrowth of work on improving the capacity of long distance cables to carry telegraphs -- a digital medium. In a sense, we've come full circle.
One of the ideas that people were working on is what we'd call frequency division multiplexing: sending multiple simultaneous telegraph signals on the same wire but encoded on carriers of different frequencies. Once you started to work in that direction an audio telephone would be simple, relatively speaking. So somebody would have "invented" it, because plenty of people were working along those lines.
The lone genius inventor is a mythical idea, one that distorts our thinking about stuff like intellectual property. There are genius inventors, to be sure, but surely there were men like Thomas Edison or Nicola Tesla that lived in the dark ages. The reason we've never heard of them is that even a genius needs other people's ideas to build upon.
Ever heard of hypergraphia?
There's lots of tricky optimization problems where better algorithms could make a huge difference. How much fuel do you load on an airplane given that (a) any fuel you have at the end of a flight leg above the margin of safety is useless cargo and (b) fuel has different costs at different airports? It's probably a safe bet that it's always more energy efficient to transport fuel by ground though.
What about optimizing traffic flow through a city by coordinating traffic lights? If you could minimize the total time cars spend idling in traffic, you'd save vast amounts of energy. But you have to take into account how drivers will change their behavior in order to optimize their personal trips.
The idea that energy prices should be kept high, through a carbon tax, is intended to harness the market's ability to provide approximations of optimal solutions to resource distribution problems by internalizing the environmental costs of energy use.
What's the Matter with Denmark?
and
Denmark's Military Arrogance.
Apparently we can add legalized pot to the catalog of horrors you mention.
is worth developing games at all.
In a world wracked with hunger, poverty, ignorance, and environmental catastrophe, is writing games what you ought to be spending your time on?
Oh, wait.
You want to know whether you can make money.
Well, it looks like your friend has learned the first lesson of business: most customers are unreasonable. You can't expect them to care about your problems, e.g., keeping a roof over your head and keeping a wolf from the door. Fuming over the unreasonability of customers is a waste of time, and time is money. If you can't keep yourself from doing this, you should consider the first question, above, because you aren't cut out for business.
A corollary of this is that failing to manage customer expectations is like losing track of that bottle of nitroglycerin that you know is on your desk somewhere. This means keeping a careful rein on your salesmen, including your inner salesman. Salesmen have one imperative: sell. When you're a one man band, it's easy to sell because you have control over prices. You simply whip up expectations to the greatest degree you can, then drop the price until the product moves. This can work, provided that you can take your profit up front. For many kinds of software, especially software sold as a service, this is dangerous, dangerous because most of the costs of supporting a sale are downstream.
Your friend kind of screwed up here, because he's got a service based revenue model and he expected customer expectations to be reasonable. That's OK, because another important lesson of business is this: you screw up just as much as anybody else. If you want to win, you've got to learn from your mistakes faster.
I knew a guy who had a really extremely useful product, but it required a great deal of support. Such a product "wants" to be expensive. He could have made a decent living selling it to only two or three customers who'd spend 100x what certain other customers would pay. Once he had that under control he could have dropped the price a bit and got a few more customers, growing his business step by step by taking successive nibbles of the market. Instead, he tried to grab the whole market in one fell swoop by pricing low, and ended up with more support costs than he could handle, spending all his time mollifying unprofitable customers while profitable customers stewed.
Web businesses superficially seem to be a different animal. They often seem to run on no visible means of support, somehow managing to give expensive things away for free. In truth, the basics remain the same: manage expenses and costs so that you come out ahead. Web businesses make money by aggregating lots of small, sometimes infinitesimal bits of revenue that have even tinier increments of cost. You can make a lot of money selling a ringtone for a buck because once you have the customer's money in hand they never call you for support. Google is successful in the search business because the number of transactions they handle are astronomical. They're tough to dislodge from their position because of the massive investment you'd need to get your transaction costs down; start with the cost of changing a single customer's web habits, multiply it by the number of customers you need to succeed, and it's a daunting hole to climb out of.
It sounds like your friends are well positioned to make a good living with this kind of model. First, they have created a product people care about. That's a rare, rare gift. There's lots of money out there attempting to do this with conspicuous lack of success. One of the biggest costs associated with any sale is the cost of getting people to pay attention, so when people care about a product that's money on the bottom line right there, provided you have any revenue at all. If they can find any source of revenue at all, and keep support costs close to nil, they can very likely come out ahead. If they want to get rich, they sell the business to some operator who has
Well, the first step in becoming interested in learning to play an instrument is listening to music. I know my kids weren't all that interested in rock until these games started to get popular, although early on their knowledge was a bit -- let's say idiosyncratic. They'd know who Deep Purpose was, but when I offered to play some Rolling Stones the name drew a blank.
One reason to think these games might be a bridge to musicianship is that players really listen to the music in a way they don't if it's just playing on the car radio. They learn to anticipate the shape of the next lick in order to hit the beats correctly and anticipate the direction of pitch.
I'd imagine that a controller like this would work best with game songs that had been specially arranged so that some note played on the correct string would sound right. This would make what would be an easy song on a conventional controller considerably more challenging, for players who had already mastered the game. Players could improvise a bit a way from the game's licks, e.g. playing the right string with a note 1/3 away from the game soundtrack. There might be new game modes, for example you could hit any note so long as it was on time and on the correct musical scale.
"Thank you sheriff for helping improve my business. Keeping all the young ladies on staff as busy as they can physically manage is great for business, especially in these tough economic times."
Tough economic times?. Doesn't she mean that she is grateful that the sheriff's stimulus had caused her business to expand in hard economic times?