Roop says

JVM Language War

Posted on December 7, 2007 by Daniel Roop

Today it seems that certain people have their panties in a wad over a post from Charles Nutter on how to make Ruby syntax look like Groovy syntax.

When I first saw Charles’ post I immediately saw it as a tool to help a friend of mine who is familiar with Groovy syntax understand Ruby syntax a little bit better. And I think Charles was attempting to show how powerful Ruby is as a language, and how easy it is to make the language read how you want it. I think it is importnat to note what Charles was attempting to do. He was not attempting to implement an interface so that it could be used from java, he was trying to make Ruby syntax look like Groovy syntax. This is important because if he wanted to implement the as method he could have done something as simple as this:


class ::Object
  def as(interface)
   self.class.class_eval do
      include interface
   end
   self
  end
end

I didn’t actually test this code, but I can’t imagine I am too far off here. If this does work than you could very easily dynamically add an interface to a class.


x = myObject.as java.util.Iterator

And as long as myObject has a hasNext, and next method in it’s class definition then Java should be able to use the class just fine. I think it is also important to point out, that there is never a good reason to actually do what his example did in ruby. Unless you are sending the object out to Java you don’t need to implement the interface.

So in my opinion all the things that Graeme complained about were irrelevant in the context of Charles’ post. They are just the blatherings of someone who has a personal issue with someone else’s work for no apparently good reason. I think Charles said it best in his comment on Graeme’s blog

“Come on Graeme…Groovy’s doing fine. Take the high road and let the language live its own life. It will be better for it.”

I agree, Groovy is a good language, and has amazing qualities all on its own, just like Java, C#, Python, SmallTalk and the millions of other languages that exist. There is no need for a language war, especially a one-sided war. I don’t think anyone in the JRuby community is going around saying Groovy is a bad language and shouldn’t be used. In fact even though I am a huge advocate of Ruby and JRuby I supported the idea to look into Groovy and Grails first for our Java stack at work. We came to the conclusion to look into JRuby and Rails because although Groovy is a very mature well balanced language and great enhancement to the Java language, Grails does not seem to have the same level of polish and finesse that the Groovy language has accomplished.

At the end of the day, I applaud Charles for his openness and support for all languages on the JVM. I believe nothing but good things can come from the collaboration of the language implementors, including but not limited to better performance and improved language constructs. And I think it is important to note that my experience with the Groovy community has been nothing but good, current anomaly excluded.

Posted in languages | Tagged groovy, java, jruby, jvm | Leave a comment

Eric Evans Presentation at JAOO

Posted on November 21, 2007 by Daniel Roop

I was clicking through infoq this morning, and came across a presentation by Eric Evans on DDD. Eric wrote the book Domain Driven Design. I have not yet had the pleasure to read this book, but I will be sure to put up a review as soon as I get to it.

I first heard about Eric through the Software Engineering Radio Podcast. He was inerviewed in a very early episode, and his ideas really resonated with me. If you are interested in DDD or haven’t yet heard much about DDD, I would strongly encourge you to look into this development philosophy. It seems to be rooted in the same fundamental ideas as BDD and TDD, but I think Eric reached his conclusions through a different path, so he has a slightly different perspective than what the BDD guys bring to the table.

Posted in development, programming, software, theory | Tagged bdd, book, oo, tdd | Leave a comment

Recording with multiple inputs into GarageBand

Posted on November 18, 2007 by Daniel Roop

I have found that it was a lot of work to record three seperate tracks, on three seperate computers and then sync them all up afterwards for 2nd Player. So I did some research to figure out how I could record multiple inputs into a single garage band session.

I found this article about how to use Audio MIDI Setup to configure an Aggregate device. That worked great on everyone else’s computer, but mine! First let me say that this is a really cool tool, you can basically get a USB hub(~$10) at your local electronics store instead of a firewire mixier (~my arm). For someone just starting off in podcast this is a huge savings.

Back to my problem…Unfortuatenly I couldn’t get this to work on my MacBook Pro Core Duo. This wouldn’t be a problem if everyone was using the same version of GarageBand, but I have not upgraded to iLife ’08, so if Bucky recorded two tracks, he would have to export them as one aif file (which isn’t good for mixing).

My problem wasn’t actually not being able to create the aggregate device, rather, it was that it would not save the settings for programs to have access to.

SOLUTION: I run as a standard user. I know I probably don’t need to, but the fact that it works so great 99.9% of the time, I do. But for some reason, OS X did not feel the need to let me know that I did not have credentials high enough to save my Audio MIDI Setup changes. So to fix this, I just simply needed to log in to my admin account, and create the aggregate device.

In my experience I didn’t need to stay logged into the admin account once the device was created, but if you are having problems, that is where I would start. I hope this helps some other poor sap, that happens to have the right conditions for this to be a problem.

Posted in music, software | Tagged garage band, mac os x, podcast | 1 Comment

When is a Tool not a Tool?

Posted on November 12, 2007 by Daniel Roop

A couple weeks ago my colleague Brian LeGros published an article about Object Persistance and Architecture. It was a very good article in his series on design practices, but it made me think about some struggles I have had when working with persistance frameworks.

Before I begin I want to attempt to establish two seperate types of frameworks. The first type are like Rails, Fusebox, PureMVC, and Django. These frameworks establish guidelines for laying out your application, and are meant to be worked within. I believe this type of framework is usually used at the presentation layer.

The second type of framework is meant to work within your design, or help you achieve your design. This is important because the other frameworks you design within, these frameworks help you design. I hope I am getting my point across here, it seems a little confusing. These frameworks usually help you achive a specific goal, like persist your data, wire your objects, or validate your domain. Some examples include Coldspring, Hibernate, and OVal.

This brings me to the point I want to make with this post. The first type of framework dictactes how your project is designed, the second should not. The second should be used as a tool inside your design, and I think this is where many people, including myself, have shot themself in the foot when using these tools.

Lets take Hibernate as an example. Hibernate, if you don’t know, is a Persistance Framework aka ORM aka Data Mapper for describing and transfering your Relational Model to your Object model. If you are layering your application like a good developer you will use this tool in the integration layer.

Now this is my opinion, but I believe that the layer boundaries should not be crossed unless you have a really good reason. I personally do not think that using Hibernate, a tool, is a good reason to break my layering, and allow Hibernate to dictacte how I design my domain. This has really been a hard thing to do in practice, I find myself wanting to solve the problem as fast as I can, and I ignore any good layering or design practices. I allow my tools to dictate what my domain looks like. Although this will be good for churning out a quick product, I think in the long haul of an application, the maintence will be much easier if you have a well thought out business layer.

I didn’t mention iBATIS above but I like this persistence framework better than Hibernate because it allows me to very easily hide all the database details in the integration layer and not does even define any facilities that would possibly encrouch into my business layer.

At the heart of this post I realize I am reallying encouraging focus on each problem in the appropriate layer. Focus on solving the business rules in the business layer, solve the persistence problems in the integration layer. In addition I would suggest focusing most of your time and attention in the business layer, and leave the persistence layer for last. If you do this, in the long run you will have an easier time making changes to your application as business rules change. Because you won’t have to worry about how it affects how you save an object, because that is not a concern of your business layer, that is a concern of your integration layer.

Posted in development, programming, theory | Tagged framework, hibernate, java, rails, spring | 4 Comments

Buildr Apache

Posted on November 5, 2007 by Daniel Roop

Big Congrats to the Buildr team for getting accepted into the apache incubator program. I haven’t been working with Buildr as much since my team decided to go with Maven (for now) but it is a great alternative to Ant or Maven for the Java community.

Posted in build | Tagged ant, buildr, maven | 1 Comment

Flex Frameworks

Posted on October 24, 2007 by Daniel Roop

Recently there has been a lot of discussion at my office, and online about whether or not a framework is necessary in Flex. Before revealing my opinion I wanted to go over a few reasons why I believe frameworks are used.

I went to Wikipedia and looked for a list of common features in web application frameworks. I choose web frameworks because I believe most Flex developers are coming from a web background. I found a comparison chart of the most common application frameworks, so I based my list off of their chart.

Ajax Help
i18n
ORM
Testing
Database Migration/Versioning
Security
Template System
Caching
Validation (Model/Form)

I felt the need to add a few points that were not listed on their comparison

Common Application Structure
Common Request Flow

Now to begin this discussion let’s talk about the items that don’t apply to flex.

Ajax Help: I don’t think I need to say much here. Flex itself is a RIA Framework. More importantly Flex is Flash, and Flash was the original Ajax.
i18n: Fortunately the Flex engineers in their infinite wisdom realized that more and more applications are needed to i18n. I would assume this knowledge came from the fact that most of Adobe’s clients are government organizations, and I would imagine they need to internationalize a lot. Lucky for us we don’t need to solve this problem, we just need to figure out where to store all the properties.
ORM: At the end of the day Flex was designed for building user interfaces, just like HTML and JavaScript. How many HTML ORM frameworks exists? I have heard rumor of a mysterious technology that allows you to connect to a database via JavaScript, but I have yet to confirm the existence of said technology. So I think we can all agree that ORM is a problem that the backend webservice, or remote object will have to address, not Flex, or it’s framework.
Database Migration and Versioning: See previous point
Security: I believe this is the first of a few places where the problem is different in Flex than in Web based Applications. In this case I believe it is almost a non-issue since Flex is stateful, you don’t have the added complexity of maintaining a users session/credentials, in a stateless application. I do believe that there are security issues with Flex but none that warrant a full blown framework handling them.
Template System: First let us define a template system. A template system is not where the view files go, it is what the view files are written in. In the case of Fusebox, or Model Glue, you use a mixture of HTML and CFML. In Java you can choose from Velocity or JSP as your template language of choice. In Flex you have MXML, that is it. In the future some one might come up with a different templating system, but I believe Adobe/Macromedia engineers have developed an extremely powerful templating language, that works very will with ActionScript.
Caching: In web frameworks this traditionally has to do with saving the rendered HTML from the dynamic ColdFusion or PHP to improve performance. This cuts down on processing time, and increases the possible requests per second. Since flex is a compiled artifact, that is delivered all or nothing, there isn’t much caching can help you here.
Validation: Flex has a validation framework. Although I have gone back and forth as to how heavily it should be used, I think it solves the problem domain in the UI. Unfortunately it is very difficult to plug it into some backend validation framework, so if any work is to be done, it would be creating this bridge.
Common Request Flow: This one is complicated, I think in the context of how web developers currently think about this problem, it doesn’t need to be solved. At the very least it doesn’t need to be solved the same way it is solved in web applications. Flex is a stateful application and should be treated as such. Typically an event/message system is used to manage stateful applications. That is why I was so excited about Model Glue: Flex. I never cared much for Model Glue in ColdFusion because I thought the whole event system was awkward, but in Flex it made perfect sense.

Posted in languages, programming, theory | Tagged flex, framework | 3 Comments

Assert Property Equality

Posted on October 23, 2007 by Daniel Roop

When you start doing more thorough testing of your code you will quickly find that the existing JUnit functionatly is not always robust enough to relieve some of the tedium in testing. Let’s take for instance a simple equals method for a person object.


public boolean equals(Object o) {
   Person person = (Person) o;
   Boolean isEqual = true;

   isEqual &= (firstName == null && person.firstName == null) || (firstName != null && person.firstName != null && firstName.equals(person.firstName);

   isEqual &= (lastName == null && person. lastName == null) || (lastName != null && person. lastName != null && lastName.equals(person. lastName);

   return isEqual;
}

Moving past the crazy Java code necessary to handle all the edge cases for equality between two objects, you will begin to notice all the edge cases you need to test. Here are the ones I noticed:

Same Object is Equal to Itself
Different Object Instances with Same Values are Equal to Each Other
If (insert property here) is null it is equal
If (insert property here) is null on one object but not the other it is not equal
If (insert property here) is not null but different than another object it is not equal

As you can see there is a minimum of 5 test cases for equals, and for each property you add, there is 3 more tests that need to be written. After copying and pasting a lot of code today, I decided to come up with a more reusable method. (Thank you Kent Beck…Red Green Refactor!)

So I came up with a little test Utility


package com.danielroop.test

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

import java.lang.reflect.Method;

public class TestUtil
{
   public static void assertPropertyEquality(Class c, String property, Object value1, Object value2) throws Exception
   {
      assertPropertyNotEqualWithDifferentValues(c, property, value1, value2);
      assertPropertyWithOneNullIsNotEqual(c, property, value1);
      assertPropertyWithOneNullIsNotEqual(c, property, value2);
      assertPropertyWithBothNullsIsEqual(c, property, value1.getClass());
      assertPropertyWithBothNullsIsEqual(c, property, value2.getClass());
   }

   public static void assertPropertyWithBothNullsIsEqual(Class c, String property, Class type) throws Exception
   {
      Object instance1 = c.newInstance();
      Object instance2 = c.newInstance();

      String propertyName = property.substring(0, 1).toUpperCase();
      propertyName += property.substring(1, property.length());

      Method setter = c.getDeclaredMethod("set" + propertyName, type);

      Object[] args = new Object[1];
      args[0] = null;

      setter.invoke(instance1, args);
      setter.invoke(instance2, args);

      assertTrue(instance1.equals(instance2));
      assertTrue(instance2.equals(instance1));
   }

   public static void assertPropertyWithOneNullIsNotEqual(Class c, String property, Object value) throws Exception
   {
      Object instance1 = c.newInstance();
      Object instance2 = c.newInstance();

      String propertyName = property.substring(0, 1).toUpperCase();
      propertyName += property.substring(1, property.length());

      Method setter = c.getDeclaredMethod("set" + propertyName, value.getClass());

      Object[] args = new Object[1];
      args[0] = null;

      setter.invoke(instance1, value);
      setter.invoke(instance2, args);

      assertFalse(instance1.equals(instance2));
      assertFalse(instance2.equals(instance1));
   }

   public static void assertPropertyNotEqualWithDifferentValues(Class c, String property, Object value1, Object value2) throws Exception
   {
      Object instance1 = c.newInstance();
      Object instance2 = c.newInstance();

      String propertyName = property.substring(0, 1).toUpperCase();
      propertyName += property.substring(1, property.length());

      Method setter = c.getDeclaredMethod("set" + propertyName, value1.getClass());

      setter.invoke(instance1, value1);
      setter.invoke(instance2, value2);

      assertFalse(instance1.equals(instance2));
      assertFalse(instance2.equals(instance1));
   }
}

It isn’t the cleanest code, but it does handle the property equality cases. So to implement this, you would just staticly import the assertPropertyEquality method (or call it using the static reference TestUtil.assertPropetyEquality). What I ended up doing in my tests, is setting aside a single method for testing property equality like so.


@Test
public void testPropertyEquality() throws Exception
{
   assertPropertyEquality(Person.class, "firstName", "Daniel", "Tyler");
   assertPropertyEquality(Person.class, "lastName", "Roop", "Hunt");
}

The first paramenter is the object that should have the property set. The secod paramenter is the java bean property that should be set. The thrid and fourth parameter are two different valid values for the property.

I am not sure if this is the best way to solve this problem, but it seemed to reduce my copy/paste code significatly.

Posted in programming, testing | Tagged java, junit, tdd | Leave a comment

2PP Episode 4: Bungies the Chick

Posted on October 12, 2007 by Daniel Roop

The last couple weeks have been pretty busy for me. Between giving presentations, at work and at usergroups, and working on the 2nd Player Podcast. Well next week should slow down considerably and I hope to put out a few more posts about coding. One is going to be about Persistence Driven Design, which I don’t even know what that means, but I know I have an opinion. And I am currently trying to formulate my ideas about how Component Driven Design fits into how to design Flex Applications, and whether or not having a “framework” like Model-Glue Flex or PureMVC is really necessary in Flex or even makes sense.

That being said, please check out the fruits of my recent work on the latest episode of the 2nd Player Podcast.

Posted in gaming, programming | Tagged 2ndPlayer, flex, framework, model-glue | Leave a comment

JVM Language War

Eric Evans Presentation at JAOO

Recording with multiple inputs into GarageBand

When is a Tool not a Tool?

Buildr Apache

Flex Frameworks

Testing

Common Application Structure

Remote Requests

No Global Event System

Assert Property Equality

2PP Episode 4: Bungies the Chick

Blogroll

Other Me

Archives