SpringOne 2GX

I have moved to a new blog

Matthew Taylor — Fri, 12 Mar 2010 16:46:00 CST

I am tired of maintaining blog software on my own, so I’ve created a new blog here. This site will stick around indefinitely, but I won’t be posting here, and I probably won’t be very responsive to comments.

Open Source Update: jQuery PeriodicalUpdater, TestingLabs, GPars, etc.

Robert Fischer — Fri, 12 Mar 2010 12:28:00 CST

I’ve done a fair bit of fairly small open source updates recently.

jQuery PeriodicalUpdater: The main function now returns a handle that can be used to call stop(), thereby ignoring any updates that may come back and preventing future updates from being sent.
TestingLabs: I released TestingLabs 0.4 to work with Grails 1.2.0. Had a bug with versioning under Grails: More info on JIRA.
Presentations: I’m now storing the slides for my presentations on GitHub. They’re under a Creative Commons License.
ClosureBridge: This is a tiny library (up on the repo.smokejumperit.com Maven repo) that provides a link between Groovy’s Closures and Callable/Runnable/Java code.
Fun with GPars: A small library where I was experimenting with GPars
GPars: Submitted a fix and generally been discussing things with the GPars community (and by that, I mean Vacalv Pech)

See my GitHub page for more info.

This post was by Robert Fischer, written on March 12, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/os-update-march2010/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/os-update-march2010/

This article was a post on the EnfranchisedMind blog. EnfranchisedMind Blog by Robert Fischer, Brian Hurt, and Other Authors is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Open Source Your Project (with Jasig)

John Lewis — Wed, 10 Mar 2010 12:52:00 CST

Here is the full screencast from my Jasig 2010 Conference Session on "Open Sourcing Your Project (with Jasig)". Enjoy!

Actor style messaging and honey do lists

Andrew Glover — Wed, 10 Mar 2010 09:56:00 CST

As I previously mentioned in “Free lunches, mousetraps and the Actor model“, Edward A. Lee wrote an interesting article entitled “The Problem with Threads” in which he advocates leveraging the actor model in popular languages (such as in Java) as opposed to adopting an entire new paradigm (like Erlang). He states:

We should not replace established languages. We should instead build on them.

It appears that more than a few hip people agree with his line of thinking. It turns out there are quite a few options available for leveraging the actor model in Java. That is, aside from alternative languages like Scala, which supports actors and Groovy with GPars, there’s framework’s like Kilim, ActorFoundry, Actors Guild, and jetlang.

I ended up employing Kilim at a client side over a year ago to replace a thread based computational model. At the time, GPars was in its early stages and I was specifically looking for a speed up in application performance. The multi-threaded application was taking roughly 5 hours to complete.

In the end, the speed up attributed to Kilim (or indirectly leveraging its actor model) was hardly noticeable (some aspects of Kilim were noticeably faster though — such as spawning a task was quite fast as opposed to spawning a normal threads) as the real performance gain was leveraged by reducing and improving database queries (as usual, performance issues were essentially IO bound); nevertheless, the prime benefit of Kilim, which at the time I had overlooked, was the notion of a mailbox. That is, in the actor model, processes can share data more safely.

There are quite a few different implementations and ways to facilitate message passing in various languages and platforms, but to me, the actor model’s mailbox notion is quite intuitive. In Kilim’s actor model, messages are passed between processes via a Mailbox — in many ways, you can think of it as a queue. Processes can put items into a mailbox and also pull items from a mailbox in both a blocking and non-blocking manner (blocking of the underlying process not a thread).

As an example of leveraging mailboxes in Kilim, I wrote two actors (a Husband and a Wife) that extend from Kilim’s Task type. Previous versions of Kilim had an Actor type; however, as of version 0.6, Task is the way to go.

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Husband extends Task {
 private Mailbox<Message> mailbox;

 public Husband(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   System.out.println("Husband listening...");
   Message msg = mailbox.get(); // blocks
   if (msg.getReceipient() == Message.HUSBAND) {
    System.out.println("Husband hears: " + msg.getMessage());
    Message reply = new Message(Message.WIFE, "Yes, dear");
    mailbox.putnb(reply);
   }
   Task.sleep(1000);
  }
 }
}

Under the covers, Kilim works by weaving bytecode so as to control Task types and facilitate their safe interaction — specifically, Kilim’s weaver is looking for methods that throw the Pausable type (previous versions used the @Pausable annotation).

In the Husband class, a few things are going on — first, the instance waits for a message from a shared mailbox. In this case, I used a blocking get call (as in reality, a husband really doesn’t do anything else but waits for orders (I mean requests) from his wife). When a message is picked up, the instance checks to see if it was intended for it (in many cases, wife instances can communicate with children types sending messages like “clean your room” or “brush your hair”).

Once a Message type (which, in this case, is not a Kilim type) is determined to be sent to a Husband instance, the Husband type replies appropriately by creating a Message and placing it into the mailbox instance. Finally, the sleep call is just placed to facilitate reading console output.

The Wife class is similar (expect that she doesn’t wait to listen…). Like the Husband instance, this class creates a Message (in the form of a Honey Do) and sends it off via the shared MailBox; however, she doesn’t wait around — that is, the instance uses the putnb call, which is non-blocking. What’s more, she’ll also attempt to see if anything is in the mailbox for her, but in her case, she also uses a non-blocking call (getnb) like so:

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Wife extends Task {

 private Mailbox<Message> mailbox;

 public Wife(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   Message request = new Message(Message.HUSBAND,
    "Please do x, y, and z today, husband.");

   mailbox.putnb(request);
   Task.sleep(1000);
   Message msg = mailbox.getnb(); // no block

   if (msg != null && msg.getReceipient() == Message.WIFE) {
    System.out.println("Wife hears: " + msg.getMessage());
   }
  }
 }
}

As you can see, if there is a message waiting for her, she’ll hear it, otherwise, she moves on and requests her husband to do something else.

Lastly, everything is coordinated by a simple driver class containing a main method like so:

import kilim.Mailbox;
import kilim.Task;

public class HoneyDo {

 public static void main(String[] args) {

  Mailbox<Message> sharedMailbox = new Mailbox<Message>();

  Task wife = new Wife(sharedMailbox);
  Task husband = new Husband(sharedMailbox);

  husband.start();
  wife.start();
 }
}

Note how a Mailbox instance is created for my custom Message type; what’s more, the sharedMailbox is then shared between both the wife and husband instances. Lastly, things are started via the start method.

Running this hip example yields the following output (remember, your exact output will most likely look different; however, the logic sequence of activities will line up. That is, the wife requests things be done and the husband responds with “yes, dear”, which the wife hears).

 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear

The actor model facilitates concurrent programming by allowing a safer mechanism for message passing between processes (or actors). Implementations of this model vary between languages and frameworks — I suggest checking out Erlang’s actors followed by Scala’s as each implementation is quite neat given their respective syntax.

In the end, if you want to leverage plain Jane Java actors, then have a look at Kilim (or one of the other frameworks available) — just make sure you’ve finished your honey do list first, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Annotation-Based Spring Portlet MVC

John Lewis — Tue, 09 Mar 2010 13:34:00 CST

Here is the full screencast from my Jasig 2010 Conference Session on Annotation-Based Spring Portlet MVC. Enjoy!

ESDC 2010 resources

Andrew Glover — Mon, 08 Mar 2010 12:48:00 CST

I recently had the opportunity to present four different talks at the Enterprise Software Development Conference (or ESDC) in San Mateo, California. In an effort to provide additional data points and information, I created individual resource pages for each talk. These pages (hosted at my company’s site — beacon50.com) provide links to articles, blog entries, tutorials, and a copy of each presentation. If you’re curious to see what you missed at ESDC, then have a look, man:

Thanks to everyone who came to ESDC and attended my talks — I had a great time discussing these topics (and more!) with you!

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Scala: Post-Functional, Post-Modern, or Just Perl++?

Robert Fischer — Sat, 06 Mar 2010 21:30:00 CST

Let’s start with some background.

I complained that Scala did not seem to be very functional to me, but I didn’t really know how best to express what was fundamentally wrong with it. I did know that if “functional languages have a fixed set of features” like Scala’s creator, Odersky, claims, then it wasn’t simply “first-class functions in there, function literals, closures”, “types, generics, [and] pattern matching”. Scala has missed the functional boat in some basic way.

After a kerfuffle in the comments, Brian enlightened us all by telling us what is a functional programming language. His explanation (while being a self-admitted generalization) is summarized as follows:

So, what is it that differentiates the functional programming languages from all the other programming languages? It is simply this: the functional programming languages use, as their fundamental model of computation, the lambda calculus, while all the other programming languages use the Turing machine as their fundamental model of computation.

Six months later, Odersky responds with a very interesting post, which actually agrees that Scala is not a functional language in Brian’s sense, but instead argues that any language is functional if it “makes programming centered around functions easy and natural”. He then runs through a list of features which is in common with functional languages, noting that Scala has them within handwave enough (more on that later). He ends wishing that people would “stop thinking of functional programming as a different, novel, or exotic way to code”. Even more, though, Scala is apparently “an early example of a new breed of postfunctional languages”.

And that gets us to this blog post.

First of all, Odersky is still missing the point. It’s not about whether you use fold, map, and iter, or whether you can write closures easily. It’s not even really about pure functions vs. side-effects. To code in a functional style is a fundamentally different way of thinking about problems: instead of thinking about problems as nouns that are doing things, functional programming views a problem as a series of transformations to the world which results in an answer. This is why functional programming is considered “a different, novel, or exotic way to code”: it is a different, novel, and (as of yet) exotic way to code. It’s as different, novel, and exotic from OO as OO was from procedural. It’s a different way of thinking about the entire issue. You can check out this snippet of an IRC conversation from #ocaml for more on that.

The paragon of this way of programming is point-free programming, where you are quite literally building up a mega-function that describes how your program works, and then executing that one, single function when you run that program. If your language doesn’t lead people to re-discover point free programming at least in the small, then the language really isn’t taking function manipulation and functional language type conceptions seriously. And that’s the case with Scala: even Odersky admits that in Scala, “currying is more verbose and much less used than in other functional languages”. (Protip to Scala people: If one of the fundamental stunts of a style is pervasive in all the code but yours, you’re not in the same style of programming.)

What really gets me, though, is the claim that Scala is “an early example of a new breed of postfunctional languages”, because aside from the static typing, all the language features that Odersky trots out already exist in Perl. It’s hard to be a vanguard of a new breed of programming languages when there’s prior art from the 1980s.

Don’t believe me? The existence of a book on the topic unconvincing? Then let’s run the list of functional language features from Odersky.

Functions as first class values: check.

sub apply(&$) { # Take a function as an argument no problem $_[0]->($_[1]);
}
 
sub times2($) { # Create a function to take print $_[0]*2 . "\n";
}
 
apply(\&times2, 3);

Convenient closure syntax: check

my $x = 2;
apply { print $_[0]*$x . "\n" } 3;
 
my $times_x = sub($) { print $_[0]*$x . "\n";
};
$times_x->(3);

List comprehensions: check. (See perlfunc on list data.)
“Curried” function definitions and applications: check-ish.
Okay, so calling this a “check” on Scala is a bit of a reach (cite, cite, cite, although note this—here is a more sympathetic run-down on Scala currying). Ignoring the foo(2,_:Int) syntax for a moment, we can implement basically the same style of “‘curried’ function definitions” such as Scala’s List#foldLeft.
```
sub add { my $x = shift; return sub { $x + shift };
}
add(2)->(3); # Okay, so you do need an extra ->
```
In the case of our apply function above (where we take a function as the first argument), it’s even easier.
```
apply { print $_[0]*$x . "\n" } 8;
```
Now, there isn’t really argument skipping (i.e.: foo(_:Int,3)) as a syntax feature, and there isn’t a built-in curry function, but if you want Scala’s Function.curried in perl, here it is:
```
# This code released under Creative Commons 0 and WTFPL.
sub curry(&@) { my($f,@args) = @_; return sub { $f->(@args, @_); };
}
 
sub add($$) { return $_[0] + $_[1];
}
 
my $curried = curry(\&add, 2); print $curried->(3) . "\n";
```
Lazy evaluation: check. See Scalar::Defer for lazy val equivalents and Tie::LazyList for lazy seq equivalents. People generally use a double-return approach for generators (which I realize are different than lazy seqs and only kinda-sorta lazy).
Pattern matching: check (okay, check-ish). See Switch. The decomposition isn’t there, which is the biggest weakness. But the general cumbersomeness and lack of real algebraic data types hamstrings the coolest parts of pattern matching anyway, so I’m calling it a draw. (This should be read as a generous and sympathetic ruling for Scala: Cedric Beust, for instance, rails against pattern matching/case classes and says “it’s hard for me to see case classes as anything but a failure“.)

In addition, perl’s got a few features in its favor for functional programming, like more flexible arguments, autovificiation, list/argument coercion, and dynamic symbol table mangling. Since perl also has OO capabilities, perl is at least as convincing a “post-functional language” as Scala. But there’s even more in common between the two than that.

Odersky’s “post-functional language” is really a subtype of Larry Wall’s “post-modern language”: it’s an attempt to create a language that is a grab-bag of multiple paradigms. And when you do that, you’re just begging for the complaints that you hear leveled against both perl and Scala: it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language, etc. (cite, cite, cite) Now, those who master the language (or master their favorite subset of it) love the TIMTOWTDI aspect. But it also means that the language is left as a jack-of-all-trades, master of none. Yes, Scala and perl integrate a lot of powerful tools from functional languages—but learning OCaml still blew my mind, despite knowing perl for years. As I started off saying, Scala is not a functional programming language. It is a statically typed object oriented language with closures.

Now, there is a sense in which Odersky is really onto something. The world of programming is forever transformed with closures and list comprehensions as being mandatory for new high-level languages, even if they’re otherwise object oriented. And software developers are going to need how to work with them effectively if they want to read code moving forward. Yes, after 20+ years, the rest of the programming world finally caught up to one of perl’s fundamental insights.

Comments

March 7, 2010, Barry Kelly wrote: Functional programming optimizes for different things than OO does. That means for different problems, you want to take different approaches, depending on your level of familiarity with the problem domain and the solution strategies. And thus for a language that supports both paradigms, different people will often end up using different subsets of the language. But I don't think this is necessarily a damning criticism. Our problems are bigger and more compositional. We need languages that have the semantic richness to support different solution strategies. An example. There's an isomorphism between OO polymorphism / dynamic dispatch, and algebraic data types / pattern matching and destructuring. OO lets you add subclasses as late as dynamically at runtime. ADT lets you add functions freely, and such functions are more composable that they're dealing with well-defined quantities. More generally, OO is about defining loosely bound protocols, while FP is more about flexibly defining transformations over tightly defined structures. But if you want to write a solution that's natural for one paradigm in the other, you end up re-inventing and poorly reinventing the other paradigm. In a comment somewhere else out in the ether, I made an argument that getting FP to work as well as a dynamically typed late bound language like Ruby for fast-iterating web solutions that join together multiple independently developed and fast-iterating modules, you'd end up writing what amounted to a dynamic language just to avoid the brittleness that comes from the over-specification that naturally falls out of static typing. I will agree that e.g. currying is useful, as it decomposes the concept of functions of arbitrary arity into what amounts to a linked list of unary functions; and this is particularly handy for programming in a point-free style. But point-free mostly helps (I would assert) on problems where what you need to do is create an algorithm, where little helpers like fold, map, memoize etc. are your bread and butter. But not all problems are like that, not by a long shot.
March 7, 2010, Ittay wrote: "because aside from the static typing, all the language features that Odersky trots out already exist in Perl" That is a big 'aside'. You also forgot that Scala runs on the JVM and Perl not. Not to mention that I think it is common consensus that Perl code is very unreadable. So Scala is a language that combines some FP characteristics with OO, running on the JVM and with a readable (and scalable) syntax. That's a big win for me.
March 7, 2010, Robert Fischer wrote: I will freely grant that there's a lot to be gained by having some flexibility, but languages that end up trying to play in multiple sandboxes end up either doing one part badly (e.g. OCaml and OO, Scala and functional). The answer seems to be using multiple languages for different contexts, not trying to create the One True Language with all the features of the world in it. That's why when I encounter a programming problem, I will generally reach for perl, Groovy, or OCaml/F#: which one I go for depends on the nature of the problem. But I don't long for a day when there's a language that has all the features of perl, Groovy, and OCaml, because they're fundamentally incompatible takes on the process of programming. The strongly opinionated natures of these languages is precisely what makes them so good. Scala's lack of strong opinions is what's frustrating me. Well, that and having to explain to Java devs over and over again at No Fluff events that learning Scala does not mean learning to program in a functional style. I mean, you can code Scala in a functional style, but I can code Java in a functional style. And yes, it's a bit easier to code in a functional style in Scala, but learning Scala is no more learning functional programming than learning perl is learning functional programming.
March 7, 2010, Robert Fischer wrote: The "readable (and scalable) syntax" bit is a big assumption—at least to my ear, there's as much concern about the readability of Scala code as there is about perl code. And how much Scala's static typing really helps vs. how much it gets in the way is a matter of contention. But both of those are an aside. The purpose of this post was not to say that people should stop coding Scala and start coding perl: if you're still futzing around in Java-land, Scala (like Groovy and JRuby) is a productivity huge win that can leverage your existing infrastructure. Groovy's probably the semantically closest, JRuby's the conceptually cleanest, and Scala keeps the fetishized complexity and the BDSM aspects of Java. No, this wasn't a call to go back to perl. The purpose of this post is to show that the idea of merging closures with imperative isn't a new idea, and that Scala is no more a functional language than those languages (like perl) which merged the concepts beforehand.
March 7, 2010, Richard Vowles wrote: I've been saying this for 6 months at least now - Scala and Perl have way more in common than Scala has in common with any other language. Including a tendency towards unreadability.
March 7, 2010, Marc wrote: "It’s as different, novel, and exotic from OO as OO was from imperative." OO is as imperative, if not more so, than C. I assume you meant procedural? Also, there is nothing new in programming languages, period. Everything you see in "new" languages was figured out at least 20 years ago. So, all language designers are just mixing and matching as they see fit. So it's unfair to single out Scala in this regard. While you're at it, go after Groovy, Clojure, Boo, F#, etc.
March 7, 2010, Nick Bauman wrote: I find the description "combines some FP characteristics with OO" problematic when discussing hybrid Functional / OO languages. The more I use one of my favorites of these languages, Python, the more I find the OO aspects receding into the background and the functional ones coming to the fore. It seems to me that Functional is OO "done right" where when I do use OO in them, it's not as heavyweight and seems more natural. I think the key is that in most traditional OO languages the concept of what a type is tends to be much narrower. Can you confirm this in your experience?
March 7, 2010, Thomas Heywood wrote: Robert, I admire your ability to "professionally blog." You delivered no useful content, but you did it with inspiring attention to page hits and comment controversy. Yes, Scala is a multiparadigm language. Yes, Perl is one too. Yes, they both share features from Common Lisp. That's not really worth my or your time. But you cleverly used the confrontational tone to make the blatant non-issue into a controversial issue. You cleverly used Blogosphere's beloved "Scala" and "Perl" tags in a single article. You nagged about a minor syntax issue like it was life-or-death as only a true master-of-functional-programming-who-blogs-more-than-he-actually-programs can. Bob, you're my hero - a true Dilbert's Wally in flesh. A guy without any real code to show - but who "realigns the tone of existing projects" and whose "technical leadership focuses on pragmatic communication" like there's no tomorrow. Wally - sorry, Robert - do you think you could write some posts on how to professionally sell bull and call it "technical accomplishments?" Many of us CompSci majors would like to get in on this money for nothing scheme. Unless, of course, you're not comfortable writing about things you actually do know a little about.
March 7, 2010, Nilanjan Raychaudhuri wrote: Well I believe it is possible to write unreadable code in any language and I am not sure blaming any programming language for that is a good idea.
March 7, 2010, Daniel Spiewak wrote: Throwing out static typing fundamentally changes what Scala has to offer. In a sense, I agree with you that if we completely threw out Scala's type system (and all that it entails), then we would end up with a language which improves very little (if at all) over languages like Perl or Ruby. However, that first step is a doozy and not really fair. Consider a snippet like this:
```
"123".to[Int] // => 123
".+".to[Regexp] // => /.+/
true.to[Regexp] // compile error!
```
There's a lot of magic going on here, all of which is made possible by the static type system. In fact, while this sort of thing is *possible* in a dynamic language with open classes (like Ruby), the implementation will be ugly, unscoped, brittle and difficult to extend. In Scala, the implementation looks something like this:
```
trait Converter[-A, +B] { def apply(a: A): B
} implicit object StringToInt extends Converter[String, Int] { def apply(str: String) = str.toInt
} implicit object StringToRegexp extends Converter[String, Regexp] { def apply(str: String) = Regexp(str)
} implicit def toSyntax[A](a: A)= new { def to[B](implicit conv: Converter[A, B]) = conv(a)
}
```
This is taking advantage of a feature which Scala inherits from Haskell called typeclasses. This is an feature which is inherently tied to static typing and is often very difficult to emulate in dynamic, so-called "more flexible" languages. The real magic of this is two-fold. First, it's scoped, and so we actually have to import these members before they start messing with our objects. It's hard to over-state how important this is to keeping such extensions from devolving into intractable monkey-patching. Second, it's extremely extensible. What if we want to add another conversion from Foo to Bar? Just define it ourselves as an implicit value in scope! Or, if we don't want the implicit syntax, we can always specify the conversion explicitly:
```
// off in *our* code, separate from the converter lib
implicit object StringToBool extends Converter[String, Boolean] { def apply(str: String) = str.toBoolean
} "true".to[Boolean] // => true
"false".to(StringToBool) // => false
```
I'm not even going to try to imagine how to do this sort of thing in Perl. Even in Ruby, which usually makes monkey-patching quite simple, the implementation still ends up extremely nasty:
```
class Object def to(target) case target when :fixnum if self.class == String self.to_i else raise "Unknown conversion: String -> :fixnum" end # ... end end
end
```
...and, you get the picture. You could probably do this in a nicer way, but it would still end up being fragile, unscoped and virtually impossible to extend. This is what you're throwing away when you discard the type system, not some unreliable correctness "guarantee". And if I can throw together an example like this in a blog comment in just a few lines of Scala, imagine what can be done in a non-trivial system with real requirements. The type system is an intrinsic part of Scala's power and expresivity. Remove it and you're not even looking at the same language.
March 7, 2010, Daniel Spiewak wrote: While currying and point-free aren't as syntactically clean as they could be in Scala, they are certainly still used (I use those features all the time). Does this make Scala less "functional" than Haskell or ML? Yeah, probably (I've made that argument in the past). Does it mean that Scala is no more functional than Perl? Absolutely not. Theoretically speaking, currying is possible in any language which supports closures (alblue, if you're reading, yes I do mean "closure" and not "lambda"). You can even define a curry function in C++, though the obfuscated template mess it entails makes it nigh unreadable. Lambdas ("closures" if you will) and function values do not a functional language make. C has function values, and I don't think anyone who understands the debate will argue that it is "functional". Ruby has function values and lambdas, but they are fundamentally different constructs and produce different values (just like in Perl). Again, not a functional language (though you can use many patterns which find their roots in FP, like map and fold). My point is this: you can't go out of your way to link FP to point-free and lambda calculus and then turn right around and claim that Perl and Scala are in the same league. Scala's unified functions and function values alone should be sufficient to overturn that one.
March 7, 2010, Robert Fischer wrote: Yes, I meant procedural.
March 7, 2010, Martin wrote: You really can't claim "perl has had _____ since the 80's" and then point to books about Perl 5. Perl 25 years ago is *very* different than it is now. Your point that Scala and perl are similar is well taken, but I'm not totally clear why this is bad for Scala or Perl. The way Perl 6 is going towards a virtual machine, I wouldn't be surprised to see Perl and Scala and Java running together on a JVM sometime soon.
March 7, 2010, Robert Fischer wrote: I'm not saying it's bad for either Scala or perl to be similar to each other — on the point of similarity, I'm simply saying that in the ways Odersky argues Scala is "functional", perl is just as functional, and so I'm still unconvinced that Scala deserves to be called a "functional language". You don't hear people listing off the functional languages like: "Haskell, OCaml, perl, Lisp...". So to hear people say "Haskell, OCaml, Scala, Clojure" just gets my goat. I'm also saying that on the point of similarity, it shouldn't be a surprise that we're getting similar unreadability/complexity complaints about Scala as we got about perl, since they are so similar. I heard something about perl getting onto the JVM for AppEngine, but can't find additional info on it.
March 7, 2010, Robert Fischer wrote: In what ways do Scala's unififed functions and function values outperform perl?
March 7, 2010, Robert Fischer wrote: Note the point I'm arguing: I'm arguing that Scala is no more a functional language than perl is. Functional languages can be dynamic (e.g. Clojure), so static vs. dynamic typing is irrelevant to the point I'm trying to make.
March 7, 2010, Robert Fischer wrote: You've earned a special spot in my heart: this is my new favorite flame of all time. I mean, the fact that you say I don't have "any real code to show" just goes to show that you're not paying attention, because you've somehow managed to miss my long trail of open source projects. And you kinda missed the boat on the entire fundamental question: "Is Scala a functional programming language?" But still, the Dilbert references, the accidentally-on-purpose "slip of the keyboard", and the general long-suffering tone is really nicely done. A+
March 7, 2010, Robert Fischer wrote: Oh, and you're fair on the dating thing. It's hyperbolic to conflate Perl 1 with Perl 5, although I honestly have no idea how far back I can go in perl and still have my code samples work. If you find out, let me know.
March 7, 2010, Robert Fischer wrote: Brian Hurt, the co-blogger here on EnfranchisedMind, is theoretically working on a post about how OO is fundamentally broken. I'll leave that to him. My experience has been that many of the Gang of Four design patterns just aren't relevant anymore, and inheritance is something I'm extremely reluctant to use and much more aware of its difficulties. I'm not sure exactly what it would mean to say that "the concept of what a type is tends to be much narrower", but I certainly have a much thinner type hierarchies in the world of functional programming.
March 7, 2010, Robert Fischer wrote: Oh, not to mention the cite of enterprise-ese from SmokejumperIT.com. I mean, that's some real attention to detail for the zingers. In all seriousness, this is my favorite flame of me of all time. Thanks!
March 7, 2010, Dave wrote: FWIW, I really dug this post. As to the topic at hand, I'm not even sure what point there is to saying Scala is or isn't "functional". The only real purpose seems to be to make it easy to show how awesome Haskell is by point out Scala's perceived shortcomings as a functional language. For my money, Scala is simply "Java: The Next Generation". A general-purpose, statically-typed, object-oriented language that has broad applicability to many problem domains. Arguing "what is functional" might be a fun exercise, but it's not really going to lead us anywhere; look at most n-tier Java applications: to say they are object oriented would be a vast overstatement. Java is object-oriented in that it's main means of organizing code are around classes and objects (which is exactly the same as in Scala), but most systems still end up using OO only when it helps, and throwing it for imperative/procedural stuff when it makes sense to do so. I would be willing to bet that Scala will be much the same way; the code inside our classes might be much more functional (simply because its' simply worth-it to do in Scala, whereas it's not terribly so in Java), but I don't see it ushering in some functional utopia (LISP has had, oh, I don't know, the entire history of the field of computer science to usher this in and largely failed [no offense to LISP]). Scala is an escape route from Java's cruftiness without having to bend your mind or prejudices too much. Much as Java was to C++.
March 7, 2010, Tracy Harms wrote: The most interesting sentence in your post, to me, was this: If your language doesn’t lead people to re-discover point free programming at least in the small, then the language really isn’t taking function manipulation and functional language type conceptions seriously. This has me wondering, though, about your agreement with Brian that the key quality is reliance on lambda calculus as the model of computation. Not that I'm convinced we need a "key quality." It just looks to me that the range of languages you have in mind would not be identified through this criterion.
March 8, 2010, joe poki wrote: what's up with these groovy people nowadays? groovy++ is 10 trillion times faster than scala actors, now this piece. your rant could be summarized like I Do Not Like Scala. Look, I get that. But I must say it's funny that you use this patronizing tone with Odersky as he was a n00b who has no idea about languages and then once you get a trollish comment, you go on and post it everywhere: OMG somebody was responding to my trollish post in a trollish manner, what a surprise? as for your post: just because a language can be used in a certain way (or certain language toolsets can be simulated in that language) that does not mean that the users will find that specific style idiomatic. What matters is the style you will meet the most while reading or writing code in that specific language (hack, even java has various functional libraries: lambdaj, functionaljava etc. but how many people would consider code written with these library java-like?). When people say that scala is "kinda functional", what they really mean is that the language is nudging you into that direction (preference for pattern matching, option type, final variables, map, foreach,closures, partial functions etc.). And this nudging towards the functional style is what makes scala "postfunctional". (other features responsible for the "scala feel" but not directly related to the functional thing: static typing w/ type inference, a powerful type system, xml literals, implicit converions, case classes, mixins + various actor libs etc.)
March 8, 2010, Robert Fischer wrote: My issue isn't with people saying Scala is "kinda functional". It's saying it's a "functional language". I've heard people say they want to learn Scala b/c then they'll know functional programming, and that's just wrong. Worse, I've heard people write off functional programming because they didn't like Scala. This means that the misconception that Scala is a functional language is hurting real functional language adoption and hindering people's advancement as software developers by making them think they know functional when they don't. So I'm trying to reinforce the barrier between real functional languages and languages with closures. I'm not particularly knocking Odersky here: what he's done with Scala is pretty impressive. But he's clinging to a title that Scala doesn't deserve. While I appreciate the move with "postfunctional", I'd be a big fan if it also meant he'd give up "functional" — but he's just taking both titles on. In so doing, he's diluting what we mean by a "functional language", and that's just not helpful to anyone involved. The evidence does seem to be that Odersky doesn't really know functional languages. Or, if he does know them, he knows them academically or intellectually, and doesn't really grok them. But you can't be an expert on everything, and I get that. This whole conversation is really kind of sad. There's such an extreme dichotomy here: the assumption seems to be that if you criticize a language, you must hate it. I don't hate Scala: Scala is what Java should be. It's finally a competitor to C# on the JVM — the advanced capabilities of C# have been downright embarrassing for a long time, and Scala evens the playing field. I'm just criticizing the way we talk about this language, and providing counter-evidence to some of the claims made about it.
March 8, 2010, Robert Fischer wrote: Which languages do you see as missing one of the two qualities?
March 8, 2010, Robert Fischer wrote: As I will say below, my issue is mainly one of vocabulary and pedagogy, because I'm frustrated with the murky waters that such marketing-speak has created.
March 8, 2010, Robert Fischer wrote: PS: From someone who has been there (remember: I'm a static typing fan, too): If you want to debate static typing usefulness vs. dynamic typing usefulness, don't argue that it's hard to implement type safety in a dynamically typed language. It doesn't win you any points with the dynamic language crowd, because they've already accepted they don't need it.
March 8, 2010, Peter Lewerin wrote: Daedalus and his son Icarus were imprisoned by King Minos, and made themselves wings out of wax and feathers to escape. Before they took off from the island, Daedalus warned his son not to fly too close to the sun. The sensation of flying made Icarus forget the warning and he soared higher and higher. Eventually the wax melted and he fell into the sea. A programmer can escape the prison of procedural programming using functional programming, but going for the purest form of FP isn't really a sustainable goal. Most likely, these wonktional programmers will melt their wings by straying too close to the realm of mathematics and plunge to their deaths.
March 8, 2010, Thomas Heywood wrote: And you kinda missed the boat on the entire fundamental question: “Is Scala a functional programming language?" Scala is a multiparadigm language that supports procedural, functional and object-oriented programming. We've had that since 1950s and Lisp. Now, what was the fundamental question again?
March 8, 2010, Thomas Heywood wrote: (Mea culpa: we've only really had it supplied with the language since 70s, when Lisp machines took off. Still, a blatant fact is blatant, no matter how much you blog it into shape.)
March 8, 2010, Vassil Dichev wrote: Robert, if you like Perl, that's nothing to be ashamed of :-) Seriously, I think your article is thought-provoking, if a little controversial. Still, there are several things I disagree with. First of all, I have interpreted Odersky's article in the spirit of: "OK, I don't insist on calling Scala a functional language". One important piece you didn't mention was immutable data structures. Perl doesn't scale very favorably here. Was this on purpose? I find it important not just what a language *can* do, but also what it *cannot* (easily) do. Mutation and scoping are some of the things Scala restricts rather successfully. I also don't find how the fact that Perl has flexible arguments, autovivificiation, list/argument coercion, and dynamic symbol table mangling makes it more functional. Does Haskell have these? Do you consider Haskell functional? Then I also don't see many people argue that Java is object-oriented. By the same reasoning, it's not- it certainly has types that are not objects, and you can certainly write in a procedural style in Java (unfortunately some people really do). Also, I don't see you arguing that OCaml is not object-oriented, because it's also considered a multi-paradigm language. I see that in one of your comments you agree that OO is poor in OCaml, which is fair enough, but I think some OCaml users wouldn't agree with you on this count either. I most emphatically agree that if you "know" how to write working Scala code, this doesn't mean you know all about functional programming. But I disagree that this harms "real" (read purer) functional languages any more than Java harms "real" object-oriented languages (whatever they are). In the end, I'm also fine with the definition of "statically typed object oriented language with closures".
March 8, 2010, Vassil Dichev wrote: I've just read some of the blog posts you've linked to, and it's quite telling that two of them complain that Scala is too functional, while you complain that it's not functional enough. I think this is the problem with Scala: you can't appease everybody without any mental effort on their part to get used to the new style of programming. And I think the same can be said of OCaml. I also think OCaml would be a wonderful language to learn (and I might try it soon).
March 8, 2010, Paul Kaletta wrote: All of your examples should work with any version of Perl 5, which came out in 1994.
March 8, 2010, Martin Odersky wrote: Robert: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. So, it must be because of a series of freak accidents that I organized ICFP, am a member of the IFIP working group on functional programming and am a member of the editorial board of the Journal of Functional Programming. And I even published quite a bit on lambda calculus, too :-). Seriously, I stand completely by my article on postfunctional programming. I believe your post here has added nothing of substance to the discussion. http://www.scala-lang.org/node/4960
March 8, 2010, joe poki wrote: if you cite every single well-known post that dismisses scala one way or another and you go on and say "it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language", then people will rightly assume you do not like scala, I do not get it why you are surprised (notice, I did not say you hate it, just that you dislike it). see, the patronizing stuff again "Odersky doesn’t really know functional languages". As I tried to point out: what matters is how a language is used and what's considered idiomatic and in that sense scala definitely has some functional feel to it (and no, it's not just about closures or foreach, but preference for pattern matching, option types, final variables, map, foreach,closures, partial functions etc. etc.).
March 8, 2010, Tracy Harms wrote: To the best of my knowledge, Factor, Joy, FL, and J are languages that favor anonymous arguments (and/or emphasize composition of functions) while lacking reliance on lambda expressions.
March 8, 2010, Robert Fischer wrote: If you're up for not calling Scala a "functional programming language", tell Odersky.
March 8, 2010, Robert Fischer wrote: It's not patronizing to say someone doesn't know something, or to disagree with the way someone is using language. That's just not what patronizing speech is. It'd be patronizing if I started explaining to Odersky what closures are and how they're supposed to work, or if I sent you off to look at this link. That would be patronizing.
March 8, 2010, Thomas Heywood wrote: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. Martin, hate to break it to you, but all you ever did was bring effective functional programming to a mainstream platform for the benefit of industry and academia. Call me back when you write a wrapper library or two, learn the persistence API of a web framework, or realign the tone of existing projects.
March 8, 2010, Robert Fischer wrote: That's cool that you're so involved. Ultimately, though, our problem is boiling down to one of language. If Scala and perl are functional languages, how do we differentiate them from languages like Haskell, OCaml, and Lisp, where the fundamental way of tackling problems is different? I'd like to use the term "functional programming language" for the latter, and I'm more than happy to stick to "postfunctional programming language" or "multi-paradigm programming language" for the former. But that means we stop calling Scala a functional programming language, as most of the commenters here on the post already have. Deal?
March 8, 2010, Robert Fischer wrote: Yeah, that's the general issue with these multiparadigm languages like Scala and perl. If OCaml narrowly avoided that fate (and I think it has), it was by completely subjugating the OO aspect to the functional aspect, and not really using the OO aspect much.
March 8, 2010, joe poki wrote: If you think saying somebody does not know squat about a subject while that person is supposed to be some sort of an expert on the topic is not condescending, then I do not know what is. By the way, it seems I was not alone, see Odersky's comment above.
March 8, 2010, Robert Fischer wrote: The immutability is a good point, and it's an area where Scala certainly pulls ahead. Actually, the Ruby (and, to a lesser extent, C#) people regularly say that Java isn't really OO, because a lot of things in Java weren't either objects or messages. I think Ruby inherited that criticism from the old SmallTalk people. And I'll happily argue that OCaml isn't object oriented: while it has objects, it's certainly not oriented towards them. What harms functional programming languages is when Java people learn Scala and then think they know functional programming languages. Or, worse, when they decide they don't like Scala and then conclude they don't like functional programming. This happens a lot because Scala was lauded as a functional programming language on the JVM which was comfortable for Java people. It's the murkiness in the water that's the issue.
March 8, 2010, Daniel Spiewak wrote: In Perl, functions and lambdas are fundamentally different. If nothing else, this can be seen by the different invocation syntax. You can convert between functions and lambdas (just like in Ruby and Groovy), but they are very different constructs as far as the language is concerned. To me, one of the essentials of a functional language is that functions are merely lambdas which have been assigned to a named value. OCaml and Haskell encourage this notion with their syntax for function declaration (in fact, Haskell's function decl syntax is exactly the same as its value decl syntax). Perl doesn't even come close to meeting this qualification. Scala does substantially better, though I'll admit that it does have its gotchas (methods are sometimes tricky).
March 8, 2010, Robert Fischer wrote: While that's a bit hardcore of a comparison (and somewhat damning on people's ability to learn), I definitely agree with your point. And Scala's great in this regard—as I said a number of times, I think Scala is where Java should be if Java's growth hadn't been stunted. If you look at how C# has evolved, Scala's basically right in line with that kind of development. And so a Java developer learning Scala in order to push their way of thinking about types and functions is a great move.
March 8, 2010, Robert Fischer wrote: True — I'm oversimplifying the world into imperative and functional. There are other paradigms out there (e.g. Factor's stack-based approach) which also can lead to point free programming.
March 8, 2010, Robert Fischer wrote: Do they work before that? (Or, rather, would they work before that if I dumped the prototypes?)
March 8, 2010, Robert Fischer wrote: True: there are conversions that need to be made between functions and lambdas in perl. This suggests for Scala (as a multiparadigm language) having a somewhat stronger functional aspect than perl, but it still doesn't make it a functional programming language a la OCaml and Haskell.
March 8, 2010, Alicia wrote: Wouldn't it be awesome if you really could make money writing b.s.? People won't even donate a dollar towards valuable open source projects...the suggestion that you could make money for being good at b.s. is hilarious.
March 8, 2010, Robert Fischer wrote: Amen.
March 8, 2010, Robert Fischer wrote: True enough. I'm just trying to wrap my head around how Odersky can really grok functional programming and then assert that it's simply bolt-on features of a language. The difference between Haskell and Java is not simply one of syntactic sugar. Claiming he's mistaken about how FP works is actually a generous take—claiming he's clinging to the FP title for Scala for some ulterior reason when he should know better is much less generous. I was trying to give him the benefit of the doubt.
March 8, 2010, James Iry wrote: Robert Fischer Finally Admits That Scala Is Functional (http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that.html)
March 8, 2010, Martin Odersky wrote: Robert, please, read my post again: http://www.scala-lang.org/node/4960 Nowhere did I define functional programming exclusively by a list of features. Instead I had as my central definition: "A functional language makes programming centered around functions easy and natural." A good test of this would be: is it common to write functional programs in the language in question? It's usually far easier to tell whether a program is functional than whether a programming language is functional. By that standard Scala is clearly functional; many of the classes and modules written in it are purely functional and every cool idea from Haskell seems to be implemented sooner or later in Scala (not that we don't invent some cool ideas of our own as well). I don't know Perl well enough to be able to tell whether there are many functional programs written in it, and whether the expression of such programs is easy and natural.

Griffon rises once more

Andres Almiray — Sat, 06 Mar 2010 17:45:00 CST

The Griffon team is very pleased to announce that Griffon 0.3 has been released!. This release is loaded with new features, plus a good number of bug fixes. Here's a quick tour on what 0.3 has to offer:

Addon enhancements

As you may know, addons are Griffon's runtime plugins; you can use them to extend the capabilities of an application. Addons were introduced in 0.2 however they only exposed a small set of hooks (factories, methods, props) plus their own life cycle hooks. Starting form this release addons are able to contribute application event listeners and all types of delegates that a FactoryBuilderSupport builder can handle.

Native libraries support

What do you do if your application requires a platform specific library or jar? What if you need to package several of those depending on which platform you intend to run on? What about plugins and native libraries? Well all these questions and more can now be solved by following a file placement convention that can save you lots of time. Supported platforms at the moment include: Windows, Linux, OSX and Solaris (all 32bit versions).

Packaging enhancements

Closely related to native libraries support, you're now able to specify additional settings and resources that can merged into the generated JNLP files when running on webstart and applet modes. No need to manually fumble with those files anymore. Plugins can take advantage of this feature too.

Artifacts API

Since the beginning Griffon has had basic artifacts (Model, View, Controller) but there was no easy way to query them for additional info. This is precisely what the artifacts API does for you now. Additional artifact types may be added an listed when calling 'griffon stats'. this API is further enhanced by the artifacts-plugin.

Lightweight services

Griffon 0.3 introduces services support. Services in Griffon differ from their Grails counterparts as they are not transactional. The Griffon runtime will inject an instance of a particular service to other artifatcs following a simple naming convention; this is not a replacement for a full DI solution but gets the job done without installing additional plugins.

Threading additions

While SwingBuilder's edt{}, doLater{} and doOutside{} are very handy they only work if the current toolkit is Swing. Griffon supports other toolkits via plugins (SWT, Pivot, Gtk, and JavaFX) so it makes sense to have generic threading facilities that can work with any toolkit. This is precisely what UIThreadHelper does.

In addition to this features, a new set of plugins is available too; check'em out

artifacts - further enhancements to the artifacts API. distributed as a plugin to keep core's dependency count low.
i18n - message i18n support using Spring's MessageSources.
erlang - support for making RPC calls to Erlang servers using Erlang's JInterface.
flyingsaucer - an XHTML renderer component.
processing - make 2D/3D renders and animations with the Processing Programming language and Griffon.
serial - serial port communication libraries.
thrift - Apache Thrift support (another serialization option).
jmx - a straight port of the Grails JMX plugin, originally created by Ken Sipe.
p6spy - another Grails plugin port.

Speaking of toolkits the following plugins have become available too:

swt - relies on SWTBuilder.
pivot - brand new UI Toolkit from VMWare labs, donated to Apache.
gtk - GNOME integration via java-gnome.

Griffon couldn't stay behind the recent NoSQL movement:

berkeleydb - available now!
db4o - available now!
couchdb - preview mode
neo4j - preview mode
riak - preview mode

Other existing plugins have been updated, perhaps most notably Spring, GSQL and builder plugins.

Let us know what your impressions are of these new features and tools. We would also appreciate if you let us know if Griffon has been of use to you and how. Feedback is welcome always.

Keep on Groovying!

Free lunches, mousetraps and the Actor model

Andrew Glover — Tue, 02 Mar 2010 18:01:00 CST

A politician once mused

A free lunch is only found in mousetraps.

While this quote is amusing, it’s painfully true. In fact, the whole notion of a free lunch and its consequences was copacetically captured by Herb Sutter in an article entitled “The Free Lunch is Over: A Fundamental Turn Toward Concurrency in Software” that was published in Dr Dobb’s Journal back in 2005. In this well crafted masterpiece, Mr Sutter tore apart the misplaced belief that Moore’s Law would continue to unleash higher and higher CPU clock speeds and thus he predicted an end of the “free lunch” that we’ve had when it comes to increasing the performance of software applications. That is, clock speeds have roughly stabilized around 3GHz — and they’ve held there for a few years now.

As Mr. Sutter points out

the growth [in chip speeds speeds] will come mostly in directions that do not take most current applications along for their customary free ride.

Thus, obtaining an appreciable speed up in application performance requires taking advantage of multi-core chip architectures (where Moore’s Law has been realized). And to do this, of course, Mr. Sutter advocates concurrent programming:

applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains

Interestingly, the author concludes with a few points, one of which hits the nail on the head with respect to where the majority of mind share around this subject is focused:

we desperately need a higher-level programming model for concurrency than languages offer today

Indeed, the basic programming model of hip languages like Java is thread based. And while multi-threaded applications aren’t terribly hard to write — there are challenging to write correctly.

In a paper published in 2006 by Edward A. Lee entitled “The Problem with Threads“, the author argues that concurrent programming isn’t all that hard. In his view, the problem isn’t with concurrency — it’s with the prevailing model: threads.

As he states:

The problem is that we have chosen concurrent abstractions that do not even vaguely resemble the concurrency of the physical world

The author goes on to point out that the inherent non deterministic nature of threads presents a conundrum for developers:

a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane.

Mr. Lee provides an interesting story regarding the challenges and hidden dangers of concurrent programming. He relates an experience where a multi-threaded application that had a strict code review policy in place along with 100% code coverage (note, what type of coverage or how it was obtained wasn’t disclosed) ran for 4 years without error. Nevertheless, finally the code deadlocked. He goes on to speculate that many

multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures

As such, Mr. Lee espouses an alternative to threads: actors. He’s quick to note that actor-oriented models aren’t new, but what he does suggest is interesting. He notes that languages that have actors, such as Erlang, weren’t taking root (at the time); thus, he submits:

We should not replace established languages. We should instead build on them.

Fast forward to today. Java the platform isn’t dead. It’s thriving with a multitude of alternate JVM languages — a few of which embed the actor model (namely Scala). What’s more, libraries written in Java and for Java are available, which enable the actor model (such as Kilim). Plus, the Java language itself has started to add more complex features to enable easier concurrent programming.

So what’s the lesson in all of this? First, the evolutionary instinct to throw more hardware at a performance problem is now extinct. Programs written today will need to be designed with concurrency in mind. Second, doing this with normal threads is challenging at best. A better, more understandable way is via the actor model, which is available in a number of frameworks and alternate languages. Therefore, learn them today, lest you find yourself snagged by a mousetrap, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Part 1 of Jonas Partner's series on OpenCredo Esper extension project

Russell Miles — Fri, 26 Feb 2010 07:25:53 CST

My colleague Jonas Partner has just published the first article in a series that is going to provide a walk through the new OpenCredo Esper extension project.

For anyone interested in what this project brings to the event-based-architecture table, Jonas' series is a great place to start.

Azure pricing and what this means for the cloud market, explained on InfoQ

Russell Miles — Thu, 25 Feb 2010 04:54:23 CST

My first article for InfoQ was published earlier today. In this article I summarise an interview with Matt Deacon of Microsoft on Windows Azure's entry into the priced, public cloud market.

This is a real rite-of-passage for the Azure PaaS and I attempt to frame what this means within the context of the emerging cloud utility market.

easyb will support behavior tagging

Andrew Glover — Mon, 22 Feb 2010 18:31:00 CST

Back in the Age of Aquarius, I wrote an article entitled “Use test categorization for agile builds” in which I attempted to delineate various types of tests and then went on to suggest how to categorize these various tests so as to get the most out of a build run (i.e make it fast and effective at providing meaningful feedback). Back then (and to an extent now) my concern was with test execution; that is, I like to categorize tests as fast and slow. Accordingly, I run the fast ones all the time, such as before I check-in (I prefer a fast build to be less than 3 minutes — longer and I get bored). What’s more, for the slow ones, I usually schedule a build (via Hudson, for instance) that runs them hourly, nightly, etc — it all depends on how slow they are, man!

As it turns out, unit-like tests are usually the fast ones and functional-like tests are the slow ones. This all makes sense as functional ones usually require a lot of test up, like seeding a database or firing up Selenium.

Categorizing tests by execution speed it helpful, but a bit broad in some cases. Thus, I often find myself grouping tests (or behaviors) by feature, behavior or goal. That is, there might be a macro-feature in development broken up by a series of stories (or tests) and I find it’s helpful to run those stories as a group in isolation for focus. Those behavior groups are then aggregated into iteration builds that correspondingly execute all targeted behaviors, for instance.

This exercise, combined with the influence of TestNG (which supported test groups long long ago) has lead to a new feature in easyb: tags. With the tags keyword, you can categorize a behavior and then exercise only those desired behaviors via the -tags command line option or via the tags attribute in easyb’s Ant task, for instance.

Thus, the following story is tagged as “23949314″ — this happens to be a Pivotal Tracker story ID and in the current iteration, there are 4 stories 23949314, 23949315, 23949316, 23949317.

tags "23949314"

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

The beauty here is that when this particular story is run, its status is pending, thus providing some status as to a particular feature.

Going forward in this iteration, subsequent easyb stories are tagged with appropriate IDs (23949315, etc) and during this iteration, builds are run that exercise these particular tags in isolation. Of course, there are other builds that exercise all other existing stories (via a build pipeline) so as to perform a continuous regression.

The tags keyword is flexible too — you can add multiple tags by including the tag names in a List like so:

tags ["23949314", "functional"]

scenario "AcmeFoo should support expired account deletions"
scenario "AcmeFoo should support child account deletions"

In this case, this story is tagged as both 23949314 and functional — accordingly, a build can be configured to execute only functional behaviors and, of course, this one will be included. Conversely, if a build is run with a tag such as prototype, then this particular story won’t be executed.

This is an evolving feature in easyb. Right now, only story level tags are supported. Scenario tagging is planned. What’s more, tags are currently supported in the tip of easyb’s SVN repository — if you’re eager to start using them now, you’ll have to build your own version of easyb. Otherwise, a release is forthcoming, which will contain this feature. Can you dig it?

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Setting up Clojure 1.1.0 on Mac OSX

Ken Sipe — Sun, 21 Feb 2010 22:27:00 CST

As part of the Lambda Lounge, established by Alex Miller (Thanks!!), we have started a group to study the SICP. We just started and are going virtual... if you would like to participate, email or tweet me (@kensipe). In the process of studying SICP and LISP, I plan on focusing on Clojure. Clojure was previously on my machine as I was reading Stu's book Programming Clojure, however increased usage would require some maturing of my tools. This led to the discovery of Mark Reid's blog on Setting up Clojure for Mac OS X, however I assume based on updates and changes over the last year, it requires some updates.

Read Mark's blog first... getting clojure, the clojure-contrib and jline. Here are the differences:

Create an environment variable CLOJURE_HOME assigned to the directory for clojure
Create the /bin directory for the clj script included below
Add $CLOJURE_HOME/bin in the $PATH
Clojure is distributed with clojure.jar in the CLOJURE_HOME... so I maintain that. It is expected that contrib and jline are in the same directory.
Mark's clj script has been updated below... The previous script invokes classes which are depreciated.

Here is the updated script:


#!/bin/bash
# Runs Clojure using the classpath specified in the `.clojure` file of the
# current directory.
#
# Ken Sipe   2010-02-20
# Inspired by Mark Reid 
# original: http://github.com/mreid/clojure-framework/blob/e1c80cc650f448713243be8272dba1fa3c1a7cea/clj
#
# This scripts expects $JAVA_HOME and $CLOJURE_HOME to be defined for the system it is running on
# The clojure.jar is standardly in the clojure_home dir (and not in the lib directory), so
# the expectation is that clojure-contrib.jar and the jline.jar are placed in the same dir

CLJ_DIR=$CLOJURE_HOME
CLOJURE=$CLJ_DIR/clojure.jar
CONTRIB=$CLJ_DIR/clojure-contrib.jar
JLINE=$CLJ_DIR/jline-0_9_5.jar
CP=$PWD:$CLOJURE:$JLINE:$CONTRIB

# Add extra jars as specified by `.clojure` file
if [ -f .clojure ]
then
   CP=$CP:`cat .clojure`
fi

if [ -z "$1" ]; then
   java -server -cp $CP \
        jline.ConsoleRunner clojure.lang.Repl
else
   java -server -cp $CP clojure.main -i $*
fi

Love the TextMate support and the history support in JLine!

OpenCredo Esper is Go!

Russell Miles — Sun, 21 Feb 2010 09:49:42 CST

I have the huge pleasure today of announcing the public availability of the open source OpenCredo Esper project, which has today hit its 1.0 release. From Jonas Partner's (O/C Esper project lead) release notes:

The OpenCredo Esper project builds on top of the excellent Complex Event Stream processing project, Esper. The OpenCredo Esper project is primarily motivated by a desire to make using Esper easier within messaging applications built on Spring Integration.

Using Esper to provide views of the data/messages passing through a system is an excellent way to improve the comprehension of complex event driven/asynchronous messaging based applications in Spring Integration.

In order to implement the Spring Integration integrations, the OpenCredo Esper project also created a Spring-style template which makes calling Esper extremely simple regardless of whether the application is using Spring Integration.

I had a hand in the early development of this project and it's great to see it joining the OpenCredo AMQ project in our open source ranks.

Look for a follow-up post where I'll show how to use OpenCredo Esper to implement a simple Throughput Monitor to some Spring Integration-based messaging infrastructure.

DynamicDomainProperties and the AGPL

Robert Fischer — Sat, 20 Feb 2010 18:24:00 CST

I just released the DynamicDomainProperties plugin for Grails, which allows domain classes to have dynamic properties. It’s pretty nifty, if I do say so myself.

Based on my frustration with the Grails plugin culture because of differing cultural assumptions about open source works, and based on my lack of appreciation for the promises of indirect compensation offered to me as an open source developer, I’ve decided to release it under the GNU-Affero GPL 3.0, which is like the GPL but (among other things) requires the source to be available to the users of a web app that use this plugin.

I’m open to the idea of releasing it under the more “biz-friendly” BSD, but then I’m going to want a different form of compensation. So I’m putting up a bounty via Pledgie: if I was building this plugin as a consultant, it would have cost a client about $2500. So, if the commercial community contributes $2500, I’ll do a BSD release. Anyone who donates $250 or more gets a single-domain usage license right away.

For more information on the plugin, see the plugin page on grails.org. (I’ve had enough difficulty with GitHub’s wiki freaking out on me and would rather avoid that.)

Comments

February 22, 2010, Marc Palmer wrote: I'm interested to see how this pans out Robert - good luck!
March 4, 2010, Jeremy Flowers wrote: Way to go. This looks like the way forward to me. In the Microsoft' arena GUI component vendors started to sell there wares this way too, like Infragistics. I always thought plug-ins would have to go the same way to get support for your plug-ins. You have to put food on the table somehow..
March 5, 2010, Does Grails have a problem? « The MetaSieve Blog wrote: [...] I have time to, I can completely comprehend Robert’s point of view and his desire to get a different kind of compensation for his open source work. In fact, there should be plenty of space for both approaches (and [...]

This post was by Robert Fischer, written on February 20, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/dynamicdomainproperties-grails-plugin-agpl/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/dynamicdomainproperties-grails-plugin-agpl/

Book Review: DSLs in Boo

Andrew Glover — Thu, 18 Feb 2010 17:34:00 CST

While I don’t spend a lot of time on the .NET platform anymore, I’m still a big fan of Boo. Having cut my teeth on Python many years ago, I’ve always enjoyed hip Pythonic languages and when Boo came out for the .NET platform way back when, I jumped on the opportunity to experiment with it and leverage it at client sites. What’s more, it’s no secret that I’m a fan of DSLs as I do find they can be quite powerful, for example, in leveraging natural language semantics that enhance the “user experience” such as with expressing intent.

Thus, when I had a chance to read Ayende Rahien’s “DSLs in Boo“, I jumped at the opportunity, baby! Ayende does a great job of of introducing the notion of DSLs (interestingly, there isn’t a ton of literature here specifically about DSLs alone other than Martin Fowler’s bliki and of course, Wikipedia) in the first chapter, specifically covering the various types of DSLs (i.e. internal, external, and he goes on to define graphical ones plus he reluctantly includes fluent interfaces). What’s more, he also explores why one would want to write an DSL. Here he covers a few reasons, but a quote stuck out regarding one particular reason, which is for expressing

rules and actions in a way that’s close to the domain and understandable to business people

This is, of course, the intent of easyb — that is, to express intentions in an easily understandable language that stakeholders can grasp.

After chapter 1, Ayende goes on to cover the basics of Boo, which, of course, would be needed should you want to actually create a DSL in Boo! It isn’t until chapter 4, however, that you start to get your hands dirty coding DSLs; nevertheless, I understand the need to introduce the various required concepts leading up to chapter 4. Thus, in chapter 4, a few high level examples are covered.

Later chapters go into some details about writing and maintaining DSL code; plus, in chapter 7, he unveils Rhino DSL, which is an open source project that facilitates authoring DSLs in Boo (Ayende, by the way, is a prolific coder — he’s all over the map in the .NET world). Chapter 8 finally covers testing a DSL, which I can attest as quite difficult but paramount to a DSL’s success and stability. He also goes on to cover versioning, which I found quite intriguing as backward compatibility is a double-edged sword.

What I find most interesting is the way in which a base language affects the resulting implementation of a DSL (i.e. the end result). That is, Pythonic DSLs still have the oft complained about “white-space issue.” For instance, here is a code snippet from the book for an order processing engine:

upon auth_denied:
  when preferred_customer:
       delay_order_until_payment_is_authorized "preferred customer benefit"
  when default_customer:
       cancel_order "no money, no order"

Note how the underlying language (Boo) forces the DSL to use spaces (rather than say brackets or def/do/end like calls), what’s more, underscores (i.e. _) are required so as to keep the compiler happy. It’s, in many ways, the same in something like easyb (which is, of course, backed by Groovy), which is essentially forced to use brackets and in one case, a comma like so:

given "a preferred customer", {
  //blah blah
}

Note how Groovy requires the DSL to include a comma between the description String and the Closure. Ruby, by the way, and in the case of something like RSpec, doesn’t have this requirement. For instance, in RSpec:

it "should return item enqueued" do
  @queue.enqueue("test")
  @queue.dequeue.should == "test"
end

Yet, notice the do and end! Needless to say, you can see similar influences in something like Scala too.

DSLs are interesting beasts and they’ve clearly affected productivity on various platforms (need I remind you that Rails is a DSL?). “DSLs in Boo” specifically explores DSLs on a specific platform, yet it’s still an interesting read. Because it’s my bag, I’m definitely looking forward to more books exploring DSLs as a main subject! All in all though, this is an interesting book regardless of your chosen platform. Can you dig it, man?

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Reporting from SpeakerConf 2010

Ken Sipe — Wed, 17 Feb 2010 17:14:15 CST

I was able to attend speakerconf 2010 this year in Aruba. It was an amazing gathering of talented leaders in the software development space. Each day of the conference started with several 15 – 30 minute talks lasting roughly 3 hours. According to the retro at the end of the conference, most people enjoyed and preferred these short talks as a primer to longer conversations in the afternoon along the pool or beach. Most talks were met with the struggle to maintain time often due to the many follow on questions generated by the subject. As far as I know the subjects were selected by the speaker and they were generally not preannounced. It is impossible to capture the essence of the conference and I make no effort to cover the most valuable part of it… the evening free form discussions. Most of the information went so fast that it was difficult to mentally be engaged and take notes. Here is a glimpse of what was discussed.

Day 1
Stu Halloway
Stu introduced the ADD development… which is alcohol driven. Stu then jumped into clojure, introducing a private testing project he is working on called circumspect. Stu offered up some advice for working in clojure:
* be less clever
* idiomatic clojure
* make adjectives not nouns

The focus on circumspect was to provide an idiomatic testing option for functional testing in clojure. Stu mentioned that through his testing exploration that an test he created actually detected a bug in the clojure code.

Dennis Byrne
Dennis is the first to discuss a topic on hardware and general process constraints in a talk titled Memory Barriers. The challenge is that virtual machines and hardware interfaces reorder code in ways most developers are not aware of. Fences or memory barriers define for the VM what can and can’t be reordered. There was some discussion on the expensive nature of these barriers.

Matt Deiters
Matt introduces a challenging problem that he has been working on in a story about vertex. The problem stems from social network analysis… it doesn’t work in SQL. Their previous implementation in SQL might take an hour to find all the details need for just 2 degrees of separation in a social network. Matt introduces neo4j an open source nosql graph database and neo4jr-simple, which is a RESTful ruby API. I enjoyed the fact that Matt wasn’t a No SQL bigot… He espoused a “Not all SQL” approach, using alternatives where SQL databases fall down.

Fred George
Fred displayed a triangle with management, story and programmers (or workers) at the vertexes. He wanted to focus on the relationship of the story to the programmer. Fred focuses on a Lean process and raises the question if acceptance tests are really lean? This stirred some debate. In the end, It appeared to me that what was being argued in most cases was the definition of acceptance tests vs. other types of tests. I don’t know if I agreed with Fred’s position, which we discussed at length the rest of the conference. My favorite part of his talk was a list of words or phrases that are flags that your project isn’t Agile. They include: Review, I need it in writing, write me a ticket, plan, checklist, code freeze, gant chart.

Brian Goetz
Brian’s talk is on how we find ourselves in this mess with multi-cores. Brian gives a wonderful history of processors defining them in eras: CISC era, RISC era, and Multi-Core era. The big take-aways for me include:
* a move from explicit to implicit parallelism
* moore’s law favors bandwidth over latency
* cost of memory access

With the speed of today’s processors, it takes 200-300 clock cycles to get 1 memory fetch, where it used to be 1 cycle. As latency increases we need more caches. Memory access times by clock cycle are roughly:
* Register ~ 1 cycle
* L1 ~ 3
* L2 ~ 15
* RAM ~ 200 – 300

Brian states “Memory is the new disk”. Clearly memory access is the new problem to solve in computer hardware. Brian also states that there is no programming model for this new multi-core era. Based on the talk, it appears to be that the industry has a new chicken or the egg problem. Hardware is struggling to evolve, because there is no software development model. Software is struggling because there isn’t a new standard. Brian concludes with latency is the enemy and the industries need to provide development teams with new tools. There will be a growing need to understand the memory access model of a running program, which can only be determined at run-time at the chip level. It will be necessary to understand the Integer pipe and memory cache misses. At the end of Brian’s talk, Nygard mentioned Chuck Moore’s Multi-Core chip where each core runs a tiny forth program. It is something I’ve added to the list of things to look into.

Michael Feathers
Michael discusses challenges to object oriented and functional language hybrids. There is background that I didn’t record, but one of the great observations is that functional programming is a “tell, don’t ask” model and object oriented programming is a “ask, don’t tell” model. In the FP approach, programming logic and data seem to bubble up the call tree and in the OO approach the opposite is true, logic seems to be pushed down the tree. Michael then looks at what it looks like conceptually if FP is on top of OO or OO is on top of FP. Michael then introduces the group to an algorithm used to solve morphological watersheds :)

Day 2
Steve Vinoski
Steve introduced us to a product his startup company Verivue, Inc is producing for the big media companies for streaming video. The IO throughput numbers were unbelievable. The software at the core of the product… Erlang!

Obie Fernadez
Obie and Desi introduced us to the agile practices of Hashrocket, indicating that they have evolved past iterations and they question the value added by iteration activities. They develop in one-week windows and use Pivotal Tracker for tracking stories and progress. The term “Iteration” isn’t even in their vocabulary. Later in the week, I challenged Obie to see if the word “week” replaces the word “iteration” as a convenience and to see if they were doing all things an ”iteration” would entail. The short answer is No! Clearly pivotal tracker desires a good look. Another tool Obie mentioned later in the week was Balsamiq... a tool used for screen mocking. Yet another tool to checkout.

Phillip Hanrigou
Phillip starts with the phrase “any sufficiently advance technology should feel like magic”. He continues with the fact that 30% of Amazon’s sales is based on recommendations. This was an interesting talk that had me flashing back to Matt’s talk on neo4j looking for synergies.

Oren Eini
Oren suggests that TDD doesn’t scale… with a beautiful picture of a motorcycle with training wheels. The major point is that unit tests are bad and scenario based tests are good.

Brian Marick
The take away… “I don’t want to care about anything until I absolutely have to care about it”… Love it!

Dave Thomas
Dave introduces us to vector functional languages such as KDB and k. These specialized languages are the workhorses behind querying ½ terabyte of data in 1 second for the hedge fund industry. Dave claims this is the most interesting technology to come along in 25 years. If interested, he suggests getting started with j from jsoftware.com

Eric Yew
Eric gives us a deep dive into GPUs. He was on the NVidia team that built the technology. Eric suggests that GPUs are making the industry rethink previous assumptions that are not correct in the GPU world. How would we code differently if:

There were no costs to threads
And no costs to context switching

The approach suggests that memory lookup is too expensive (seems like we keep hearing this :). It is cheaper to recalculate a value on a 100 threads then to retrieve from memory.

This model supports scale and throughput and not latency. Latency once again is sacrificed.

The memory model is upside down as well from the traditional general processors. There are 3 memory access points:

global - ~ 100 cycles to get to it
shared
local – stacks

It appears that the old paradigm of being abstracted from the hardware is over. The benefit is that the price of 2 Teraflops is near nothing… thank you computer gaming community!

Day 3
Neal Ford
Neal did a wonderful job presenting a presentation on presentation :) at a conference on conferences… it was a very meta way to start the morning. The big take away is http://presentationpatterns.com/ a site and forth-coming book on presentation styles, techniques and anti-patterns. The biggest benefit of the book is its focus on the practical. It will include templates for good practices.

Amanda Laucher
Amanda starts by defining the classifications of assholes and morons which got a lot of mileage the rest of the day. Amanda focused on educating us on terminologies in the category theory space with examples in F#. Here was what I was able to capture:

* Catamorphism - a fold
* Anamorphism – unfold
* Endomorphis – takes a type and returns the same type
* Homomorphism – takes a structure and returns the same structure or shape
* Monoid – A Functor
* Monad – Applied context
* A Monad is a monoid in the category endofunctors

Dave Hoover
Dave discussed the value of Resque and how it help in the development of Groupon.com

George Malamidis
George continues the conversation on memory access times and threads, introducing us to Node.js as a high scale solution for the web.

Michael Nygard
Thoughts on consistency – what a great talk! Michael introduces the concept of an observer and a super observer in a system through an object lesson. He then follows it up with the fact that with in a database there are often inconsistent states… the point is at the end of a transaction there cannot be any inconsistent states. For example, it is possible that an insert into the database would result in a violation of referential integrity… this is ok and necessary until a commit occurs.

Consistency is based on time. Frozen time means no change.

Another practical example:
2 ebay users making the same query at roughly the same time get different query results. This is viewed as being ok, because from the perspective of the observer it is consistent (they have no idea). From the perspective of a super observer there are some inconsistencies. This led to some discussion in mainly of the corporate failures stemming from the complexity created when trying to maintain consistency from the perspective of a super observer (which is a fallacy and trap).

Aslask Hellesoy
Another agile talk… this one focused on visualization of the return on development through CFD graphs. The suggestion was that velocity is a questionable valuation.

References included: CFD Details and a google spreadsheet
Robert Martin
I don’t think you can summarize Uncle Bob… you have to experience him :)

Summary
I made a couple of interesting observation / assessments through the conference. The first is there was a large percentage of the speakers / attendees that had a strong EE background. I truly enjoyed revisiting challenges at this level again.

Here are some of my takeaways from the conference:

We are at the beginning of a new era in field of computing. One in which we do not have a standardize model or tools
There is a need for programming solutions which reduce (or leak) the abstraction from the memory model that is generally preferable in the previous programming model. It will be necessary to indicate that values in memory are near, far or very far. It will be necessary to be able to measure and understand the cache miss rate.
We appear to be at our limits in our pursuit to improve latency. Worse…. Latency is the component that is consistently sacrificed to increase throughput.

Dead Programmers Society

Matt Stine — Tue, 16 Feb 2010 21:42:00 CST

A local Pastor once gave the advice of introducing ourselves and our kids to dead people. It is his belief that if his kids grow up idolizing the likes of Eric Liddell, Jim Elliot, and Hudson Taylor, they would be far better off than by looking up to many of our so-called “heroes” of today. I happen to agree with his advice, but that’s not the subject of tonight’s blog entry.

I think that this advice is very applicable to us as software developers today. While our industry is still young enough that a great many of our “founding fathers” are still around, it is surprising to see how often their work and contributions go unnoticed by the vast majority of us. At the January Memphis/Mid-South Java User Group meeting, our program focused on books that all of us as developers should read. Four of us gave our takes on the topic. Joel Neely, one of a few people that I learn from every time I get near them, pulled yet another rabbit out of his hat by focusing on several books, all of which had been published before the majority of us were out of diapers! One book struck me in particular: A Discipline of Programming by Edsgar W. Dijkstra. In it EWD “presents a formal approach to developing (non-deterministic!) algorithms, using what we would now call a DSL for algorithm design. Incidentally, that book was published in 1976.” (Thanks Joel for the excellent summary). I’d like to pull out just a couple of quotes from that book:

A most important, but also a most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language, this influence is - whether we like it or not - an influence on our thinking habits.

Just out of curiosity, does this sound anything at all to you like the frequent admonitions to learn a “language of the year (LOTY)?” Of course that isn’t the context of EWD’s quote, but the underlying principle remains the same. Almost universally accompanying that admonition is a statement along the lines of “even if you never use it in your day job, it will affect THE WAY YOU THINK about programming during your day job.”

…a carefully chosen separation of concerns is essential for the design of in all respects, high quality programs…

Does “loosely coupled, highly cohesive, modular architecture” come to mind?

…the fact that programming languages could be used as a vehicle for instructing existing automatic computers, has for a long time been regarded as their most important property…we shall try to redress the balance, and we shall do so by regarding the fact that our algorithms could actually be carried out be a computer as a lucky accidental circumstance that need not occupy a central position in our considerations…I view a programming language primarily as a vehicle for the description of (potentially highly sophisticated) abstract mechanisms.

I hear so much of what is bandied about today as “new” embodied in this quote. The calls to liberate programming from its “C” roots by banishing primitives, because hey, primitives are only their to keep “Java from being too slow!” The calls to favor “essence over ceremony” in language design by eliminating boilerplate code in favor of sensible defaults that clear away the noise from the algorithmic intent that we’re trying to communicate. The constant reminders that it’s more important for our code to be readable to humans, not to computers, because that’s what compilers are for.

What’s the point? The point is that most, if not all, of the ideas that are “new” today are simply restatements of past ideas in a different context. A wise man, one much wiser than I, once said “…there is nothing new under the sun” (Ecclesiastes 1:9). Edsgar W. Dijkstra passed from this earth in 2002, but his ideas live on, and they are very much applicable to software developers today. There are may others like him: Donald Knuth, John McCarthy, Alan Turing, David Gries - some dead, some alive, but all giants upon whose shoulders we stand. We would do well to consider their words.

Detecting eviction events on a WebSphere extreme Scale client

Billy Newport — Thu, 11 Feb 2010 14:42:00 CST

I've just pushed another sample to github. This sample shows how to attach a listener to the grid which watches transactions involved a set of maps. Any eviction events in those maps are 'noticed' and an eviction event is inserted in to a map thats basically used like a simple queue. I wrote a client side listener that can be attached to a client grid reference. This listener polls the server side grid looking for these events and returns them to the client.

The particular use case that prompted this sample was a customer using the grid to store application sessions and they needed a way for applications to be notified when the grid evicted their sessions. They wanted EVERY application JVM to see EVERY eviction. This is important to realize. Every eviction event will be processed by every application JVM instance. If we just needed the eviction event to be handled by exactly one application JVM then I'd write it using the getNextKey function in WXS.

The test package has sample objectgrid.xml and deployment.xml files as well as a test case showing how to invoke the client to test it.

How to use WebSphere eXtreme Scale in front of a database

Billy Newport — Tue, 09 Feb 2010 14:06:00 CST

This is a very common scenario. The customer wants a Map to reflect entries in a database table. They want:

To preload database records in to the grid map
Lazy fetch anything not preloaded in to the grid map
Write any changes to entries in the map back to the database

The sample on github shows how to do this. This sample uses the wxsutils library on github also. This contains code for several patterns and makes using WXS easier. The main things used by this sample are the bulk load primitives in the wxsutils library.

The sample as is works on the command line and uses a mysql database. OpenJPA 1.2 is used as an object relational mapper which means you can substitute DB2 or Oracle pretty easily. There is no mysql specific code in the main sample. I do register the mysql driver in the code.

The main package includes the objectgrid.xml and deployment.xml files showing how to make the grid with one Map (Customer) with an attached Loader. The Loader uses the builtin JPALoader. This Loader converts Map.get and map.update/delete methods to SQL commands to the database. The META-INF folder has the persistence.xml file which points at the database to use with the program.

The test package contains code to create a database table and fill it with records for the test. There is another test case that shows how to preload the database table in to a Map efficiently (using WXSUtils WXSMap.insertAll). The final test case just shows us looking up records in WXS.

For very large record sets then it may be necessary to fetch the records in a parallel fashion for highest speed but for reasonable numbers of records (I tested with 300k records on my laptop), the approach in this simple sample should suffice.

Spring Web Flow RefCard

Craig Walls — Mon, 08 Feb 2010 21:34:00 CST

In case you've not heard or don't follow me on Twitter, I'm pleased to announce that my fourth DZone Refcard, one covering Spring Web Flow, was released today. You can also read a short interview that I did with James Sugrue.

In case you're wondering...yep, I'm still working on Spring in Action 3. In fact, I'm now writing the Spring Web Flow chapter...so I get a chance to expand on what's in the Refcard. It's a lot of fun writing Refcards, but it's incredibly difficult to cram so much good material into less than 6 pages. In fact, despite my best efforts to keep it brief, over 2 pages of material landed on the cutting floor before the final product made it online. I assure you that there all of that good stuff, and more, will make it into the SiA3 Web Flow chapter.

I hope you like the Spring Web Flow Refcard. I hope to get a chance to do some more later this year once I've finished working on SiA3.

Goodbye cable, hello internet TV

Matthew Taylor — Sat, 06 Feb 2010 18:14:00 CST

This post is for Mario. I started it as an email to him, but he suggested it as a blog post in the first place, and now that it’s done it does seem to be post-worthly (although off-topic).

Here are the details of my new home TV system.

First of all, the only paying services I have for TV entertainment are DSL and Netflix. You can get the cheapest Netflix membership and still get all the “Watch it now” content that they have. Not the best and most recent movies, but there is a lot of stuff you can watch, and I always seem to find something interesting for myself or the kids. I think you can get the basic Netflix account for under $10.

My DSL is the only other monthly expense, which is $60 a month. But it’s only that high because I have a static IP address, which I want to use to access my home computers remotely (at some point in the future).

In order to handle all the streaming content to not only my media computer, but the other 2 computers in my house, I bought an N-band wireless router for $80. You can get a G-band wifi router for under $60, but it is 50Mbps vs over 300Mbps. It is worth it because I can watch youtube on my computer while my kids watch a movie on Netflix.

Hulu is awesome, and it is even more awesome because of Hulu Desktop, which installs on your Mac as an app and interfaces with hulu without a web browser. My Apple remote worked with it without configuring everything, so I can change shows easily without getting up.

The computer I’m using is just the MBP I was using for development for G2One. It only has 2 MB of memory, and it seems to be working fine. I was going to sell it and buy a new Mac Mini, but I thought why not try this one out first, and it is working just fine.

A note about resolution… I have a 1080p HDTV, and the quality of the streaming video can be hit-and-miss at times. Hulu *always* looks great, but Netflix can sometimes deliver crappy video quality if the shows you are watching are older. And YouTube usually looks crappy on a 52-inch TV, but it is better than nothing.

Let me know if any of you attempt this, I’ll be interested to hear of other people’s experiences. I’m really happy so far, but then I hate cable companies. I get so frustrated with the DVR UIs. Don’t they pay usability experts to design them? AT&T Uverse was the best I’ve seen so far, so coming back to Comcast here made me want to throw up.

Another thing you need to think about is placement of the media computer. If you are going to use a remote, you have to put it in a place with line of site to your remote, so it can’t be behind the entertainment center somewhere. I also have a spot right in front of the flatscreen where I put my (very small Apple) keyboard and wireless mighty mouse. You’ll still need to put a keyboard and mouse somewhere because you can’t do everything with your remote.

I Don’t Get It

Robert Fischer — Fri, 05 Feb 2010 14:29:00 CST

When encountering a bug in an open source project, most Java people seem unwilling to either fix it themselves or pay the maintainer to fix it—they’d rather abandon the project or kludge their software painfully and repetitively. WTF?

Comments

February 5, 2010, Hamlet D'Arcy wrote: In the past my problem has been that my organization would not let me rely on a personal or nightly build of a project. So when you need a workaround by the end of the week, waiting 2 months for the next release candidate of an OS project is not an option. ... now go release JConch 1.2.
February 5, 2010, Dave wrote: I've encountered this a few times. Sometimes, I'm trying to get things done, so I hack around the problem and then there's not always time to go back and learn a new codebase to submit a patch. Further, having submitted a few patches to a maven plugin (a piece of software I cannot stand, but submitted anyway), it's been months since I uploaded a freakin' zip file to their JIRA and no movement. I also think compared to, say, Ruby, a lot of Java packages are very large and complex. If I find a bug in Spring or Hibernate, my chances of even navigating the codebase to find out where the problem is are nil. And Spring is actually pretty clean code; I mucked through JSCh and the maven release plugin and was HORRIFIED at how awful the code was. And then there's the myriad build systems and spotty tests; One of the Castor devs asked me write a test or he wouldn't accept my patch; my patch was to make his code actually compile. And their tests on trunk (and release tag) didn't pass. Meanwhile, on github, I've submitted patches to things that I wrote and tested in less time than it took to find the svn link on Apache's site. I've also incorporated others changes to my code (that they didn't even submit). Granted these things are not as complex as Spring, but, well, maybe that's a good thing?
February 5, 2010, Dave wrote: @Hamlet D'Arcy in your case, I have imported the released version I'm using into our company's svn repo and made changes I needed against that, then deployed THAT to our maven repo. It was painful, but worked.
February 5, 2010, Robert Fischer wrote: Argh. I've totally forgotten about JConch 1.2. Just released it. It's now a Gradle-based build (I wanted to OSGi-ify the project and have a Maven repo).
February 5, 2010, Peter Niederwieser wrote: From my experience, most developers aren't even willing to take the time to report a bug they encounter...
February 6, 2010, Aristotle Pagaltzis wrote: I agree with Peter – I actually tweeted the same observation just a few weeks ago. I got one response to that that didn’t satisfy me either. It’s not limited to Java either.
February 6, 2010, James Carr wrote: Yeah... this has often surprised me as well. I've witnessed a team try to use some open source solution and give up because of a minor bug and go to a much more difficult to use proprietary solution (which amusingly had more critical bugs). I was also surprised when at my current client site they actually asked me spend a week working on fixing a bug in an open source project and submit a patch... that's definitely the best attitude to have. :)
March 8, 2010, Michael Chermside wrote: For projects in ALL languages, the difficulty in getting a patch accepted is a genuine issue (and is difficult to solve). There is a sweet-spot of small, recent projects that accept patches easily. Older projects are often neglected (or abandoned) by their original authors, which makes accepting patches difficult. Larger projects necessarily set standards (like requiring unit tests or moderately complicated review processes, or certain coding standards) which not every patch will meet. The problem is not easily solved because these are inherent problems rather than just projects being obstinate. Meanwhile, Java programmers are probably worse because (1) many well-known open-source Java projects are large and corporately sponsored which makes it difficult to get them to accept patches, and (2) many Java programmers work in corporate environments where it is difficult to get "permission" to contribute to an open source project. Simply not being in the habit of doing so makes the practice less likely than with other languages.

This post was by Robert Fischer, written on February 5, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/i-dont-get-it/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/i-dont-get-it/

Groovy, Grails, Griffon @ ESDC 2010

Andres Almiray — Thu, 04 Feb 2010 18:50:00 CST

In just a few weeks (March 1-3) the first edition of ESDC will take place in San Mateo, California. ESDC is a brand new conference that offers more than 70 workshops and technical classes. There are plenty of topics to choose from. Groovy, Grails and Griffon are no exception. A list of Groovy related workshops and classes follows.

WORKSHOPS

Groovy Tutorial – Scripting on the JVM - Paul King

Groovy is a dynamic language for the JVM; it’s like a super version of Java. For Java programmers, it offers a syntax that closely resembles (in some cases exactly resembles) Java, but offers many improvements that not only greatly simplify code but also provide an enriched environment with many productivity features. In many cases, such features are promised in Java versions 7, 8 or up, but they are available today in Groovy.

For non-Java programmers, Groovy provides a great entry point to the JVM. It allows code to be written which harnesses many of JVM features without the large learning curve associated with learning all of Java. Groovy’s mix of language design choices and features make it suitable for everything from small scripting tasks through to large complex software systems with stringent Agile quality requirements.

The tutorial will introduce attendees to Groovy, cover writing their first programs, run through a whirlwind tour of the basic language features, including data types, regex handling, XML processing, databases, graphics, file processing, build tasks, using Closures, testing and more.

The tutorial will also talk about the pros and cons of using Groovy, available tool support, great ways to introduce Groovy intro your project, what practices may change if you adopt Groovy, and briefly compare Groovy with other JVM languages.

Prerequisites: This is an introductory workshop. It assumes that attendees have some programming experience but requires no in-depth Java experience. It is suitable for Java programmers wanting to increase their productivity by using a dynamic language or for non-Java developers such as PHP or .NET developers wanting to leverage the JVM without the burden of learning all of Java.

Groovy Power Features - Paul King

Some of the power features of Groovy you’ll learn about are:

Leveraging Groovy’s features to write DSLs
Writing Web Service servers and clients in a few lines of code
Replacing Design Patterns with language features and/or libraries
Talking to the Polyglot world from Groovy: Scala, Clojure, Jython, JRuby, JavaScript and Jaskell
Harnessing constraint/logic and functional programming
Simple but powerful tests
Simplify how you write build tasks
Accessing Hibernate through GORM
Harnessing parallel processing
Leveraging Spring and OSGi

Prerequisites: This is an intermediate to advanced tutorial. It assumes that attendees have some previous exposure to Groovy or are accomplished at Java. Alternatively, you can take the Groovy Tutorial.

CLASSES

Make Your Builds More Groovy - Paul King

The bane of many developers' lives is their build scripts. They find them hard to write, hard to understand later, and each project seems to do things in vastly different ways and they take forever to run—if they successfully run at all. This class looks at the available technologies to ease the burden of writing build files with a particular focus on technologies that support the Groovy programming language. We’ll cover:

The “build your own” approach, including process and parallelization features using Ant from Groovy; using Groovy from Ant; using Ivy; using Gant; using Maven and GMaven; using Graven; using Gradle; continuous integration server hooks; and deployment management.

While these options leverage the Groovy language, they are by no means solely for building projects that make heavy use of Groovy directly. All of these technologies are very much applicable to Java only as well as polyglot projects. A brief look at non-Groovy alternatives will also be covered.

As we discuss each technology (some would argue that some of the options we have for writing builds actually can make our lives worse!), we’ll try to look at the pros and cons and best practices.

Groovy from the Trenches - Andrew Glover

Groovy has been successfully leveraged at various companies around the world in order to build enterprise applications on the Java platform quickly. In particular, Groovy has proved its value at a large financial services client on more than one occasion to build mission critical applications in short order, all while leveraging their existing investment in the Java platform from developer tools all they way to data center management.

From exposing legacy data models via RESTful Web services, to mission-critical reporting applications built with GroovySQL and Spring, to Groovy's core language features and much, much more, I'll show you tips and tricks that separate Groovy from the pack and expose how one can quickly build real world applications that meet a business's needs quickly with fewer lines of code.

Make the Most of your Testing Time in the Java Virtual Machine - Andres Almiray

The Java platform ecosystem harbors many languages besides Java. In that vast set of languages there is one that has received the title of “Next-Generation Java,” but not because it dismisses Java, not at all! It is because it embraces the language and extends it in a friendly and fluent way. That language is Groovy. Testing Java code can be cumbersome, especially when rigid limits as verbose syntax and static typing get in the way. Groovy can help you write less code while retaining the same behavior. It can also test your Java production code without any special bridge between languages. Groovy integrates seamlessly with all Java libraries, testing frameworks and IDEs, which means you won’t be throwing away your Java knowledge, you’ll just make it groovier. You’ll learn how to use Groovy to aid Java tests in key areas as code verbosity, mocking, XML production/consumption, and behavior-driven development.

Prerequisites: Attendees should have good knowledge of the Java language and common testing frameworks like JUnit and TestNG, and be proficient in one of the major Java IDEs (IDEA, NetBeans, Eclipse), as well in Apache Ant or Maven. Laptops loaded with the latest stable groovy distribution can be found at groovy.codehaus.org/Download

Make Your Tests More Groovy - Paul King

Testing can be a complex and thankless task. The technologies change so fast that your tools don't work as they should or you have to write lots of low-level boilerplate code that is obsolete almost as soon as it's written. Your tests are brittle and hard to relate to customer requirements. You aren't even sure that you are testing the right things. Let's explore some techniques and tools for easing some of these burdens and try to move testing from tedious and hard to easier and fun!

In this class, you’ll sample a flavor of many techniques and tools, and cover these topics:

Using easyb for BDD-flavored acceptance tests
Developer testing using JUnit 4, TestNG, Instinct, Spock and GMock
Writing domain specific testing languages (testing DSLs)
Testing Web applications with WebTest, Tellurium, Selenium and WebDriver
Testing RESTful and SOAP-flavored Web services
Testing databases with DbUnit
Testing rich clients and GUIs with FEST
Performance testing with JMeter
Model-driven testing

Many of the examples will use the Groovy language, but the lessons apply to Ruby, .NET, and other languages and scenarios.

Easy BDD with Groovy - Andrew Glover

The Manifesto for Agile Software Development essentially focuses on meeting customer needs through reducing wasteful activities. For example, Agile developmental practices push for reducing repetitive documentation and for a rapid acceptance of change. Yet, achieving these goals is by no means easy. While a process can enable increased collaboration, for instance, there are various tools that can effectively implement Agile principles.

Once such tool is easyb (www.easyb.org), which is a Groovy-based domain specific language, which facilitates collaboration by bridging those that define requirements (i.e. customers) and those who turn requirements into code (i.e. development). With easyb, collaborative teams can develop stories in a specific format, which are then implemented as tests through a framework that marries the underlying application. This test suite enables change and produces accordance among Agile teams in short order.

In this talk, you will learn how to embrace collaboration and change rapidly by defining easyb stories that exercise a Java application end to end. You will learn how to define specific easyb structures, how to plug them into real code, and how to run them in an automated fashion. You will see first hand how non-coders can define tests easily and how the collaboration this brings yields working software faster.

Building Desktop Applications with Griffon (Part 1 & 2) - Andres Almiray

Building a desktop application is a hard task; there are so many things to keep track of that many projects simply fail to meet their goals. Setting up the project structure, keeping each artifact in a well-identified location given its responsibility and type, defining the base schema for managing the application's life cycle, making sure the build is properly set up, and more. These are recurring tasks that should be handled by a tool or, better yet, a framework. Griffon is such a framework. Inspired by the Grails framework, Griffon aims to bring the same productivity gains to desktop development. There are so many traits shared by both frameworks that a Grails developer should be able to pick up the pace fairly quickly.

Prerequisites: Attendees should have good knowledge of the Java language and Java Swing. Laptops loaded with the latest stable Griffon distribution found at griffon.codehaus.org/Download.

Construction Techniques for Domain Specific Languages - Neal Ford

Domain-specific languages have been the Next Big Thing for years now, but they have quietly started penetrating the development world. This talk covers language techniques in Java, Groovy and Ruby on how and why to create DSLs. This class starts by motivating you to convert APIs into DSLs, and various patterns, anti-patterns, and best practices for how to achieve the optimum effect. You’ll also learn about the very important topic of implicit context, and how language constructs can allow you to write less verbose and more expressive code.

RESTing Easy With Grails - Andrew Glover

Representational state transfer (REST) is a way of thinking, not a protocol or standard. It's a style of designing loosely coupled applications that rely on named resources (in the form of URLs, URIs and URNs, for instance) rather than messages. Ingeniously, REST piggybacks on the already validated and successful infrastructure of the Web: HTTP. That is, REST leverages aspects of the HTTP protocol such as GET and POST requests, which map standard business-application needs, such as create, read, update and delete (CRUD). By associating requests, which act like verbs, with resources, which act like nouns, you end up with a logical expression of behavior (GET this document and DELETE that record, for example).

In this class, you will learn about the mechanism for creating RESTful applications with Groovy’s Grails, which gives you the ability to apply RESTful techniques with a full-fledged Web application framework that supports an ORM and testing to boot! As you will learn, using Groovy's Grails framework makes building RESTful Web services a snap.

See you there!

Keep on Groovying!