Here are a couple of quick links to articles to the Joel on Software site:
Alvin Alexander | Java, Scala, Unix, Perl, Mac OS X
I've been working on a document for one of my customers named "Use Case Best Practices", but then I decided to search the Internet to see if I could find anything similar to what I was thinking.
The best thing I've found is this Coad Letter on Borland's web site. There is enough meat here that I'm scrapping my plans and just suggesting they read that document instead. Kudos.
The checklist provided below isn't ready for prime time, but I wanted to make sure I put a copy of this information somewhere. Basically, I have started to create a checklist of detailed items I need for user interface screens when creating a detailed design specification. So, what I've started to do is list all possible user interface field types, and what features of each interface element that can vary.
Frankly I'm not sure if this is a good idea or not, but if you're into heavyweight processes, this information is certainly needed by someone at some point.
One of the things I learned (or was reminded of) is that -- properly done -- Use Cases really bring out some state-related issues that you can't get from plain old requirements.
I'm working with a client on fixed price software development (and have been doing so for nearly two years now), and this brings a lot of risk to my side of the table, so I'm very careful that we all understand exactly what's being developed.
Here are two quick links to free programs that I've used to convert Microsoft Word documents (aka, ".doc" files) to plain text:
I just started using catdoc today in combination with glimpse, and I'm pretty happy with it. Note that catdoc also includes an XLS to CSV converter, which is most helpful for my current project.
JBuilder has a nice feature that I've started using lately to track "to do" items. These are the places in my Java projects where I know that I need to fix or change something, but I just don't have the time to do it at the moment. So, what I do is create a "todo" Javadoc tag that I can use as both a reminder and a management tool. Here's how it works:
Don't like your curly braces at the end of the line? Rather have them on the next line? What about your block indentation, your else's, your while's, and your catch's, implements, extends, and throws? How about those import statements, and what about that line wrapping?
Problem - the CSV file
You have a file that contains columns of data, and each column is separated by a comma (a CSV file). The width of each column can vary, but the column data is guaranteed not to contain any columns itself, so it's safe to think of the comma as truly being a column separator. So, how do you read the data?
Solution - the Perl split function
Okay, so what you're saying is that you have CSV file data that looks like this:
I've finally finished creating my first two JBuilder OpenTool projects. They are very simple, but time is scarce, so the development process was drawn out. Here are quick links to the two tools:
Keith Wood has written a book about the JBuilder OpenTools, appropriately named "Inside the JBuilder OpenTools API". Here is a link to his site, and here is an even more direct link to the JBuilder OpenTools code samples he has on his site.
Tools | Preferences, and then when the resulting
Preferences dialog shows up, choose
Browser in the tree on the left
hand side of the dialog, then
Look & Feel. In the Look &
Feel combo box on the right you can choose from the following options:
Here's a link to the Java API doc for how to set a mouse pointer/cursor shape to one of the predefined shapes. It's amazing how bad the memory gets ... here's a link to an article I wrote a long time ago about "How to turn the Java mouse cursor (pointer) into an hourglass".
I've been using JBuilder X Foundation a lot lately. I've had to do a lot of prototyping for a current project, and as far as I've seen JBuilder has the best JFC/Swing generating tools around, bar none. So, I ditched an attempt to start working with Eclipse and I went back to the free version of JBuilder, and I haven't been disappointed.
Here is a quick dump of JBuilder-related bookmarks I added to my personal collection last week. These are all related to Open Tools, and more recently how to build JBuilder applications using Ant.
Here's an example of how to add a JPopupMenu to a JTable. The purpose of the popup menu is to let the user right-click on contents in the table and work directly with those contents.
In the code below I've taken a real class and trimmed it down considerably for these demo purposes. I hope the code remaining is useful enough to help you implement your own JPopupMenu on a JTable, or perhaps in other components as well.
Here's an example of some code where I'm detecting when a user selects a tab in a JTabbedPane. There are pretty much just three important pieces of code, and I've labeled those with comments and the numbers 1, 2, and 3.
Here is a quick example of how to set JTable column widths. I don't know if this is a perfect solution, but it is one possible solution:
Help, I need to install a Perl module, and I need to know what my Perl "include" path (library path) is?
Here's a simple way to print your Perl include path from the command line:
perl -e "print qq(@INC)"
You can just run that command from the Unix/Linux or DOS command line. The output I get from this command on my Windows PC looks like this:
C:/Perl/lib C:/Perl/site/lib .
The output I get on a nearby Linux server looks like this:
Summary: This is a brief discussion about how to debug a JBuilder OpenTool. Debugging an OpenTool is not at all like debugging normal Java code, and a special technique is required, specifically starting one instance of JBuilder from an existing JBuilder environment. These notes apply to JBuilderX, and may not work for other versions.
Here are a couple of quick tips related to the development of JBuilder OpenTool's. I just started working with the JBuilder OpenTool API this weekend, and it seems relatively easy to get a handle on.