No Fluff Just Stuff

Griffon @ Silicon Valley Web JUG

Andres Almiray — Fri, 03 Jul 2009 16:00:00 CDT

Want to know more about Griffon? will you be in the Bay Area around July 21st? then you're invited to Silicon valley Web JUG's next meeting, I'll have both the pleasure and honor of giving an introductory talk about Griffon. Do you still think that Swing application development simply sucks or it is too painful to bear? let me show you what Griffon offers then decide for yourself see you there!

Keep on Groovying!

Integrate WebDevGeekly into the podcast feed?

Robert Fischer — Fri, 03 Jul 2009 13:00:01 CDT

So, I’m a regular on WebDevGeekly, a “discussion about web development issues, news, and views”—really, it’s a kibitz session between Michael Kimsal (publisher of WebDevPublishing), me, Matthew Eernisse, and the Windmill guys (Mikeal Rogers and Adam Christian). Topics range wildly, but it’s always exploring the dynamic and changing culture of web development.

I’ve been making a habit of sharing my media appearances via the EnfranchisedMind podcast feed, but stopped sharing WebDevGeekly when it became clear I was going to be a regular. At this point, though, I’ve gotten a request to put it back onto the feed. What do people think?

Ever seen two robots discuss AOP in python?

Greg Turnquist — Fri, 03 Jul 2009 11:00:00 CDT

I couldn’t resist using this website to put together a little movie. What is better than a couple of robots discussing aspect oriented programming in python? (This was based on my earlier post The Case forAOP in Python)

Okay, maybe its a little stiff, but you have to admit that putting this together on a web [...]

Links for 2009-07-02 [del.icio.us]

Aaron Gustafson — Fri, 03 Jul 2009 08:00:00 CDT

Extreme JavaScript Compression With YUI Compressor
An excellent presentation from Nicholas on how to squeeze the most code out of your JavaScript when it comes to compression.

Spring Python makes final 1.0.0 release

Greg Turnquist — Thu, 02 Jul 2009 16:00:01 CDT

Please read the official press release from SpringSource about this historic release of Spring Python. Please visit http://www.springsource.com/download/community in order to download a copy. NOTE: Spring Python has now been relocated to the top level, instead of being inside EXT.

It’s the first Spring Extension to reach live status and also progress to a stable 1.0.0 [...]

Links for 2009-07-01 [del.icio.us]

Aaron Gustafson — Thu, 02 Jul 2009 13:00:00 CDT

Google is using hProduct!
I completely missed this, but it looks like Google is parsing hProduct now when crawling he web. As one of he first people actively working on he spec, I'm thrilled to see this happen.

My Article on Grails Logging in This Month’s GroovyMag

Robert Fischer — Thu, 02 Jul 2009 11:00:00 CDT

http://groovymag.com/images/gm9_125.jpg”>
I’ve got an article in this month’s GroovyMag entitled “Goldilocks and Grails Logging — Part 1″. As the title implies, it’s about getting logging just right, and this month’s installment talks about how to think about logging, the underlying Log4J library design, and the basics of the Grails Log4J DSL. Next month will [...]

Continuations to Continue

Greg Wilkins — Thu, 02 Jul 2009 08:00:01 CDT

Jetty-6 Continuations introduced the concept of asynchronous servlets to provide scalability and quality of service to web 2.0 applications such as chat, collaborative editing, price publishing, as well as powering HTTP based frameworks like cometd, apache camel, openfire XMPP and flex BlazeDS.

With the introduction of similar asynchronous features in Servlet-3.0, some have suggested that the Continuation API would be deprecated. Instead, the Continuation API has been updated to provide a simplified portability run asynchronously on any servlet 3.0 container as well as on Jetty (6,7 & 8). Continuations will work synchronously (blocking) on any 2.5 servlet container. Thus programming to the Continuations API allows your application to achieve asynchronicity today without waiting for the release of stable 3.0 containers (and needing to upgrade all your associated infrastructure).

Continuation Improvements

The old continuation API threw an exception when the continuation was suspended, so that the thread to exit the service method of the servlet/filter. This caused a potential race condition as a continuation would need to be registered with the asynchronous service before the suspend, so that service could do a resume before the actual suspend, unless a common mutex was used.

Also, the old continuation API had a waiting continuation that would work on non-jetty servers. However the behaviour of this the waiting continuation was a little different to the normal continuation, so code had to be carefully written to work for both.

The new continuation API does not throw an exception from suspend, so the continuation can be suspended before it is registered with any services and the mutex is no longer needed. With the use of a ContinuationFilter for non asynchronous containers, the continuation will now behaive identically in all servers.

Continuations and Servlet 3.0

The servlet 3.0 asynchronous API introduced some additional asynchronous features not supported by jetty 6 continuations, including:

The ability to complete an asynchronous request without dispatching
Support for wrapped requests and responses.
Listeners for asynchronous events
Dispatching asynchronous requests to specific contexts and/or resources

While powerful, these additional features may also be very complicated and confusing. Thus the new Continuation API has cherry picked the good ideas and represents a good compromise between power and complexity. The servlet 3.0 features adopted are:

The completing a continuation without resuming.
Support for response wrappers.
Optional listeners for asynchronous events.

Using The Continuation API

The new continuation API is available in Jetty-7 and is not expected to significantly change in future releases. Also the continuation library is intended to be deployed in WEB-INF/lib and is portable. Thus the jetty-7 continuation jar will work asynchronously when deployed in jetty-6, jetty-7, jetty-8 or any servlet 3.0 container.

Obtaining a Continuation

The ContinuationSupport factory class can be used to obtain a continuation instance associated with a request:

    Continuation continuation = ContinuationSupport.getContinuation(request);

Suspending a Request

The suspend a request, the suspend method is called on the continuation:

  void doGet(HttpServletRequest request, HttpServletResponse response)
  {
    ...
    continuation.suspend();
    ...
  }

After this method has been called, the lifecycle of the request will be extended beyond the return to the container from the Servlet.service(...) method and Filter.doFilter(...) calls. After these dispatch methods return to, as suspended request will not be committed and a response will not be sent to the HTTP client.

Once a request is suspended, the continuation should be registered with an asynchronous service so that it may be used by an asynchronous callback once the waited for event happens.

The request will be suspended until either continuation.resume() or continuation.complete() is called. If neither is called then the continuation will timeout after a default period or a time set before the suspend by a call to continuation.setTimeout(long). If no timeout listeners resume or complete the continuation, then the continuation is resumed with continuation.isExpired() true. There is a variation of suspend for use with request wrappers and the complete lifecycle (see below):

    continuation.suspend(response);

Suspension is analogous to the servlet 3.0 request.startAsync() method. Unlike jetty-6 continuations, an exception is not thrown by suspend and the method should return normally. This allows the registration of the continuation to occur after suspension and avoids the need for a mutex. If an exception is desirable (to bypass code that is unaware of continuations and may try to commit the response), then continuation.undispatch() may be called to exit the current thread from the current dispatch by throwing a ContinuationThrowable.

Resuming a Request

Once an asynchronous event has occurred, the continuation can be resumed:

  void myAsyncCallback(Object results)
  {
    continuation.setAttribute("results",results);
    continuation.resume();
  }

Once a continuation is resumed, the request is redispatched to the servlet container, almost as if the request had been received again. However during the redispatch, the continuation.isInitial() method returns false and any attributes set by the asynchronous handler are available.

Continuation resume is analogous to Servlet 3.0 AsyncContext.dispatch().

Completing Request

As an alternative to completing a request, an asynchronous handler may write the response itself. After writing the response, the handler must indicate the request handling is complete by calling the complete method:

  void myAsyncCallback(Object results)
  {
    writeResults(continuation.getServletResponse(),results);
    continuation.complete();
  }

After complete is called, the container schedules the response to be committed and flushed.

Continuation resume is analogous to Servlet 3.0 AsyncContext.complete().

Continuation Listeners

An application may monitor the status of a continuation by using a ContinuationListener:

  void doGet(HttpServletRequest request, HttpServletResponse response)
  {
    ...
    
    Continuation continuation = ContinuationSupport.getContinuation(request);
    continuation.addContinuationListener(new ContinuationListener()
    {
      public void onTimeout(Continuation continuation) { ... }
      public void onComplete(Continuation continuation) { ... }
    });
    
    continuation.suspend();
    ...
  }

Continuation listeners are analogous to Servlet 3.0 AsyncListeners.

Continuation Patterns

Suspend Resume Pattern

The suspend/resume style is used when a servlet and/or filter is used to generate the response after a asynchronous wait that is terminated by an asynchronous handler. Typically a request attribute is used to pass results and to indicate if the request has already been suspended.

  void doGet(HttpServletRequest request, HttpServletResponse response)
  {
     // if we need to get asynchronous results
     Object results = request.getAttribute("results);
     if (results==null)
     {
       final Continuation continuation = ContinuationSupport.getContinuation(request);
       
       // if this is not a timeout
       if (continuation.isExpired())
       {
         sendMyTimeoutResponse(response);
         return;
       }
       
       // suspend the request
       continuation.suspend(); // always suspend before registration
       
       // register with async service.  The code here will depend on the
       // the service used (see Jetty HttpClient for example)
       myAsyncHandler.register(new MyHandler()
       {
          public void onMyEvent(Object result)
          {
            continuation.setAttribute("results",results);
            continuation.resume();
          }
       });
       return; // or continuation.undispatch();
     }
     
     // Send the results
     sendMyResultResponse(response,results);
   }

This style is very good when the response needs the facilities of the servlet container (eg it uses a web framework) or if the one event may resume many requests so the containers thread pool can be used to handle each of them.

Suspend Continue Pattern

The suspend/complete style is used when an asynchronous handler is used to generate the response:

  void doGet(HttpServletRequest request, HttpServletResponse response)
  {
     final Continuation continuation = ContinuationSupport.getContinuation(request);
     
     // if this is not a timeout
     if (continuation.isExpired())
     {
       sendMyTimeoutResponse(request,response);
       return;
     }
     
     // suspend the request
     continuation.suspend(response); // response may be wrapped.
     
     // register with async service.  The code here will depend on the
     // the service used (see Jetty HttpClient for example)
     myAsyncHandler.register(new MyHandler()
     {
       public void onMyEvent(Object result)
       {
         sendMyResultResponse(continuation.getServletResponse(),results);
         continuation.complete();
       }
     });
   }

This style is very good when the response does not needs the facilities of the servlet container (eg it does not use a web framework) and if an event will resume only one continuation. If many responses are to be sent (eg a chat room), then writing one response may block and cause a DOS on the other responses.

Continuation Examples

Chat Servlet

The ChatServlet example shows how the suspend/resume style can be used to directly code a chat room. The same principles are applied to frameworks like cometd.org which provide an richer environment for such applications, based on Continuations.

Quality of Service Filter

The QoSFilter(javadoc), uses suspend/resume style to limit the number of requests simultaneously within the filter. This can be used to protect a JDBC connection pool or other limited resource from too many simultaneous requests.

If too many requests are received, the extra requests wait for a short time on a semaphore, before being suspended. As requests within the filter return, they use a priority queue to resume the suspended requests. This allows your authenticated or priority users to get a better share of your servers resources when the machine is under load.

Denial of Service Filter

The DosFilter(javadoc) is similar to the QoSFilter, but protects a web application from a denial of service attack (as best you can from within a web application). If too many requests are detected coming from one source, then those requests are suspended and a warning generated. This works on the assumption that the attacker may be written in simple blocking style, so by suspending you are hopefully consuming their resources. True protection from DOS can only be achieved by network devices (or eugenics :).

Proxy Servlet

The ProxyServlet uses the suspend/complete style and the jetty asynchronous client to implement a scalable Proxy server (or transparent proxy).

Gzip Filter

The jetty GzipFilter is a filter that implements dynamic compression by wrapping the response objects. This filter has been enhanced to understand continuations, so that if a request is suspended in suspend/complete style and the wrapped response is passed to the asynchronous handler, then a ContinuationListener is used to finish the wrapped response. This allows the GzipFilter to work with the asynchronous ProxyServlet and to compress the proxied responses.

Where do you get it?

You can read about it, or download it with jetty or include it in your maven project like this pom.xml.

Euler was groovy too

Andrew Glover — Wed, 01 Jul 2009 16:00:00 CDT

I recently stumbled across Project Euler, which is a hip website containing quite a few different math challenges. The idea being that people can attempt to solve any particular challenge which ever way they can (that is, in any language and with any algorithm) — the site doesn’t provide answers either — you must create an account and submit your answer. Project Euler will then check your answer and issue a response — correct or incorrect. If it’s your bag and you Google the project, you’ll find some interesting posts solving various problems in various languages ranging from F# to Scala to C (and everything in between). What’s also interesting is that each post for a problem usually is different in some way or another, which of course provides some interesting learning opportunities.

Problem 1 entails figuring out the sum of numbers divisible by 3 and 5:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.
Find the sum of all the multiples of 3 or 5 below 1000.

I thought it would be interesting to see if I could solve this in Groovy as the solution clearly deals with iterating over a series of numbers — and as everyone who has played with Groovy (or some other dynamic language for that matter) knows, iteration is a blast, baby!

Accordingly, my first pass yielded the following code:

def sum = 0
(1..<1000).each{
 if((it % 5 == 0) || (it % 3 == 0)){
   sum += it
 }
}
assert sum == /* do it yourself, baby! */

Note that I’m using Groovy’s exclusive range feature to easily iterate over all numbers less than 1000. I then proceed to use Groovy’s it variable, which represents the current value in the iteration (i.e. 1, 2, 3, etc) and test the instance with Java’s modulo operator (that is, modulo returns the remainder of division — 10 modulo 5 is 0, but 11 modulo 5 is 1). If there is a match, I add it to the sum variable. This is programming 101 and brought me back to the Age of Aquarius, baby!!

That was easy enough; however, I wanted to see if I could do away with the sum variable by using one of Groovy’s many hip magic methods attached to collections. Thus, my second attempt leverages Groovy’s findAll method, which permits putting a condition in the resulting closure, which then returns a collection meeting that criteria. Accordingly, with the returned collection of numbers meeting my criteria (that is, any number that is divisible by 5 or 3), I then have to issue the sum method like so:

def val = (1..<1000).findAll{(it % 5 == 0) || (it % 3 == 0)}
assert val.sum() == /* you gotta figure it out yourself, man! */

Groovy’s sum method is straight forward — it takes all the values in a collection (presumably add-able) and adds them up!

Admittedly, the second example is a bit harder to read (at first glance, that is) but it sure is a bit more aesthetic than the first brute force bogue example, isn’t it?

You can now follow The Disco Blog on Twitter, baby!

CommunityOne 2009

Jason Lee — Wed, 01 Jul 2009 13:00:01 CDT

New MSDN Article on RIA Services Published

Brad Abrams — Wed, 01 Jul 2009 11:00:01 CDT

I saw Maurice de Beijer recently published a good introduction article on .NET RIA Services.

Getting started with the .NET RIA Services

The post starts with a very good introduction:

RIA, short for Rich Internet Applications, is a bit of an umbrella term for all sorts of applications delivered through the browser. The key aspect however is that they deliver some business function and are not just about flashy graphics. Business applications tend to work with data and other business resources so they are usually built in the standard N tier architecture. If we take a look at this N tier architecture for the most common type of business resource, the database, we typically see the Create, Read, Update, Delete, (CRUD) pattern appear all the time. While implementing the CRUD pattern in Silverlight isn’t extremely difficult the very fact that the Silverlight application runs in the browser without direct database access and all server communication is done asynchronously makes this harder than it needs to be. This is exactly one of the problems the .NET RIA Services is trying to solve. Of course there is more to the .NET RIA Services and the standard CRUD operations is just one of the issues addressed. As we will see in this article it addresses much more by including things like data validation, general communication, keeping client and server code synchronized and more.

When evaluating the .NET RIA Services we should be looking at it from two different perspectives. First of all it is a set of design guidelines of how to create a RIA style application. Secondly it is a series of .NET libraries and Visual Studio templates implementing the design guidelines. So even if you don’t want to use the .NET RIA Services binaries, studying the design is very useful for a Silverlight line-of-business (LOB) developer. Another thing to keep in mind when evaluating the .NET RIA Services is that it is not just about Silverlight but more general. The first samples may be with Silverlight clients but a client could equally well be written in ASP.NET/JavaScript, WPF or any other client that can call WCF services.

Enjoy!

Review: "Iron Python in Action" by Michael Foord and Christian Muirhead

Ted Neward — Wed, 01 Jul 2009 08:00:01 CDT

OK, OK, I admit it. Maybe significant whitespace isn't all bad. (But don't let me ever catch you quoting me say that.)

The reason for my (maybe) shift in thinking? Manning Publications sent me a copy of Iron Python in Action, and I have to say, I like the book and its approach. Getting me to like Python as a primary language for development will probably take more than just one book can give, but... *shrug* Who knows?

Bear in mind, I have plenty of reasons to like IronPython (Microsoft's Python implementation for the .NET environment):

A good friend of mine, Harry Pierson (aka @DevHawk), is the PM on the IPy project, and I'm generally prejudiced in favor of those things that people I know and respect.
I'm generally a fan of dynamic languages, particularly those that let you do strange and twisted things to the type system and its instances at runtime. (Yes, I'm looking at you, ECMAScript...)
I spent some quality time with IronPython Studio last year while researching a Visual Studio Extensibility "Deep Dive" paper.
I've known Jim Hugunin (the creator of IronPython, and Jython before that) for some years, ever since his days working on AspectJ, and he's one of those scary-smart guys that, despite knowing they're scary-smart, still render me stunned when I listen to them.
I'm a huge fan of the DLR. It's like having Parrot, but without having to wait a decade (give or take).

But, just to counterbalance the scales, I have plenty of good reasons to dislike IronPython, too:

Significant whitespace.
The "There's only one way to do it" oath that Pythonistas seem to hold as religion. (Somebody told me that building C-Python—the original implementation—only works for you if you swear a holy oath to The One True Way on the One True Way Bible. Needless to say, I believe them, and have never tried to build C-Python from sources as a result.)
Significant whitespace.
Uh.... did I mention significant whitespace yet?

I admit, it was with some hesitation that I cracked open the book. Actually, to be honest, I was really ready to just take out all my dislike of significant whitespace and pour it into a heated, vitriolic diatribe on everything that was just wrong with Python.

And...?

Well, OK, I admit it. Maybe significant whitespace isn't all bad.

But this is a review of the book, not the technology. So, on we go.

What I liked about the book

The focus is on both .NET and Python, and doesn't try to short-change either the "Python"-ness or the ".NET'-ness by trying to be a "Python book (that happens to run on .NET)" or a ".NET book (that happens to use Python for code samples)". The authors, I think, did a very good job of balancing the two, making this the book to get if you're in that area on the Venn diagram where "Python" overlaps with ".NET".
Part 2, "Core development techniques", starts down the "feed you the Python Kool-Ade" pretty quickly, heading straight into Chapter 4 ("Writing an application and design patterns with IronPython") without much of a pause for breath. The authors get into duck typing, protocols, and Model-View-Controller within the first four pages, and begin working on a running example to highlight some of the ideas. (Interestingly enough, they also take a few moments to point out that IronPython on Mono works, and include a couple of screen shots to that effect as we go, though I personally wonder just how many people are really going down this path.) I like the no-holds-barred, show-you-the-code style, but only because they also take time throughout the prose to talk about some of the concepts at work underneath and laced throughout the code. "Show me then tell me" is a time-honored tradition, but too many authors forget the "tell me" part and stop with code. These guys do a good job of following through.
The chapters in Part 3, "IronPython and advanced .NET", form an interesting collection of how IronPython can fit into the rest of the .NET stack, demonstrating how to use IronPython with WPF, ASP.NET, and IronPython's crowning glory, Silverlight. If you're into front-end stuff, this is the section where I think you're going to have the most fun.
The chapters in Part 4, "Reaching out with IronPython", is I think the most important part of the book, showing how to extend IronPython (chapter 14) with C#/VB extensions (similar to how a C-Python developer would extend Python by writing C code, but much much simpler) and the opposite—how to embed IronPython inside of existing C#/VB applications (chapter 15), which is really an exercise in using the DLR Hosting APIs. While the discussion in chapter 15 is good, I wish it'd had a bit more thorough discussion of how the DLR could be hosted regardless of the scripting language, though I admit that's pretty beyond the scope of this book (which is focused, after all, entirely on IronPython, and as a result should stay focused on how to host IPy).

What I found "Meh" about the book

Part 1 ("A new language for .NET", "Introduction to Python", and ".NET objects and IronPythong") does a good job of bringing the rank beginner up to speed, getting some basic Python ideas across in the same breath that they bring .NET home. The only problem is, it only works well if you're neither a Python programmer nor a .NET programmer. Chapter 1, for example, does a sort of Cannonball-into-the-pool kind of dive into Python, but dives equally into the "Iron" parts as it does the "Python" parts. If you're either a Pythonista or a .NETter, I suspect you're going to be tempted to flip pages pretty quickly, and (I suspect) miss a few things. Chapter 2 is all about Python (meaning .NETters will probably spend some time here), but it certainly doesn't feel like an exhaustive reference, nor does Chapter 3 stand as an exhaustive discussion about all things .NET, either. I almost wish all three chapters had been collapsed into one—suffice it to say, I don't feel like I know the Python language, and don't feel like this book could be my Python reference next to me as I learn it, and I know that it's not a great .NET reference, either. Fortunately, the goal of these three chapters feels pretty clearly to be "Teach you just enough to make you dangerous (and able to understand the rest of the book)", and once we hit Part 2, rubber meets road pretty quickly.
By the time you hit Chapter 7, less than halfway through the book, the authors have created a fairly nice, if simplistic, application for later dissection, but it's not until you hit Chapter 7 that they begin to start unit-testing, even though they insist (on page 17) that "Dynamic language programmers are often proponents of strong testing rather than strong typing" (a quote they attribute to Bruce Eckel, though I'm relatively certain I heard Dave Thomas and Neal Ford say it with respect to Ruby, long before Eckel started "Thinking in Python... or Flex... or whatever"). If unit-testing is that important, why wait three chapters into the application's development before writing a single unit-test? This doesn't jibe with me, somehow.
If you're into back-end stuff, chapter 12 on "Databases and web services" is pretty bland. The fact that the two are combined into a single chapter is indicative, all by itself, of how deep or intensive the coverage goes, and there's zero mention of anything beyond basic ADO.NET. The coverage on web services covers REST relatively well, but there's zero coverage of WCF, and the whole of SOAP-based services is all of four or five pages. And Workflow? Doesn't exist, isn't even mentioned (except for an appearance in a table, "The major new APIs of .NET 3.0"). Yikes.

What I actively disliked about the book

Actually, not much. Manning did their usual superb job of arrowed callouts to point out particular concepts in the code listings, the copyediting is professional (meaning there's no obvious typos or misspellings that just break up the flow of prose, something that not all publishers seem to take seriously), and the graphics flow nicely alongside the prose, not dominating the page but accentuating it.

In fact, about the only thing I'd care to criticize is the huge number of footnotes, particularly in the first chapter. (By page 20 in the book, there have already been 30 footnotes.) When you have three footnotes per page, on average (and sometimes more), it does tend to distract, at least to me it does. It feels like there were ways, for most of them, to inject the idea or concept into the main prose, or leave it out entirely, but that could just be a difference of writing style, too.

Summation

If you're a .NET developer interested in learning/using IronPython on your next project, this is a definite winner. If you're a Python developer looking to see how to break into .NET, I'm not so sure this is your book, but I say that mostly because I'm not a Pythonista and can't really speak to how that mindset will find this as an introduction to the .NET space. My intuition tells me that this would be a good springboard into another book on .NET for the Python programmer, but I'll have to leave that to Pythonistas who've read this book to comment one way or another.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Enterprise JavaFX - complete edition

Max Katz — Tue, 30 Jun 2009 16:00:00 CDT

The following series shows how to connect JavaFX to enterprise server-side technologies. This series covers Seam.

Part 1 - Introduction: JavaFX and Seam with Flamingo
Part 2 - Tutorial: JavaFX and Seam with Flamingo
Part 3 - Flamingo CRUD feature
Tooling: Exadel JavaFX plug-in for Eclipse

A future series will cover how to connect JavaFX with Spring framework.

Spring WS plugin 0.2.2 released

Russell Miles — Tue, 30 Jun 2009 13:00:05 CDT

I've just released version 0.2.2 of the Spring WS plugin. The major new feature in this release is the capability to completely customize the how an incoming document is routed to your endpoint by being able to override the default naming strategy. For more info, checkout the plugin's homepage.

A massive thanks goes out to Ivo Houbrechts for contributing the new customization code!

I’ve Updated My About Page

Jason Lee — Tue, 30 Jun 2009 11:00:00 CDT

Central Florida Software Symposium - Aug 21 - 23, 2009

Tue, 30 Jun 2009 09:00:00 CDT

No Fluff Just Stuff is pleased to announce the Central Florida Software Symposium, Aug 21 - 23, 2009.

Catch these Featured Sessions

Emergent Design & Evolutionary Architecture
by Neal Ford

Most of the software world has realized that BDUF (Big Design Up Front) doesn't work well in software. But lots of developers struggle with this notion when it applies to architecture and design. Surely you can't just start coding, right? You need some level of understanding before you can start work. This session describes the current thinking about emergent design & evolutionary architecture, including both proactive (test-driven development) and reactive (refactoring, composed method) approaches to discovering design. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping you code in sync with the problem domain.

JSF 2.0: Advanced Topics
by David Geary

This session covers advanced aspects of JSF 2.0.

The Java Memory Model
by Brian Goetz

What's the worst thing that can happen when you fail to synchronize in a concurrent Java program? Its probably worse than you think -- modern shared-memory processors can do some pretty weird things when left to their own devices.

Fan and Fortress at the Lambda Lounge

Alex Miller — Tue, 30 Jun 2009 08:00:01 CDT

This month at the Lambda Lounge (Thursday, July 2nd, 6 pm), we will be bringing you two NEW languages that start with F.

First, I will be introducing you to a research language called Fortress aimed at people doing scientific computation on large (peta-size) systems. It is a language that explicitly tries to meet the challenge of running systems up to a million cores and is “infested” with parallelism. This is a language for tomorrow.

Next, Scott Bale will be talking about the Fan programming language. This language takes the best of languages like Java and C#, throws out the cruft, and bleeds in some modern features. Is it the next Java? Java++? Come find out…

Should be a great night with two languages making their debut at the Lounge.

Another Interview: NFJSOne

Robert Fischer — Mon, 29 Jun 2009 16:00:01 CDT

Lots of interesting podcasts over on the NFJSOne Podcast site, including one with yours truly.
Here’s the summary of my interview from the NFJSOne podcast site:
Robert and Jared talk about the wave of convention over configuration that’s sweeping the Java software, a little about GORM versus Hibernate, and how Grails is leading the way for the [...]

Desert Southwest Software Symposium - Jul 24 - 26, 2009

Mon, 29 Jun 2009 15:00:00 CDT

No Fluff Just Stuff is pleased to announce the Desert Southwest Software Symposium, Jul 24 - 26, 2009.

Catch these Featured Sessions

The Amazing Groovy Weight-loss Plan
by Scott Davis

"The central enemy of reliability is complexity." (Dr. Daniel Geer) Java is a powerful programming language. A smart developer can do nearly anything with Java. So the next question is, "How quickly can it be done? How many lines of code does it take to do common tasks?" Groovy greases the wheels of Java by decreasing the complexity of the language while preserving the raw power. At first glance, you might think that this talk is simply about how Groovy drastically reduces the lines of code you need to write. What this talk is really about is bringing simplicity, clarity, readability, and yes, beauty to your source code.

Test Driven Design
by Neal Ford

Most developers think that "TDD" stands for Test-driven Development. But it really should stand for "Test-driven Design". Rigorously using TDD makes your code much better in multiple ways.

JSF 2.0: An Introduction
by David Geary

This session introduces JSF 2.0 fundamentals, with emphasis on new features in JSF 2.0.

JavaFX and Seam with Flamingo - Dzone article, part 2

Max Katz — Mon, 29 Jun 2009 13:00:00 CDT

Part two of JavaFX and Seam with Flamingo article. Part one here. This part is a step-by-step tutorial on how to connect JavaFX to Seam with Flamingo.