Slow. Very slow.
The past three weeks have flashed past and I’ve produced very little code. In my defence I have learned a lot in this time and that’s why things are progressing slowly.
So, where are we at?
- Felix launcher is working reliably and configuring an OSGi environment suitable for Omneity and loading Omneity development builds without me having to leave Eclipse (all this also makes debugging a breeze).
- Omneity core, data and related APIs are starting up, connecting to a local embedded Neo4J database and correctly marshalling Adapters.
- Two Adapters have been started; MVNAdapter and OBRAdapter (these will process Maven and OBR repositories respectively). These are currently nothing more than skeletons for testing startup and shutdown, but they work and interact correctly with the Omneity core and data components.
- Logging is all working using this simple interception library and LogBack connector.
- As mentioned above, a Neo4J database is currently being embedded. This currently uses a custom library bundle.
- Plenty of new information on the Omneity wiki, including some design notes, information on current components, a new ‘developer sub-site’ created using mvn site.
- Refactor the data component. The current design is too cumbersome, it’s inelegant (a sure sign that it’s wrong). I need to refactor it to break it up into smaller, more focused classes.
- Review all current code for thread-safety.
- Add code to the Maven adapter to read Maven repositories and build an internal CoMo model.
- Testing—need to start developing tests for the code being written. (No, I am not coding to test. Why? Because most of my code is exploratory. I’m constantly trying out new ideas and ways of doing things, a breathtakingly inefficient method of developing software, but a valuable one for someone learning a lot of new things. ;) )
- Coverage analysis: I will tool the build with (probably) Cobertura, to perform coverage analysis, once I have some tests in place.
Some of the things that have been slowing me down
Pretty obvious, but I’m having to really bring myself up to speed on Java. Funnily enough, most of the ‘drag’ is the silly things like knowledge (or lack thereof) of Java libraries. Whenever I need to do anything the first thought that crosses my mind is, ‘there must be a library to do this’, swiftly followed by, ‘someone else must have done this before’. These thoughts are followed by Google searches, lots of reading, looking through code and Javadocs trying to figure out how other people’s code works or how a library is put together. All valuable learning experiences though!
iPOJO is terrific. Really. It makes life very easy on the whole, but learning the intricacies of iPOJO is a little more involved. I’ve had a couple of glitches;
- When constructing a composite I could import services but they were not correctly being mapped by a corresponding @Require within the component (details). (For now I am just developing without the composite as this works fine. I will have to add the composite later as it help isolate parts of the system from one another.)
- I have a weird difference between building via Eclipse (using the M2 plugin to run Maven) and building using Maven on the command line; the iPOJO Maven plugin throws an error on the command line when doing mvn clean install, but if I build clean in Eclipse then mvn install on the command line, no problem—I guess this is to be expected, but the iPOJO manipulation is still attempted and runs successfully in the latter case (details). Not a major issue (in that I can proceed without it), but needs to be solved in the long term.
I’m not exactly ignorant of object orientation (I cut my OO teeth on Smalltalk back in the late 80′s, long before I came across C++ and before Java was a twinkle in James Gosling‘s eye), but sitting down and starting a new project from scratch requires a lot of thought, design, tweak, realise you could do it better another way, tweak, rewrite, rinse and repeat as required. All of this is time consuming, but provides valuable learning opportunities (I’m certain that more practiced engineers would land on the ‘right’ solution more quickly—I certainly hope so, otherwise why would we pay them?). I’m also re-reading a number of books to get myself in the OO design frame of mind, I particularly like Holub on Patterns: Learning Design Patterns by Looking at Code, Holub.
Eclipse, Maven, Git, PMD, Checkstyle, FindBugs, etc.
This is a catchall observation about tooling. While I have used all of these tools professionally at one time or another I’m using this project as an opportunity to ‘play’. For example, I seldom use Eclipse, but I do work with many developers who use it and so my contact tends to be troubleshooting problems they have (like problems with Subversion plugins when passwords change). With this project I have an opportunity to ‘feel their pain’ and more importantly to figure out things like how to ensure that the Eclipse plugins work with an identical setup to the one I use for system builds (always an issue on projects where developers work almost exclusively in an IDE but the build manager uses almost exclusively a build tool like ANT or Maven).
I like the assistance of PMD, Checkstyle and FindBugs in spotting potential weaknesses in code. I do, however, find that this early in my Java programming learning curve I look at the advice and wonder (based on looking at other people’s code) whether the advice issued by these tools helps or hinders. For example, I am often admonished by Checkstyle that my public methods are not designed for extension and I should make hem abstract, final, or empty. This is, strictly speaking, true. I see the logic behind the advice, but I also seldom see that advice adhered to in other people’s code. All of which raises the question, ‘is it really worthwhile, or is this overkill?’ At the moment I’m opting for overkill. I’d rather make my classes difficult to extend, but safe. I can always go back a review my design to make the classes extensible later.
On a similar vein, these tools had me putting in a lot of ‘final’ and ‘transient’ keywords. In this case I think the ‘final’ keywords are a good habit (they make a clear statement and prevent accidental changes to, for example, parameter arguments—mitigating the dreaded ‘side effect’ bugs), but the ‘transient’ less so.
This ‘play’ time also takes away from raw coding time, but is providing some useful lessons (yes, I’ll write some up once I get time).
Although I’ve been well aware of issues about shared memory, race conditions, and other issues raised by threading since my university days learning about operating system design, I’ve seldom had to deal with them while programming. Omneity requires a lot of thread programming. I’m spending a lot of time with Java Concurrency in Practice, Goetz et al. and Java Threads, Third edition, Oaks & Wong.
The next big task is writing the code to process Maven repositories, so recently I’ve been trying to get to grips with Maven internals to see if I can use the existing code to process a Maven repository into a CoMo representation. My current thinking is ‘maybe’. I need more time on this, and a considerable amount of ‘poking’ the code. The documentation of this code is okay, but with my lack of practice reading Java code and Javadocs, figuring out how to leverage the existing code is a bit of an uphill battle. But I shall prevail!