I often use Cygwin with ssh and putty to remote into various Windows servers. It’s a lot quicker than Windows Remote Desktop and, well, I’m a command line junkie. But since db2cmd defaults to launching a new window/session, it doesn’t play nicely with ssh. Sure, I could remotely attach or catalog the node and database, but that defeats the purpose of being quick and simple.
To work around this, I add the following alias to my .bashrc:
alias db2=’db2cmd -i -w -c db2′
It’s imperfect (it works only for isolated commands or scripts), but it’s great for quick commands.
Handled correctly, loose typing can be a powerful thing , but with great power comes great responsibility. The license to enjoy the benefits of dynamic typing comes with the responsibility to actually design with real objects. If one just strings together collections of simple types, weaker typing can lead to some very confusing code.
I was reminded of this today in an improbable way. I uplifted some old, unfamiliar code to a modern Java version, which included adding in generics: taking untyped collections toward strongly-typed ones. This meant grokking and stepping through the code to infer data types where nested collections were used, and it smoked out what the design really looked like. One commonly-used structure came to this, and there were several others like it:
HashMap<String, HashMap<String, HashMap<String,
HashMap<String, HashMap<String, Vector<String>>>>>>
Wow. I wish I was joking.
This just screams, “make objects!” It reminded me of perhaps why the “everything in triplicate” crowd fears dynamic typing. If you aren’t designing with objects, then strong typing partly saves you from yourself. In this case, the addition of crazy nested generics actually made the subsequent code easier to understand and less error-prone.
But a much better approach, of course, is to create new classes to handle what these nested collections do, with the added benefit of factored behavior. In this case, the real objects exist very plainly in the problem domain; just follow the nouns. A truly object-oriented design usually doesn’t need strong typing to clarify the design.
This does require diligence and I’ve often been guilty of missing objects, too. Yet perhaps this example reveals a new code quality metric: if you need more than two adjacent angle brackets to make the “raw type” compiler warnings go away, it’s time to step back and look for objects.
Today I found myself needing to run ahead of the current stream of development and code some things to be merged in later. I needed the flexibility of easy branching and merging atop a code base that’s maintained in CVS. CVS branches are overkill and Eclipse/CVS change set grouping is too limited. What I really wanted was Git, but migrating wasn’t an option, and doing a full git cvsimport would take forever. I just needed simple local changesets atop the shared CVS repository.
Fortunately, I stumbled across a simple workflow by Kris Johnson that met my needs perfectly. I used it with a few minor variations, such as synching (cvs update) differently, using TortoiseCVS for a few operations, and doing the final commit via Eclipse (so that I could get one last look at the changes in the Synchronize view). But it’s a very helpful process that I’ll hang on to.
While I’m jotting things down, here’s the .gitignore I created for the Eclipse/Java projects I’m working on.
A key agile principle is to do the simplest thing that could possibly work. So it seems paradoxical that as Agile grows, so does the number of increasingly-complex tools to manage the process. Yet a great way to manage Scrum artifacts (backlogs and burndowns) remains the simple wiki. To this end, ComSwiki has worked well for me, as it is lightweight, flexible, and fast.
But new corp-rat standards require that I use SharePoint to the degree that “if it’s not in SharePoint, it doesn’t exist.” So I had the admins create a SharePoint Wiki for my team, and started filling it up with backlogs, how-to’s, and other content.
Frustration soon followed as simple editing often requires deleting text and starting over. The SharePoint Wiki’s WYSIWYG editor (only available in Internet Explorer) tries to be useful, but often just gets in the way. For example, try adding a row or column to an existing table: it can’t be done.
Not to be deterred, I turned SharePoint’s limitation into a feature. The WYSIWYG editor doesn’t work in Chrome and instead pops up a simple text box with the raw, ugly, generated HTML. Yet I can edit this HTML to do things that the WYSIWYG editor won’t. So, I now typically keep both Chrome and IE open on the same page and switch back and forth depending on what sort of editing I need to do.
It’s a stone-age approach, but then again, SharePoint is a stone-age tool. Hopefully, the WYSIWYG editor will be improved and expanded in future releases, but until then, it would have been better for Microsoft to take a “simplest thing” approach. That is, support the simple markup language of ComSwiki and other wikis rather than attempt a (mostly broken) WYSIWYG editor.