Changing Themes

I’ve decided to change this blog to a personal one, not about programming or anything else technical, so I can focus all of my programming posts on Inside The Machine.

Great definition of DSL… for the many misguided

Recently a friend of mine pointed me to an article posted by Martin Fowler on DSL’s in kind of a Q and A format.   (http://martinfowler.com/bliki/DslQandA.html).  It does a suberb job of explaining what a Domain Specific Language is.

Anyone who calls Excel*, or Eclipse, or Internet Explorer (yes I’ve even heard this one), a DSL should read it!  When most uninformed people talk about these as DSL’s, they probably mean DSA (Domain Specific Application… probably can’t find that on wiki, I think I just made it up).  But then aren’t most applications domain specific, as oppose to languages which can be General Purpose or Domain Specific?

(*VBA for Excel and/or the formula language used inside the Excel spreadsheet could be classified as DSLs.  For VBA for Excel, what would make it an (Internal) DSL versus still a GPL, is that you have references to extra (implicit) objects that only make sense in the context of working with a Workbook.)

Gas Cost Averaging

Despite my best efforts, I can’t remotly tie this to a technical/programming related post, but I can raise the, “it’s my personal blog and I’m going to do it anyway”, flag.

Recently, I’ve been trying to educate myself on saving/investing, and one (apparently basic) concept that I had no pevious knowledge of is Dollar Cost Averaging.   The idea applies to securities, where you invest the same amount of money at a constant interval of time, say quarterly.  So if I want to invest 1000 dollars a year, I could invest quarterly 250.  What this would do is buy me less shares of my security during the quarters it was on a high, and more shares when on a low.  The result is that you end up with a greater rate of return than if you had bought the same amount of shares when it was high or low, and therefore have a greater rate of return.

So I was noticing gas prices were pretty good yesterday and this idea hit me.  What about Gas Cost Averaging!?  It would work in a similar fashion, but save you at the pump over time.  You would buy 10 dollars every other day, or 5 or whatever makes sense for you depending on your driving habits.  But the idea is that you would spend the same dollar amount each time you put gas in and you’d go on regular intervals, regardless of prices that day.  The same dollar amount is important as it means you buy less gas at higher prices, and more gas at lower prices.  Unlike a stock for example, you wouldn’t get hit with a brokerage fee, on the other hand, you would get hit with inconvenient, frequent trips to the gas station.

I like the idea.

Thoughts?

SlideRocket

A new slide presentation tool is coming out called SlideRocket.  It is awesome!

Think Google Docs slide presentation tool, but with the rich capabilities that Flex/Flash can give you.  It’s easy to use and can import from other products such as MS PowerPoint and Google Docs spreadsheet documents.

I encourage anyone who creates presentations ever to take the tour that is linked on the main page.  It’s an example slide deck that they put together to showcase some the capabilities.  When looking at it, you can go full screen by clicking the Full Screen button at the bottom right corner.  One thing I should mention that wasn’t intuitive to me at first is that you have to click the slides to advance them, versus pressing the down arrow as in PowerPoint.

If you’re interested, sign up for the beta.   It will probably take a couple of weeks for them to respond, so no worries if you don’t hear back immediately.

Learning Scala

Some friends of mine that I work with and I are all trying to learn Scala. We’ve made a pact to learn something new each week. Our plan is that each week we’ll show our simple program illustrating whatever concept in Scala we decided to learn about the week before, and then decide on the topics for next week.

Last Monday was the end of our first weeks assignment, that of creating a simple Hello World Application. Our thought was that this would get us through the installing of the Scala compiler, interpreter, etc. The assignment for this week and to create a program that illustrates traits and mixins, or at least to understand them. The following are notes I’m taking are to assist in my learning process.

Traits

Traits are the simpler of the two concepts Mixin’s and infact are part of what makes them up. Traits are mechanically similar to abstract classes in Java, but are meant to be thought of in more of the way that an interface is in Java, and that is that they are meant to contain the signatures of the supported methods of a class. They just happen to allow implementation as well in Scala. This differs from my interpretation of what an abstract class is meant for in general, which is to abstract common functionality of related objects in an object hierarchy and support polymorphic behavior (which interfaces do as well).

One important note about a trait is that they cannot have constructors with arguments. (Which may be more commonly referred to as parameters is Scala?? I don’t know. The Scala documentation site refers to themas parameters when pointing the constructor part out.) Anywho, it would seem that in most cases you wouldn’t have a reason to rewrite the default constructor unless to provide a default value for one of the instance variables that takes more than one line of code to accomplish it.

Finally, you use ‘extends’ or ‘with’ to implement/extend traits it appears, rather than the keyword ‘implement’. I would have used ‘exhibit’ instead of ‘extends’. It just seems to make it read more like a sentence to me.

Traits are used frequently with other traits and/or abstract classes I think to create Mixin’s.

Mixins

Mixins allow you “to reuse new member definitions of a class”.. yeah.. that seems a little confusing. Their example that they then give makes more sense to me, but I still need to think to wrap my mind around it here..

So, they show an Abstract class, then a Trait that extends it and adds another new method. They then have another concrete class that extends the original Abstract class, giving you the following relationship.

Next they show an example usage of all three classes. They create a class that extends the ConcreteImpl ‘with’ the Trait. (i.e. class jabba extends ConcreteImpl with Trait. This new class inherits the methods of all three ConcreteImpl, Trait, and Abstract classes. The example says that the first parent (ConcreteImpl) is the superclass of jabba and the second parent, third, and so-on are, starting with the trait I called Trait above are the Traits of the jabba class. If I read the example correctly it sounds like the traits cannot overlap methods found in the abstract class that they extend. Is that correct anyone?

Okay, it’s making a little more sense now. So Mixin’s are a way to structure your class hierarchy so that you effectively get multiple inheritance. One question I have though is, can I use all traits so like “class jabba extends trait1 with trait2, trait3, …, traitN” (where trait2 through traitN would extend trait1)?

I tried to copy, compile, and run the example they code they had on the Mixin’s page and it didn’t run, but I think it’s because I tried to do it at midnight when tired and probably messed up some mundane detail, like put a decimal in the wrong place or something.

Well, I think that’s enough study for participation in the group tomorrow.

Groovy Ignores Scope

Let me start out with.. I like Groovy. I haven’t used it extensively yet on any of my projects, but I have done odd jobs with it.

With that said, there seems to be an important issue with Groovy in my opinion and I don’t understand why there aren’t many posts about it, or why it’s not mentioned in the documentation, or why it still exists… Groovy does not currently enforce scoping constraints.

Take the following for example:
class PrivateMethodClass {If you were to attempt to call any of these private variables/methods in Java, outside of the PrivateMethodClass, you would get an error when attempting to compile. In groovy on the other hand, this is totally acceptable to do.

private static String privateMessage = ‘foo’
private static String getPrivateMessage() { ‘boo’ }

private String privateInstanceMessage = ‘instanceFoo’
private String getPrivateInstanceMessage() { ‘instanceBoo’ }

private static void sayHelloStatic() { println(’hello static’) }
private void sayHelloInstance() { println(’hello instance’) }
}

 

So in Groovy this:
class PrivateMethodClassTest {public static void main(String[] args) {

println ‘attempt to call static.’ 

PrivateMethodClass.sayHelloStatic() 

new PrivateMethodClass().sayHelloInstance() 

println PrivateMethodClass.privateMessage 

println PrivateMethodClass.getPrivateMessage() 

println new PrivateMethodClass().privateInstanceMessage 

println new PrivateMethodClass().getPrivateInstanceMessage()
}
} 

Yields:
C:\projects\grovvyScopingFlaw>groovy PrivateMethodClassTest.groovy
attempt to call static.
hello static
hello instance
foo
boo
instanceBoo
instanceBoo

There is a Jira issue for this at http://jira.codehaus.org/browse/GROOVY-1875 and it is supposed to be fixed in 2.0 if I’m reading the issue ticket correctly.

I debated about whether I should post about this or not as I thought this might be old news, but as I mentioned this to people around me who are very interested in Groovy, I got a lot of surprised responses. So there it is.

Annotation @Override: Making the compiler work for you

I was writing/running JUnit tests for a project at work today when I came accross some odd behavior with the assertEquals method. Before I go into the problem, let me over simplify the model I was working with.

I created a class Foo that extended a class Boo, written by another project team. Boo overrode the Object.equals method (or so I thought), as shown in the diagram below.

Now from the simple diagram, coupled with the fact that you know somethings up, you may have guessed that they didn’t really override the equals method in Boo. They overloaded it by changing the signature from

boolean equals(Object boo)

to

boolean equals(Boo boo)

This was a mistake on their part, an oversight on mine, and the result was the following statement in my JUnit test failed

assertEquals( fooA, fooB );

Whereas the following statements passed without a problem.

assertTrue( fooA.equals( fooB ) );

assertTrue( fooB.equals( fooA ) );

It took me a while to take notice of the signature mismatch on Boo.equals. (no jokes or insults please ).

It passed on assertTrue because assertTrue invoked fooA.equals( fooB ), and when the JVM didn’t find an exact signature match on the method in Foo, or a method of equal name but more general types, it went to the next closest match, which was the equals method of Boo taking a Boo for comparison.

It failed on assertEquals because assertEquals treated both objects passed in as java.lang.Objects. This meant that the equals method of Object, unless overridden, was going to be called. Since it wasn’t overridden, the result was the equivelant of fooA == fooB.

My Point

My point is that, if they had put an annotation tag @Override on their equals method, Boo wouldn’t have compiled in the first place and I wouldn’t have gone through this. And I thought it was worth brining attention to on my blog as I haven’t seen many people use it yet since made available in Java 1.5.

My First Post

So I have a blog. What does one say on their first post? I do not know.

Weebles wobble, but they don’t fall down!

How’s that. Future entries will hopefully be more technical in nature than this.

That’s all for now. Thanks for reading.