Just the other day I decided to change my password for an important online account to a secure one generated by KeePass, the free, portable and cross-platform password safe. It almost ended in a very bad situation when the program (which is otherwise an excellent one) decided to crash right after I had added an entry for the account, but before I had saved the database… and just after I had logged out of the account! Argh!

My online banking site doesn’t seem to have a simple way to reset the password, which is probably a good thing in retrospect, but… it’s a weekend so calling the bank was out of the question. After a few moments of panic, however, I realized that I had used KeyPass’ automated keylist generator a few days back, which meant the password was still there. The only thing lost was the account association, and — phew! — I was able to log back in with the first unnamed password from the list.

So obviously, I’m convinced that utilizing the keylist generator serves more purposes than one. If you haven’t done so, save yourself a potential headache:

Select Tools > Generate Password List… from the main window.

Set the length and characterset for the generated passwords, and click OK.

Enter the number of passwords to generate.

To add a site, edit the next blank item from the list along with its random, pre-generated password.

The later versions of Eclipse (I believe 3.4+) have migrated the menu system for plug-ins from using the antiquated actionSets to org.eclipse.ui.menu’s, commands, and handlers. Using an ISourceProvider, the state of your plug-in’s menu items can be managed dynamically; something that was rather painful to do with the old actionSets (when instead it was necessary to wait for the action to be invoked in order to get a handle to its IAction). There’s a great set of tutorials on the newer technique here and here.

In the process of migrating my plug-in to the new system, however, I came across a bit of trouble enabling and disabling the items. Seemingly, setting the “enabledWhen” flag for the menu items wasn’t working. Here’s the sample XML for the extension (can you spot the problem?)

<!-- Managing the UI state (enabled or disabled) of the menu item is accomplished by setting the 
variable referenced below within a class that extends ISourceProvider. -->
<extension point="org.eclipse.ui.services">
	<definition id="com.example.SampleItemSourceProvider">
		<variable name="com.example.SampleItemState" priorityLevel="workbench" />
	</definition>
</extension>
 
<!-- Menu item definition -->
<extension point="org.eclipse.ui.menus">
	<menuContribution locationURI="menu:org.eclipse.ui.main.menu?after=additions">
		<menu id="com.example.menuitem1" label="Example Menu Item" commandId="com.example.command1" <!-- Defined elsewhere --> >
			<enabledWhen>
				<with variable="com.example.SampleItemState"><equals value="stateEnabled"></equals></with>
			</enabledWhen>
		</menu>
	</menuContribution>
</extension>
 
<!-- Handler definition -->
<extension point="org.eclipse.ui.handlers">
	<handler class="com.example.MenuItem1Handler" commandId="com.example.command1" <!-- Defined elsewhere --> >
		<activeWhen>
			<with variable="com.example.SomeOtherVariable"><equals value="stateActive"></equals></with>
		</activeWhen>
	</handler>
</extension>

So as a note to self in case I forget (likely!), apparently an inactive handler is enough to override the enabledWhen flag of a menu item, which occurs when they are not managed by the same variable (or kept synch’ed). The opposite is also true. It’s easy to forget about those tricky handlers when they don’t define the actual menu item but are merely associated with them.

This summer, I’ve learned an incredible amount as an interning software engineer. Although it has certainly been informative in a technical sense, one of the things that I am growing to appreciate in greater depth is the emphasis on improving the process itself in which I have traditionally programmed. My company, like many other companies which practice agile development principles, stresses the importance of proper coding habits such as code reviews, team transparency, sensible object orientation, Test Driven Development, and so on — pretty much the textbook pragmatic programmer stuff, at least in the ideal.

Admittedly, none of these have come particularly easy. Each concept introduces an additional learning curve  on top of the hard, technical concepts that are necessary to make satisfactory progress during the day. Add to that the pressure of having a clearly defined task but only a limited interval in which to accomplish it (read: summer employment woes), and the temptation to forgo the ideal in favor of what’s more efficient is even stronger. But we all know that early “efficiency” can lead to a nightmare down the road, in terms of code quality, stability, and maintainability. So wherein lies the balance?

I’d like to use TDD as an example here, though this problem extends to many other coding practices. It is a practice that has, in my very limited experience, been particularly difficult to convince myself that a) the initial investment pays off; and b) having conceded the first point, to apply the technique effectively. For myself, adaptation of TDD has been rather evolutionary; however not in the sense that I don’t fully understand the importance of testing — rather, in the idea of development being driven by tests that you write. For those that need it, here’s a quick recap of the process:

1. Write a test that prototypes the functionality you wish to achieve. This forces the developer to think of the overall architecture before any code is written that, had it been written beforehand, could influence the developer’s willingness to make design change decisions.
2. Run the test. It might (and probably should) fail.
3. Write the minimum code necessary for the test to pass.
4. Repeat, refactoring as necessary.

So… it took me a while to realize the power of testing (and as a side note, how using proper design techniques like MVC and its derivatives make it a much less painful process). I learned this partly from hearing it evangelized so heavily at work, and to some degree the hard way from the first implementation of GCast. Always present is the tension of how to balance “perceived” productivity (i.e., what’s tangible that you produce), and the satisfaction of knowing you did things right.

I’m convinced that this boils down to three elements: efficiency, quality, and sanity. Sanity because testing is, um, boring.

But from here it gets tricky: in rewriting most of this code from scratch, I have used tests extensively and so far am tickled at how useful they are in the design process, let alone for their obvious benefits. Yet, the closest I have come so far to true TDD is concurrently designing classes and their tests (and that itself mainly due to the fact that in the case of GCast, the situation is prime for such a mode of development). The reason for this particular method is that I dislike the added formality of writing out the tests and then implementing the classes. If I’ve spent my spare time dreaming up the implementation already, I’d rather code first and then test, code and test, et. al. — in the wrong order, yes, but iterative nonetheless.

Thinking about it, my adaptation of testing has been progressive as my perception of the added benefits has widened: Use tests, waste less scarce time hair-pulling and debugging. Use tests during the design process, and they contribute to better architecture decisions. Begin the process from tests, and it’s the berries. Right?

Only that’s where I’m stuck in the balancing act.