Handy git Scrum Script Across Many Repos

The older I get, the more I forget.  I guess it's unavoidable.

In a scrum meeting, you're supposed to say what you did during the last day, what you're going to do the next day, and whether you're blocked by anything.

Since I work on several git repositories on any given day, I created this handy dandy bash script to pull my commits from the git log for each repository:


Download the script & save it somewhere into your PATH; I have mine in ~/bin.  Here's a one-liner to do get it; just copy it into a terminal & run it.

curl -sSL https://gist.githubusercontent.com/matthewadams/9aeec475cc46297152228c1e8ccca8b0/raw/26840f1eb30a2891b3859a0607c54d5be444ed49/git-scrum.sh > ~/bin/git-scrum && chmod ugo+x ~/bin/git-scrum

Now, change into a directory that contains a bunch of git repositories and run git-scrum. You'll see something like this:

$ git-scrum
Commits between 2016-11-15T11:30:00-0600 and 2016-11-16T11:30:00-0600:
/Users/matthew/Documents/github/SciSpike/9aeec475cc46297152228c1e8ccca8b0
26840f1 2016-11-16 08:56:22 -0600  (HEAD -> master, origin/master, origin/HEAD) update mode & minor change [Matthew T. Adams]
/Users/matthew/Documents/github/SciSpike/docker-node
/Users/matthew/Documents/github/SciSpike/docker-yaktor
/Users/matthew/Documents/github/SciSpike/docker-yaktor-base
/Users/matthew/Documents/github/SciSpike/docker-yaktor-node
/Users/matthew/Documents/github/SciSpike/node-config-cev-generator
/Users/matthew/Documents/github/SciSpike/words
/Users/matthew/Documents/github/SciSpike/yaktor
dc78e9f 2016-11-15 16:17:58 -0600  (HEAD -> master, origin/master) increase timeout due to slower performance of travis build machine [Matthew T. Adams]
9b6dcab 2016-11-15 16:10:56 -0600  fixes #35: use ./run.sh grunt ... [Matthew T. Adams]
83160ca 2016-11-15 15:24:29 -0600  fixes #22 [Matthew T. Adams]
af4e652 2016-11-15 13:54:08 -0600  closes #29 [Matthew T. Adams]
/Users/matthew/Documents/github/SciSpike/yaktor-auth
1b31c75 2016-11-15 16:12:48 -0600  (HEAD -> master, origin/master) use ./run.sh grunt ... from now on instead of running a local grunt [Matthew T. Adams]
cddf67b 2016-11-15 15:42:24 -0600  fix "the input device is not a TTY" issue [Matthew T. Adams]
/Users/matthew/Documents/github/SciSpike/yaktor-branding
/Users/matthew/Documents/github/SciSpike/yaktor-docs
/Users/matthew/Documents/github/SciSpike/yaktor-dsl-xtext
/Users/matthew/Documents/github/SciSpike/yaktor-lang-js
/Users/matthew/Documents/github/SciSpike/yaktor-ui-angular1

That takes care of at least not having to remember what you did; you'll still have to figure out what you're going to do! Hope you likey.

Near-Zero Effort Default Spring 3.1 Bean Profiles

A client of mine is performing a code migration over an extended time during which the "old" bits need to be executed unless the "new" bits are desired.  Naturally, we leveraged Spring 3.1 bean profiles to perform this amazing feat.

Now, the currently documented way of doing this is to use Spring 3.1's well-known Java system property spring.profiles.default. Since by default, the old bits should be active, all you need to do is ensure that somewhere in your target environment you're specifying the Java system property spring.profiles.default with a value that is a comma-delimited list of Spring bean profile name(s) that reflect the old bits. When you want the new bits, set spring.profiles.active with the profile name(s) that activate those new bits, thereby overriding the default profiles.  Note that you can, of course, have both properties defined at the same time, since one is for the default activation and the other is for explicit activation.  (BTW, you could instead use native OS environment variables as well.)

Pretty nice, but there are just a couple of issues with that, IMHO.

• It requires changes to the target environments.  If you have many such environments or there is a resistance to changing system properties or environment variables, you must deal with that friction.
• It's not immediately obvious what the default profiles are.  You can't tell from the XML configuration file elements or @Configuration classes alone which profiles are intended as your default ones.  You have to know which target environments are setting which default profiles, if any, since they're set per environment.

As for the first issue, the more agile your organization, the easier it is to change configuration like this, so not really a huge deal.  However, as I see it, the fewer unnecessary changes per release, the better.

With regard to the second issue, if there were a way to make it obvious which profiles were intended to be activated by default when viewing Spring XML configuration files or @Configuration classes, it'd be just jim-dandy.  Well, it turns out that you can.

There's a rather underdocumented feature in Spring 3.1 that defines a reserved default profile name, namely "default", that will serve to activate a beans element that includes it in its profile.  For example, if you're using "old" and "new" as your profile names corresponding to the bits you want to activate, and the old bits are your default, simply define your beans elements like this:

<beans>
  
  <!-- define beans here that don't change by profile -->
  
  <beans profile="old,default">
    <!--
      Define beans reflecting the "old" bits here.
      
      They'll be active unless any profiles are activated explicitly
      via spring.profiles.default, spring.profiles.active, or other
      means.
    -->
  </beans>
  <beans profile="new">
    <!--
      Define beans reflecting the "new" bits here.
      
      They'll be inactive unless they're explicitly activated.
    -->
  </beans>
</beans>

It's worth noting that if any bean profiles are activated by any means (PropertySource, spring.profiles.default or spring.profiles.active), the reserved "default" profile is ignored.

By leveraging Spring 3.1's reserved default profile name "default", you don't need to change your target deployment environments and you can see very quickly & clearly in your Spring configuration files which profiles are intended to be your default(s).

Nice!

Official JPA 2.0 API jar in Maven Central

I'd love to see an official JPA 2.0 API jar, with sources & javadoc, available in Maven Central as javax.persistence:jpa-api:2.0, so I entered this issue:
http://java.net/jira/browse/JPA_SPEC-19

Right now, you have to dig to find various implementations' groupId:artifactId:version values.

If you want that, too, then vote for the issue!

Spring & JPA over Hibernate: Don't forget SpringSessionContext!

NB:  I'm writing this one down so that I don't forget.

If you're using Spring 3.1.1 and JPA with Hibernate as your JPA provider, you're probably using Spring's LocalContainerEntityManagerFactoryBean with a persistenceProviderClass of org.hibernate.ejb.HibernatePersistence.

I was having trouble getting Hibernate's Session to get hooked up to Spring's JpaTransactionManager.  To fix this, include the following entry in your Hibernate properties:

hibernate.current_session_context_class=org.springframework.orm.hibernate3.SpringSessionContext

It's configured automatically when you're using Spring & pure Hibernate with either LocalSessionFactoryBean or AnnotationSessionFactoryBean, but it doesn't appear to be so when using LocalContainerEntityManagerFactoryBean.

Now, hopefully neither your nor I will forget again.

BitBucket offers free unlimited git PRIVATE repos

I am really growing to like git and the distributed way of version control and I have to acknowledge GitHub as a very popular place for social coding.  I've noticed one thing, though, that's prevented me from using it: you have to pay for private repositories (US$7/mo as of this writing).

Fortunately, I noticed that BitBucket, from Atlassian, not only has added git support (I was using it with Mercurial), they also support unlimited public and private repositories and up to five users for free, with reasonable paid plans from there.

In fact, all plans support unlimited public & private repos, and it seems to have most if not all of the same bells & whistles (issue tracking, wiki, pull requests, etc). I think it beats GitHub for small projects that you don't want to share just yet (if ever).

I wonder what would have happened if BitBucket had offered git before GitHub did -- maybe BitBucket would have been the new, cool place to store your code!

Anyway, just thought I'd let people know about the great service.

Running TestNG & JUnit 4 tests in the same Maven project without duplication

Update on 16 Mar '12:  Cedric has informed me that the TestNG master branch now supports JUnit 4.  Try it out!

As of this writing, TestNG still doesn't support JUnit4.  Problem is, Spring Roo uses JUnit 4 and I happen to be developing a liking for TestNG lately.

Many folks out there have suggested defining two Surefire executions, one for JUnit 4 & one for TestNG.  I did that, but every time I do, it looks like the default configuration of Surefire runs first, then whatever other test executions that you've defined next, often resulting in duplicate tests being run.

I noticed that the default Surefire execution id is default-test.  By simply defining an execution with id default-test and setting skipTests to true, I was able to avoid the unwanted default run.  You could either redefine the default-test execution or defeat it and define whatever other test executions you want to.

Here's the POM snippet that defeats the default-test execution and defines one for JUnit 4 & TestNG:

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.11</version>
        <executions>
            <execution>
                <id>default-test</id>
                <configuration>
                    <skipTests>true</skipTests>
                </configuration>
                <goals>
                    <goal>test</goal>
                </goals>
            </execution>
            <execution>
                <id>junit-tests</id>
                <goals>
                    <goal>test</goal>
                </goals>
                <configuration>
                    <testNGArtifactName>none:none</testNGArtifactName>
                    ...
                </configuration>
            </execution>
            <execution>
                <id>testng-tests</id>
                <goals>
                    <goal>test</goal>
                </goals>
                <configuration>
                    <junitArtifactName>none:none</junitArtifactName>
                    ...
                </configuration>
            </execution>
        </executions>
    </plugin>

I hope this helps you some time.

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!