JDO Goes Social!

JDO goes social with a Twitter feed, Facebook & Google+ pages:

Twitter:  @JavaDataObjects
Facebook:  http://www.facebook.com/JavaDataObjects
Google+:  http://j.mp/javadataobjects

So follow, like & +1!

NoSQL + JDO = :) , NoSQL + ORM = :(

Ah, if only more people knew about JDO & DataNucleus:

http://architects.dzone.com/news/non-sense-nosql-orm-frameworks

JDO, by design, supports any kind of underlying datasource.  DataNucleus, the open source JDO reference implementation, already supports several NoSQL stores, including db4o, NeoDatis, Amazon S3, Google's BigTable, HBase, & MongoDB, as well as every major RDBMS around.

JDO:  http://db.apache.org/jdo
DN:  http://www.datanucleus.org

Uh oh: TZ database down, in legal battles?

http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html

This is bad.  We need an IETF/Oasis/etc standard for this data.  I don't want to have to deal with multiple competing timezone data.  It's nontrivial at best, and often very difficult, to deal with different timezones and daylight savings issues, let alone historically.

What a nightmare this could turn out to be.

Why can't bundle manifests be pretty-printed?

I've had to wade through lots of OSGi bundle manifests lately, and I have to say, they are hard for an average Joe to read.

So, I entered an enhancement request for bnd to provide a directive for pretty-printing manifests. I include an example of what I'd consider pretty-yet-still-manifest-spec-compliant.

If you've suffered my fate as well, please add a +1 comment for it (until such time as github adds back voting for issues).

Convenient Maven POM to wrap jars for OSGi

I've been doing some OSGi work at my current gig. If you ever have a jar that isn't OSGi-ready, this is a handy-dandy little pom.xml that will use bnd (via maven-bundle-plugin) to wrap the jar, and any dependencies you want to include, in an OSGi bundle jar. Just replace theGroupId with the groupId, theArtifactId with the artifactId and theVersion with the version of the Maven artifact you want to wrap et voila.

<project
    xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
    ">
    <modelVersion>4.0.0</modelVersion>

    <groupId>theGroupId</groupId>
    <artifactId>theArtifactId.osgi-wrapped</artifactId>
    <version>theVersion</version>
    <packaging>bundle</packaging>

    <name>${artifactId}</name>
    <description>${artifactId}</description>

    <dependencies>
        <dependency>
            <groupId>theGroupId</groupId>
            <artifactId>theArtifactId</artifactId>
            <version>theVersion</version>            
        </dependency>
        <!-- TODO:
            Add any other dependencies you want to embed here,
            then make sure to include their artifactIds
            in the space-separated list in <Embed-Dependency>
            below.
        -->
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>2.3.5</version>
                <extensions>true</extensions>
                <configuration>
                    <instructions>
                        <Import-Package>*;resolution:=optional</Import-Package>
                        <_exportcontents>*</_exportcontents>
                        <Embed-Dependency>theArtifactId</Embed-Dependency>
                    </instructions>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

A Baker's Dozen More Rules, and Not Just for Beginning Programmers

I just saw on a blog called Panopticon Central, I saw an entry called Seven Rules for Beginning Programmers. I had to continue the list with some rules (caveat emptor #12 below) of my own.

1. Write automatable unit & integration tests and run them on every build. Do not declare yourself to have a successful build until not only everything compiles but also all tests run successfully.
2. Make judicious but appropriate use of interfaces.
3. Don't overuse inheritance; it leads to brittle hierarchies. Always prefer composition.
4. Layer software appropriately. Recognize that even when using an object-oriented language, some artifacts, like service layers & strategies, are procedural in nature.
5. Understand the difference between persistent domain objects and data transfer objects, and combine the two only when you understand the tradeoffs.
6. Avoid anemic domain models.
7. Understand source control, branching & merging.
8. Understand aspect-oriented programming, and how it complements object-oriented programming via modularization of cross-cutting concerns.
9. Always pay attention to advances in new or existing programming languages, techniques, and ideas.
10. Understand dependency injection, inversion of control and how it makes your code less coupled.
11. Always keep your business logic independent of the environment in which it will run.
    
    These last two apply to life, not just programming:
    
    
12. Know the difference between a rule and a guideline.
13. When faced with a choice, the one that it is more emotionally difficult for you to choose is often the right one.

Health insurance for Facebook users?

Here's what I know.

• Health insurance providers are businesses.
• Businesses need customers.
• Many people in the US either don't have health insurance or they have overpriced, catastrophic-only coverage plans (like me).
• Facebook has lots of users. Lots.

Given what I believe to be true above, what if Facebook negotiated health insurance rates for group coverage for its entire eligible user base, then each participating user could pay the rate themselves? Imagine that. This could be the largest group policy in the history of the US, with all members of the group benefiting from the economies of scale, and the provider gaining a potentially huge number of customers. Facebook could even take a small piece for putting it all together.

What constitutes a "group" when it comes to a group healthcare policy? Could Facebook users constitute such a group?

What do you think?

.NET: Like working at McDonald's?

So I noticed this blog entry on why Expensify doesn't hire .NET programmers, started to leave a comment, then ended up writing more than I had intended.

Here's what I've noticed after working in Java pretty much forever (1996-present) and being forced to work in .NET now (2010). When you compare Java language to C#, and the JVM to the CLR, I think it's basically a wash. Minor, albeit annoying, syntactical differences, different flavors of syntax sugar, etc. Not much to talk about there.

Next up is something that's a difference, but not huge: the standard libraries available on each platform. Java collections, IMHO, are superior to those in .NET. LINQ does offer something new to .NET and is nonexistent in pure Java, but with the advent of other programming languages for the JVM, like Groovy & Scala, those holes have been plugged, which brings me to my main point.

What really separates Java & .NET is the ecosystem of projects & languages available. Java, thanks to its low (free) cost of entry, has enjoyed tremendous innovation over the years. From JUnit to today's BDD frameworks, to the persistence frameworks like JDO & iBatis, to dependency injection, IoC and AOP, to the new NoSQL technologies, to build & dependency management tools like Ant, Ivy, Maven & Gradle, to OSGi, and to open source libraries too numerous to count that can do just about anything low level that you need done, Java's ecosystem simply can't be beat. The level of innovation on the Java platform is simply staggering.

Having said all that, Java is not without its warts. EJB 1 & 2 were terrible, especially entity beans. It wasn't until much later that all of enterprise Java took a lesson from the playbook of SpringSource, who revolutionized Java development. JDO provided a great, universal, lightweight persistence model that is still going strong today, but the JCP, due to its political nature, felt the need to reinvent the wheel (and do it worse) with exclusively-relational JPA. Logging in Java was being served fine by log4j, but then the JCP felt the need to change all that and ignore the de facto standard. The result was Apache's commons-logging, so that you could use either logging technology and continue coding. We'll see where modules and superpackages versus OSGi end up, and where closures are going. It wasn't looking good for a while, but now the JCP might be learning some lessons from the past.

Anyway, while Java is not perfect, it has stimulated just amazing work. The support of other languages on the platform make for a promising future, too. I've always walked away from an experience with Groovy & Grails saying "wow". I'm very interested in the promise of Scala, too. .NET is showing signs of innovation life in things like its dynamic type and Expando object (taken from Groovy, BTW), but it takes the whole community to really produce useful stuff. Codeplex is a start, but is absolutely dwarfed by the numerous pure Java or JVM-compliant projects out there in open source land.

Only time will tell if the .NET ecosystem can ever catch up with that of Java.

JDO Support Spreads For Good Reason

It looks like Google AppEngine for Java's JDO support is beginning to spread to others. In particular, Grails now supports JDO on GAEJ, and it looks like GORM is being enhanced to support JDO.

Some of you may not have been aware that JDO has been under active, continous development at Apache ever since before the JDO 2.0 release. In fact, it's the only JSR that I know of that was and continues to be developed in open source, with the expert group's doors flung wide open, and its discussions on a public mailing list. The most current version of JDO is 2.2, with 2.3 imminent.

I, for one, am really happy to see Grails support JDO, seeing that I entered an enhancement request for it a very long time ago. Back then, it got shot down, but clearly, things have changed.

Why did the folks at GAEJ go with JDO over Hibernate? Well, I can't speak for them, but recall that Hibernate (and JPA), by design, target relational databases only, whereas JDO's API is designed to be fundamentally independent of the underlying datastore. Since the most common implementations of JDO in the past have been object-relational mappers, one major enhancement delivered in JDO 2.0 back in 2006 was to standardize object-relational mapping metadata. This had very little effect on the API, and where it did, it was only a matter of convenience for those who needed hybrid applications that used both JDO and SQL together.

JDO, by design, is intended to support any kind of datastore. This is an important point, because only JDO allows us to consider new and exciting ways of storing our data. With little or no change to our code, we can run our applications against relational databases, Google's BigTable on GAEJ, or even new, as yet undeveloped datastores.

I don't think that the day is far off that JDO supports not only cloud-based datastores (BigTable might be considered one), but also multiple datastores, whose boundaries are managed by your JDO implementation. Imagine a comprehensive persistent object model of your entire domain, regardless of where and how its bits and pieces are stored and retrieved, whether they be via relational databases, clouds, web services, RESTful services, other stores, and/or multiple, heterogeneous instances thereof. Better yet, imagine writing a Grails or even a Naked Objects application over such comprehensive object models!

We've all heard of the unified view of the customer; well, JDO is definitely the path to get there.

Good Domain Modeling

In my experience, the topic of good domain modeling comes up, and people are often lacking resources that discuss it thoroughly. I have found three texts that have been extremely helpful in this area, and I would recommend reading them in this order:

1. Chapter 1 of "Java Modeling in Color With UML" by Peter Coad, which can be found online at http://www.petercoad.com/download/bookpdfs/jmcuch01.pdf
2. "Streamlined Object Modeling" by Jill Nicola, Mark Mayfield & Mike Abney (Google "Streamlined Object Modeling")
3. "Domain Driven Design" by Eric Evans (Google "Domain Driven Design")
   

Coad's book "Java Modeling in Color With UML", discusses the idea of color and explicitly modeling as classes his four archetypes:

• Description (aka "catalog-like entry"),
• PartyPlaceThing (aka "Actor"),
• Role (aka "representation of an actor in an event context"), and
• MomentInterval (aka event, action, interaction, or transaction).

Since MomentIntervals represent actions, events, transactions, or interactions, they get the hottest color: pink. The remaining colors are ordered according to decreasing temperature: Roles (participating in MomentIntervals) are yellow, Actors (playing Roles) are green, and Descriptions (describing Actors) are blue.



These ideas are a good start, but you quickly find out that they are too rigid; you cannot give a class a single color, because it participates differently in different contexts. For example, consider a "subsequent role" pattern: a role class Employee may be played by an actor class Person, but a role class Manager may be played by an actor class Employee; this implies that an Employee can be either an actor or role, depending on the context. Thus, a Manager is a subsequent role of the role Employee, and a single color and archetype will not suffice.

As a result of this phenomenon, a refinement to Coad's color modeling technique is in order. Specifically, it is not the classes that need to have a color, but it is the associations between them that need to be colored. Given the example above, you quickly realize that, if you represent the association between Person & Employee as a line (like you do in UML), then the Person side of the line should be green and the Employee side of the line should be yellow.

Streamlined Object Modeling by Nicola et al, rigorously discusses domain modeling, and presents examples in Java & Squeak (Smalltalk). The book, published in 2001, is showing its age, in that rollbacks are handled directly in code, and explicit persistence handling in the domain objects is discussed and illustrated. Today, these two burdens have been lifted, thanks to execution within a transactional context and transparent persistence, so this part of the examples and discussions can be safely ignored. Also, notably absent from Streamlined Object Modeling is the discussion of placing a domain model within an enterprise context; see Eric Evans' Domain Driven Design for such a complimentary discussion.

Streamlined Object Modeling does have a web site that is fairly static (it looks like the last update was 2002), but informative at http://www.streamlinedmodeling.com.

From the above website:

Streamlined Object Modeling pares down object modeling to just the bare essentials necessary to model business domains, business rules, and business services.

• Object think and object selection principles.
• Twelve all-encompassing "collaboration patterns" for modeling real-world relationships.
• Five kinds of business rules, three types of services, and six categories of properties.
• Rigorous methods for discovering, organizing, and implementing business rules around objects.

I hope you find these useful. They have had a profound impact on the way that I approach development, and their ideas have thus far withstood the test of time.

Mac OS X: Mouse-Follows-Focus (Not Focus-Follows-Mouse)?

More from the Windows-Power-User-to-Mac-Power-User-Adjustments department: Windows has a really nice key on the keyboard that I use a lot: the context-sensitive menu key. It looks something like this on most Windows machines:
It allows me to perform a right-click wherever focus currently is without having to use the mouse.

So, Mac OS X has its equivalent of right-clicking, which is Ctrl-Click. So far, so good, except that I still have to use the mouse. Next, I discovered that Fn-NumPad-5 (which is Fn-Option-I on my MacBook Pro, BTW) does the same thing as a Ctrl-Click, so that I can do the Mac equivalent of a keyboard-only right-click. The problem is, instead of using the current focus (which I maniuplated via various keyboard navigations), it uses the current location of the mouse pointer as the location where the Ctrl-Click is effected.

Ideally, I'd like Fn-NumPad-5 to use the current focus to effect the click instead of the current pointer position, but I'd be willing to have the mouse follow the current focus. I've seen focus-follows-mouse, but that's not what I'm trying to do here.

Anyone have any ideas?

POP woes with Yahoo Mail

I'm pretty happy with Yahoo Mail, having been a customer since the service first started, however, I'm having some problems now that I've started using POP access.

Throughout the day, I get prompted by Mail on Mac OS X to reenter the password for my two POP accounts (one for my "@yahoo.com" email address and one for my "@matthewadams.org" address). This happens probably 10 or more times per day. It also happened when I was using Microsoft Outlook 2007 on Windows XP. Oh, and yes, I am checking the "remember my password" checkbox.

Naturally, I contacted Yahoo Business Mail tech support with low expectations of their ability to diagnose and correct the problem, assuming that if I see it from both Mac OS X and Windows, chances are the problem's on their end. Needless to say, my low expectations were met and not exceeded.

Several times each day, I have to reenter my POP password, and it's getting annoying. Anyone else seeing these problems?

Mac OS X and mp3 Files

So I've been using my new MacBook Pro for a month or so now, and this'll probably the first in what I'm sure will be a series of questions as I transition from being a power Windows navigator to the same on Mac OS X.

I'd like to copy iTunes playlists, consisting only of mp3 files, to my various, generic, USB mp3 players. When I plug the player in, it doesn't show up in iTunes. Please don't tell me that my only option is to find the mp3 files on disk and copy them using Finder (or PathFinder)!

JPOX Is Better Than Hibernate?

Oh, yeah, the whole reason I started back into the blogosphere: I saw a post over on the JPOX forum that I thought was worth sharing, just for the stir-the-pot factor. It's entitled "JPOX better than Hibernate according to Hibernate trainer!"

NB: JPOX is a JDO- and JPA-compliant ORM, and is the reference implementation for JDO 2.0.

In all fairness to Hibernate, clearly the most widely used ORM in the marketplace, it wasn't a trainer from Red Hat/JBoss/Hibernate; it was actually a Spring Framework trainer (no, not me, to my knowledge) who mentioned it. Perhaps the poster, Chris Colman, could expound a bit more on why. It looks like he's from Step Ahead Software and exPOJO, and does a fair amount of JDO and Hibernate work.

Catching up

I'm going to take a moment in this post to catch up, since it's been a while since I posted anything. Let's see, my last post (other than to say that I'm moving to this new blog), had to do with persistence within an SOA.


While I still absolutely love what Xcalia has been able to do with transparent persistence (namely, move beyond relational databases and allow you to use literally anything that you can connect to or call upon from Java as a data source), I was given an opportunity to go to work for Interface21, the people behind the Spring Framework.

So far, it's been a great experience. I'm a senior consultant now, primarily doing training (which I enjoy very much), consulting, and some technical marketing. I tried to keep my Interface21 profile page interesting; you can judge for yourself.

I'm still serving on the JDO and JPA expert groups, but not the SDO expert group anymore. Hopefully soon, those of inclined to do so will begin blogging about enhancements in JPA 2.0, and I'll probably do that on the Interface21 team blog. As has been the case for years, the JDO 2.0 and 2.1 work has been progressing nicely over at Apache JDO.

Well, that'll do it for now, and I hope to post a bit more regularly now. We'll see if I actually do...

Goodbye JRoller, Hello Blogger.

Not that very many people read it, but I've decided to move my former blog to Blogger and my own domain (matthewadams.org). We'll see how it goes using Blogger!