November 19, 2007 by tmalaher.

This has been one of my concerns all along.

The claim is that “enough testing” will eliminate the need for the compiler to do static checking at compile time.

http://www.artima.com/weblogs/viewpost.jsp?thread=217080

Frank Sommers seems to be saying otherwise… in the long run.

So, I’m feeling justified in my decision to stick with Java, where I gain maximal benefit from IDEs and compilers.

Posted in Practice, Software | Print | No Comments »

May 3, 2007 by tmalaher.

I’ll be presenting at the May 9th Meeting of the Calgary Java Users Group.

See you there!

Powered by ScribeFire.

Posted in Software | Print | No Comments »

March 29, 2007 by tmalaher.

When I was presenting to the Calgary Java User’s Group about Building your own search engine, the topic of Egothor came up. I’ll have to check it out. See my previous comments on searching email.

Powered by ScribeFire.

Posted in Software | Print | No Comments »

March 29, 2007 by tmalaher.

With the advent of Sarbanes-Oxley, it seems everyone is hot to start changing their passwords on a regular basis. This is enough of a problem for people, but when systems need to use passwords to get things done automatically, it turns into a nightmare.

I started putting together a specification for a password “lockbox” that would handle this. It would have to be able to handle standalone machines that were their own security domain (e.g. Unix with local passwd file) or a group of machines that share the same password (e.g. NIS or AD). It would be nice if you could encode the password expiration policy and have the system automatically change the password for you so it wouldn’t expire. You’d want sophisticated ACLs to control who can see which passwords.

Yesterday I went to a presentation from a company about a product of theirs that seems to cover all of this and more: Cyber-Ark’s Enterprise Password Vault.

It’s not cheap, but on the old build-versus-buy continuum, I think this is one I’d rather buy.

Posted in Tools | Print | No Comments »

March 19, 2007 by tmalaher.

QueryForm: a Swing-based Java tool for editing database tables.

For those times when you just don’t want to write a CRUD interface or use raw SQL. DbVisualizer’s “Update where” and “Insert into” functionality is OK for one or two rows, but this tool lets you edit many rows almost painlessly.

powered by performancing firefox

Posted in Tools | Print | No Comments »

March 19, 2007 by tmalaher.

DbVisualizer: essential tool. I practically live in it. I have it open all day every day. I use it for ad-hoc reporting, quick updates, and to build up, debug and validate the queries I put into my software. It will connect to anything that has a JDBC driver.

One of the features I’ve used is the charting of foreign-key relationships to build a cube-wall sized poster of the data model for a product we installed. I pasted together 9 letter-sized sheets (the product knows how to print the huge image in segments). Life saver.

I use the free version, and I’ve even tried out the “personal” (i.e. for-pay) version on a trial license for a while and the graphing capability was pretty fun too, but I have other ways to do that and so didn’t go for it.

powered by performancing firefox

Posted in Tools | Print | No Comments »

December 5, 2006 by tmalaher.

My editor of choice, when not using an IDE like NetBeans:

jEdit - Programmer’s Text Editor

Features:

• It’s written in Java so it’s cross platform
• It has a million plug ins that do useful things
• Free, open source.
• It has a nice XML/HTML editing mode that does “code completion” on tags and attributes, and gives you a tree view and validation error list.
• It has syntax coloring for more computer languages than you can shake a Turing Machine at.
• It can even compile and run code from within the editor, so if you don’t have an IDE, you can turn it into a poor-man’s one, or use it for languages that don’t otherwise have an IDE, like Perl.
• It can remotely edit files over [S]FTP.
• There’s CVS integration (…note to self: check for Subversion integration…)

powered by performancing firefox

Posted in Tools | Print | No Comments »

December 5, 2006 by tmalaher.

Here’s a tool I really like, for editing XML files, especially ones that have useful “human readable” representations, like XHTML:

XMLmind XML Editor

Features:

• There’s a “free” version (lacking some features). Professional version isn’t unreasonable for a single seat.
• Written in Java so it’s cross platform
• You can easily create new templates for new XML schemas (just create or point at a DTD and a CSS stylesheet from a valid, minimal, but otherwise empty XML file conforming to the DTD)
• Has a plug-in architecture, and there are a few plugins you can get right from their site, as well as write your own.

I find myself using it to edit XHTML, DocBook and other XML file types (e.g. DITA).

The advantage over something like JEdit is that rather than telling you when you create invalid markup, it won’t let you create invalid markup. And it certainly won’t let you create non-well-formed markup. (If the preceeding distinction isn’t clear then read the definitions of well-formed and valid.)

powered by performancing firefox

Posted in Tools | Print | No Comments »

June 21, 2004 by tmalaher.

The group I’m in here at a major telecommunications provider has a nice little setup of HP’s OpenView and Remedy’s Action Request System.

OpenView listens for and seeks out problems with various internal
and customer-owned systems. When something serious occurs, it uses some
3rd party integration software (RemedySPI) to create a trouble ticket
in Remedy. Rules fire to assign the ticket to an appropriate “triage”
person. Notification is then sent to the assignee by email or text
pager, depending on the severity of the problem. There is a POTS modem
plugged into the Remedy box that is used to send text pages, and the
Remedy box is allowed to make outgoing SMTP connections to the Internet
to deliver e-mail.

Remedy and OpenView are linked so that closing the ticket removes
the corresponding event in OpenView, and the OpenView event is
annotated with the Remedy ticket number.

Both use an Oracle database to store information about tickets and events.

Each system (Remedy, OpenView, Oracle) runs on a separate piece of Sun hardware.

So we have 3 single-points-of-failure that could cause notification
of critical events to stop: Openview (the software, or the hardware
it’s running on), Remedy (likewise) or Oracle (likewise).

Additionally, failure of a single 100baseT switch or switch port would sever connectivity and take out the notification system.

I’d like to set up something that would detect a failure of one or more of the three critical systems, and notify someone.

Obviously this backup notification system has to be independent of
the three in question. So it should run on some 4th piece of hardware
which is plugged into a different switch. It would then poll or look
for heartbeats from the 3 systems, and use it’s own resources to notify
someone of a problem.

As far as I can see it would be OK if this backup monitoring box
used the same Internet connection, since e-mail is only used to deliver
lower-severity notifications, and a loss of Internet connectivity would
be a Critical-level event, which would use the POTS line to deliver the
notification.

The main monitoring system would then be set up to monitor the backup system, to make sure it’s running.

So… finally, to the question:

What software would you use to set up this monitoring/notification
system? Obviously one could install a completely parallel set of
[OpenView, Oracle, Remedy], but that would be overkill, as we only need
to monitor 3 machines and a few daemon processes.

Is there some nice Open Source project out there that would allow me
to quickly solve this problem? Has anyone done something like this? Any
comments on my failure-mode analysis? Am I worrying about the right
things?

Comments

Posted in Practice, Software | Print | No Comments »

June 7, 2004 by tmalaher.

Sometimes a vendor supplies a command-line utility for performing some function that we want to use from within our scripts and programs.

There are some unwritten (at least as far as I can find) rules about how to write one of these utilities so it can be used properly.

Some vendors get this right. Others, not so much…

The Rules

Return an error status indicating success or failure. For bonus points, return multiple different error codes depending on what went wrong. (The Anna Karenina Principle)

And you know what? That’s about it. The rest (arguments, input/output locations, etc., etc.) really depends on the context and function of the item in quesiton. Though the following are useful:

• Provide a useful usage message if invalid arguments are passed.
• Provide an explict way (e.g. –help option) to ask for the above usage message.
• Use GNU-style arguments.

But these are really for human consumption, not for use in a script.

Recent Failures

I won’t name names, but here are some of the failures I’ve seen recently. (And these are from Big Companies that should know better. Including one company that actually has its own version of Unix… they should really know better.)

• utility always returns status 1. How the HECK am I supposed to know if it worked? Why are you always returning failure? Didn’t you read a single Unix man page? Didn’t you notice that non-zero exit codes mean failure?
• -q option suppresses error messages to stdout/stderr… and suppresses the error code return as well. Take a look at diff(1) sometime. The -q option just suppresses the listing of the differences, but still returns the error code.

Strangely enough, these rules apply equally well to Windows command-line utilities. Yes, these do exist.

Another suggestion

If it can be done with a command-line utiltiy, then give us an API we can use.

If you even just create a simple C library, we can then wrap it into our favorite language as a Perl Extension Module, or a Java Native Interface (JNI) pacakge.

If you feel like creating a pure Java implementation of the Library, that would be good too.

From Dan Moore:

On a different tack, but still touching some of the same principles, you may want to check out the Command-Line Options section of the Art of Unix Programming

Originally Posted June 7, 2004 11:20 AM

Posted in Practice, Software | Print | No Comments »