....here's a document:
<foo>
<bar>
baz
</bar>
</foo>
Here's the XPath expression to get all "bar" nodes:
/foo/bar
Nice and concise.
Over on the PMD project we're replacing many of our Java rules (find empty catch blocks, empty if statements, etc) with XPath expressions. For example, here's the XPath expression that finds empty if statements:
//IfStatement/Statement/Block[count(*) = 0]
Sweet, eh? Props to Dan Sheppard who came up with this excellent technique.
> (We also use this convenience any time > we talk about company property, ideas, > and actions.)
Fair enough, yup, that's true.
> This is why I think the U.S. government > must officially recognize and apologize > for its wrongdoings.
I think the U.S. has done this in some situations... i.e., national holidays for Martin Luther King Day, apologies for Japanese internment camps (http://www.factmonster.com/spot/internment1.html) , accidental bombing of the Chinese embassy in Belgrade (http://www.usatoday.com/news/index/kosovo/koso590.htm).
Yup, it'd be nice to deprecate some of our past. Trail of Tears, slavery, and much more. If we're Win32 programmers, we need a USHistoryEx.
I was thinking about what you said earlier about "our government's shameful past". Sometimes I wondor if it would make a difference to say "our government leaders' shameful actions" or "the bad things some people did". Because it seems to me that companies don't do wrong things, and countries don't do wrong things - _people_ do wrong things.
There's a neat short story by the Russian author Bulgakov called "A Dog's Heart". In it one of the characters is talking about how the country has changed since the Bolsheviks took over, and he says "It's not the fault of the capitalists that someone stole the boots in the hall! And it's not the fault of the capitalists that the house committee instituted mandatory choir singing!" And he goes on to say, more or less, that it comes down to individual people making individual decisions. When I go to work this morning, will I curse and shout at someone who cuts me off in traffic? Then that's my fault, not society's, or the government's, or anyone else.
Re-reading that, it's murkier than I had hoped. Ah well.
I highly recommend that Bulgakov book if you're a Russian author fan, though. Good stuff.
I must say, it's good that the U.S. is the kind of place where these sort of documents are unclassified and posted on the web. In other countries I daresay these documents would never see the light of day.
"Democracy is the worst form of government, except for all the others that have been tried" --Winston Churchill
Perchance... but it's an applicable anecdote in that it addresses the extent of U.S. bombing of water facilities.
Furthermore, and with all due respect since my knowledge of U.S. airstrikes on water facilities during the Gulf War is quite limited, without supporting references, one could consider your statements anecdotes. Crikey!
To quote from Richard Hallion's "Storm Over Iraq":
New York peace activist Erika Monk visited Baghdad immediately after hostilities, in the wake of a UN team that had concluded Iraq had been devasted back to a "pre-industrial" level. Instead, she found "a city whose homes and offices were almost entirely intact, where electricity was coming back on and water was running". She concluded it was "post-industrial enough for us to be caught in a lot of traffic jams".
Finding incidents where U.S. soldiers have made bad decisions is easy. All sorts of situations arise and sometimes soldiers do the wrong things. U.S. soldiers have a comparatively good record on that sort of thing, though.
> And we are also trying to say that > war is horrible, and kills people, > and should be avoided at all costs.
Peace is not the lack of war. And "at all costs" means different things to different people. Britain avoided war "at all costs" for quite a while in the 1930s... until Germany had invaded Poland.
> it is just small change, it took me > 2 minutes to think it up
The thing that keeps me on my toes is that sometimes the marketing folks are right! Sometimes it only takes a few minutes to make a little change they want that will make a big difference.
For example, say you've written some Java GUI product and the marketing fellow runs up and says "hey, we've got to have an 'About' option on the menu, our customers won't pay us without it!". It'll literally take me 5 minutes to put a new JMenuItem on there that uses a JOptionPane to popup up a little information that he wants in there. And it can always be expanded later if they then decide that it needs to have a Flash viewer embedded or something.
> need to deep rewrite of existing codebase
This points to a good XP practice wherein code is refactored all along so that change is not painful. In fact, since change is expected, you make it easy by maintaining a slew of unit tests and keeping the code clean.
> P: You signed off on the spec. It > doesn't have it in it.
The problem with "signing off on the spec" is that it doesn't work any more than "type all the characters right the first time" does.
When I'm programming, I follow a feedback loop of:
- write some code - write a couple tests - oops, test failed, didn't think about that condition - write more code, tests pass, yay
Why would a marketing person be any different? I daresay marketers change their minds, improve their stuff, and think of new things just as much as I do.
This thread has slipped off the Slashdot main page, but what the heck, we'll carry on anyhow:-)
Right on - mock objects are thin, thin, thin. If you have to do tons of setup, something's wrong.
I was thinking about a database - it's kind of weird in that it's are part of the application, but it's not compiled in or anything. I mean, there's this big complicated DB schema that has all sorts of constraints and triggers and whatnot and the application sort of sits on top of that and hopes for the best. And there's no way to "check" the DB short of replicating lots of DB logic (table relationships and whatnot) in the application code, so that if one changes than both have to change.
Thus, the obvious solution is never to save any data. It all must be reentered every time the application runs.:-)
> There is just no way that, on a short > iteration cycle, I can assume that the > state of the database can be reset > to some baseline in any sort of timely manner.
Right on. So don't test against the database directly. Use mock objects. Since you're doing J2EE, I reckon you're using JDBC in your session beans, or you're using a bunch of entity beans, or you've got some sort of DAOish layer somewhere. Any of those can be mocked up in one way or another; give it a whirl.
I don't mean to minimize the difficulty of unit testing J2EE stuff - I mean, any time a bean gets resolved it throws a wrench in the tests. But try to refactor as much as possible into plain ol' Java objects, and mock out the rest.
I'm an idiot too - that's why I write a bunch of tests, otherwise I'd be breaking things all the time:-)
I've had great results with unit testing PMD - here's the current test report. So I'm pretty hyped up on them....
> Do the simplest thing - add whatever you need > to the existing classes and just do it."
Hm, that doesn't sound XPish. XP says to refactor as you go. So when you add some code and things are getting complicated, refactor to make it simple.
> You won't find an XP shop that will > encourage modularity over implementation time.
"Modularity" can be taken to extremes, too:
int x = IntegerFactory.createInteger("5").toInt();
> Most programmers are like any other > people - they can be tempermental, > stubborn, selfish, and proud.
Yup, just like anybody else. But how will these people ever improve their interpersonal skills if they don't work with other people?
> Where XP excells is late stage bug > fixing, where hit-and-run is definitely > the right strategy.
If you do XP all the way through, the pair programming, short iterations, and especially the unit tests will minimize the "late stage bug fixing". You did have unit tests, right?
> To a first approximation software development is a lore that is passed and not some kind of a hard core science.
I agree. There's a lot of comp sci theory out there that breaks down once it gets out of its strong areas - sorting, searching, finite state machines, etc.
> I have found tons of problems by using use cases, uml diagrams, state diagrams or even flow charts
OK, you feel you have found and solved problems before writing code. Fair enough. However, consider how much time you have spent on that non-coding stuff, though, and how much you could have accomplished if you had spent that time writing tests and code.
What's more valuable to the customer after a month - 80% of the functionality in clean, testable code? Or 0% of the code but a big pile of Visio diagrams?
> I've eliminated thousands of bugs simply by having the right design to begin with.
Have you? How do you know that?
Yours,
Tom http://pmd.sf.net/
Re:Java applications I've SEEN are unimpressive...
on
The Future of Java?
·
· Score: 1
FWIW.... ditto.
IDEA is slow to start up, but its refactoring tools are beautiful. Just the "optimize imports" tool alone is worth it. I find myself renaming variables and such much more often now that I know I can do it easily and safely....
CPD uses a variant on Greedy String Tiling to find duplicated code in Java programs. There's also a JavaSpaces version since finding duplicated code is fairly parallelizable....
Yours,
Tom
Re:Jabber, XMLBlaster and friends
on
MOM and SOA on Linux?
·
· Score: 3, Interesting
Like the parent poster said, Jabber is much more useful than just sending IMs around.
We're using Jabber on Linux to support http://cougaar.org/ administration - to stop/start/configure nodes, check on status, etc, etc. It's pretty sweet, especially when used via Rich Kilmer's Jabber4R Ruby Jabber client. Check out http://www.infoether.com/ruby/jabber4r/ for more info...
Tom Find unused Java code with http://pmd.sf.net/
You can catch some of the problems....
on
Effective Java
·
· Score: 4, Informative
...that Effective Java talks about by using a static code analyzer. Like this one:
http://pmd.sf.net/
PMD will find places where you've used concrete collections rather than interfaces, left unused code lying around, etc., etc.
Slashdot Mirror
....here's a document:
<foo>
<bar>
baz
</bar>
</foo>
Here's the XPath expression to get all "bar" nodes:
Nice and concise.
Over on the PMD project we're replacing many of our Java rules (find empty catch blocks, empty if statements, etc) with XPath expressions. For example, here's the XPath expression that finds empty if statements:
Sweet, eh? Props to Dan Sheppard who came up with this excellent technique.
Tom
> (We also use this convenience any time
) , accidental bombing of the Chinese embassy in Belgrade (http://www.usatoday.com/news/index/kosovo/koso590 .htm).
> we talk about company property, ideas,
> and actions.)
Fair enough, yup, that's true.
> This is why I think the U.S. government
> must officially recognize and apologize
> for its wrongdoings.
I think the U.S. has done this in some situations... i.e., national holidays for Martin Luther King Day, apologies for Japanese internment camps (http://www.factmonster.com/spot/internment1.html
Yours,
tom
Yup, it'd be nice to deprecate some of our past. Trail of Tears, slavery, and much more. If we're Win32 programmers, we need a USHistoryEx.
I was thinking about what you said earlier about "our government's shameful past". Sometimes I wondor if it would make a difference to say "our government leaders' shameful actions" or "the bad things some people did". Because it seems to me that companies don't do wrong things, and countries don't do wrong things - _people_ do wrong things.
There's a neat short story by the Russian author Bulgakov called "A Dog's Heart". In it one of the characters is talking about how the country has changed since the Bolsheviks took over, and he says "It's not the fault of the capitalists that someone stole the boots in the hall! And it's not the fault of the capitalists that the house committee instituted mandatory choir singing!" And he goes on to say, more or less, that it comes down to individual people making individual decisions. When I go to work this morning, will I curse and shout at someone who cuts me off in traffic? Then that's my fault, not society's, or the government's, or anyone else.
Re-reading that, it's murkier than I had hoped. Ah well.
I highly recommend that Bulgakov book if you're a Russian author fan, though. Good stuff.
Yours,
Tom
Fair enough.
I must say, it's good that the U.S. is the kind of place where these sort of documents are unclassified and posted on the web. In other countries I daresay these documents would never see the light of day.
"Democracy is the worst form of government, except for all the others that have been tried" --Winston Churchill
Yours,
tom
> Are you saying usa should just
> destroy artifacts because Irak do?
Nope.
> I agree that usa could shoot if the
> soldiers come storming with artifacts
> around their necks, but why bomb museums?
Right on, exactly. The U.S. doesn't bomb museums.
Yours,
tom
Perchance... but it's an applicable anecdote in that it addresses the extent of U.S. bombing of water facilities.
Furthermore, and with all due respect since my knowledge of U.S. airstrikes on water facilities during the Gulf War is quite limited, without supporting references, one could consider your statements anecdotes. Crikey!
Yours,
Tom
To quote from Richard Hallion's "Storm Over Iraq":
:-)
New York peace activist Erika Monk visited Baghdad immediately after hostilities, in the wake of a UN team that had concluded Iraq had been devasted back to a "pre-industrial" level. Instead, she found "a city whose homes and offices were almost entirely intact, where electricity was coming back on and water was running". She concluded it was "post-industrial enough for us to be caught in a lot of traffic jams".
You set 'em up, I'll knock 'em down
Yours,
tom
Finding incidents where U.S. soldiers have made bad decisions is easy. All sorts of situations arise and sometimes soldiers do the wrong things. U.S. soldiers have a comparatively good record on that sort of thing, though.
Yours,
Tom
> if Saddam Hussein did it, then it's
> okay for the U.S. to do it too.
U.S. troops didn't ransack museums in Iraq. U.S. bombs were used on military targets.
> Using your logic, it would be perfectly
> acceptable for Bush to use VX gas on
> demonstrators in New York.
throw new RudenessException();
Tom
Right on. This book:
http://www.af.mil/lib/csafbook/stormoiraq.htm
has some excellent descriptions of how accurate the U.S. strikes were in Gulf War I. As you say, no doubt accuracy has only improved....
Yours,
tom
> And we are also trying to say that
> war is horrible, and kills people,
> and should be avoided at all costs.
Peace is not the lack of war. And "at all costs" means different things to different people. Britain avoided war "at all costs" for quite a while in the 1930s... until Germany had invaded Poland.
Yours,
Tom
Yup, it probably will go untouched due to accurate weapons and careful U.S. application thereof:
o ti on.html
http://www.bullatomsci.org/issues/1991/s91/s91f
Tom
...when he invaded Kuwait in 1990 and his soldiers ransacked the museums:
r aq 1/000801a.htm
http://www.globalpolicy.org/security/sanction/i
Tom
> it is just small change, it took me
> 2 minutes to think it up
The thing that keeps me on my toes is that sometimes the marketing folks are right! Sometimes it only takes a few minutes to make a little change they want that will make a big difference.
For example, say you've written some Java GUI product and the marketing fellow runs up and says "hey, we've got to have an 'About' option on the menu, our customers won't pay us without it!". It'll literally take me 5 minutes to put a new JMenuItem on there that uses a JOptionPane to popup up a little information that he wants in there. And it can always be expanded later if they then decide that it needs to have a Flash viewer embedded or something.
> need to deep rewrite of existing codebase
This points to a good XP practice wherein code is refactored all along so that change is not painful. In fact, since change is expected, you make it easy by maintaining a slew of unit tests and keeping the code clean.
Yours,
tom
> P: You signed off on the spec. It
> doesn't have it in it.
The problem with "signing off on the spec" is that it doesn't work any more than "type all the characters right the first time" does.
When I'm programming, I follow a feedback loop of:
- write some code
- write a couple tests
- oops, test failed, didn't think about that condition
- write more code, tests pass, yay
Why would a marketing person be any different? I daresay marketers change their minds, improve their stuff, and think of new things just as much as I do.
Yours,
tom
This thread has slipped off the Slashdot main page, but what the heck, we'll carry on anyhow :-)
:-)
Right on - mock objects are thin, thin, thin. If you have to do tons of setup, something's wrong.
I was thinking about a database - it's kind of weird in that it's are part of the application, but it's not compiled in or anything. I mean, there's this big complicated DB schema that has all sorts of constraints and triggers and whatnot and the application sort of sits on top of that and hopes for the best. And there's no way to "check" the DB short of replicating lots of DB logic (table relationships and whatnot) in the application code, so that if one changes than both have to change.
Thus, the obvious solution is never to save any data. It all must be reentered every time the application runs.
See ya,
Tom
> There is just no way that, on a short
:-)
> iteration cycle, I can assume that the
> state of the database can be reset
> to some baseline in any sort of timely manner.
Right on. So don't test against the database directly. Use mock objects. Since you're doing J2EE, I reckon you're using JDBC in your session beans, or you're using a bunch of entity beans, or you've got some sort of DAOish layer somewhere. Any of those can be mocked up in one way or another; give it a whirl.
I don't mean to minimize the difficulty of unit testing J2EE stuff - I mean, any time a bean gets resolved it throws a wrench in the tests. But try to refactor as much as possible into plain ol' Java objects, and mock out the rest.
I'm an idiot too - that's why I write a bunch of tests, otherwise I'd be breaking things all the time
I've had great results with unit testing PMD - here's the current test report. So I'm pretty hyped up on them....
Good luck,
tom
> Do the simplest thing - add whatever you need
> to the existing classes and just do it."
Hm, that doesn't sound XPish. XP says to refactor as you go. So when you add some code and things are getting complicated, refactor to make it simple.
> You won't find an XP shop that will
> encourage modularity over implementation time.
"Modularity" can be taken to extremes, too:
int x = IntegerFactory.createInteger("5").toInt();
> Most programmers are like any other
> people - they can be tempermental,
> stubborn, selfish, and proud.
Yup, just like anybody else. But how will these people ever improve their interpersonal skills if they don't work with other people?
> Where XP excells is late stage bug
> fixing, where hit-and-run is definitely
> the right strategy.
If you do XP all the way through, the pair programming, short iterations, and especially the unit tests will minimize the "late stage bug fixing". You did have unit tests, right?
Yours,
Tom
Another DARPA funded open source project:
http://pmd.sf.net/
It's been developed to keep the Cougaar - http://cougaar.org/ - code nice and clean, but anyone can use/improve. Props to DARPA for supporting PMD!
Tom
> To a first approximation software development is a lore that is passed and not some kind of a hard core science.
I agree. There's a lot of comp sci theory out there that breaks down once it gets out of its strong areas - sorting, searching, finite state machines, etc.
> I have found tons of problems by using use cases, uml diagrams, state diagrams or even flow charts
OK, you feel you have found and solved problems before writing code. Fair enough. However, consider how much time you have spent on that non-coding stuff, though, and how much you could have accomplished if you had spent that time writing tests and code.
What's more valuable to the customer after a month - 80% of the functionality in clean, testable code? Or 0% of the code but a big pile of Visio diagrams?
Yours,
Tom
You wrote:
> I've eliminated thousands of bugs simply by having the right design to begin with.
Have you? How do you know that?
Yours,
Tom
http://pmd.sf.net/
FWIW.... ditto.
IDEA is slow to start up, but its refactoring tools are beautiful. Just the "optimize imports" tool alone is worth it. I find myself renaming variables and such much more often now that I know I can do it easily and safely....
Tom
...using this thing here:
http://pmd.sourceforge.net/cpd.html
CPD uses a variant on Greedy String Tiling to find duplicated code in Java programs. There's also a JavaSpaces version since finding duplicated code is fairly parallelizable....
Yours,
Tom
Like the parent poster said, Jabber is much more useful than just sending IMs around.
We're using Jabber on Linux to support http://cougaar.org/ administration - to stop/start/configure nodes, check on status, etc, etc. It's pretty sweet, especially when used via Rich Kilmer's Jabber4R Ruby Jabber client. Check out http://www.infoether.com/ruby/jabber4r/ for more info...
Tom
Find unused Java code with http://pmd.sf.net/
...that Effective Java talks about by using a static code analyzer. Like this one:
http://pmd.sf.net/
PMD will find places where you've used concrete collections rather than interfaces, left unused code lying around, etc., etc.
Tom