Code Formatting
One of the things that bothers me most about working with other programmers is dealing with code formatting other than my own, and I have never had the patience to sit down and write all of the rules to format code just the way I want it. In normal Java or C/C++ source, I can deal with varying levels of whitespace and curly brace placement, but code formatting moves from minor annoyance to productivity killer when dealing with markup languages like HTML, JSP, or XML.
When working with markup involving open and close tags, the best method I've found to keep track of opening and closing tags is to consistently indent. This means that any enclosed tag is indented from its enclosing tags. We're all used to this in XML where indenting is usually fairly consistent, but let's look at a few examples where indenting can help prevent you from making mistakes.
Most programmers I've worked with enter the basic structure of a document as follows:
<html> <head> <title>Title</title> </head> <body> </body> </html>
More often than not, these same programmers frequently leave out the closing html or body tag. With a little indenting, it becomes much easier to spot problems:
<html>
<head>
<title>
Title
</title>
</head>
<body>
</body>
</html>
With this form, you immediately spot the problem when you have a gap in your closing indent sequence. Of course, I know there are tools that help you with this, but do you want to spend your time learning tools or coding? I prefer to code so I try to use a form that will let me spot problems with or without a tool.
Taking this a step further, you can see where this kind of code formatting really pays off:
<html>
<head>
<title>
Title
</title>
</head>
<body>
<table>
<c:forEach items="${list}" var="item">
<tr>
<td>
${item.a}
</td>
<td>
${item.b}
</td>
</tr>
</c:forEach>
</table>
</body>
</html>
Note how easy it is to see that any code printed in the forEach loop will be part of the table tag. I have yet to see a programmer indent their JSP/JSTL this way yet it makes it so much easier to read and maintain.
Here's another approach I use in the case of long code lines, especially when there is no closing tag:
<input type="submit" name="submit" value="Text of the Submit Button" onClick="return confirm( 'Are you absolutely sure?' )" />
When you write code, you have to keep in mind that all programmers are different. Some use GUI editors, some text mode. Some run at uber-geek, high resolution while others still run at 800x600 because it's easier to read. Keeping your code within a 78 character width often works best for everyone involved so finding ways to format to that width is important to productivity.
You can also take this approach into normal code:
return functionWithLotsOfParameters( param1, param2, param3, param4, param5 );
These are just a few of my methods of making code more readable while at the same time increasing productivity by reducing compiler errors, whether browser, JSP, or compiler. It may feel like it takes longer to format everything this way, but it pays off in the long run.
Posted at 04:16PM Jun 19, 2007 by Jason Koeninger in General |
The JDB Library
Over the years, I've written a lot of code, but no piece of code has kept my interest like the B-tree implementation I first wrote for a college file structures course. At Oklahoma State University, building a working B-tree was a bit of a rite of passage for all Computer Science students. Sad as it may be, few were able to accomplish the feat. But me? I was hooked. It seems like I coded solid for a couple of days to build the initial B-tree without delete support and spent another day implementing delete. As it turned out, I messed up one rotation in delete, but it just meant the tree was in an underflow condition on a page, not out of order.
During the initial R&D phase for Shepherd while trying to build a data store for the directory, I experimented with Sybase SQL Anywhere, DB2, and even OpenLDAP. Unfortunately, none of them measured up to the combination of speed, ease of installation, and porability I wanted. Sybase was easy to install and came with royalty free runtime licenses, but for directory data, it was slow. DB2, speed demon that it is, was just too expensive and too painful to install in this situation. OpenLDAP worked okay, but it forced Shepherd users into running some kind of Unix box since it wasn't portable to OS/2. At the time, the primary target platform was OS/2 so OpenLDAP wasn't an option. With no other viable alternatives, I set out to write my own data store.
Creative in naming as always, the JDB library was born. The initial version drew on features I liked from Sybase SQL Anywhere and disliked with xBase databases. All data was stored in a single file. The goal with this approach was simplicity. Having supported xBase databases in past projects, getting someone to zip up a set of 30 .dbf and .cdx files was a serious pain. Even though Shepherd users would be more technically adept, it still would be easier to ask for just one file. While this early version of JDB worked, it suffered from its lack of support for transactions and logging. Power outages and software crashes frequently destroyed the database requiring a rebuild from an LDIF import file.
So, a major rewrite took place to add transactions and logging and clean up the code. The end result was a faster JDB library with a more professional disposition. Over the past few years, I've been slowly debugging the code so that I can talk about uptime in months instead of weeks. As of last month and with the help of Mac OS X and its development tools, I was able to find two bugs which were capable of corrupting portions of the B+Trees within the data file. Now, I am cautiously optimistic that our uptime will soon be measured in years.
How does JDB work, you ask? Glad you did. It may not be as elegant as some would like, but it gets the job done.
JDB does not work with a row or column metaphor. Instead, it works on data as a whole. As such, it might be more appropriately called an object database. Instead of rows, it includes an interface with a simple set of read/write functions not unlike Java's Serializable interface. Applications wishing to use JDB as a data store implement these two methods for any class they wish to store in JDB and then use the API to create the database, create tables, store data, commit, rollback, etc. There is no SQL interface, but one could easily be added by creating a "row" data type with the appropriate supporting SQL language tools.
So here I sit with a transactional storage engine with commit, rollback, and crash recovery capabilities. The question I keep asking myself is what should I do with it, if anything? Should I implement a MySQL storage engine and go up against InnoDB? Given the recent uncertainty, it doesn't seem like a bad idea. Should I open source it as a general library and see if anyone has any interest in it? Unfortunately, either of those options carries with it the weight of time required to comb through source for release and potentially remove lower-level libraries we don't wish to open. It's not a competitive or licensing issue in those cases but more of a code quality issue. Some of our core library dates back to my first few years of programming. As such, the design of the code is very poor and would reflect badly on the company if open sourced.
If you have any ideas, please let us know.
Posted at 12:54AM Dec 14, 2006 by Jason Koeninger in General | Comments[1]
Launch of JJCC Blog
JJCC is finally launching a blog to replace the archaic, manual html writing we had been doing to create news, articles, tips, and other information. Hopefully someone will find some use for the information presented here. Posts prior to this post are reposts of content already published on our site.
Posted at 02:41PM Dec 06, 2006 by Jason Koeninger in General | Comments[0]