This weekend I traveled to Portland for the memorial service of my uncle, Al Miller. Al was a special guy and I wanted to write down some of the things I’ve been thinking about since his death, especially after being surrounded by his large and loving group of family and friends.

It’s hard not to start talking about Al without talking about polycystic kidney disease. Most people develop PKD later in life and may not even know they have it. But Al started showing symptoms when he was just 12 or 13 years old. He and my dad Jim were tested at about that time and my dad was told he had a mild case but my uncle had an acute case. This was the first time doctors told Al that he wasn’t going to live that long.

My grandfather also had PKD disease and died a few years later. My grandmother Vesta had to start teaching to make ends meet and they were very poor for several years, apparently living on not more than onion sandwiches if my dad is to be believed. Jim and Al didn’t have a lot of supervision and spent most of their days wandering rural Missouri on the outskirts of Sedalia, doing what boys do when left unattended.

I’ve heard just hints of many stories from this time – tales of BB guns, firecrackers, girls, and the things boys naturally get follow when allowed to run free and wild. According to my dad, Al was the most brave and fearless person he ever met. Al and Jim used to sneak out in the middle of the night and roll the car down the road to start it and then go on hair-raising joy rides through the back roads, probably nearly killing themselves more than once.

I don’t know a lot about Al in those younger years but I know he played basketball (wearing a fiberglass brace to protect his kidneys) and the string bass. He ultimately went to college at Central Methodist University in Missouri where he made a name for himself as part of a group that staged a sit-in of the administration building in support of a teacher. He was invited not to return. :)

Al moved to Portland after that and lived there for the rest of his life. It was clear to me from his service that he spent the next forty years in Portland participating in, and perhaps more importantly, building communities around his passions.

Al’s early years in Portland were spent at Oregon State and eventually he became involved with the Oregon Gaming Commission as a photographer. He was also making the connections at this time that would grow into his love for nature and conservation.

In his early 20’s, he received his first kidney transplant which lasted just eight months or so before it rejected. Soon after he received his second kidney transplant which would last many years. Al was a passionate believer in organ donation and he frequently asked me whether I had signed my organ donor card. Donors gave him a total of three kidneys over his life and by extension helped so many people.

My early memories of Al are happy ones as we usually saw him on holidays at my grandmother’s house or occasionally vacation trips out to the west coast. Once we rented a cabin with Al out on the Oregon coast. My memories are fleeting but I remember bunk beds, reeds, and the stark Oregon coast. I also remember meeting them to camp at Crater Lake once and sitting around the fire telling stories.

Al was always full of stories as anyone who knows him can attest. He told wonderful, funny, touching stories. It was hard to tell how much of them were actually true, but that made them no less enjoyable. :) The oldest story I can remember him telling us was one about my dad when they were kids. They shared a room and when my dad got up to go to the bathroom in the middle of the night, Al would jump up and close the door to their room. My dad would come running back from the bathroom and slam into the door. According to my uncle, he pulled this trick on my dad for years, although that may have been an Al embellishment.

In 1980 he inevitably (due to their interests and the circles they traveled in) met my aunt, Beth Parmenter. It’s hard to imagine two people better suited in temperament and interests and clearly they were made to be together. They married in 1985 in the Washington DC area where Beth’s parents lived. I was at the wedding (I was about 11 or 12) and I don’t remember too much of it except that it was very personal and joyful. I think it was the first time I ever wore a suit.

As many people attested at the memorial service, Al was masterful at having a vision for what should be done and then convincing other people to get involved. I don’t know the full extent of everything he was involved in over the years but I met people from all sorts of groups and projects and many of them had gotten involved because Al had gotten them involved and excited. Al was a tireless advocate for conservation, the environment, birding, and various political causes. He loved to get people together with potlucks, clear trails, and was always willing to help others if they needed a hand.

Al had a way of talking with people that just drew them out and made them feel special. Going places with him was a trip because you never know when he was going to grab some guy in the street or a restaurant and get into some crazy conversation about hats or yo-yos or who knew what. He made connections with people like breathing in a way I always envied.

One of the unifying things many people shared with Al was his love of food and cooking. He loved to chat someone up in a restaurant on the way to a table to find out about what they were eating. I think he would have sat down at someone’s table and tried it if someone hadn’t pulled him along. Every time Al ever cooked a meal around me, he got me to help all the while talking away a mile a minute about the ingredients, where he’d learned the recipe, some amazing meal he’d had somewhere.

Before I was engaged, my wife and I took a trip to the northwest and we crashed on Al and Beth’s floor for a couple days. He made me his famous salmon, which primarily involves drenching it in butter and parmesan, sealing it in foil, and baking on a grill. There was a lengthy story that went with the recipe that involved learning it from an indian in the backwoods somewhere. According to his wife, some of the elements of the story were even true. :)

Al loved kids. He had such a child-like love of the world and life that he seemed to naturally connect at a level most people don’t, especially people without their own kids. Al and Beth served as surrogate babysitters/aunt+uncle/friend to countless kids of their friends. Over the years I heard about them often from Al and Beth and met some on my occasional trips to Portland. They called him “Uncle Al the Kiddies Pal”. In his later years Al bought a tiny red Ford truck he called the Little Red Ranger and the kids loved that truck as much as he did. It is one of my great regrets that my kids never got to know Al or love him the way other kids did.

At some point, Al got into woodworking and eventually was a teacher at a woodworking school in Oregon. Clearly, he had both a natural talent for the craft and the eye of an artist based on his pieces. He made many beautiful things over the years but most famously a series of “dieter’s candy dish” tables. Each table featured a candy dish along with mortal hazards that had to be bested to get the candy. Some had dishes pierced with iron or blue spikes. One was a low wobbly table that moved if you tried to brace yourself while reaching over it. Another was a monkey’s paw where you could grab the candy but not pull your hand back out while holding it. Some common elements he used a lot were twisted wood and large numbers of spikes, often piercing another surface. I think one of the things Al loved so much about woodworking or kids or cooking was his love for teaching and involving others. He had a natural desire to always be sharing and wanting others to learn. And he loved learning from others as well.

One final aspect of Al I wanted to mention was music. I’ve always had a passion for music and Al always had a deep love of music and I found a connection with him there. Over the years I sent Al and Beth a number of mixed CDs with fun stuff I was listening to and I’ve heard he spent many hours listening to those and other CDs. When Al listened to music he really listened to it, often just sitting in a chair with headphones and not splitting his attention as many people do, but rather really focusing on the music. As far as I can tell, his musical interests were widely varied and he had little concern for genre. I always felt quite free to send him mixed CDs that ran the gamut from classical to jazz to rock, whatever I thought was good.

In particular, I’m thankful that he got me listening to Lyle Lovett. Someone Beth knows knew the cello player for Lyle Lovett and so they were big fans early in his career and at some point Al introduced me to them too. Lyle has always been a favorite of my wife and I and we ultimately chose to dance to a Lyle Lovett song at our wedding. I’m sure that wouldn’t have happened without the recommendation from Al years earlier.

Al touched many people throughout his life and his memorial service was a wonderful tribute with people from all times in his life present. I heard so many stories and I’m already sorry I’ve forgotten so many. Hopefully I captured a few here. Al’s enduring love of people, learning, teaching, sharing, and his belief in the ability to change the world were always inspiring. I won’t forget him. I love you Al.

Question: “Is it possible to write a multimethod that has defmethods which handle ranges of values? For example, say that a person has an age. Can I write a multimethod that accepts a person as a parameter and returns “child” if age < 16, "adult" if 16 <= age < 66 and "senior" if age >= 66?”

Answer:

Sure – how a multimethod “switches” to choose an implementation is abstracted by a function of course, specifically the dispatch function you give it when you create the multimethod. Very commonly, the dispatch function is just “class” to switch on type but it can be anything. Each defmethod specifies a specific value it matches on, so you can’t have a defmethod that directly matches a range (afaik).

In your example, you don’t really need a multimethod though – I would just use cond for that:

user=> (defn ticket [age]
         (cond (< age 16) :child
               (>= age 66) :senior
               :else :adult))
#'user/ticket
user=> (ticket 10)
"child"
user=> (ticket 20)
"adult"
user=> (ticket 90)
"senior"

Now, you could use the ticket function above as the dispatch function for a multi-method if you wanted to switch behavior based on those kinds of tickets and that would make some sense. Here I create a print-name multimethod that switches behavior based for a Person record using the ticket function on the age:

user=> (defrecord Person [name age])
user.Person
user=> (defmulti print-name (fn [person] (ticket (:age person))))
nil
user=> (defmethod print-name :child [person] (str "Young " (:name person)))
#<MultiFn clojure.lang.MultiFn@44547842>
user=> (defmethod print-name :adult [person] (:name person))
#<MultiFn clojure.lang.MultiFn@44547842>
user=> (defmethod print-name :senior [person] (str "Old " (:name person)))
#<MultiFn clojure.lang.MultiFn@44547842>
user=> (print-name (Person. "Jimmy" 5))
"Young Jimmy"
user=> (print-name (Person. "Alex" 36))
"Alex"
user=> (print-name (Person. "Edna" 99))
"Old Edna"

user=> (Math/max 5.2 2.7)
5.2
user=> Math/PI
3.141592653589793

But recently I need to get the Class of a well-known Java class, which I would normally have done with String.class in Java. This *looks* like a static field so I first tried to access it like one:

user=> String/class
#<CompilerException java.lang.Exception: Unable to find static field: class in class java.lang.String (NO_SOURCE_FILE:405)>

No dice. This makes sense when you consider that saying Foo.class is not really referencing a field, but rather a part of the Java language syntax (just like this.) defined as “class literals” in JLS 15.8.2.

Eventually it occurred to me that if (Foo/method) is a static method call and Foo/field yields the value of a static field then maybe just Foo is the class reference. Sure enough, it is! So if you are calling an API that requires a Class, you can just pass the name of the class to refer to the class of that type.

user=> Math
java.lang.Math
user=> (class Math)
java.lang.Class
user=> (seq (.getFields Math))
(#<Field public static final double java.lang.Math.E> #<Field public static final double java.lang.Math.PI>)

It’s sometimes helpful when working with Java objects to use bean to get a handy map view into the Java object:

user=> (map #(:name (bean %)) (seq (:fields (bean Math))))
("E" "PI")

Ehcache is the most widely used open source Java caching library. Terracotta (my former employer) bought Ehcache last year and I was intimately involved in tending it while I worked at Terracotta … just to make my relationship to this clear.

Periodically someone notices that Ehcache pings a Terracotta server when it is instantiated and periodically thereafter and sends it the following information:

• Operating system name (os.name)
• Java VM name (java.vm.name)
• Java version (java.version)
• Platform (os.arch)
• Terracotta version (if applicable)
• Terracotta product name/version (if applicable)
• Uptime
• Hash of IP address – used as a fingerprint for correlation

The Terracotta update check server sends back information about whether a newer version of Ehcache exists. If so, a message is displayed to the console.

This of course is no different in operation than what most of the other software on your desktop or most open-source app servers do these days. I’ll admit it’s a little unusual for a non-server library to perform this kind of check but I think that line is pretty gray if you ponder it for a minute.

Generally, people seem upset when they find this out and feel like the library is spying on them or in some way intruding on their application. I’ve listed above the information that is actually being sent and it’s nothing nefarious (being open source, you’re welcome to peruse the code yourself).

The update check is made in a separate background thread – it will time out if there is no response due to network setup and it safely handles conditions where thread creation is not allowed (Google App Engine most notably). You can turn the update checker off either in the Ehcache xml configuration (with updateCheck="true" on the root <ehcache> element), or programmatically if you dynamically create caches, or VM-wide with the system property -Dnet.sf.ehcache.skipUpdateCheck=true.

Terracotta expects and recommends that any production deployment of Ehcache will turn off the update check, just as it would likely turn off the update check in Glassfish, or any other such software.

I think it might be helpful to consider why Terracotta/Ehcache would want such a check in the first place. This information tells Terracotta how Ehcache is being used as a metric of adoption. That information can be fed through the marketing and business sides of Terracotta. Those numbers let Terracotta convince investors that people use the library and consequently get funding to pay the salaries of the world-class team at Terracotta and the machines in the giant perf lab that makes Ehcache awesome.

The information about Ehcache versions and OS/JVM environments tells Terracotta how to place emphasis during QA. If 80% of users run on Linux, then it makes sense to focus testing efforts on that platform. Similarly, if a small but significant number are running JDK 1.5 then that might keep it in the QA and support matrix for longer. Again, this information lets Terracotta put limited financial resources to the most efficient use to make Ehcache awesome.

While these features may initially feel intrusive, I think on some reflection that they are not really doing anything evil or scary, that they are easy to turn off, and that while they provide value to Terracotta, they also provide value to the user, both in version information in the short term and in an awesome product in the long term.

Sometimes I think people underestimate the amount of engineering work that goes into an open source product like Ehcache or Terracotta or Quartz, especially one backed by an actual company. Terracotta as a company employs a team of a couple dozen people who are creating truly world-class products, equal in innovation and quality to any number of commercial, non-open source, non-free products. But to make that work financially, there must be some part of the products that actually provides revenue. Small things like an update check actually make a big difference on the business side of the equation, both in growth and efficiency. I think if you consider it in those terms, you’ll find that the trade-off of information for engineering value is still weighted heavily in favor of the user.

The first suggestion people always make about the update check is why can’t it default to off? The answer to that should be obvious – no one would take extra steps to turn it on and provide that information (even if it is harmless). There is no point in having the update check code if it is not on by default. You are welcome to read that rationalization as evil if you want, but I think that’s naive.

Google shows you ads when you use their free search engine – this trades your attention (and occasional clicks) for a valuable service. Any other Internet “free” service is asking you to participate in a trade of something (often attention to ads or personal information) in exchange for a valuable “free” service. The Ehcache update check is really nothing different – an exchange of information for free use of a great piece of software. I personally see no moral issue with making an exchange of this information for great (free) software – seems like a bargain to me.

Check out these keynotes:

• Guy Steele (Oracle) – “How to Think about Parallel Programming: Not!”
• Douglas Crockford (Yahoo) – “Heresy and Heretical Open Source: A Heretic’s Perspective”
• Billy Newport (IBM) – “Enterprise NoSQL: Silver Bullet or Poison Pill?”
• Hilary Mason (bit.ly) – “Machine Learning: A Love Story”

Like language stuff? There are seven talks about Clojure! Four talks about Scala! Five talks about Groovy! A Java Puzzlers talk starring Josh Bloch (author of “Effective Java”) and Crazy Bob Lee! Other talks about Ruby, Perl 6, Lua, and Go!

Rethinking that old relational database? Check out some NOSQL talks about MongoDB, Cassandra, Hadoop, Riak, HyperGraphDB, Mark Logic.

Working on the web? Check out talks on JavaScript, jQuery, HTML 5, semantic web, RDFa, microformats, and node.js. Or talks about cloud infrastructure – dev ops with Chef or Puppet, deployment with jclouds, and using EC2 for testing.

Maybe making mobile apps? Check out talks on Android, mobile HTML 5, background processing, or a case study in how Square built its Android application.

Interested in how to scale your app? Check out talks from developers at Twitter, eBay, Flickr, Flightcaster, and BackType. Or learn how to build distributed apps with Terracotta, Akka, Conduit, or Google App Engine.

There is also a party featuring the enigmatic Strange Passions track. The Strange Passions track features talks given by attendees on non-technical topics. The 2009 sessions included talks on astronomy, neurons, options trading, building houses in Mexico, and more. The winner receives a genuine Klein Bottle!

You can register for Strange Loop right now! The early bird price is just $150 (what?! that’s crazy low) until August 6th, so don’t miss out.