I found this line of code in a test suite I was modifying.
assertEquals("Next number must increment ", next == next, next > first);
[...] the "fake" surrender tactic is not new. Which makes me wonder whether all wars might not be dishonorable to some extent.
It's been observed plenty of times before that war brings out the best and worst in people, on all sides. On one hand men and women will put themselves in mortal danger for the greater good of others. On the other hand, men and women will take advantage of the situation - looting, corruption or manoeuvring and manipulating for personal gain.
The extremes of war provides a backdrop for stories of honour and dishonour play out again and again on both small and large scales. And we should acknowledge both: honour and be proud of our men and women who selflessly give of themselves and be ashamed of those who do the opposite.
One thing is worth considering: Are the Iraqi "fake" surrenderers heroes? For their country, they boldly place themselves in the line of fire against the world's largest and best equipped military force, with only a crude piece of trickery as a shield. How brave (or desperate) would you have to be to to come out of a perfectly good hiding place - weaponless - and drawing attention to yourself? Sure my buddies might be hiding nearby with their guns ready, but if I did it, it'd be the bravest thing I'd ever done, by a country mile.
These Iraqi's do use "unfair" deception, but the invading force has "unfair" technology.
War sure does suck.
I thought it was great. So I went to post this comment:
This is a good read.
I'd also add that testing validation is a pain-in-the-neck, but if you have, you _must_ test it. Any mistakes in the validation code look bad and can quite possibly prevent a user from submitting valid data.
And then I pressed submit and got...
HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: entryID should never be null! at org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:254) at org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:295) at org.apache.jasper.servlet.JspServlet.service( JspServlet.java:241) at javax.servlet.http.HttpServlet.service( HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain. internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain. doFilter(ApplicationFilterChain.java:193) at geekblog.filters.ReferralsFilter. doFilter(ReferralsFilter.java:74) at org.apache.catalina.core.ApplicationFilterChain. internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain. doFilter(ApplicationFilterChain.java:193) at geekblog.filters.PrefsSetupFilter.doFilter( PrefsSetupFilter.java:84) at org.apache.catalina.core.ApplicationFilterChain. internalDoFilter(ApplicationFilterChain.java:213) at org.apache.catalina.core.ApplicationFilterChain. doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve. invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$ StandardPipelineValveContext.invokeNext( StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke( StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke( ContainerBase.java:995) < ... and so on for a few hundred lines ... > Apache Tomcat/4.1.24
I am not making this up.
Not that I should find it too amusing... I know this blog's comment form can be a little dodgy too :)
I have a fascination with dead technologies, which explains why I started reading the Java Web Services Tutorial today. In the XSLT chapter, I came across this gem entitled Generating XML from an Arbitrary Data Structure.
It describes how to implement just enough of the interface of a SAX parser to drive an XSLT stylesheet. The example given transforms an LDAP database entry (in the form of an ldif file) into an XML document using the default XSLT transformation. The trick works quite well in this situation, because the ldif file has to be parsed anyway.
This kind of trick might also work in other situations where parsing and transformation are required. For example, you could build a tiny web-app that runs free-format queries against an SQL database, and returns HTML formatted table results. Using an external XSLT stylesheet would give scope for customising the display.
Today, while peacefully coding EJBs, I found myself writing code using the dreaded
PortableRemoteObject.narrow() again. Charles "Fischkopf" Miller went into some detail about how painful this is in one of his recent blog entries. But in case you haven't experienced the exquisite clunkiness of
PortableRemoteObject.narrow(), here is a code sample:
// Get a bunch of things Collection collection = home.findByInternalGroupingKey(internalGroupingKey); Iterator iter = collection.iterator(); // Take the first one PolicyOptionGroup policyOptionGroup = (PolicyOptionGroup) PortableRemoteObject.narrow( iter.next(), PolicyOptionGroup.class);
The call to
PortableRemoteObject.narrow() is required because the objects in the
collection returned by the finder do not actually implement PolicyOptionGroup interface. Which is surprising, if you think about it. If they did implement the PolicyOptionGroup interface, we could write the more idiomatic:
PolicyOptionGroup policyOptionGroup = (PolicyOptionGroup) iter.next();
(Which is quite long-winded enough in itself, but that is the subject of another blog entry.)
Based on the comments to Charles' blog entry by Thomas Roka-Aardal and Bob Lee, there is a good reason for this verbosity. It goes like this: EJBs use RMI, RMI is transported by IIOP - the CORBA protocol - and the existing CORBA libraries cannot possibly be wrapped or modified for the convenience of EJB programmers.
In other words, this ugliness is caused by exposing an implementation choice that is at least two steps removed from my EJB code. And the benefits? The only two offered are:
Surprisingly, Bob Lee - in his comment on Charles' blog arguing the case for
PortableRemoteObject.narrow() - pointed out that it was possible to hide the call to
PortableRemoteObject.narrow() from EJB client code. Excellent. Let's do it and knock out "2 lines" of code (plus method declarations) per finder per EJB client.
And don't get me started on the UI itself. I mean, it seems to be based on Excel! That is such a satanic idea that it baffles me. How can they get away with such a stupid tool, year after year?
Well, not only did Microsoft base a a large chunk of the UI on Excel, several of the good features of Excel seem to have disappeared in the process! For instance, Project has only one level of undo. This is thoroughly inexcusable in a modern desktop application. Other functions are tacked-on and kludgy - like PERT charts and the whole Duration1, Duration2, Duration3 ... Duration9 thing.
On the other hand, Project is the product by which every other in the class is judged. Some competitors are better at particular tasks, some are cheaper, and some are both. But Project is good mix - not the most expensive and not the least. It can do a reasonable job of small projects, large projects and everything in between.
Another neat thing about Project is that it exposes its data model via ActiveX, so you can script it in VBA (or Python!). Last year I wrote a set of macros to take milestone dates from plans, plonk them into a spreadsheet and then graph how those milestones moved over time. Very effective at making any "planned slippages" visible to upper management.
Overall, MS Project is a comprehensive, competent offering. Sure it has some kludginess, gaps and obvious hangovers from earlier versions, but it works, has industry mind-share and is widely used.
Which is what many people say about Java.