Colin's Devlog

Property interfaces and Guava functional programming

2010-06-18T01:09:00.001-04:00

Something that I’ve been thinking about lately is how I can make it easier to use Guava’s methods that operate on Functions, Predicates, etc.

One simple use for Functions is to get properties of objects, allowing you to (among other things) create a transformed view of a collection containing a certain property from each element. For example, transforming a list of Person objects to a String collection of names. Any time you want to do something with a collection of objects based on a certain property of those objects, this is useful.

However, it's rather ugly and awkward to have to create an anonymous inner class inline when calling a method that uses a Function. While you can create static final instances of such functions and methods that return instances of functions, with many classes you could end up with many such instances and methods. One good way to reduce the number of Function objects you need to create and make it easy to work with certain common properties (such as IDs, names, etc.) on many objects is to create interfaces that each expose a single such property:

interface HasId {
   Long getId();
}

Not only does this help add consistency to your classes, it allows you to collect behavior that can work on any type of object that has the property the interface exposes. I'd probably name such classes as the plural of the property name ("Ids" and "Names", for example).

class Ids {
  private Ids() {}

  public static final Function<HasId, Long> GET = 
    new Function<HasId, Long>() {
      public Long apply(HasId hasId) {
        return hasId.getId();
      }
  };

  public static Iterable<Long> of(
      Iterable<? extends HasId> items) {
    return Iterables.transform(items, GET);
  }
}

This makes working with the IDs of a list of things with IDs as easy as possible:

List<Person> people = ...
for(Long id : Ids.of(people)) { ... }

The GET function is exposed to allow its use for anything you might want a function for, not just tranform. For example, with a HasName interface and Names class similar to the code for IDs, I could do something like this:

List<Person> people = ...
Iterable<Person> bobs = filter(people, compose(equalTo("Bob"),
  Names.GET));

This would of course filter a list of people to an iterable that only includes people with the name Bob. It uses static imports (because they make this stuff read a lot nicer), and the methods are:

I think this approach can make working with the properties of objects using Functions a lot easier and cleaner, while also encouraging more consistency between classes in general, which is nice.

Get your UI out of my logic

2010-03-25T22:06:00.000-04:00

public enum Type {
  Select,
  TypeA,
  TypeB,
  TypeC;
}

This used in a domain object.

I've also seen a list of objects retrieved from the database and put into an Object array with "Select" as array[0] and the rest of the objects being actual objects someone might care about. Let's just have everyone remember what type of objects are in this array, and they should also remember that the first element isn't one of those!

I can't imagine what people find so hard about producing a new list or whatever to base their combo box model on at the time that the combo box is actually created. Furthermore, with something like the enum above, the enum constants use lowercase letters because it'll look nicer when they're rendered in the UI using the default toString(). The use of toString() to produce the text for the UI in general bothers me. I want it to produce text that's helpful to me in error messages... use some other means for rendering it to users.

I guess what I want to say is: keep user interface concerns where they belong, near the user interface!

What's the issue with @Inject?

2010-01-22T18:38:00.000-05:00

Reading Uncle Bob's recent post about dependency injection frameworks, I noticed that quite a few people seemed to be treating the use of Guice's @Inject annotation in their application code as a reason to prefer other DI frameworks to Guice. For the most part, none of them provided any explanation for why using the annotation in application code was a problem other than "I don't like it". Even ignoring the fact that JSR-330 standardizes the only annotations and the one interface from Guice that are used in application code and will be usable with Guice 2.1, I find it difficult to understand these points of view. What's the issue people have with it?

Why it's good

@Inject is just one annotation that, in a typical concrete class, will be used on one constructor and MAYBE a couple setters. It allows dependencies to be injected without any explicit configuration of the Spring XML form while retaining safe and predictable behavior by ensuring that injections always take place using the exact constructors and methods you want to use. It saves you from ever having to specify anything using strings, making it possible to refactor and rename classes and methods without any risk of breaking your DI configuration... I think this is an extremely important point. It generally doesn't allow anything unexpected to happen.

Tied to the framework?

I feel like the knee-jerk reaction to using @Inject in classes is that by doing that, you're somehow tying yourself to Guice. As Uncle Bob put it,

I don’t want to write a Guice application. Guice is a framework, and I don’t want framework code smeared all through my application. [...] I don’t want to have @Inject attributes everywhere [...]

I understand that when he says this, Uncle Bob is arguing against using DI frameworks in general. Ignoring that argument for now and accepting that DI frameworks are worth using, the fact is that if you're using a DI framework, you are tying yourself to it. It's how your application is configured, unless you're doing all the work to create an alternate way of wiring the application together in which case... why? If you choose to switch to another DI framework or stop using a DI framework entirely (and how likely are either of these, really?) it is going to involve some work to remove the existing configuration and write the new configuration. And removing a bunch of @Inject annotations would be an absolutely trivial part of that.

Annotations are not code

I think it's important to note that annotations are not code. By themselves, they do nothing. You can use a class even without the annotations on its elements available on the classpath. When writing tests, you can completely ignore them. Guice's annotations will also never be in the body of your code, meaning you should generally be able to ignore them when reasoning about how a class behaves. One comment I read (from a Spring XML user) stated that the commenter considered annotations "just as bad" as code and likened the @Inject annotation to providing your classes with the ApplicationContext (Spring's central container interface). This is, of course, way off base. Providing programmatic access to the central container ties the code itself to the DI framework. The class can then use the framework's code directly to get access to any object it wants, anywhere in its code. Testing the class would require configuring a container and looking through the class to see what needs to be in it. The framework becomes a Service Locator framework. The @Inject annotation imposes no such thing.

In general, I think the benefits provided by Guice and the configuration safety provided by the use of @Inject far outweigh the at most minor annoyance of placing an annotation or so per injectable class. In future posts I'd like to talk more about what I like about dependency injection and Guice.

Git and CVS

2009-07-10T02:06:00.000-04:00

In my last post I talked a little about my experience starting to learn to use Git. Now I'm going to talk about what I'm doing with it currently in an environment where Git can't be used as the end-to-end version control system (at least not immediately).

The Situation

At work we're using CVS for a legacy project that I'm working on. It's been around a while and the practices with it are pretty set. Branches are used for release versions of the product and that's about it. I tend to have a feature or two I'm working on and I also occasionally do something experimental. The trouble is, getting changes related to separate things mixed together can make it confusing to know what needs to be committed and what doesn't when it comes time to commit something (committing early and often would help with this, but it's not quite how things are done). Especially problematic would be if changes related to different things affected the same file.

To deal with this, I'd sometimes check out a separate copy of the project into another directory and work on something specific there, but this wasn't very efficient. I'm programming in Java using Eclipse, and in addition to the issue of keeping track of multiple complete copies of the project, I'd have to switch workspaces or open up another copy of Eclipse to work with those copies. This wasn't very efficient.

The Solution

When I started looking into Git and experimenting with it, I realized that I could probably use it locally with a totally different VCS acting as the central repository. Git stores all its data in a single folder in the root of the working directory, which means that its files aren't mixed into your entire directory structure the way they are with CVS and its CVS subdirectories in every directory.

Here's the process I used to get this project set up for work with Git:

Check out a clean copy of the project into a new directory to use.
Get the environment all set up for normal use in Eclipse.
Do git init to create the Git repository at the root of the project.
Create and set the .gitignore file, having it ignore compiled code output folders, among other things. (Note: It should also ignore all CVS folders.)
git add . everything that isn't ignored, making sure you aren't getting anything you don't want to.
Do the initial git commit.
From there, use Git normally... create a development branch, and branches off that for features, experiments, etc.
When you're ready to commit something to CVS, merge the changes all the way down to the master branch and commit in CVS.

When I switch branches, I just refresh the project in Eclipse and it immediately reflects the branch I'm now on. Since the files that exist may differ between branches, I also like to use tasks in Mylyn. I have tasks that are specific to whatever I'm doing on a specific branch, and I activate them while working on them. I'd done a little of that before, but it's even more useful in this situation. If I'm working on some files and need to switch to another branch that doesn't have them, I just deactivate the task and the editor tabs go away. I switch branches, do whatever I need, and then when I switch back and activate the task. Despite the fact that the files ceased to exist on the files system for a while, when the task is reactivated the files are right back there like before!

This approach has made it far easier and more fun to work on multiple separate things at once, and it's easy to do even though the central repository is the ancient CVS! Thanks for being awesome, Git!

Update:

How you interact with CVS when doing this is important. First, the .gitignore file should be set to ignore all CVS folders! You don't want changes to the files in the CVS folders to have to be committed to your Git repository. You want to ignore the fact that you're also using CVS as much as possible. Given that, you should also only ever update from CVS or commit to CVS from your master branch! Things can get really weird if you update or commit in a branch you've created.

Learning Git

2009-07-08T04:04:00.001-04:00

One thing that I've been realizing more and more recently is the importance of keeping up with advancements in developer tools. I'm a strong believer that if you aren't using the best tools available for the job you're doing, you aren't being as effective as you could be, regardless of how much effort you put in to it. Plus, as a lazy programmer I certainly don't want to put more effort in to something when a better tool could save me from that.

Up until recently, I'd only used CVS and Subversion for source control... CVS at work and a little in college, and Subversion at home because I knew it was more recent than CVS. As I started to pay more attention to what I was seeing around the web on blogs and Hacker News, I began to notice a lot of positive references to Git. It seemed a little intimidating to me, at first... largely command line based, with no full-featured shell integration like Tortoise for Windows? I didn't know about that... I like just right-clicking on files for diffs, commits, etc.

Tales of the wonders of branching in Git were probably what brought me around to finally try it out this weekend... well, that and GitHub, which is awesome. Anyway, on sitting down and starting to learn it I discovered that it really wasn't hard at all to pick up. A quick git init, git add . and git commit and I had a small existing project that I hadn't put in version control yet committed to a Git repository. And from there, pushing it to a repo on GitHub was incredibly easy as well. I then spent some time experimenting with branching and merging and all that fun stuff. I'll admit that I certainly still don't know all the intricacies of it, but the basic process was as easy and wonderful and rainbows as advertised.

One of the things I really love about Git is the fact that it uses a local repository in addition to a remote one (and that only if you want/need it to). Branches are such a great way of keeping logically separate units of work... well, separate, and that includes experimental changes. It's nice to be able to have experimental branches without them needing to be stored in the central repository that everyone on a project uses. Also great is the concept of the working directory, and how easily and quickly the files in it change as you change branches. Having one directory you can work from with all the different branches of your project has many advantages. I think I'll get in to that and some details of how I'm starting to make use of Git at work in my next post, which will probably be related to using Git locally with a central CVS repository.