NFJS One

Weld extensions alpha available

Pete Muir — Thu, 11 Mar 2010 16:00:28 CST

simplejson 2.1.0

Bob Ippolito — Thu, 11 Mar 2010 13:00:21 CST

simplejson (documentation) is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.5+. It is pure Python code with no dependencies, but features an optional C extension for speed-ups.

simplejson 2.1.0 is a major update with several new features and bug-fixes:

Decimal serialization officially supported for encoding with use_decimal=True. For encoding this encodes Decimal objects and for decoding it implies parse_float=Decimal
Python 2.4 no longer supported (may still work, but no longer tested)
Decoding performance and memory utilization enhancements http://bugs.python.org/issue7451
JSONEncoderForHTML class for escaping &, <, > http://code.google.com/p/simplejson/issues/detail?id=66
Memoization of object keys during encoding (when using speedups)
Encoder changed to use PyIter_Next for list iteration to avoid potential threading issues
Encoder changed to use iteritems rather than PyDict_Next in order to support dict subclasses that have a well defined ordering http://bugs.python.org/issue6105
indent encoding parameter changed to be a string rather than an integer (integer use still supported for backwards compatibility) http://code.google.com/p/simplejson/issues/detail?id=56
Test suite (python setup.py test) now automatically runs with and without speedups http://code.google.com/p/simplejson/issues/detail?id=55
Fixed support for older versions of easy_install (e.g. stock Mac OS X config) http://code.google.com/p/simplejson/issues/detail?id=54
Fixed str/unicode mismatches when using ensure_ascii=False http://code.google.com/p/simplejson/issues/detail?id=48
Fixed error message when parsing an array with trailing comma with speedups http://code.google.com/p/simplejson/issues/detail?id=46
Refactor decoder errors to raise JSONDecodeError instead of ValueError http://code.google.com/p/simplejson/issues/detail?id=45
New ordered_pairs_hook feature in decoder which makes it possible to preserve key order. http://bugs.python.org/issue5381
Fixed containerless unicode float decoding (same bug as 2.0.4, oops!) http://code.google.com/p/simplejson/issues/detail?id=43
Share PosInf definition between encoder and decoder
Minor reformatting to make it easier to backport simplejson changes to Python 2.7/3.1 json module

Charter for Compassion [Flickr]

Aaron Gustafson — Thu, 11 Mar 2010 11:00:23 CST

Aaron Gustafson posted a photo:

ar.charterforcompassion.org/share/the-charter/

PyCon 2010, Analysis: The Other Kind of Testing

Bob Ippolito — Thu, 11 Mar 2010 08:00:27 CST

I gave a talk at PyCon 2010 in Atlanta last month called Analysis: The Other Kind of Testing (video). It's a very simple overview of techniques such as split testing (AB testing) and a call to action to improve django-lean.

Atlanta was a fantastic location for PyCon 2010, and I look forward to returning next year. Hopefully if I give another talk I'll be able to put a little more time into it :)

As per usual, I've been incredibly lazy about updating this blog, so you're much better off following @etrepum on Twitter.

The Community Manager

Pete Muir — Wed, 10 Mar 2010 16:00:34 CST

Using BIRT and Actuate with JSF, RichFaces

Max Katz — Wed, 10 Mar 2010 13:00:49 CST

Virgil Dodson from Actuate posted a great tutorial on how to use BIRT and Actuate with JSF. RichFaces is used as well. The tutorial uses jsf4birt library developed by Exadel.

jsf4birt can be downloaded here.

Actor style messaging and honey do lists

Andrew Glover — Wed, 10 Mar 2010 11:00:43 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.

Links for 2010-03-09 [del.icio.us]

Aaron Gustafson — Wed, 10 Mar 2010 08:01:45 CST

Google Responds To Privacy Concerns With Unsettlingly Specific Apology
The Onion... brilliant as always.
Using Git for SVN Repositories Workflow
Great overview of using Git with standard SVN repository layouts.

Annotation-Based Spring Portlet MVC

John Lewis — Tue, 09 Mar 2010 16:00:46 CST

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

Mockito 1.8.3 Released

James Carr — Tue, 09 Mar 2010 13:00:45 CST

Szczepan has announced on the Mockito user mailing list that 1.8.3 of Mockito has been released. This released includes several small (but useful) additions as well as bug fixes.

The two parts of this release I like are the new annotations @Spy, @Captor, and @injectMocks. These add to the already useful @Mock annotation to simplify test setup tremendously. Additionally, the @Mock annotation is now configurable so you can add different Mock/Stub styles; previously @Mock only supported the default mock behavior, now you can configure it to RETURNS_MOCKS, CALLS_REAL_METHODS, etc.

This release also includes a feature I requested that can be useful when trying to get legacy code under test, something I call deep stubs. Ever been in the situation where you have code with something like this in the middle of it:

someCollaborator.getFoo().doBarThings().getBaz().execute().processResult();

Normally to stub this call, you’ll have to mock every object returned by each method call, and then stub the last one. Examples for code like this can be a little verbose, but now you can just @Mock the aggregate root and do something like:

given(someColllaborator.getFoo().doBarThings().getBaz().execute().processResult).willReturn(resultObject);

Just remember friends, this is only good for legacy code… if you are already writing your code exemplar first to drive your design, you should know better than to make your object know too many details about it’s neighbors.

This release also includes a patch I submitted to stop having all of the examples in a test run when trying to run a single one in eclipse and intelliJ when using MockitoJunitRunner.

For a complete list of features/fixes, see the release notes.

Another Good Tidbit from GOOSGBT

James Carr — Tue, 09 Mar 2010 11:00:43 CST

I’m currently in chapter 12 of Growing Object Oriented Software Guided By Tests and thought I’d share another good tidbit from one of the asides:

Put Tests in a Different Package

We’ve adopted a habit of putting tests in a different package from the code they’re exercising. We want to make sure we’re driving the code through its public interfaces, like any other client, rather than opening up a package-scoped back door for testing.

Good point! Almost everytime I’ve found my self expose a method that should be private as protected or default it’s been because that method was really in gross violation of Single Responsibility Principle and I’ve often taken such code and extracted it to a separate object.

Thoughts?

Java Champion

Howard Lewis Ship — Tue, 09 Mar 2010 08:00:49 CST

You might call it petty, you might call it vain, but I've aspired to be recognized as a Java Champion for the last couple of years. The process by which you are selected for this is a bit secretive, but I've finally gotten the nod and joined the roster.

My larger goal for Tapestry has always been to create a web application platform so compelling that it would draw developers to the Java programming language, just to be able to use it. Of course, that's not so much a goal as it is a journey. Technologically, I think Tapestry has the chops to embrace that goal (or journey) ... and looking at current discussions and developments in the Tapestry world, I think the other critical areas where Tapestry is lagging (namely, Documentation and Marketing) may come around.

Want to do your part? Blog about Tapestry ... what you like, what you don't like, what's missing, and what's hidden.

ESDC 2010 resources

Andrew Glover — Mon, 08 Mar 2010 16:00:27 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.

Webinar recording: Add BIRT Reporting to JSF Applications Using RichFaces

Max Katz — Mon, 08 Mar 2010 13:00:24 CST

Add BIRT Reporting to JSF Applications using RichFaces recording is available here. You can also download the complete application I showed during the webinar here.

Test

Max Katz — Mon, 08 Mar 2010 11:00:25 CST

Test

Posted via web from maxkatz’s posterous

Buzz Buzz

Sean Kane — Mon, 08 Mar 2010 08:00:31 CST

The evening light today was perfect for shooting some tree blossoms and the busy bees working on them. I was using my 28-135 lens for these shots which means I had to crop quite a bit to get the right detail. The real challenge here was sharp focus with the quickly moving bees. For that, I used live view, zoomed in to quickly manually focus on the bees while somewhat still. Once they started to move, I let the rapid-fire shutter go. This collection is out of about 30 total attempts.

Griffon rises once more

Andres Almiray — Sun, 07 Mar 2010 16:00:24 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!

PodcampNashville ‘10 take-aways

Cal Evans — Sun, 07 Mar 2010 13:00:29 CST

Dear Reader, The dust has settled, the swag-bag has been rifled through and the drink tickets have all been exchanged for various combinations of kool-aid and vodka. Since I can’t find any of my Microsoft friends who can can me into the beta for the new Microsoft Courier, I had to go old school and take [...]

Podcamp Nashville ‘10 Review

Cal Evans — Sun, 07 Mar 2010 11:00:20 CST

Dear Reader, Today was the day! Podcamp Nashville 2010, downtown Nashville at the Cadillac Ranch. As always with the Nashville camps, overall it was great experience. The sessions were quality with speakers like Mitch Canter and Kate Gallagher. It was great to meet some new friends and catch up with some old [...]

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

Robert Fischer — Sun, 07 Mar 2010 08:00:28 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 imperative. 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, 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.

This post was by Robert Fischer, written on March 6, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/post-functional-scala/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/post-functional-scala/

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.

NFJS One

Weld extensions alpha available

simplejson 2.1.0

Charter for Compassion [Flickr]

PyCon 2010, Analysis: The Other Kind of Testing

The Community Manager

Using BIRT and Actuate with JSF, RichFaces

Actor style messaging and honey do lists

Links for 2010-03-09 [del.icio.us]

Annotation-Based Spring Portlet MVC

Mockito 1.8.3 Released

Another Good Tidbit from GOOSGBT

Put Tests in a Different Package

Java Champion

ESDC 2010 resources

Webinar recording: Add BIRT Re­porting to JSF Ap­pli­ca­tions Using RichFaces

Test

Buzz Buzz

Griffon rises once more

Addon enhancements

Native libraries support

Packaging enhancements

Artifacts API

Lightweight services

Threading additions

PodcampNashville ‘10 take-aways

Podcamp Nashville ‘10 Review

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

Let’s start with some background.

And that gets us to this blog post.

Webinar recording: Add BIRT Reporting to JSF Applications Using RichFaces