Yes, teachers do get a kick back. One of my professors told our post grad class (during one of the much loved 'pub lectures') how they could stand to make $1000s from recommending the 'right' books.
I never got a kickback when I was a professor (what was I doing wrong?) Sometimes, I got a free copy of the book (Woo Hoo!) From my point of view as a prof, there would be 2 reasons to require the latest edition:
(most important) The content has actually changed significantly, covering new material or improving coverage of old material. In a field like Computer Science, this is plausible. For a topic such as Algebra or Calculus, it seems implausible.
Exercises have been changed -- if I were to assign Exercises 1, 4, 17 at the end of section 10.9, I want to be sure that all the students are doing the same exercises. Otherwise it's a grading nightmare.
According to the stats we collect at www.jstor.org, Win98 accounts for 1.4% of our hits (appx 2.1 million out of 151 million so far this month), but they account for only 0.6% of the Firefox users. Both Win95 and WinME are below 0.1%.
Mac OS X (all versions) is about 9% (the user-agent string, which is what we use for this analysis, doesn't distinguish versions of OS X, so I don't know how many of these are 10.2 or earlier).
So you're saying that since SGI didn't sue ATI years ago, they should just roll over and let their patent rights evaporate? If my neighbor has been letting his dog dump on my front lawn for years, does that mean that I lose my right to ask him to pick it up or take the dog elsewhere? I don't think so.
Alexander Graham Bell was 4 hours ahead of a rival inventor filing the patent on his telephone. Being first is all, in this race. (From Wikipedia: Bell then secured his own patent in 1876, just hours before Elisha Gray visited the patent office for his own work on the telephone.)
The Wikipedia article also tells the story of Antonio Meucci, who apparently invented the telephone several years earlier but was too poor to take out a patent. Seems things really weren't all that different 130 years ago.
No public money is being spent on this. RTFA. If 20/20 Communications thinks they can make it work, and they're putting their own dough into it, I say, go for it!
Sure, I can walk into any coffee shop (except *$) in town and have connectivity, but what about in the park? And if Joe Public can wean himself from AOL because he gets faster connections with the wireless card that came with his laptop, and not have to pay a cent, I say, go for it!
And there's another point. WiMax is great in concept, but if the consumer needs to buy new hardware to take advantage of it, it won't be as widely useful as 802.11b/g is right now.
Works with my Verizon Blackberry. And, of course, with a BBerry I'm already paying for data services, so that's not a problem. I had downloaded the earlier "Google Local" on my Cingular/Motorola cell, and it worked there, but the data charges were killing me.
But in my case, the waterfall model was the textbook example of how not to do things...
Yes, we "all" "agree" that this is true. That "waterfall" is too rigid, that you can't possibly know all the requirements up front, and that your "process" must be adaptable. And then management comes in and says "I want to see your full requirements, a Gantt chart showing all your milestones on this project, and your deadline is September for the whole project". And they hire a "project manager" to oversee the process who is apparently wedded to waterfall, and loves his Gantt charts.
Despite the typos, this posting is right on the mark. The BB integration with M$ Exchange server is excellent. I can't speak for how well it works with any other servers (e.g., Lotus). If you're already using Exchange (and, believe me, I have plenty of beefs with that product), the BB is an excellent mobile partner.
My mistake -- there is no PS/2 port on the T40, but there is one on the dock, and that's the one I've used on occasion. I've got a bluetooth mouse, so mostly I don't need it.
I use just about everything on my IBM T40 except the PCMCIA slots and the parallel port at one time or another. I'm a developer. I travel for work a few times a year, but I take my laptop home almost every night.
I use the video port to drive a projector in conference rooms. I use the USB port for many purposes -- mouse, Blackberry connector, flash drive. I use the PS2 port rarely, but have plugged a mouse into it once or twice. Ethernet port, built-in wireless, and bluetooth are used daily. CD-RW not so often, but as the previous writer noted, it has "saved my butt" a couple of times. CD-ROM/DVD used lots both for work and entertainment. Since most of the places I stay have either ethernet or wireless in the hotel room, I don't often use the modem port -- except when I visit my parents, who only have dial-up, still.
The 1400 x 1050 screen sometimes feels cramped to me, as I run it at 1600 x 1200 when it's docked on my desk at work. I will never buy a laptop with a smaller screen.
For all this, I'm willing to lug the weight around. That weight includes the 9-cell extended life battery (1.06 lbs) for a total of almost 6 lbs.
Yes, I read the filing. I agree with the filing. And you're right -- I misspoke about what the original patent covered.
The filing uses information that was not available to the general public in 1986. Based on that information, the filing asserts that the claims in the 1986 patent were "obvious" based on the claims in the patent filed more than a year earlier (making it prior art). If their assertion is correct, then the 1986 patent should be voided. I agree with all that.
While many software patents are "patently" invalid because of obvious prior art, this one was not obvious to me at the time. Although, I was working in a related field (computer graphics), and not directly in data compression. I had colleagues who were in signal processing (and DCT is at base a signal processing application), and none of them said "oh, that's obvious".
If you read the pubpatent filing, their main point is that an earlier patent, issued to the same company, is prior art for all the points in the '672' patent. The earlier patent was filed more than a year (plus one month) prior to the filing of the '672' patent, which makes it legally prior art.
Anyway, the sucker has less than a year to run, as it was filed in October, 1986. Probably why the lampreys at Forgent are pushing so aggressively. It'll only be a cash cow for another 11 months.
Interestingly, I could have been a target of Unisys, except they couldn't have gotten much blood from this stone. I was the original author of the "compress" program, which turned into an early "open source" effort (although the term hadn't been invented at the time). Compress was an implementation of LZW, based on Welch's 1984 paper in Computer. Only later was I informed that it was patented. After it had been incorporated into Berkeley Unix releases and into the GIF format. I was happy when that patent finally expired, but I had absolutely no doubt of its legitimacy.
As for the claimed superiority of PNG over JPEG, I'd say it depends on the application. JPEG was designed precisely and specifically for the purpose of compressing photographic images. Such images
Do not compress well using techniques like LZW and Huffman coding
Have intrinsic variation in pixel values due to noise in the recording process
Don't have precisely straight and sharp edges
These characteristics make them poorly suited to lossless compression techniques, and also mean that a lossy technique will not degrade the image further than the original noisy recording method did. (Unless you turn up the loss level too high.)
Because of the "if you have a hammer, every problem looks like a nail" principle, people have used JPEG in applications that it's not suited for -- applications where the lossy compression DOES degrade the image quality, and where a different method (LZW, for example) would in fact give a smaller file. Then other people point at these examples and say "PNG (or GIF) is better than JPEG!" My toolbox has hammers, screwdrivers, wrenches, etc. I try to pick the appropriate tool, and don't hammer with a wrench, for example. The same should be true of our computer tools.
In 30+ years of coding, I've used many different "standards". I've come to the realization that the details of the standard are unimportant -- what's important is that you have one.
Personally, I find "hungarian" variable names painful to behold. But if I'm working on code that used them originally, I'll try to make myself be consistent with the existing style.
Indenting and white space standards are totally unimportant with a good IDE. In Eclipse, hit control-shift-f to make it look the way you want it to.
Commenting is more problematic. I've gone from heavily commented to no-comment XP programming. I've settled down into a "minimal comment" regime. I try to write code that doesn't need comments by using short functions with meaningful variable, method, and class names. But where a comment can inject additional clarity, or where the code is necessarily obscure, then a comment can really help. (And by obscure, I don't mean "obfusticated" -- I mean code that is handling some bizarre real-world circumstance that most code readers probably would not think of.) Use your judgement. Ask yourself "if I came back to this code in a year, what bits would I be confused about." Then clarify that code. If it can't be further clarified, write a comment.
As for "javadoc" or "pod", I think that it is essential if you're writing code that will be used in "binary" form by others. Try using something like DOM or Spring without documentation and see how far you get! But Javadoc for the sake of meeting some metric ("all public methods must have Javadoc") is purely silly. Even when I was working on a strict XP team that enforced a "no comments" discipline, we put Javadoc on a couple of methods. We found ourselves continually going back to read the code to answer questions such as "is this index 0-based or 1-based?" A simple Javadoc comment stating "index is 1-based" saved many minutes of coding time.
Practice test-first writing. It's weird the first several times you do it, but at least for me, the more I do it, the more comfortable it feels. You can't always do it, I'll be the first to admit. But if I never write a line of code that doesn't have a test motivating it, I have a lot more confidence that the resulting code is going to do what I intend it to do. On the flip side, if I can't think of a test case that requires some particular "if branch", then maybe I don't really need to write that line of code.
Get a coverage tool and use it. Don't blindly try for ~100% coverage (you'll never get it anyway), but it can point out bits of code that are undertested.
In addition to "writing specs for new developers", pair a new developer with an experienced developer for a few weeks. Just a couple of hours a day will transfer the group practices much faster than any document will. IMO, this works best when the experienced developer is the "navigator" and the new developer has his or her hands on the keyboard, "driving." Doing == Learning. Watching == Boredom and Distraction. As an experienced developer, this is really hard for me -- I want to drive -- but it really does work.
Practice group ownership of code. Don't let any individual piece of code belong to a single person -- in the sense that only one person understands it and only one person is "allowed" to touch it. Not only can this save you when the "guru" leaves, but it helps to prevent wheel-reinvention and accretion of "ugly code". It encourages the attitude of "if it's broken, and I'm working on it now, then it's my responsibility to fix it."
Frequent integration in a multi-developer shop is essential. Don't let each developer work alone for a month or maybe even a week without reintegrating the code.
A bunch of this sounds very XP-ish. That's because XP is not a new thing. XP is a combination of good practices all "turned up to 11." We tried XP for about a year and had mixed results -- out of 4 projects, one was successful, one was an utter and complete failure, one was mothballed
Finally, I think you are overestimating the effect of the rural and surban subsidy, and understating the unreimbursed services provided by the rural population.
I used to live in New York State in the 60s and early 70s. Periodically, someone would start agitating about NYC seceding from the state and forming its own state. But it never happened. One reason it never happened is that NYC is a net money sink. More state money flows into NYC than flows out of it via state taxes. So in at least one case, the "rural" areas are subsidizing the urban areas, not vice versa.
I belong to a homebrewing club. We have monthly meetings at which we talk about brewing and sample each others' beers. The club owns a breathalyzer. After using it for several months, its accuracy starts to drift, and we have to send it back to the company for recalibration. Before we did this the last time, it was reading numbers like 0.20% for someone who had had just a couple of beers.
So, yes, breathalyzers need to be recalibrated. Whether US (or any other) law requires that the police be able to produce paperwork, I don't know.
Generally, the "roadside sobriety check", which might include breathalyzer, walking toe-to-toe, reciting the alphabet backwards, etc. is used only to establish a presumption of guilt, which then allows the police to take one into custody and to (attempt to) obtain a blood test.
You mean like I can already do with my Motorola V551 from Cingular?
I'm annoyed at Cingular for some other things (coverage area doesn't include my parents' house, for example), but this one item makes me happy that I switched from Verizon. I would be really pissed at them for this.
Seeing the entire context doesn't enlighten me any more than does the single line above. The only purpose of the comment, imo, is to flag to the reader "if you think you understand what is happening here, you might want to look again."
Slashdot Mirror
They aren't patent applications, they're trademark applications.
Oh! That's very different.
Never mind!
(With a nod to Gilda Radner... We miss you.)
Yes, teachers do get a kick back. One of my professors told our post grad class (during one of the much loved 'pub lectures') how they could stand to make $1000s from recommending the 'right' books.
I never got a kickback when I was a professor (what was I doing wrong?) Sometimes, I got a free copy of the book (Woo Hoo!) From my point of view as a prof, there would be 2 reasons to require the latest edition:
Some "real world" stats:
According to the stats we collect at www.jstor.org, Win98 accounts for 1.4% of our hits (appx 2.1 million out of 151 million so far this month), but they account for only 0.6% of the Firefox users. Both Win95 and WinME are below 0.1%.
Mac OS X (all versions) is about 9% (the user-agent string, which is what we use for this analysis, doesn't distinguish versions of OS X, so I don't know how many of these are 10.2 or earlier).
So you're saying that since SGI didn't sue ATI years ago, they should just roll over and let their patent rights evaporate? If my neighbor has been letting his dog dump on my front lawn for years, does that mean that I lose my right to ask him to pick it up or take the dog elsewhere? I don't think so.
Alexander Graham Bell was 4 hours ahead of a rival inventor filing the patent on his telephone. Being first is all, in this race. (From Wikipedia: Bell then secured his own patent in 1876, just hours before Elisha Gray visited the patent office for his own work on the telephone.)
The Wikipedia article also tells the story of Antonio Meucci, who apparently invented the telephone several years earlier but was too poor to take out a patent. Seems things really weren't all that different 130 years ago.
No public money is being spent on this. RTFA. If 20/20 Communications thinks they can make it work, and they're putting their own dough into it, I say, go for it!
Sure, I can walk into any coffee shop (except *$) in town and have connectivity, but what about in the park? And if Joe Public can wean himself from AOL because he gets faster connections with the wireless card that came with his laptop, and not have to pay a cent, I say, go for it!
And there's another point. WiMax is great in concept, but if the consumer needs to buy new hardware to take advantage of it, it won't be as widely useful as 802.11b/g is right now.
Works with my Verizon Blackberry. And, of course, with a BBerry I'm already paying for data services, so that's not a problem. I had downloaded the earlier "Google Local" on my Cingular/Motorola cell, and it worked there, but the data charges were killing me.
Sigh.
Despite the typos, this posting is right on the mark. The BB integration with M$ Exchange server is excellent. I can't speak for how well it works with any other servers (e.g., Lotus). If you're already using Exchange (and, believe me, I have plenty of beefs with that product), the BB is an excellent mobile partner.
My mistake -- there is no PS/2 port on the T40, but there is one on the dock, and that's the one I've used on occasion. I've got a bluetooth mouse, so mostly I don't need it.
I use just about everything on my IBM T40 except the PCMCIA slots and the parallel port at one time or another. I'm a developer. I travel for work a few times a year, but I take my laptop home almost every night.
I use the video port to drive a projector in conference rooms. I use the USB port for many purposes -- mouse, Blackberry connector, flash drive. I use the PS2 port rarely, but have plugged a mouse into it once or twice. Ethernet port, built-in wireless, and bluetooth are used daily. CD-RW not so often, but as the previous writer noted, it has "saved my butt" a couple of times. CD-ROM/DVD used lots both for work and entertainment. Since most of the places I stay have either ethernet or wireless in the hotel room, I don't often use the modem port -- except when I visit my parents, who only have dial-up, still.
The 1400 x 1050 screen sometimes feels cramped to me, as I run it at 1600 x 1200 when it's docked on my desk at work. I will never buy a laptop with a smaller screen.
For all this, I'm willing to lug the weight around. That weight includes the 9-cell extended life battery (1.06 lbs) for a total of almost 6 lbs.
Yes, I read the filing. I agree with the filing. And you're right -- I misspoke about what the original patent covered.
The filing uses information that was not available to the general public in 1986. Based on that information, the filing asserts that the claims in the 1986 patent were "obvious" based on the claims in the patent filed more than a year earlier (making it prior art). If their assertion is correct, then the 1986 patent should be voided. I agree with all that.
If you read the pubpatent filing, their main point is that an earlier patent, issued to the same company, is prior art for all the points in the '672' patent. The earlier patent was filed more than a year (plus one month) prior to the filing of the '672' patent, which makes it legally prior art.
Anyway, the sucker has less than a year to run, as it was filed in October, 1986. Probably why the lampreys at Forgent are pushing so aggressively. It'll only be a cash cow for another 11 months.
Interestingly, I could have been a target of Unisys, except they couldn't have gotten much blood from this stone. I was the original author of the "compress" program, which turned into an early "open source" effort (although the term hadn't been invented at the time). Compress was an implementation of LZW, based on Welch's 1984 paper in Computer. Only later was I informed that it was patented. After it had been incorporated into Berkeley Unix releases and into the GIF format. I was happy when that patent finally expired, but I had absolutely no doubt of its legitimacy.
As for the claimed superiority of PNG over JPEG, I'd say it depends on the application. JPEG was designed precisely and specifically for the purpose of compressing photographic images. Such images
- Do not compress well using techniques like LZW and Huffman coding
- Have intrinsic variation in pixel values due to noise in the recording process
- Don't have precisely straight and sharp edges
These characteristics make them poorly suited to lossless compression techniques, and also mean that a lossy technique will not degrade the image further than the original noisy recording method did. (Unless you turn up the loss level too high.)Because of the "if you have a hammer, every problem looks like a nail" principle, people have used JPEG in applications that it's not suited for -- applications where the lossy compression DOES degrade the image quality, and where a different method (LZW, for example) would in fact give a smaller file. Then other people point at these examples and say "PNG (or GIF) is better than JPEG!" My toolbox has hammers, screwdrivers, wrenches, etc. I try to pick the appropriate tool, and don't hammer with a wrench, for example. The same should be true of our computer tools.
Amen!
In 30+ years of coding, I've used many different "standards". I've come to the realization that the details of the standard are unimportant -- what's important is that you have one.
Personally, I find "hungarian" variable names painful to behold. But if I'm working on code that used them originally, I'll try to make myself be consistent with the existing style.
Indenting and white space standards are totally unimportant with a good IDE. In Eclipse, hit control-shift-f to make it look the way you want it to.
Commenting is more problematic. I've gone from heavily commented to no-comment XP programming. I've settled down into a "minimal comment" regime. I try to write code that doesn't need comments by using short functions with meaningful variable, method, and class names. But where a comment can inject additional clarity, or where the code is necessarily obscure, then a comment can really help. (And by obscure, I don't mean "obfusticated" -- I mean code that is handling some bizarre real-world circumstance that most code readers probably would not think of.) Use your judgement. Ask yourself "if I came back to this code in a year, what bits would I be confused about." Then clarify that code. If it can't be further clarified, write a comment.
As for "javadoc" or "pod", I think that it is essential if you're writing code that will be used in "binary" form by others. Try using something like DOM or Spring without documentation and see how far you get! But Javadoc for the sake of meeting some metric ("all public methods must have Javadoc") is purely silly. Even when I was working on a strict XP team that enforced a "no comments" discipline, we put Javadoc on a couple of methods. We found ourselves continually going back to read the code to answer questions such as "is this index 0-based or 1-based?" A simple Javadoc comment stating "index is 1-based" saved many minutes of coding time.
Practice test-first writing. It's weird the first several times you do it, but at least for me, the more I do it, the more comfortable it feels. You can't always do it, I'll be the first to admit. But if I never write a line of code that doesn't have a test motivating it, I have a lot more confidence that the resulting code is going to do what I intend it to do. On the flip side, if I can't think of a test case that requires some particular "if branch", then maybe I don't really need to write that line of code.
Get a coverage tool and use it. Don't blindly try for ~100% coverage (you'll never get it anyway), but it can point out bits of code that are undertested.
In addition to "writing specs for new developers", pair a new developer with an experienced developer for a few weeks. Just a couple of hours a day will transfer the group practices much faster than any document will. IMO, this works best when the experienced developer is the "navigator" and the new developer has his or her hands on the keyboard, "driving." Doing == Learning. Watching == Boredom and Distraction. As an experienced developer, this is really hard for me -- I want to drive -- but it really does work.
Practice group ownership of code. Don't let any individual piece of code belong to a single person -- in the sense that only one person understands it and only one person is "allowed" to touch it. Not only can this save you when the "guru" leaves, but it helps to prevent wheel-reinvention and accretion of "ugly code". It encourages the attitude of "if it's broken, and I'm working on it now, then it's my responsibility to fix it."
Frequent integration in a multi-developer shop is essential. Don't let each developer work alone for a month or maybe even a week without reintegrating the code.
A bunch of this sounds very XP-ish. That's because XP is not a new thing. XP is a combination of good practices all "turned up to 11." We tried XP for about a year and had mixed results -- out of 4 projects, one was successful, one was an utter and complete failure, one was mothballed
I used to live in New York State in the 60s and early 70s. Periodically, someone would start agitating about NYC seceding from the state and forming its own state. But it never happened. One reason it never happened is that NYC is a net money sink. More state money flows into NYC than flows out of it via state taxes. So in at least one case, the "rural" areas are subsidizing the urban areas, not vice versa.
I belong to a homebrewing club. We have monthly meetings at which we talk about brewing and sample each others' beers. The club owns a breathalyzer. After using it for several months, its accuracy starts to drift, and we have to send it back to the company for recalibration. Before we did this the last time, it was reading numbers like 0.20% for someone who had had just a couple of beers.
So, yes, breathalyzers need to be recalibrated. Whether US (or any other) law requires that the police be able to produce paperwork, I don't know.
Generally, the "roadside sobriety check", which might include breathalyzer, walking toe-to-toe, reciting the alphabet backwards, etc. is used only to establish a presumption of guilt, which then allows the police to take one into custody and to (attempt to) obtain a blood test.
You mean like I can already do with my Motorola V551 from Cingular?
I'm annoyed at Cingular for some other things (coverage area doesn't include my parents' house, for example), but this one item makes me happy that I switched from Verizon. I would be really pissed at them for this.
My favorite comment (not written by me) is this line from the Unix V7 source:
. s.html
sub r3,r0 / this is the clever part
You can see the whole file at http://minnie.tuhs.org/UnixTree/V7/usr/sys/40/m40
Seeing the entire context doesn't enlighten me any more than does the single line above. The only purpose of the comment, imo, is to flag to the reader "if you think you understand what is happening here, you might want to look again."