The Road to Scala

To be honest, Scala has been on my periphery for some time now. I had heard of it before, but the first real mention I actually remember was a talk Ted Neward gave at No Fluff one year. I couldn’t go to that talk, but I remember him talking about it a few times some other talks he did that weekend.

Fast-forward 2010. When I went to Strange Loop, there was some buzz on Scala. Of course, Scala is kinda mainstream for Strange Loop then so there wasn’t that much talk on it, but there was buzz. Of course I ignored it.

So, with all that, this is what I knew about Scala:

• It’s statically-typed. Since Python has been my first love, I really can’t get into static typing. I see the benefits, but writing code in those languages makes it feel pedantic.
• It runs on the JVM. I already have Jython as my JVM-alternative of choice.
• It’s kinda functional and kinda OOP. OK, Python is also like that, but that idea weirded me out.

Then we fast-forward to just a couple months ago. I read this excellent blog post and thought he was spot on when talking about the perils of modern day software developers. I honestly know nothing else about Michael Church, but he was spot on in the second part, so how right was he on the first part — the list of languages?

I already know Python and C. And, OK, not ML and Clojure, but I know what their general idea was. And then there was Scala again. It was this thought that got my attention:

I think Scala is the language that will salvage the 5 percent of object-oriented programming that is actually useful and interesting, while providing such powerful functional features that the remaining 95% can be sloughed away. The salvage project in which a generation of elite programmers selects what works from a variety of programming styles — functional, object-oriented, actor-driven, imperative — and discards what doesn’t work, is going to happen in Scala. So this is a great opportunity to see first-hand what works in language design and works in language design what doesn’t.

And I’m all for that — there are some good parts of OOP, but a lot of it has become painful. All the styles Church listed have some merits as well as downsides. If you can actually do all of them, then the cream of each style should rise to the top.

Another one of his thoughts grabbed me was:

[Scala] has an incredible amount of depth in its type system, which attempts to unify the philosophies of ML and Java and (in my opinion) does a damn impressive job.

Incredible type system? In a static language? I have yet to see such a beast. OK, the only static typed languages I have used are Pascal, C, and Java, and not one of them are good.

So, not to lengthen this anymore, I decided to dip more than my toe in the Scala waters and see what all this hype was about. After mucking with it off and on for about a week, I have to say that I’ve impressed. Actually, more than impressed: I haven’t had this much joy in discovering a language since I started banging on Python over 10 years ago.

I’m far from a journeyman in Scala, but I’m getting up to speed on it rather quickly. When I learn something, I need to be a do’er , not a reader. I’ve been using Scala Koans to play with. It uses SBT to continuously run the tests, which is very cool. When I get to the point of mucking around a little deeper, I use Scala Test with SBT to give me the same continuous feedback.

I recently did Osherove’s String Calculator kata to Step 6 in 30 minutes, without any Googling or even too much fumbling. That says something about how easy it can be to get started creating code that actually does something.

Here are some things I have learned to love in Scala:

• Pattern Matchers. This is probably my favorite. Now that I have groked them, I may never want to write a parser in anything but Scala ever again. I should also state I avoid switch-case statements of any kind in any other language but that structure works really well for Scala’s pattern matching. When you use them with regular expression groups, magic happens.
• Case Classes. It does a lot of the boiler plate of making objects for you, and you get a sane equals to boot. And, as the link says, they go nicely with pattern matchers.
• The static type system does make sense, and does not annoy me. Look at this line: val negatives = numbers.filter{ _>0} What is numbers? Well, since we are filtering it, it must be a collection of some sort. Is it a List or is it an Array? Then what is negatives? Well, since we are using filter, it must be the same kind of collection that numbers is. But my favorite part is this: it doesn’t matter. I know how negatives should behave, because it should behave just like numbers does. This makes sense to me, so much so that a type declaration for negatives becomes superfluous (hello Java …)

Now there are things that have annoyed me in Scala. But I’m a beginner so I think some of those things will iron themselves out. I’ve been coming up with web app ideas that I can start writing in Lift, which probably says something about how how I feel about learning it.

Formatting Date in Lucene Queries

Little did I know that my adventures with Terracotta would soon require me to dip my toes into Lucene so, you know, we could actually find the objects in Terracotta.

So I had an odd problem where Lucene was only searching by the year. For example, I had an object with the date of 20090915. And so I made my date range as:

datevalue:[19000101 TO 20091231]

And that worked fine. Then I changed the query to:

datevalue:[20090101 TO 20091231]

And it didn’t find it! Why not?

Even though it’s not spelled out in the documentation, you have to use the ISO Format for date/time objects. So I changed the query to:

datevalue:[2009-01-01 TO 2009-12-31]

And it started working

Using Jython as a Terracotta Command Line

My new position at work was best described to me from my AVP: “Figure out how to make it work.”  The first thing that I need to see if it will work is Terracotta.  Terracotta is cool stuff — more to follow on it later.  Probably.

If you know me well enough, or have been reading this blog for a while, you know that I’m a big fan of Python.  Well, if I need to figure out how to “make it work” it generally involves Jython.  That way, I can open a prompt up and noodle around at the object and see what makes them tick.  To me, this could be especially important in Terracotta since you have objects floating around everywhere.

Getting Jython as a command-line interface into a Terracotta cluster is trivial — almost not worth blogging about.  And the result is oh-so cool.

Here is my Jython script. It just imports some common things and a Spring application context, and then get an object from the context. That object contains my Terracotta root object, which means that it stays in sync across my client and server JVM’s.

import sys,os

from org.springframework.context.support  import ClassPathXmlApplicationContext

if __name__ == '__main__':

    ctx = ClassPathXmlApplicationContext("applicationContext.xml")

    worker=ctx.getBean("worker")

Not that there isn’t anything specific to Terracotta in there — just like it should be.

I then wrote a shell script to setup my environment and run my Jython script in a Terracotta-instrumented environment. I actually run everything in Windows (unfortunately) so I have some Cygwin magic in there to change the classpath and to run the dso-java.bat in a cmd window:

#!/bin/sh

cp="dowork.jar:/c/Projects/jython2.5.1rc2/jython.jar"
cygstart bin/dso-java.bat -classpath `cygpath -mp $cp` org.python.util.jython -i $1 $2 $3 $4 $5

This allows me to run any script in a Terracotta cluster and then keep a command line open to I can muck around with stuff. Thejython.jar I use is a stand-alone install. I’ve just found that easier than worrying about where all modules are.

So now I just enter the shell script name with my Jython script as an argument and away I go!

And this works exactly as I expected. I can see the state of the root in the worker object, update that state in another clustered JVM, and then see that state immediately in my Jython prompt.

I’m sure you can do the same with Groovy, JRUby and their ilk. But I use Jython. It’s just how I roll

Getting Cygwin and Java to play together

I hate it when Open Source projects can’t handle the fact that I run everything in Cygwin.  Yes, I still want to use your run.sh file and have it understand my Java interpreter. Yes, classpath and everything!  It’s not hard people!

Luckily, I keep this script handy, which I stole from ANT years ago:

case "`uname`" in
  CYGWIN*) cygwin=true ;;

esac

# For Cygwin, switch paths to Windows format before running java
if $cygwin; then
  JAVA_HOME=`cygpath --windows "$JAVA_HOME"`
  CLASSPATH=`cygpath --windows --path "$CLASSPATH"`
fi

Long Time, No Blog

Yep, it’s been a while without anything meaningful.  I’ve had a few things that I’ve though “I need to blog about that!” but never have.  So here is a list of utterly random things that may or may not make any difference to you:

• We now have two foster children.  The whole foster process is quite lenghthy and, really, it’s not easy.  As soon as you think things are getting better boom something happens and you feel like you are starting from scratch. I could go on and on and on about this but I’ll simply say: your prayers are coveted.
• I looked at my blog a few weeks ago and noted that my Diigo feed was making it look like a spam blog.  Sorry about that — I shut it off.  If you still want to see my bookmarks goto Diigo and do an RSS subscription there. Or join up and be my “friend”.  It’s actually a pretty cool service.
• Trying to add JMS Replication into Ehcache is a hard, difficult feat.  At first you may thing that reading Ehcache’s documentation may give you the answer but, alas, it wrong.  Wrong!  Pure wrong! It took lots of logging and looking at the source to figure out what was happening.  Look at my StackOverlow post and answer for the play-by-play configuration.
• We knew that the time was coming to get a new van.  Last year the air conditioning quit working and we weren’t ready to spend the $800 to fix it just then.  Our plan was to get it fixed this spring, have it last the summer, and get something this fall. And then the cruise stopped working and the horn didn’t work.  This past week,  Gina called me at work and said that the speedometer didn’t work and the coolant light was on.  I took it in and got an estimate to fix all the things wrong were $3500.  Then I drove it a little bit and noticed that it wouldn’t shift out of first gear!  $5000 for a new transmission!!  So $8500 to fix a nine-year old van?  No way!!    So Gina and I went van shopping yesterday and got a 2004 Honda Odyssey. We had a new Civic just before Leah was born and loved it!  But we didn’t think we were going to be able to get another Honda for a while.  Even used Odyssey’s are hard to come by, but the local Honda dealership (literly down the street) had a few.  Between the market now and, well, our desparation to have a new-for-us van, we got it done.  They even took our old van — and, yes, I drove it there in first gear.
• Jupiter is a really good code-review tool.  It’s built into Eclipse, so you can make comments, submit the comments via source control, and the rest of the team and see them and fix them.  This makes reviewin code with an offshore team much less painful.
• I promise to blog more often — maybe just little blips, but I will do it. I’m sure both of my readers will appreciate it.