In my previous blog post, I demonstrated how to remove the annoying template instruction comment added to all NetBeans-generated files. Peter Hull pointed out that one could also use this for a license as documented in Geertjan's Blog in the post Project-Level License Settings in NetBeans IDE 6.0. Although I generally don't need to include the license in the source code of software products I work on, this can be a useful feature for those that do.

The easiest way to apply one's own default template for licensing is to simply edit the default one that is used when you create a new NetBeans-generated source file. This is done by using the Template Manager which is accessed in NetBeans via the Tools->Templates menu. This is demonstrated by the next screen snapshot.

One can select the "Default License" and click on the "Open in Editor" button. When this is done, the initial text will include the comment that is all over the web about using of templates. However, the next screen snapshot demonstrates how I have changed its text.

With this template in place, I can generate a new class or interface or other source code artifact to test it out. In this case, I generated a class via NetBeans's class generation wizard. The generated class, with my altered license information, is demonstrated in the next screen snapshot.

The above examples demonstrated changing the default comments included in each generated source file by changing the "Default License" template as opposed as to removing it altogether as I showed in my last blog post. Removing reference to the license altogether or changing the "Default License" are the easiest ways to deal with this.

As Geertjan's post demonstrates, NetBeans has supported the ability to add custom license as well. In the first screen snapshot in this post, there are other licenses already available (such as an Apache 2 license) and one can generate custom licenses. Doing this involves coordination between a property called project.license in the nbproject/project.properties file and the reference to that file in the Templates Manager under the type of source file. For example, the Templates Manager entry for a "Java Class" contains this line:

<#include "../Licenses/license-${project.license}.txt">

As would be expected, the ${project.license} placeholder is replaced by the value that the property project.license is set to in the nbproject/project.properties file.

Caveat

As of this writing, I am having difficulty with custom licenses. When I set the property project.license=dustin and create a license template in the Template Manager named license-dustin.txt to match the format specified in the template for new Java class source code, the comment I get in a generated Java class file is "Error reading included file Templates/Classes/../Licenses/license-dustin.txt". I get this whether I try to select a file from the file system or "Duplicate" an existing license template and "Rename" it. Editing any of the pre-existing license templates provided with NetBeans 6.8 seems to work fine. This is the subject of a NetBeans Forum thread Topic 11600.

There is one significant disadvantage to simply editing the "Default License": this will affect all new source files regardless of project. The advantage of specifying the license file via the project.license property is that this is set on a per-project level. However, as I stated, I cannot get this to work properly at the moment.

Conclusion

I generally prefer to simply turn off the auto-generated comments at the top of my source code files either by removing reference to them altogether or by editing the "Default License" to be empty. However, if one wants a custom comment, such as license information and/or contact information in the top of source files, NetBeans supports this through the license templates.

Yesterday I ran across one of those blog posts that made me realize that I am not the only one with a particular pet peeve. In this case, Emilian Bold addressed my pet peeve about developers leaving the NetBeans-generated template instruction comments in the code. In the blog post The Default NetBeans IDE Java Source Template is Polluting the Web, Emilian provides a Google query that illustrates that there are over 314 thousand (occurrences of the key string he provides). As a side note, it is interesting that 314 thousand is the number of occurrences on Pi Day.

The commented-out instructions that automatically appear in NetBeans-generated source code files looks like that shown in the next screen snapshot.

The text states:

/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/

I see these annoying comments checked into the source code of projects I have worked in which NetBeans has been a heavily used IDE, but I was surprised to see how many people have made source code available on the web with these comments still there. I dislike these so much that I will check a file out of the source code repository, remove these lines, and check the file back in. Emilian's post points out that I'm not the only one that finds these annoying (he calls them a pollutant, which I think is a good description for them).

Emilian points out that NetBeans includes this in source code automatically in an effort to help developers learn how to better use the IDE and customize it, but adds: "This might sound like a great idea in practice but it's broken since most people won't change it." It is my opinion that this is the crux of the problem for this case in particular and for this category of things in general (one of the people commenting on Emilian's blog points out that Eclipse has similar features). I don't mind so much that the IDE includes these comments, but I cannot understand why one would leave them in place when checking in the code. Emilian suggests some alternative approaches that might be preferable to including commented text in the generated classes, but I'd be happy just to see end user developers remove these lines as an easy fix.

NetBeans's generation of Java servlets provides more specific automatically generated comments to help the developer working on a new piece of code. The next screen snapshot shows a method called processRequest that has a simple example implementation provided in comments. This is shown in the next screen snapshot:

Here is the generated code shown in the above screen snapshot.

/**
* Processes requests for both HTTP GET and POST methods.
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
try {
/* TODO output your page here
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet SomeServlet</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet SomeServlet at " + request.getContextPath () + "</h1>");
out.println("</body>");
out.println("</html>");
*/
} finally {
out.close();
}
}

I don't see many developers leaving the above generated code in place. This seems reasonable, but I wonder why this is different than the template instructions at the top of the source code which often do get left in place even as the code is checked into the source code repository.

Since getting serious about developing web applications with REST principles in mind, I often find myself not wanting NetBeans to automatically generate servlets that have the @doPost and doGet methods automatically call a single method (processRequest in NetBeans 6.8 as shown above).

The generated servlet code contains doGet and doPost implementations as shown in the next code listing.

/**
* Handles the HTTP GET method.
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}

/**
* Handles the HTTP POST method.
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}

It's been a Java servlet tradition for several years to have these methods do the same thing, but the rising popularity of REST has reminded us that the HTTP methods GET and POST are actually very different things despite what the web browser might tell you.

Fortunately, NetBeans makes it really easy to change these templates. How does one do that? That is where that comment that typically annoys me so much when left in managed source code actually comes in handy. That comment told me how to do it: "To change this template, choose Tools | Templates and open the template in the editor." I can change the template for the servlet under "Web" in the Tools->Templates wizard. There I can remove the commented out text and even change the behavior of doPost and doGet so that they don't call processRequest anymore (and I can remove processRequest altogether).

What if you wish to remove the comment about how to edit templates? That is done by changing the template of choice (such as the template for Java Class, Java Interface, or Java Servlet) and removing this line:

<#include "../Licenses/license-${project.license}.txt">

Once you save the template with this line removed, that text will no longer appear in files created based on that template.

The longer I develop software (and more specifically the longer that I refactor and maintain existing code), the more I realize that I want my code base to be lean. I loathe dead code and useless comments (as opposed to useful comments). It is nice to be able to work with the NetBeans template mechanism to remove some of these automatically inserted pieces of code before they even have a chance to get saved in the code repository.

One of the presentations I enjoyed at Rocky Mountain Oracle Users Group (RMOUG) Training Days 2010 was Stephen Jackson's presentation "Using SQL to Generate SQL." I have used some of the techniques he discussed in his presentation to have SQL generate SQL, but one thing I had not thought of doing was to use the CHR function to make scripts more readable. Although this post focuses on using Oracle's CHR string function implementation, other databases support the CHR (or CHAR) function as well.

One example of the usefulness of CHR is in the creating of results that include characters that are significant in the query itself. Using CHR appropriately allows the SQL developer to avoid the need to escape these characters with query syntax significance. For example, to print the last names of employees in Oracle's HR sample schema with single quotes surrounding the last names, one could write a query like this:

select '''' || last_name || '''' from employees;

The four single quotes successfully escape the quote mark both before and after the last name. Unfortunately, it can become easy to get lost in the quotes, especially for more complex queries. Because the ASCII decimal code of 39 produces a single quote when passed to CHR, the expression CHR(39) can be used instead as shown next:

select CHR(39) || last_name || CHR(39) from employees;

For me, this is more readable. Similarly, even more difficult characters can be represented with the CHR function. For example, Stephen pointed out in his presentation that CHR(10) can be used to have a new line printed in the output.

One of the interesting ideas that Stephen discussed was use of a simple script to display the various character representations available via the CHR function. One can always reference a resource like Tech on the Net's ASCII Chart or asciitable.com, but it is interesting to simply display the representations via code:

-- displayCHR.sql
--
-- Display the characters associated with basic and extended ASCII codes.
--
SET head off
SET pagesize 0
SET linesize 120
SET trimspool on
SET feedback off
SET verify off

SET serveroutput on size 5000
BEGIN
FOR i IN 32..255 loop
Dbms_output.put_line(i || ' ' || chr(i));
END loop;
END;
/

The above snippet of code, when executed in SQL*Plus, will display a large number of the characters available in the basic and extended ASCII character set. One can use the spool command to spool the output to a file. On my Windows-based machine, I was even able to view these generated symbols in the spooled output file using the basic Notepad application.

Conclusion

As Stephen pointed out in his presentation, the CHR function can make SQL*Plus scripts more readable and maintainable.

Paul Murphy's one of those tech writers who's been around the industry forever, and while I don't always agree with him, I do find a lot of what he says thought-provoking. On Saturday he posted an interesting and kind of grim take on Java's place in the software ecosystem. If I can sum it up quickly, it goes something like this: Java's greatest advantage, historically, was that its virtual machine shielded developers from the irritating shifts at the OS level, mostly from Microsoft. The original aim was to realize this advantage on the desktop, in practice that happened almost entirely on the server. Java became so good at that, in fact, that it survived despite being "an almost perfect reflection of the problem it set out to solve in the form of the most absurdly over complicated and generally unmanageable code metastasis outside Microsoft’s own Windows source."

Murphy's argument is that Oracle's long-term plans as stated will tend to devalue Java -- not because they hold specific malice towards the platform, but because, as they work to standardize and improve the OS/hardware combo they're acquired, that layer of abstraction becomes less and less necessary. Personally, it's not that convincing to me -- I think Java as an ecosystem (both of programming skills and available code modules) has become to pervasive for there to be some kind of headlong rush back to C even on Oracle's perfectly tuned appliances -- but it's an interesting look at what exactly Java is good for from someone outside the community.

Speaking of provocative things posted on ZDNet, last week also so an interesting piece from Jeremy Allison (of SAMBA fame) on Sun's (ultimately bad) attitude towards open source. Most of what he discusses is his personal experience with Linux kernel hacking for SPARC, but much of the same vibe might be attached to the company's schizophrenic, yes-we-will-no-we-won't-OK-we'll-do-it-in-this-convoluted-way road to open sourcing Java.

A colleague recently asked me, "Have you noticed that the better developers we've worked with are also fast typists?" I acknowledged that I had noticed relatively quick typing speed to be a common trait of most of the best developers that I know. It also made me think of the Jeff Atwood post We are Typists First, Programmers Second and the Steve Yegge post Programming's Dirty Little Secret.

I do know a few exceptions where a particularly talented developer is not even in the top half in terms of typing skills, but it is the rare exception. The majority of the best developers I've had the good fortune to work with are in the "top half" in terms of typing speed. I am a strong believer that good software development is much more than just hacking some code. So, I in this post, I look at the correlation between the ability to type rapidly and the likelihood of being a successful software developer.

It goes without saying that a fast typist is not necessarily a good developer. I've never seen (other than on television) anyone type faster than my mom. She had been an administrative assistant (called secretary at the time) for several years. This experience combined with an obvious knack for the skill had led to her typing 120+ words per minute with few or no mistakes (on typewriters no less). She was not a software developer.

Although it is true that typing is a big part of the software developer's job, so are many other things such as understanding customer needs, coming up with architectures and designs that feature the most important -ilities, working on teams, knowing language syntax, understanding various third-party products and frameworks, and so forth. Typing is clearly a big part of most software developers' daily routine, but what makes it seem to be so highly correlated with the most successful software developers?

We Do Well What We Do Often

In many ways, the correlation between typing and software development success is not so as much about faster typing leading to a better developer as it is about faster typing being evidence of countless hours spent with the keyboard writing code. In other words, it is not necessarily that faster typing makes the developer better or more efficient (though it obviously cannot hurt) as it is that the great developer is a fast typist simple because that developer has spent so much time coding (and learning to be a better typing as a pure side effect of those many hours). One could make the argument that becoming experienced and accomplished in software development makes one a better typist rather than making the argument that being a better typist makes one a better developer.

I have noticed that my fastest typing comes when I type the same thing over and over. What this means is that I end up being very quick to type things like build commands, database/SQL commands, application server administrative and deployment commands, configuration management commands, and the like. The things I do everyday are the things I do most quickly.

Efficient Typing Allows Time for Other Things

One advantage that faster typists have compared to developers with lesser typing skills is that less time spent typing in characters means more time doing the many other things that good software developers do: scripting routine tasks, writing and running tests, documenting for users and maintainers, learning new things, writing e-mail messages, writing blogs, etc. In an almost recursive fashion, many of these tasks that can have more time dedicated to them because a developer was able to type code more quickly are themselves beneficiaries of better typing skills as well.

Efficiency of Typing can Lead to Perceived Faster Typing

One of the interesting characteristics I've observed in many of the best developers I've worked with is their ability to take advantage of many different key strokes, macros, and other devices to accomplish the same task more quickly. Although just about every developer I work with these days uses an IDE, it wasn't all that long ago when certain developers could make the (truthful) argument that they could write and develop code more quickly in their simple text editor than most developers around them could with the IDE.

For the smallest of projects, I still find myself sometimes using these simple tools when the IDEs or other more advanced tools just feel unnecessarily heavy. I have amazed some people around me with my perceived vi prowess, but what they don't realize is that I'm really an amateur compared to some of the vi skills I have seen others possess. When these developers combine a powerful IDE with a vi emulator, it can be dizzying trying to watch them in action.

Some of the fastest developers I have worked with complement their own typing speed with knowledge of and familiarity with their favorite tools. This is often seen in the world of IDEs where a developer who knows the IDE well can take advantage of all types of different features to developer more quickly and accurately.

Fast Typing is an Inherent Advantage in Some Aspects of Software Development

Although it can be argued (as I did above) that fast typing is a side effect or consequence of years of inadvertently practicing typing while writing code, there is no question that some areas of software development are prone to benefit from faster typing. It is obvious that a fast typist has advantage when getting his or her thoughts into code, though I have seen that advantage at least partially mitigated by IDE code completion and other features.

Writing original code is an obvious area where faster typing is an advantage. Faster typing is also an advantage, however, for the person doing refactoring outside that supported well by the IDE. Faster typing might make a developer less concerned about having enough time to write that one last test he or she feels would be nice to have.

Typing is Not Writing

One of the areas where the correlation between fast typist and great developer breaks down most is when typing without creativity is considered. Developers' typing is more like authors' and reporters' typing and less like administrative assistants' typing and stenotyping. By this, I mean that a developer typically must insert his or her own creativity and thought into what he or she is typing. Rarely is the developer asked to simply type up some pseudocode or other previously dictated implementation. What this can mean is that the raw speed of typing may be not quite as important as it would be if typing up what someone else was saying or writing because some time is spent in that thinking.

Conclusion

It's not all that surprising that, at least in my experience, that the better developers generally tend to be faster typists. The correlation between productive developer and typing skills seems to enjoy somewhat of a causal relationship from both sides. Being a better developer as a result of years spent toiling over a keyboard writing code cannot help but make one more efficient with the keyboard. From the other perspective, faster typing skills help a developer to get more done in the same amount of time. As with just about everything in life and especially in software development, there are exceptions. I do know of some really good developers who are probably not in the top half of typist abilities, but they are the exception. Most of the best developers I know are also better than average typists. The good news is that developers can practice both at the same time. As one writes code, one also practices typing.

Additional References

⇒ Programming's Dirty Little Secret

⇒ We Are Typists First, Programmers Second

⇒ Speed Chess

⇒ Stack Overflow: Should Programmers Be Excellent Typists?