JavaFX at the Chicago Java Users Group

Saturday, December 12th, 2009

I’ll be giving a talk on JavaFX this upcoming Tuesday, December 15th at the Chicago Java Users Group. The talk is titled “JavaFX for Java Developers”, and is meant to be a survey of JavaFX from the perspective of someone already familiar with Java.

Thanks to the generosity of Apress, there will also be an ebook raffle for Lucas Jordan’s new book: “JavaFX Special Effects“, which I had the privilege of tech reviewing.

So if you live in the Chicagoland area, come check us out.

I Heart Joel on Software

Wednesday, December 2nd, 2009

Let me make one thing perfectly clear before you embark on this journey with me: I very much love reading anything Joel Spolsky writes. I am a Joel on Software fan-boy. I am also aware that, due to his ubiquitously strong opinions, he is frequently cited/criticized on other tech blogs, and that doing so is derivative and shallow, even though that’s what I’m about to do here.

I acknowledge this, but it’s ok, because I Heart Joel on Software.

I have read most of Joel’s books, including the self-titled “Joel on Software”, the sequel “More Joel on Software”, the dubiously too-small-to-be-a-book “Smart and Gets Things Done”, and the edited-by-Joel “Best Software Writing I”.

After reading so much of his work, it’s very clear that if there’s one thing Joel cares about, based on reoccurring topic, it’s what separates the programmer wheat from the code-monkey chaff: that is, how do you identify a Good Programmer?

Indeed, “Smart and Gets Things Done” and its analogous sections in “JoS”, and “More JoS” is billed as a hiring guide for managers looking to hire the best possible programmer.

Herein lies the paradox though: the real audience of all of Joel’s books is his core readership, which are programmers, and since the thrust of “Smart and Gets Things Done” is that 99% of programmers are terrible at what they do and not worthy of jobs, Joel then, must have a latent disdain for his own readership.

Joel’s ideal programmer has graduated from an Ivy League Engineering School, and can construct a Full-Adder from memory without using XOR gates. Further, Joel asserts that these mythical engineers are never on the market since they get hooked up with extremely rewarding and fulfilling internships right out of school and never want for anything else. The 10 or 12 engineers that fit into this category won’t buy his books since they apparently know all these things a priori, which means that it’s all of us slack-jawed programmers that must be enabling Joel’s book royalties.

So it seems that Joel is stuck in a love/hate relationship with his audience. I assume he loves to sell books, yet he must be aware that the type of programmer he takes so much time to insult and the programmer reading the insults are in fact one in the same.

Why would we, the sub-par programmers of Joel’s universe continue to enable this? It’s possible that we are indeed so Neanderthalic that we simply don’t have the higher functioning thought processes to get the joke. Do we think he’s talking about someone else?

“Ha ha, it’s so true, Joel!  Those boneheads have to submit their resumes to dice.com to get work. What morons! Ooh, what’s this? Another email from a recruiter? Yes, I am interested in a Hot Java Contract in New Jersey! A ‘must fill ASAP’?  I’m sending my resume now!”

Or perhaps we are well aware that we are both the target and the audience. In this case it becomes more like an abusive relationship. Even though he hurts us, we know he doesn’t really mean it. We keep coming back for more, hoping to read that post someday that will heal all the hurt and make it all better.

We yearn for the post from him that admits that, indeed there is no correlation between what school you went to and what type of engineer you are. In fact, how fast you can regurgitate a quick sort algorithm on a white board has nothing to do with how you’ll fare in a team, and further, that raw algorithm analysis is both an unnecessarily reductionist and irrelevant way to assess someone’s skill.

We’d like to sit on our high horses and look down at the unwashed masses with disdain and stroke our egos by saying that what we do is High Art as opposed to all those Java Lightweights that would break down and cry if they ever saw a dangling pointer, but the fact is that it requires no more (and no less) innovation or brain cells to write bug tracking software (for example) as it does to develop budget reporting software. Any project is a fount of potential technical challenges, no more or less important than any other project’s, and solved by programmers of all mental shapes and sizes.

We, Joel’s Readership, would like to think we’re better than most of the programmers out there and may feel the need to distance ourselves from all the inept imbeciles since the field has such a low barrier to entry, as compared to say, being a doctor. But of course, we’re writing software, not saving people’s lives, and if we are talking about the category of software that does keep people alive, whether by moving the laser to the correct place over the cornea, or adjusting the yaw of an aircraft so it can safely land, then it was probably written by a contractor, that class of engineer which stands diametrically opposed to the “never on the market” rule and probably didn’t go to Yale.

In fact, I imagine that, as the aircraft descends into that last critical few hundred feet above the ground, the pilot is subconsciously hoping that the engineer who wrote that motion control code was more concerned with preventing gimbal lock than with being able to sort that array of numbers in “log n” time.

We, Joel’s readership, would love to see his acceptance of us in this form, but alas, we are unlikely to see such a concession from him.  At least not while we, the JoS fan-boys, keep buying his books.

All I Really Need to Know About Programming I Learned in Kindergarten

Thursday, November 12th, 2009

On the days that I pick up my daughter from Kindergarten, she’s always bursting with excitement over what she has learned that day. It often makes me wistful for my own Kindergarten days, almost 30 years ago. As I listen to my daughter talk about her day, I reflect on my own time in kindergarten, and how, trite as it might seem, that year spent in school at age six, really gave me all the tools and life lessons I needed to be a professional programmer.

I often think back to what Miss Johnson used to say in that small classroom at Laird Elementary back in the early 80s, “now remember class, try to keep your initial load factor for your hashtables at 0.7″. At the time, I remember thinking, “now when am I ever going to use that?” But sure enough, my mid-thirties self now chuckles at my younger naivety.

After recess, we would all gather ’round and listen to her tell the story of the Traveling Salesman and how he could never find his optimal route in a deterministic amount of time. “Use a branch-and-bound algorithm!” we’d all shout at the climax of the story.

“Children”, she’d chide us, “can we do better than that?” Of course we couldn’t resist being baited like that, “use a Nearest-Neighbor Heuristic!” we’d exclaim with excitement, barely able to stay on our carpet squares.

She would often tell us that while learning to clean up after ourselves, and sharing with others were indeed important life skills, they were not relevant at that age, and we would likely learn about them in grad school.

Come to think of it, I do recall an extensive lecture on the importance of flushing and always washing your hands in Genetic Algorithms in my Masters program.

Music Explorer FX v1.1: Now with “Fame” Control

Wednesday, November 11th, 2009

Version 1.1 of the JavaFX-based music discovery application, Music Explorer FX has been released. You can try it here:

This version is mostly about performance and stability improvements and it’s also the first version to be released under JavaFX 1.2. Additionally, it sports a new feature: the “Fame” knob:

For those not familiar with how the application works, MEFX will present you with artist recommendations based on an initial artist. Pictured below, for example, is a web of six artist recommendations that sound similar to the  popular alternative metal band, “Breaking Benjamin”.

One potential issue with this kind of search though is that if you are a fan of BB, then you are likely to have already heard of many of these bands. This is where the Fame knob comes in. If you dial down the Fame knob, indicating that you want less famous recommendations, and rerun the search, you’ll now get these results:

These bands are still very similar to “Breaking Benjamin”, they just happen to be less popular. Note that the green “popularity” gauges are considerably lower than the artists on the first search. This can be a great way to explore the long tail of music.

The Fame knob works in the other direction as well. Turn it to the right (positive) and you’re guaranteed to get some mainstream results that even the RIAA would be proud of.

This release also boasts notable performance improvements and some crazy caching techniques.  In particular, I encourage you to check out the much improved image gallery (bring up your favorite artist, and click on the “photos” icon). For a more detailed rundown of MEFX, check out this post.

So whether you’re an old friend of MEFX, or a you stumbled across this post in search of what happened to that popular 80s musical, go ahead and give it a try.

Search is not Discovery

Friday, October 30th, 2009

Paul Lamere over at Music Machinery has a great write-up about Google’s new music search feature. To give you a sense of where he stands, he ends the post with a memorable mantra: “Search is not discovery”.

Search is great if I know that I’m looking specifically for Pearl Jam’s live cover of “Sittin’ on the dock of the bay“. Search becomes less useful if I’m sick of listening to Pearl Jam and want something new — something not Pearl Jam specifically, but something similar…you know, something that I’ll like.

This is where music discovery comes in. Companies like the Echo Nest are trying to make it possible to one day type “find music that I will like” into that ubiquitous search box and get back something meaningful.

On that subject, I’ve been experimenting with a feature for the next version of Music Explorer FX which will lend itself to music discovery “in the large”.

Currently MEFX allows you to explore the artist similarity space very linearly. Generally, once you’ve selected an artist you can go forward, or back, but you can’t easily branch off and return later, or see comparisons between more than a few artists at once.

But what if you could browse a much larger segment of the similarity space, and see connections between 100 artists, instead of just two? What if you could “plot a course” between Pearl Jam and Otis Redding, viewing all the artists along the way?

Below is a concept screen shot (written in JavaFX) illustrating this idea. I hope you like abstract dots!

More details to follow…

The Awkward Relationship Between Swing and JavaFX

Tuesday, October 27th, 2009

Here’s a recent awkward interaction between a Starbucks Barista and me:

Me: I’ll take a Grande Coffee (note, I don’t actually order “just a coffee”, but I’m too embarrassed to write out the actual drink. Being forced to write “Grande” instead of “medium” is embarrassment enough — I already conceded “barista” over “employee”).
Barista: Will that be all for you today?
Me: Yep — and my name’s not “Todd”.
Barista: I’m sorry?
Me: Did you just call me Todd?  My name’s not Todd.
Barista: No…I didn’t. I asked if you wanted anything else.
Me: …Ok, my mistake. (Note: a normal person would let the misunderstanding go at this point — but not me! More awkwardness to follow!)
Barista: That will be $3.50
Me: Today! You said “today”!
Barista: I don’t–
Me: You said “will that be all ‘today’”, and I heard it as “will that be all, Todd“!
Barista: Ok, well–
Me (visibly relieved): Oh man. I sure diffused that awkward situation. What a relief.

Swing and JavaFX currently find themselves locked in a perpetual cycle of awkward exchanges and misunderstandings.

We’ve been told from the beginning that JavaFX is targeted toward media-rich social internet applications and not meant to be a replacement for Swing. We then, however, have to then reconcile that viewpoint with news like SwingX’s funding drying up and the Swing Application Framework missing the JDK 7 train (or “boat” depending on how you feel these things travel).

Feelings of anger, disbelief, and dismissiveness seem to abound in the Swing community. “Why is Sun abandoning Swing? Why are they shoving another language at us?” I admit, as a Swing developer myself, the facts on the ground look bleak for Swing.

It does seem too bad that Swing and JavaFX are in a zero-sum relationship w/r/t allocated resources and active development. It’s hard to deny that many of the high-profile Swing developers are now actively pushing hard on JavaFX.

If we look beyond that, however, I think that there is plenty of room for both technologies in the client-side Java ecosphere.

The Java Platform has always been about choice — and lots of it. Today’s Java developer has a staggering amount of choice in the realm of web frameworks, persistence frameworks, logging, collections, aspects, and dependency injection frameworks. In fact, a Java developer has so much choice, they don’t even have to program in Java if they prefer a different JVM-friendly language.

But in the realm of client-side Java, the choice has been much more limited, mostly due, I imagine, to the fact that client-side Java has never exactly been an exploding marketplace of opportunity.

Web development has always eclipsed client-side work. It’s my hope that JavaFX can seek to change some of that; that it will be able to widen the reach of client-side Java and push development back onto the desktop and remind users that not every application needs to run inside of a web browser.

Sure, it’s possible that some day JavaFX will be the “Swing Killer”, but that would be a sad and unfortunate outcome. It’s my hope that JavaFX and Swing are playing a nonzero-sum game and that the world of client-side Java is big enough for both.

Music Explorer FX Mobile Edition

Tuesday, October 20th, 2009

Earlier in the year, I wrote a music discovery desktop application in JavaFX called Music Explorer FX.  Since JavaFX also has a Mobile SDK, it made sense to write a version of MEFX for JavaFX enabled mobile devices.

Although the idea and basic usage remain the same, MEFX Mobile is not just a port of the larger desktop version, but a completely separate application.

Here’s the initial screen. You can enter an initial artist in the search box as expected, or, since I find entering text on a mobile device extremely difficult, you can hit the “Surprise Me!” button to have the app randomly pick a top rated artist for you.

Once you get your initial artist, you’re presented with the usual “visual profile” complete with image, and the “familiarity” and “hotness” gauges similar to the desktop version.

Selecting the middle button will bring you to the core of the application, which is the “artist similarity” screen.

Here you’ll see a number of artists recommendations as provided by the Echo Nest. The left and right buttons will scroll through the list, and selecting an artist will promote it to the main “artist profile” screen pictured previously.

At any point, selecting the third button will return you to the search screen. Selecting the first button will bring you to a screen where you can browse through your history, which provides an easy way for you to return to a previous selection.

One of the neat things about JavaFX is that (generally) the code that runs on the desktop can run on a mobile device (and vice versa) with little issue. So if you don’t have a JavaFX-enabled phone, don’t despair; you can click on the launch button to run the exact same application as a Java web start desktop app.

For those interested, I wrote the application specifically for the HTC Diamond, which is pictured here running the application.

MEFX Mobile is an open source application and exists as a sample over at JFXtras.org. So feel free to download the source code and play around with it, or even install it on your own phone.

Enjoy!

The Nonzero-Sumness of RIA Platforms

Tuesday, September 8th, 2009

In an industry that seems to thrive on competition, it’s natural to think that the three major RIA platforms are incompatible, directly competing technologies, and that an application that uses one, will preclude the use of the other two. After all, an application written in Silverlight is one less application that could potentially be written in JavaFX.

Right?

This would be true if application development were a Zero-Sum Game, which it sometimes is, but not in the case of RIA development.

RIA platforms are currently the underdogs of adoption when compared to general web application development. When it comes time to choose a technology stack for a new project, it is often assembled based on (among many other things) what is familiar, and what others are using — and these days the default stack is web-based.

On the occasion that the requirements demand something that current web technology can’t easily accommodate, a RIA solution may slip into the mix and cross-pollinate with an existing web app. When this happens, the general awareness, and acceptance of RIA technology rises a bit more, and with it, expectation that future applications will follow suit.

Every project that uses Flex, JavaFX, or Silverlight increases the user’s expectation of how applications should behave and what’s possible. Soon users may come to expect the ability to run an application offline, out of the browser, or on a mobile device, and the higher the user expectation, the higher the demand for this type of development.

Put another way, RIA platforms have the task of not only trying to increase adoption, but also of generating the demand and raising awareness for the technology itself. This is much easier done collectively then as individual platforms.

In other words, RIA Platforms are playing a Nonzero-sum game between each other: that which benefits one, benefits all.

For this reason it is good, from an adoption standpoint, that the three RIA platforms keep pace with each other’s feature set. For example, while Mobile support may be perceived as a differentiator for JavaFX, it’s actually a good thing (and I’m sure not completely non-coincidental) that Flex and Silverlight have Mobile support planned in the near future. The reason is simply that if more applications have mobile components, the expectation, and therefore demand for this style of application, will rise. So if a project ends up using JavaFX Mobile (for example), it is not a net-loss for Flex or Silverlight, as two more mobile RIA projects may appear that would not have otherwise been there based on the demand created by the initial project.

Neal Ford hinted toward a similar trend in dynamic languages in his talk “JRuby vs. Groovy”. Despite the antagonistic title, Neal warned that if developers don’t realize that the ecosystem is big enough for both languages, neither may thrive. In other words, two seemingly competitive technologies are dependent on each other for survival as long as both benefit from the other’s successes.

There may come a time when the RIA space is so saturated that the game may switch to zero-sum, much like the current state of web application development. There may come a time when the phrase “desktop-like experience” actually refers to technology that runs on the desktop.

For now though, the task of mass adoption is far too great a challenge for any one platform. They are better off acknowledging their potential win-win situation of co-adoption.

Creating a Bordered Panel in JavaFX

Saturday, August 22nd, 2009

Recently I was looking for an easy, relatively general way to visually separate arbitrary groups of components with a border. Behold the BorderPanel:

BorderPanel is simply a CustomNode that wraps any number of nodes in a Panel (which is a custom layout Container), and sticks a border around it.

Here would be the code to generate the above layout (assuming that the widgets were contained within the “vbox” object:

BorderPanel {

  borderColor: Color.DARKSLATEGRAY

  borderWidth:10

  layoutPadding: 10

  content: [ vbox ]
}

The above layout is alright, but really I wanted it to put a border around some AnimatedCharts from the previous post:

Since I can put a border around anything now though, separating groups of charts is pretty straight forward:

Which is just two BorderPanels contained in an HBox:

HBox {

content: [

  BorderPanel {

    content: HBox { content: [chart,chart1] }

  },

  BorderPanel {

    content: HBox {content: [chart2] }

  }

 ]

}

BorderPanel itself is pretty small. Here’s the create function:

override public function create():Node {

  panel = Panel {

    content: bind [border, content]

    onLayout: function() {

      for (c in content) {

        c.layoutX = borderWidth + layoutPadding;

        c.layoutY = borderWidth + layoutPadding;

      }

      updateBorder();

    }

  }

}

It simply creates the wrapper panel, “prepending” the border to the user added content (so that it always appears behind the components). The “onLayout” function is defined to move the “layoutX/Y” of each component out of the way of the border, plus some user-defined padding.

Here’s the function which creates the border, which is called whenever any of the dependent variables are updated.

function updateBorder() {
  var width = panel.width + borderWidth * 2 + layoutPadding * 2;
  var height = panel.height + borderWidth * 2 + layoutPadding * 2;
  var rect = Rectangle {
    width: width
    height: height
  }
  var innerRect = Rectangle {
    width: width - borderWidth * 2
    height: height - borderWidth * 2
    x: borderWidth
    y: borderWidth
    arcWidth: 30
    arcHeight: 30
  }

  border = ShapeSubtract {
    fill: borderColor
    a: rect
    b: innerRect
    effect: DropShadow {}
  }
}

The border itself is a shape subtraction of a rounded rectangle from a larger rectangle which encompasses the size of the entire panel. There is also a drop shadow added to give a subtle sense of depth.

The idea of creating a border that looks like this was actually inspired by this year’s Extreme GUI Makeover at JavaOne, which featured an Email client written partly in JavaFX.

An Animated Chart in JavaFX

Tuesday, August 18th, 2009

For an upcoming demo I had some data in chart format, which would be changing frequently, so I wanted the charts to smoothly animate the value transitions rather than abruptly change to the new dataset.

The built-in charts in JavaFX 1.2 are great in their variety and configuration options, but they seem to be less forgiving when it comes to trying to animate their components. I attached a Timeline to modify the data values of the chart and my framerate quickly dropped followed by an OutOfMemory Exception. Clearly not meant to be. (Incidentally, if anyone knows how to make this work, please let me know).

Since I had my heart set on animated visuals, and since my configuration needs were meager (I didn’t even require labels), I decided to write my own small Animated Pie Chart. Click the “Launch” button below the image to try it out.

Clicking on either “Dataset” button will simulate different data populating the chart. Note that the chart wedges “wind up” to their target values. Pressing the “Indeterminate” button will “unwind” the current dataset and put the chart in a “waiting” state, which is visually indicated by having the chart pulsate. Click any of the “dataset” buttons to bring it out of “indeterminate” mode.

A potential use case here would be if the chart were displaying some data (say from a web service call), which at some point becomes stale and invalid. Rather than continue to display the stale data until the new data arrives, the chart can be placed in “indeterminate” mode while it waits for the web service call to return.

The chart’s wedges respond to mouse clicks just like the built-in charts. In fact, for maximal compatibility, this AnimatedChart simply takes PieChart.Data objects as values. Here’s what the code looks like to generate the above chart:

AnimatedPieChart {
 data: [
   PieChart.Data {value:10, action: function() {println("10")}}
   PieChart.Data {value:20, action: function() {println("20")}}
   PieChart.Data {value:5, action: function() {println("5")}}
   PieChart.Data {value:10, action: function() {println("10")}}
   PieChart.Data {value:30, action: function() {println("30")}}

  ]
  width: 300
  height: 300
  title: "Top Pie Wedges by Color"
}

Update: The source code for this example (as a Netbeans project) is available here. Thanks to those who had interest in it.

Welcome to the blog of:

Sten Anderson