Skip to main content

You know what I mean

Posted by daniel on November 10, 2003 at 8:47 AM PST

One of the reasons I like introducing young people to programming is there is a lack of ambiguity. In a programming class often the instructor and students are on the same side. The instructor is trying to help novices craft their code in such a way that the compiler can understand what they mean and so that the code meets the testable requirements.

Most of us have been rushing through code and used an assignment operator when we intended to test for equality. We don't hold the printout if ( oneThing = another ) up to the screen and say to the computer "you know what I mean." We grumble, find it, and fix it. With a teacher graded essay the student and the instructor almost oppose each other. The teacher says, "you weren't very clear here" and the student responds, "but you know what I mean." Often the teacher does know what the student meant to say and this makes grading all the harder.

Computers don't know what you mean. They only know what you wrote. Or do they? Google will often respond to a search by asking "Did you mean:". From time to time, they identify exactly what I meant to type in. From search engines to mail filters, applications have now made it easier for me to enter very complicated searches that they are able to parse on the back end. For human entered queries, the application needs to be able to parse the inexact, possibly incorrect, terms and create a useful query.

The latest java.net featured article is Erik Hatcher's second article on Lucene. In QueryParser Rules, Erik focuses on the capabilities and gotchas for Lucene's QueryParser. You may want to look back at his Lucene Intro for a review of building and querying an index. The QueryParser is used " to allow users to enter rich queries into your application. It is designed for human-entered queries. For queries that originate from your application code, it is best to use Lucene's Query API instead." In other words, the QueryParser is how your application knows what the user means.


Coding style comes up in the first of today's featured Weblogs . Vincent Brabant writes I want to continue to use my own style, even if I work in a team. He asks a series of questions including the issue that divides some development teams, "Why am I obliged to put open brackets on the same line than the declaration method, If I prefer the other style where I put the open brackets on the next line."

As anyone who works as part of a team or who is married knows, it is the little things that seem to lead to the biggest disagreements. I've learned the hard way not to say to my wife "what's the big deal, just ...". The same is true about trying to convince coworkers to change bracket placement or coding style. Vincent's solution is simple and avoids the conflicts over nothing (do not send me email that says "it's not nothing, it's important because ..."). Create two customization files for a source formatter. One version is the team's code convention and one is your own. You can then convert back and forth so that you are working with the code formatted the way you like and the team never needs to know.

Speaking of working in teams, Curtis Cooley blogs on the Principles of Extreme Programming. Curtis, like many experienced XPers, is not as focused on the practices as he is on principles. The practices support the principles and should be applied, but there needs to be a strong principle based foundation. Instead of insisting on all the practices all the time when introducing XP, he chooses "a different approach to bringing XP to an organization. I propose we offer the principles of lean software development put forth by Mary Poppendieck and Tom Poppendieck.

  • Eliminate waste.
  • Amplify learning.
  • Decide as late as possible.
  • Deliver as fast as possible.
  • Empower the team.
  • Build integrity in.
  • See the whole"

Curtis concludes that "the beauty of this approach is that you can ask the team to decide how to enable the principles. When it's their vision on how to make sure that the product has built in integrity, then you get more buy in to the process. Chances may be that they come up with the same practices that XP would have, but since it is their idea, they are more willing to do it. And they may even come up with better practices that no one ever thought of before. "

N. Alex Rupp seems to have too much time on his hands. In his latest entry Government (as it would be expressed in Java), he presents his take on a Government class. I wouldn't think that this class is best written in a language with automatic Garbage collections and other optimizations built in.


In Projects and Communities , the JavaDesktop Community links to John Kucera's JDJ article Making the Case for Client-Side Java. As John notes, corporations seem to insist on "a new software deployment paradigm in which software applications are downloaded from the internet and run within a Web browser, rather than being installed on each end-user's computer. This new paradigm significantly reduces the total cost of ownership of desktop computers in a corporate IT environment by eliminating the need to manually deploy new versions of the software."

Recently, John Reynolds blogged on an issue related to the core of this article in Field Validation Thoughts. In Kucera's article he writes "Today, most Web-based applications use HTML or dynamic HTML (DHTML) as means of interacting with the user. While a user interface that relies on HTML or DHTML is good for displaying information, it is much more limited when it comes to data entry. This is because HTML is primarily a request-response based screen-oriented protocol. In an HTML application a user must typically fill out all the fields on a form before submitting the form back to the Web server for validation."

He suggests, "The most promising alternative to DHTML is a Java-based client. Java can provide a much more interactive user interface because Java clients can provide field-level validation and can communicate with the server each time the user enters data into a field. The server receives the new input from the client, and responds by updating the application data on the screen. Unlike HTML or DHTML clients, Java clients do not need to layout the entire screen in response to each user input because Java clients can easily separate application data from the page layout." Notice the repetition of the word "can". All of these things are possible, if you code them in.

The Java Web Services and XML community is highlighting the relaxngcc project. The overview page describes how this "tool for generating Java source code from a given RELAX NG grammer" is different than Relaxer. The java.net project page explains, ""You annotate your grammar with Java code, and RELAXNGCC will turn that into full Java source code which you can use to parse XML."


In Also in Java Today , we remind you of tomorrow's Java Live: JDBC RowSet Implementations and JDBC 4.0. Sun Technical Staff Members, Jonathan Bruce and Amit Handa will be available Tuesday, November 11, at 11 A.M.-to-noon Pacific time (7 P.M.-to- 8 P.M. GMT) for an online discussion of the JDBC RowSet Implementations described in JSR 114 and the JDBC 4.0 API specification (JSR 221). The chat is a preview of coming attractions for J2SE 1.5.

In ONJava, Budi Kurniawan writes about Page Navigation in JavaServer Faces. He writes about centralizing the rules for page navigation in your Application Configuration file. He explains, "A page is represented by its tree identifier, and each possible target is represented by a navigation case. You need to specify a navigation rule for each page from which the user can navigate to another page."


In today's java.net News Headlines :

Registered users can submit news items for the href="http://today.java.net/today/news/">java.net News Page using our
news submission form.
All submissions go through an editorial review by news director Steve
Mallet before being posted to the site. You can also subscribe to the href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net News RSS
feed.


Current and upcoming Java Events:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e"> events submission form.
All submissions go through an editorial review before being posted to the
site.


This blog is delivered weekdays as the href="http://today.java.net/pub/q/java_today_rss?x-ver=1.0">Java Today RSS
feed. Once this page is no longer featured as the front page of href="http://today.java.net"> Java Today it will be archived at href="http://today.java.net/today/archive/index_11102003.html">
http://today.java.net/today/archive/index_11102003.html. You can
access other past issues in the href="http://today.java.net/today/archive/">java.net Archive.