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.