I think the time has come to officially be in the market for a new job, preferably in software development, ideally working in Java using the Eclipse IDE and perhaps continuing to develop image processing projects with the ImageJ APIs.
I've just finished up a special assignment working on a project with my current employer's R&D department. For a little more than the past six months, I've been working with a few other engineers and an experimental piece of test equipment, intended for use by the R&D department to speed up development of new products. Now that the project has reached the end of it's current test plan, it will spend the remainder of the year under review to determine if the experimental test equipment is producing promising enough results to warrant continued development.
As a regular member of the production department (in a manufacturing environment), I was brought into the project primarily to help bring operational efficiency and experience to the testing and development process. Much of this was in managing materials, conducting tests, and documenting or updating testing procedures. However, I ended up also providing some key software development and image analysis skills to the project team.
I actually found the software development and associated documentation work to be the most fun and rewarding parts of the project. While it had been somewhat over six years since I had done serious software development, it didn't take me long (about a week) to get back into the swing of hardcore object oriented development, even though the project's software is in Java, a language I hadn't used before professionally. The biggest hurdles were getting up to speed on the syntax and learning the Eclipse development environment. I even managed to get in some unit testing and test driven development, using the JUnit features I found in Eclipse. I also learned to really take advantage of the Javadoc features of the Java language and integration with Eclipse.
For many years, I've heard several of my my programmer friends, particularly my college roommate Joshua Engel, expounding on the many positive attributes of the Java language and it's run time environment. Before the Dot-Com crash I was a hadcore object oreinted Visual Basic programmer automating distributed Access databases reporting back to a central office. A few years back I read Java 2 Exam Cram by William B. Brogden and taught my self many of the language's fundamentals. In the development tasks that I recently completed I made some very effective use of inheritance, polymorphism (overloading) and the JRE's automatic memory management. I found that I actually liked the strongly typed nature of Java. If this recent project gets continued, (i.e. the test results are good enough to make continued development of the tester worth while,) I'd like the opportunity to make use of Java's network / database connectivity and multi-threading capabilities.
I was also very impressed with the Eclipse development environment. Early on I found a series of video tutorials on Eclipse by Dr. David J. Powell at Elon University that were very helpful getting started and up to speed. Though out the project I made extensive use of Eclipse's hot-key access to the Javadoc APIs, primarily at Sun but also from a few other locations. I really like a number of the features in Eclipse particularly the code completion and the refactoring tools. Once I learned the interfaces, the ability to quickly generate and modify code was really amazing. At times, even as a relative Java and Eclipse novice, I was able to code almost as fast as I can think, resulting in productivity that continually exceeded project expectations. One thing I wished I had been able to make use of was/is the visual editor, but because my current employer's network is so locked down (or unreliable) Eclipse was never able to establish a connection that would allow either upgrades or the installation of enhancements.
Like many pieces of test equipment, the one I have been working with generates a series of digital images as it's end product. When I came onto the project we had a fairly simple, single class, ImageJ plug-in that one of the mechanical engineers wrote. It would use a macro to do some preprocessing, scan for the main region of interest then preform a few built-in measurements. It then wrote the results to a CSV file, that would later be opened in Excel, combined with test configuration information and finally cut / pasted into a statistics package. I initially modified this older plug-in allowing the use of some alternate testing materials, which resulted in images that required additional preprocessing. Soon afterward I developed a new plug-in that implemented more sophisticated measurement methodology and took into account certain physical characteristics of the specific test configuration. I also started developing classes in a new java package specific to our project, thus allowing effective reuse of code via Java's import features.
One of the biggest project breakthroughs came when, on my own initiative, I began outputting the measurement results, not only as tabular data [this time in TabSV files with an .xls extension so they open easily with Excel], but also as marked up copies of the original image, showing the specific areas being measured. This allowed the project's function engineers to identify anomalies and unwanted sources of variation as they analyzed the data, leading directly to improvements in the testing and measurement methods. During the qualification of my new software, I actually went back and added my image mark up capabilities to the initial ImageJ plug-in, and we immediately discovered, and then fixed, a significant bug in the old software. Also as part of the qualification I wrote detailed documentation of the measurement methodologies, including explanations of each field in the results file(s) and examples of the marked up images with visual notations showing how they related to the fields in the results file(s).
As part of the development of the new plug-in, I wrote a number of test classes that provided unit test coverage for a modest but significant portion of the software project, which really helped catch bugs later in the project. I was even able to achieve a small amount of real test driven development. This was mostly around the routines that actually preform the measurements. I would initially make the measurements on a sample image using the standard ImageJ user interface and intermediate computations in Excel, then write a test case for that measurement on the sample image, followed by the implementation of that measurement in the plug-in. I used some similar techniques to create test images and routines to check portions of the image mark-up classes.
During the later portion of this part of the project, I was also able to go back through all my code adding detailed Javadoc comments for nearly all of the public and most of the private fields and methods in my software. Which is something I would normally do before checking code into a revision control system, but we have not been using one on this project. The last software development tasks I was implementing included one last enhancement to the marked up images and packaging the new plug-in with it's package full of class files, along with versions of the older plug-in(s), all as a single .jar file. That .jar file can now be easily installed, by simply copying it into ImageJ's "plugins" folder and used by anyone throughout our company that has ImageJ installed.
In the future I'd really like to get back into a team development environment, most likely as a junior programmer or as a tester, writing Java in Eclipse and testing with JUnit. I'd also like to do more extensive work with user interfaces in Swing, XML / HTML and/or Ajax. Since I've recently spent time working with the ImageJ APIs, more work developing image processing and analysis software would also interest me, perhaps as part of the growing biomedical community. [ImageJ was originally developed at the National Institutes of Health for analyzing medical and laboratory images.] I'm also very interested in working on and with Open Source projects, like Eclipse, JUnit and ImageJ. Alternately, I wouldn't mind an opportunity to get up to speed using C# or to apply my programing skills along with my manufacturing, traffic engineering and/or geodetic expertise.
While my compensation requirements are quite modest, I would rather like to stay in the Seattle / Eastside area as I have a significant volunteer activity as Head Coach of the Cascade Vaulters in Fall City, WA, that I'm not willing to give up just yet.
Washington State Route 204 - Wikipedia, the free encyclopedia