This argument (that tests may be flawed, and so don't help) isn't as much of a problem as you think.
Suppose 10% of the code you write contains errors (at random), and you write tests covering 50% of the code. Then you find 90% of the errors in 50% of the code (assuming your error rate in test code is the same as the error rate in 'real' code). Your error rate for the overall program should now be around 5.5%.
In other words, it doesnt matter if your tests can also be flawed, you'll still improve your code by doing testing. On the other hand, planning will make absolutely/zero/ difference to your error rate (compared to any other method that appears to implement a specification). In order to remove bugs, you have to do/some/ testing, so I have to assume you're advocating test-last.
It then boils down to whether test-driven or test-last is the most economic policy, and how much testing to do.
Anyway - since this economic argument (not flawed tests) is the crux of the matter, you should take a read of Beck's thinking on the issue, in May 1999 issue of C++ Report, particularly the last paragraph.
I'd say the big deal is your guys spent 3 man months on something they could have just downloaded. There are 4.Net/C# frameworks on this list, and 7 on this one.
The/. article describes Bill Venner's justification for writing his own; did your guys have a reason for what they did, or was it just "not invented here" syndrome?
Another question is how you could spend as long as 3 months on this at all, xUnit isn't complicated...they've just pissed away roughly £15,000-£63,000 of your customers money (depending on if they were permies or conslutants).
The junit docs document not only the framework, but the samples, and several implementations of TestListeners - an apples and apples comparison would be with the junit.framework package.
Focussing in on this, it looks like you've dropped the Assert class (presumably this is only for jdk1.4?). TestCase and TestSuite have been merged (seems sensible enough), and you've also provided a concrete Runner (no equivalent in the junit framework). This leaves the refactoring of TestResult etc into Report (roughly speaking).
Can you explain the advantages of what you've done in that last bit? I don't see that refactoring as resolving the classloader issues you mention in the article - they'd be handled in Runner/TestListener implementation.
If you program a computer to 'see' (using cameras or whatever) it can tell that two colours in an illusion are the same if they are 'really' the same.
Now do the same to a human. You might/know/ that you are seeing an illusion, but you/cannot/ see the two colours as being the same. Thus the eye isn't a simple camera, and we certainly don't have access to the vision 'bitmap' from the cornea in our concious brain, or we could train ourselves not to see the illusions.
The writeup says that the conventional explanation involves (something like) colour bleed within the neural system to get the effect; for which there is no direct evidence and no explanation for/why/ our eyes would have such a defect (why didn't illusions disappear as we evolved better sight?).
The idea that there might be some evolved preprocessing mechanism at the fundament of our vision which prevents us from seeing like cameras (as opposed to simple 'mechanical flaws') is actually recent and controversial (theres a chapter on exactly this in The Blank Slate thats worth reading), so I don't think it quite qualifies as 'banal'.
The Duke guys don't seem to be quite saying that we see the past at a macro level (leaves, trees, sheep) so much as at a micro level. Something is translating raw colour info into shape, distance and colour/cues/ that we internally reconstruct into the image using past knowledge. This layer is where the visual illusions arise.
Anyway, thats what I thought they were saying, I could have completely misunderstood. It would be more convincing if they could construct a computer model from their ideas that had the same vision defects we do.
The encryption story wasn't snake oil, and had very solid documentation. Sarah Flannery won Irish young scientist of the year, and subsequently the EU-wide prize, for her work. Her paper is here.
The Cayley-Purser algorithm she developed was subsequently shown to have security flaws; I don't recall if this was before or after the EU prize, but thats immaterial, the work was original and interesting, and worth a prize for a 16 year old!
She has subsequently written a book , which is a pop science introduction to crypto, and I understand from the blurb she's now studying maths at Cambridge.
Its incredibly easy to implement; when they submit their details, give them a link to an email whose subject or address contains a confirmation key.
This might be a Good Thing for another reason. Whitelist antispam solutions can auto-subscribe you to mailing lists, if the list works by send out a 'reply to join' message after you fill in a web page. If that practice was banned, implementing white lists would be safer.
This isn't just a pattern/antipattern thing. Many discussions er... have this pattern. Its the reason why we have the phrase "constructive criticism".
Another extreme of criticism is Bikeshed Painting, where you get swamped with alternative designs; I only mention this because of the nice story behind that link.
Yes I know this. Theres an article on devedge which explains the issues pretty well. The 'obtainment' issue the devedge writer describes is interesting, I have to assume that W3C felt that pages should link to the download page for the plugin if the plugin was unavailable, while MS felt plugins should download and auto-install.
Sun's description shows you the nitty gritty, but explains less of the 'why'.
The worst of this is the jsp:plugin tag, which generates code for the 1.3 plugin. Saves a lot of typing, but won't it get out of date pretty fast?
I changed over to a microsoft optical trackball from a standard mouse; I now very rarely get the pains in my elbow, upper arm and shoulder that came from using a mouse.
However, I now get my ass whipped in the office UT competitions:(
I've always though this was fantastically obscure, and uses a hellish mix of applet, object, and embed tags to make things work. Remember what appears below is recommended practice!
Old Style:
<APPLET code=XYZApp.class codebase=html/ align=baseline
width=200 height=200>
<PARAM NAME=model VALUE=models/HyaluronicAcid.xyz>
No Java 2 SDK, Standard Edition v 1.3 support for APPLET!!
</APPLET>
New Style:
<EMBED type=application/x-java-applet;version=1.3 width=200 height=200
align=baseline code=XYZApp.class codebase=html/
model=models/HyaluronicAcid.xyz
pluginspage=http://java.sun.com/products/plugin/1. 3/plugin-install.html>
<NOEMBED><XMP>
<APPLET code=XYZApp.class codebase=html/ align=baseline
width=200 height=200></XMP>
<PARAM NAME=java_code VALUE=XYZApp.class>
<PARAM NAME=java_codebase VALUE=html/>
<PARAM NAME=java_type VALUE=application/x-java-applet;version=1.3>
<PARAM NAME=model VALUE=models/HyaluronicAcid.xyz>
<PARAM NAME=scriptable VALUE=true>
No Java 2 SDK, Standard Edition v 1.3 support for APPLET!!
</APPLET></NOEMBED></EMBED>
</OBJECT>
Buy yourself an array of radio telescopes, and beam all your data into space. Perfect data recovery (in 50 years time) will be assured through the use of alien technology[1].
This follows the best practice of always storing critical data offsite in case of disasters like, er, the sky falling in.
-Baz
[1] of course you'll have to escape the slave labour camp first.
most CASE tools these days can import/export XMI (to varying degrees of interoperability). XMI is an XML serialization of the model the UML diagrams represent. These days you can use most Rose to draw a model to be implemented in a language it doesnt support, save it as XMI, and generate code by transforming the it. Beats trying to parse Rose's petal files.
If you just want to draw pictures, Rose is far too much baggage. If you want to use the pictures as the basis for something else, then SVG is not enough.
This reads like it gives/cable companies/ more choice in STB's, not consumers. So it will let them change suppliers on a whim. This might provide consumer benefits (lower rental costs) but since the alternate destination for the savings is higher margins for the cable co's, I wouldnt bet on it.
Quote from the passage blurb:
"With Passage, operators can introduce[...] innovative set-top boxes". I don't see how you can read this as "With Passage, operators can introduce innovative services on commodity set-top boxes", which is what the/. article imples.
A while back I tried to get a view like this up in Celestia - I was trying to see what the eclipse I saw looked like from space (I was in Noyon in 1999 - not my article; I didn't make it onto the train this guy describes, people were climbing in the windows! so I had to taxi it cross-country)
Anyhoo, I couldn't get it to work, even though I can see eclipses on eg Jupiter no bother at all. Anyone know the settings that would show this one, from say, behind ISS?
You're right that simple MVC webapps are easy, but the easiest approach is actually the one described in this article by Govind Seshadri.
What your approach misses that you get from Struts: - validation of form submissions (to java types, regexps, whatever) - automatic population of form beans, which leads to... - automagic prepopulation of forms from beans used earlier in the session (with struts custom tags) - tool support for designing complex sites (there are lots of GUIs for struts these days) - you don't need to write or maintain any of the framework:)
Every framework brings with it some constraints in how you work, but pays off in spades if you use all the features. Struts is no exception. If all you're doing is the stuff you describe, Govind's article might improve your life a little. If you build complex sites, Struts will simplify your life a lot.
Just a quick concrete example: in struts, the equivalent of the IndexServlet you describe is the DispatchAction. You'd configure like so:
Then you can write: package funky; class IndexAction extends org.apache.struts.actions.DispatchAction { public ActionForward login(...); public ActionForward mainmenu(...); public ActionForward saveform(...); public ActionForward etc(...); }...and the methods are automatically called depending on the value of 'f'. Like you said, "Of course some actions can be used for more than one thing if you code smartly.", and in this case the smartly was done for you;)
I'd like one of these devices - and I've often wondered if this strategy would be any good:
Instead of doing speech recognition to 'English', recognize speech to a textual representation of the sound (like the international phonetic alphabet - just an example). Transcription errors should be far fewer since you have a smaller set of patterns to recognize. The device should be capable of reading this version of the text back to you.
The memory required to store text is far smaller than that for sound, so I reckon even limited memory devices should be able to handle hours of dictation. When you return to base, a second program on your PC converts the phonetics to words, much like a spelling checker is used to correct transcription errors in OCR.
The philosophy is somewhat similar to that of Graffiti on the Palm - instead of trying to recognize handwriting, they changed the problem to recognizing something similar-but-simpler. I think people would get used to reading notes they've taken as phonetics (as they did with Graffiti), particularly if the PDA was also capable of reading back to remind them.
As for the command mode stuff - I'm in favour of using bushmen clicks for that;)
-Baz
Re:Strictly speaking not a new principle
on
Fanwing Planes?
·
· Score: 2
I have 2 questions: - does the paddlewheel keep the steamer afloat (generating lift)? - Is there room for a card table on a fanwing? My, that is a fiiiine power to lift ratio Mister Maverick...;)
On topic... you have *got* to see this video of another unusual flight concept, the rotopter. Would you go in any vehicle that moves like that????
Also, the cycloprop actually *is* a plane working on the same principal.
Re:Strictly speaking not a new principle
on
Fanwing Planes?
·
· Score: 4, Interesting
Its the *lift* that is being generated that is interesting, not the forward thrust. In the ducted fan you point to for example, lift is generated by the wing shape. In the fanwing, its from the rotation of the fan (the Magnus effect).
Note that in airscrews and turbines, thrust is generated in the direction of the axis of rotation. In the fanwing, both thrust and lift are perpendicular to the axis of rotation.
XDoc s as others have pointed out is a forms technology, not a competitor with PDF in all areas. However, Adobe purchased Accelio earlier in the year, who make a forms authoring and serving product (formerly known variously as FormFlow, ReachForms, RichForms); Adobe just relaunched the product line a week ago, realigning the company somewhat around server products.
Hence the impact of this announcement. If you've actually used the Accelio stuff (and I have, a lot) you'll know that it could be massively improved upon; otherproducts are biting at their heels already.
So MS weighs in immediately after Adobe's fanfare and says they're going to enter the market (note that XDocs does not even have a release date yet!) - its hardly surprising that Adobe's stock takes a hit.
Slashdot Mirror
This argument (that tests may be flawed, and so don't help) isn't as much of a problem as you think.
/zero/ difference to your error rate (compared to any other method that appears to implement a specification). In order to remove bugs, you have to do /some/ testing, so I have to assume you're advocating test-last.
Suppose 10% of the code you write contains errors (at random), and you write tests covering 50% of the code. Then you find 90% of the errors in 50% of the code (assuming your error rate in test code is the same as the error rate in 'real' code). Your error rate for the overall program should now be around 5.5%.
In other words, it doesnt matter if your tests can also be flawed, you'll still improve your code by doing testing. On the other hand, planning will make absolutely
It then boils down to whether test-driven or test-last is the most economic policy, and how much testing to do.
Anyway - since this economic argument (not flawed tests) is the crux of the matter, you should take a read of Beck's thinking on the issue, in May 1999 issue of C++ Report, particularly the last paragraph.
Cheers,
Baz
I'd say the big deal is your guys spent 3 man months on something they could have just downloaded. There are 4 .Net/C# frameworks on this list, and 7 on this one.
/. article describes Bill Venner's justification for writing his own; did your guys have a reason for what they did, or was it just "not invented here" syndrome?
The
Another question is how you could spend as long as 3 months on this at all, xUnit isn't complicated...they've just pissed away roughly £15,000-£63,000 of your customers money (depending on if they were permies or conslutants).
The junit docs document not only the framework, but the samples, and several implementations of TestListeners - an apples and apples comparison would be with the junit.framework package.
Focussing in on this, it looks like you've dropped the Assert class (presumably this is only for jdk1.4?). TestCase and TestSuite have been merged (seems sensible enough), and you've also provided a concrete Runner (no equivalent in the junit framework). This leaves the refactoring of TestResult etc into Report (roughly speaking).
Can you explain the advantages of what you've done in that last bit? I don't see that refactoring as resolving the classloader issues you mention in the article - they'd be handled in Runner/TestListener implementation.
Thanks,
Baz
That idea was patented last year... spotted it in New Scientist.
If you program a computer to 'see' (using cameras or whatever) it can tell that two colours in an illusion are the same if they are 'really' the same.
/know/ that you are seeing an illusion, but you /cannot/ see the two colours as being the same. Thus the eye isn't a simple camera, and we certainly don't have access to the vision 'bitmap' from the cornea in our concious brain, or we could train ourselves not to see the illusions.
/why/ our eyes would have such a defect (why didn't illusions disappear as we evolved better sight?).
/cues/ that we internally reconstruct into the image using past knowledge. This layer is where the visual illusions arise.
Now do the same to a human. You might
The writeup says that the conventional explanation involves (something like) colour bleed within the neural system to get the effect; for which there is no direct evidence and no explanation for
The idea that there might be some evolved preprocessing mechanism at the fundament of our vision which prevents us from seeing like cameras (as opposed to simple 'mechanical flaws') is actually recent and controversial (theres a chapter on exactly this in The Blank Slate thats worth reading), so I don't think it quite qualifies as 'banal'.
The Duke guys don't seem to be quite saying that we see the past at a macro level (leaves, trees, sheep) so much as at a micro level. Something is translating raw colour info into shape, distance and colour
Anyway, thats what I thought they were saying, I could have completely misunderstood. It would be more convincing if they could construct a computer model from their ideas that had the same vision defects we do.
-Baz
The encryption story wasn't snake oil, and had very solid documentation. Sarah Flannery won Irish young scientist of the year, and subsequently the EU-wide prize, for her work. Her paper is here.
The Cayley-Purser algorithm she developed was subsequently shown to have security flaws; I don't recall if this was before or after the EU prize, but thats immaterial, the work was original and interesting, and worth a prize for a 16 year old!
She has subsequently written a book , which is a pop science introduction to crypto, and I understand from the blurb she's now studying maths at Cambridge.
-Baz
Its incredibly easy to implement; when they submit their details, give them a link to an email whose subject or address contains a confirmation key.
This might be a Good Thing for another reason. Whitelist antispam solutions can auto-subscribe you to mailing lists, if the list works by send out a 'reply to join' message after you fill in a web page. If that practice was banned, implementing white lists would be safer.
-Baz
This isn't just a pattern/antipattern thing. Many discussions er... have this pattern. Its the reason why we have the phrase "constructive criticism".
Another extreme of criticism is Bikeshed Painting, where you get swamped with alternative designs; I only mention this because of the nice story behind that link.
Yes I know this. Theres an article on devedge which explains the issues pretty well. The 'obtainment' issue the devedge writer describes is interesting, I have to assume that W3C felt that pages should link to the download page for the plugin if the plugin was unavailable, while MS felt plugins should download and auto-install.
Sun's description shows you the nitty gritty, but explains less of the 'why'.
The worst of this is the jsp:plugin tag, which generates code for the 1.3 plugin. Saves a lot of typing, but won't it get out of date pretty fast?
-Baz
"Though poultry officials are reluctant to speak publicly about the Windhexe for competitive reasons, ..."
Ah, they're just chickens!
I changed over to a microsoft optical trackball from a standard mouse; I now very rarely get the pains in my elbow, upper arm and shoulder that came from using a mouse.
:(
However, I now get my ass whipped in the office UT competitions
Old Style:
<APPLET code=XYZApp.class codebase=html/ align=baseline width=200 height=200> <PARAM NAME=model VALUE=models/HyaluronicAcid.xyz> No Java 2 SDK, Standard Edition v 1.3 support for APPLET!! </APPLET>New Style:
<EMBED type=application/x-java-applet;version=1.3 width=200 height=200 align=baseline code=XYZApp.class codebase=html/ model=models/HyaluronicAcid.xyz pluginspage=http://java.sun.com/products/plugin/1Buy yourself an array of radio telescopes, and beam all your data into space. Perfect data recovery (in 50 years time) will be assured through the use of alien technology[1].
This follows the best practice of always storing critical data offsite in case of disasters like, er, the sky falling in.
-Baz
[1] of course you'll have to escape the slave labour camp first.
s/SVG/XMI/
most CASE tools these days can import/export XMI (to varying degrees of interoperability). XMI is an XML serialization of the model the UML diagrams represent. These days you can use most Rose to draw a model to be implemented in a language it doesnt support, save it as XMI, and generate code by transforming the it. Beats trying to parse Rose's petal files.
If you just want to draw pictures, Rose is far too much baggage. If you want to use the pictures as the basis for something else, then SVG is not enough.
-Baz
Quote from the passage blurb: "With Passage, operators can introduce[...] innovative set-top boxes". I don't see how you can read this as "With Passage, operators can introduce innovative services on commodity set-top boxes", which is what the /. article imples.
-Baz
A while back I tried to get a view like this up in Celestia - I was trying to see what the eclipse I saw looked like from space (I was in Noyon in 1999 - not my article; I didn't make it onto the train this guy describes, people were climbing in the windows! so I had to taxi it cross-country)
Anyhoo, I couldn't get it to work, even though I can see eclipses on eg Jupiter no bother at all. Anyone know the settings that would show this one, from say, behind ISS?
-Baz
Sorry the config bit got chopped out - I wroute:
<action path="/indexAction" type="funky.IndexAction" name="indexForm" scope="request" input="/index.jsp" parameter="f">
You're right that simple MVC webapps are easy, but the easiest approach is actually the one described in this article by Govind Seshadri.
:)
...and the methods are automatically called depending on the value of 'f'. Like you said, "Of course some actions can be used for more than one thing if you code smartly.", and in this case the smartly was done for you ;)
What your approach misses that you get from Struts:
- validation of form submissions (to java types, regexps, whatever)
- automatic population of form beans, which leads to...
- automagic prepopulation of forms from beans used earlier in the session (with struts custom tags)
- tool support for designing complex sites (there are lots of GUIs for struts these days)
- you don't need to write or maintain any of the framework
Every framework brings with it some constraints in how you work, but pays off in spades if you use all the features. Struts is no exception. If all you're doing is the stuff you describe, Govind's article might improve your life a little. If you build complex sites, Struts will simplify your life a lot.
Just a quick concrete example: in struts, the equivalent of the IndexServlet you describe is the DispatchAction. You'd configure like so:
Then you can write:
package funky;
class IndexAction extends org.apache.struts.actions.DispatchAction {
public ActionForward login(...);
public ActionForward mainmenu(...);
public ActionForward saveform(...);
public ActionForward etc(...);
}
-Baz
Crowd scene spam? Er... "MAKE PEOPLE FAST!!!"?
- Baz (or more likely one of his thousands of AI clones)
I'd like one of these devices - and I've often wondered if this strategy would be any good:
;)
Instead of doing speech recognition to 'English', recognize speech to a textual representation of the sound (like the international phonetic alphabet - just an example). Transcription errors should be far fewer since you have a smaller set of patterns to recognize. The device should be capable of reading this version of the text back to you.
The memory required to store text is far smaller than that for sound, so I reckon even limited memory devices should be able to handle hours of dictation. When you return to base, a second program on your PC converts the phonetics to words, much like a spelling checker is used to correct transcription errors in OCR.
The philosophy is somewhat similar to that of Graffiti on the Palm - instead of trying to recognize handwriting, they changed the problem to recognizing something similar-but-simpler. I think people would get used to reading notes they've taken as phonetics (as they did with Graffiti), particularly if the PDA was also capable of reading back to remind them.
As for the command mode stuff - I'm in favour of using bushmen clicks for that
-Baz
I have 2 questions: ;)
- does the paddlewheel keep the steamer afloat (generating lift)?
- Is there room for a card table on a fanwing? My, that is a fiiiine power to lift ratio Mister Maverick...
On topic... you have *got* to see this video of another unusual flight concept, the rotopter. Would you go in any vehicle that moves like that????
Also, the cycloprop actually *is* a plane working on the same principal.
Its the *lift* that is being generated that is interesting, not the forward thrust. In the ducted fan you point to for example, lift is generated by the wing shape. In the fanwing, its from the rotation of the fan (the Magnus effect).
Note that in airscrews and turbines, thrust is generated in the direction of the axis of rotation. In the fanwing, both thrust and lift are perpendicular to the axis of rotation.
A Slashdot headline has been truncate
- "Chuck D"
Repeat after me:
"I haven't read the XML spec, I haven't read the XML spec..."???
Section 1.1, "Origin and Goals":
"The Design Goals for XML are...
6. XML documents should be human-legible and reasonably clear."
XDoc s as others have pointed out is a forms technology, not a competitor with PDF in all areas. However, Adobe purchased Accelio earlier in the year, who make a forms authoring and serving product (formerly known variously as FormFlow, ReachForms, RichForms); Adobe just relaunched the product line a week ago, realigning the company somewhat around server products.
Hence the impact of this announcement. If you've actually used the Accelio stuff (and I have, a lot) you'll know that it could be massively improved upon; other products are biting at their heels already.
So MS weighs in immediately after Adobe's fanfare and says they're going to enter the market (note that XDocs does not even have a release date yet!) - its hardly surprising that Adobe's stock takes a hit.