James Williams' Blog

Even though I officially run with a different crew in the Java’hood, so to speak, I honestly wanted to be amazed by the JavaFX preview release. I wanted it to be some substance to back up all the chest-thumping grandstanding since last year’s JavaOne. It wasn’t.

The demo left me horribly underwhelmed. Numbering in the dozens, social media apps are an easy way of showing the wow factor of your platform while remaining accessible by normal users. IMHO, social media is a big reason (among others) of why Adobe AIR has caught on. The power play to Tonya Harding AIR would have been an app like Twirl, Twitterific, or Alert Thingy. Like I’ve said before, where is that killer JFX app? As competitors in the 2008 Script Bowl at JavaOne, Groovy, Scala, and JRuby have Twitter clients. Those languages which were deemed unworthy of JavaFX’s awesomeness have gone further in the RIA space than JavaFX itself. JavaFX has spawned many façade apps, ie pretty but non-functional and just for show. A buggy but functional demo is worth a million times more than the prettiest façade.

With moves like this JFX is DOA before it’s RIA.

When I talk to friends about developing an idea for an app in Java, I always get comments that I should do it in Adobe AIR because Java is ugly. It isn’t, per se. It just takes effort to make it look pretty:

1. Unless you can guarantee your install base is using Java6 or higher, don’t use the default LookAndFeel.
   
   Before Java 6, the default LookAndFeel was Metal, the really ugly mess that gave Java a bad name in the first place. That has been rectified in Java 6 and above with Nimbus. Many devs seem to go with the default instead of exploring what their users might appreciate. Javatoo(http://www.javootoo.com/) and JavaDesktop(http://community.java.net/javadesktop/) are good sources for news and links to different LookAndFeels. My personal favorites are Nimbus and Substance.


2. Have options.
   
   One thing that the Groovy Swing team has done is to give the LookAndFeel selection code a couple of choices it can degrade to if the preferred choice is not available.
    
   It may take a little extra effort but if you have a sizable amount of Mac users and aren’t using any special LaF, it might be a good idea to explore Quaqua(http://www.randelshofer.ch/quaqua/index.html). It will give your users a native looking Java app and you’ll benefit from the level of familiarity that they get from other Mac applications. Your app won’t stand out as the "ugly Java thing" they have to use because there isn’t a Mac version.


3. Go naked.
   
   Naked meaning undecorated. Because Java is a layer over the operating system, when you execute a call to draw a JFrame or JXFrame, you are asking the operating system to retrieve and a native window canvas to draw your application. If you are one of the few that actually architects a beatiful user experience, you are quickly betrayed by the title bar of the window which probably clashes with your LookAndFeel(unless you use one that duplicates your OS). If your core design is innovative enough, you can complement your design by making the frame undecorated, thereby hiding native details, and providing your own navigation/resize/close panel. There is a bit more work involved in this tactic because you will have to also consider if you want the same level of detail and integration with any dialogs or popup windows. One application that uses this method is Aerith(http://aerith.dev.java.net/), a smashup of Google Maps, Flickr, and Yahoo’s geocoding service.

It used to be enough to have that killer idea for an online property to be sucessful. This is still true but it is just as important if not more important to have a developer’s API. A trend I’ve been noticing is web apps launching without plans for a dev API. In the sea of the Twitter-killer wannabes, whether or not I sign up for a new service is determined by several things:

1. Are my friends on it?
2. Is it a solution to a problem I have ?
3. Does it have an API?

Number 1 will almost always win out in absence of numbers 2 and 3. But if a service is cool, but none of my friends are on it and it doesn’t have an API, it will give me pause. [In reality, I usually sign up anyway to reserve my name in case the sitch changes but that’s beside the point.]

Developers have an itch to tinker and mashup things. Operating your service as a silo is like giving me a tapeworm. The parasite is getting nourished by the nutrients coming by but isn’t giving anything back to the host. A service with a proper API upgrades that situation to that of a symbiotic one. Like the clown fish and sea anemones. By letting me access my data outside your sandbox, I’m more likely to use it more and give your more accurate data. My use of it will act as a catalyst for others to use it. Totally win-win.

APIs don’t come without potential disadvantages. An API that is not properly tuned or architected will expose flaws in your infrastructure. But on the other hand, the API will encourage different ways of interacting with your application and increase users. I often wonder if Twitter would have been as big if it launched and maintained no API cutting off the likes of Twirl, Twitteriffic, and the dozens of other desktop clients and mobile clients. Even a read-only API in anticipation of a full one, like Disqus has, is better than nothing.

Edit: Twitter has ceased supporting basic authentication (using a username and password) for third-party apps. As a result, FriendBackup no longer works. I'm working on an updated version, stay tuned for updates.

The recent "Fail Whale" occurrence spawned several responses in the blogosphere. Some complained, some took it as a Spring cleaning of sorts, while others advocated a tactic to avoid the Twitter relationship silo and cross-pollinate your friends. I’m adding one more way of coping to the list, programmatic backup of friends.

Because I feel generally sketchy about giving out my Twitter password to a random website, I’ll rolling this as a client application. Your password is as secure as your machine is, nothing is coming back to me at all.

Yeah, it looks rough but it’s something I finished in an hour so deal with it. It grabs the real name, user name, and url for each of the folks you’re following¹. The output is a csv file that can be read in Microsoft Excel, Access or OpenOffice. If there’s interest, I might extend it to other services.

You need Java 6 to run it.

Twitter does have a cap of 70 authenticated requests per hour. For most folks, the additional requests won’t make them max out. Those who are friends with enough people to populate a small town(greater than 6,900* friends) are going to have problems. You were duly warned.

¹ additional info is available but there is a fine line between getting what’s useful and duplicating their db. If you need more, @ecspike me and we can sort something out.

* 100 friends/request * 70 reqs - 1 authenticating request = 6,900<

I remember back in the day when it was prophesied that we all would be used barcodes for everything in the future. I even vaguely remember one big box store sending out bar code readers (I wanna say it was Staples). Sim chips on credit cards debuted about the same time if I recall correctly. That went no where quickly when folks realized "Hey, maybe it not a good idea to store the CC info for all my other credit cards on the SIM chip of this one." That disconnect between the intended use(quicker/more accurate than swiping) and the Americanized version caused many problems when I tried to use chipped cards in Europe. But I digress...apparently QR codes are making a comeback. Or so it’s inclusion in the Google Chart API might indicate. So the Grails plugin has been updated to add this functionality. 

btw to all the francophones, Happy Bastille Day!

This post was inspired by a post on Dzone about Java GUI toolkits. I decided to look at a couple of them: Swing and Thinlet. Swing and Thinlet represent two different ends of the Java user interface spectrum each with its own peculiarities and reasons for use and disuse.

Swing

Pros:

• Good tool support
• Lots of documentation
• Lots of mindshare
• Good extensibilty of base components
• Continuous development
• Nimbus Look and Feel

Cons:

• Not the most simple or straightforward to code
• Can require many dependencies if using components outside core(SwingLabs)
• Metal Look and Feel and the fact that it was the default giving Swing the black eye of being ugly
• The cutting edge features require Java 6

Thinlet

 Pros:

• Very lightweight, small jar(38KB)
• Doesn’t need Swing or AWT
• XML UI descriptor
• Development seems to be stagnant
• Lower requirement to run (needs Java 1.1 or higher)

Cons:

• XML UI descriptor
• Small amount of built-in components
• Few examples and tutorials
• Development seems to be stagnant

For some that I know that shall remain nameless, the use of a XML UI descriptor is treason and reason to run for the hills away from a tool doing so. To that I say, it all depends on the problem. For a very dull “entreprise” app, it might be just what the doctor order. However, trying to code something like Aerith would probably be painful.

Thinlet

SwingLabs - Next Gen Swing Components

Four toolkits for Java to develop excellent GUIs

With this post, I’ve hit the milestone that IMHO indicates your dedication to your blog. Hopefully, I’ll have many more. So without further ado, here are my favorite posts from the first hundred:

One of the first SwingXBuilder demos
At this point, I was still figuring out the limits of the builder.

jFlubber
Proving Matisse ain’t got s#@t on MigLayout.

JavaOne / 2GX
Complete and utter awesomeness...except the wifi.

Google Chart Plugin
I’m happy it’s a part of Gravl.

JavaFX
We're still waiting...

Groovy as a first programming language
Maybe Hackety Hack should be ported to Groovy

My appearance on the JavaPosse
Was incredibly nervous, hopefully I’ll be chill next time. If there is a next time.

A couple weeks back, having just finished an interview in SoMA, I ventured into the Borders on King St to grab a book for the hour-long Caltrain ride to San Jose. After about an hour in the store, I admit I’m a book geek, I found what I was looking for Just for Fun: The Story of an Accidental Revolutionary by Linus Torvalds and David Diamond. I wasn’t looking for that book specifically but mean well...you know. As an Linux devotee, obviously I’m going to appreciate the story of Linux but I think that even those who don’t use Linux would benefit from learning the story of its evolution. This lesser known story is a nice counterweight to the well-known story of Bill Gates.

The basic premise is that Linus agreed to write the book with David iff in the the process of writing it, he got to do all the fun stuff he hasn’t yet had the chance to do. Despite some feelings in the greater Linux community, there isn’t much Microsoft hating at all. I discovered a Linus that is sometimes humble¹, accidental hero/champion who is very succinct and matter-of-fact. The latter trait is often misinterpreted maliciously by those with OS envy. Almost every anecdote was entertaining and fun especially the hateration between Linus and Andrew Tatenbaum (author of Operating Systems). This book will make the Linux army bond more with their benevolent dictator. Just under 250 pages, it’s a worthwhile but quick read.

The other book I think is a great geek read was the special gift for the 2007 Summer of Code. Producing Open Source Software by Karl Fogel. It’s a great complement to Just for Fun and serves as a good roadmap for open source projects.

¹ Linux wasn’t meant to be the final name of the OS

The guys over at Mashable Conversations fêted America’s birthday by taking on the new Twitter-killer de la semaine Identi.ca. Basically, it has some good ideas but isn’t there yet. One of the core features it’s missing is the ability to search for friends to describe to. Earlier in the day I was typing in the names of people from Twitter and FriendFeed to see if they were on Identi.ca yet. Most weren’t signed up yet but mashable was one of the ones I found with an account. Actually it was some seemingly benevolent party that was squatting the name and included a message that he wasn’t the real mashable and for them to contact him for transfer. What if he weren’t so benelovent and was holding it for ransom? Life in the pseudo-post Twitter era is mostly a crapshoot that goes like this:

1)New service introduced.
2)Praises are sung on FF crowning it as the Twitter killer.
3)Early adopters sign up to preserve continuity of usernames and review it.
4)Find friends from Twitter.
5)It turns out to not be all it’s cracked up to be.
6)Rinse and repeat.

What I need is a service that will monitor the blogosphere and reserve my name of choice so that when the foretold Exodus from Egypt ...err..Twitter happens, I won’t have to be jw3058i instead of my user id of choice. I can see a squatter capturing a username and followers from other networks when a new service pops up. I really hope the use of OpenID and i-names really catch on for networks. Without it, microblog squatting might become more of a reality.

OpenID http://openid.net/

i-names http://i-names.net

Free i-names http://www.freexri.com

I recently had to dust off some SwingXBuilder work for an interview and it got me thinking about the evil that is Matisse. Ok, it’s not that evil, it’s just that I couldn’t use it and one tends to consider things he can’t have are evil. And the more I had to do without it, I realized it was less of a necessity than I thought.

1. Ditch Matisse.
Seriously. Matisse generates a lot of code that isn’t very readable. I don’t like letting the computer think it’s smarter than me, anyways. Even if you are the only UI guy, why be selfish and make everyone use Netbeans for the benefit of your bloody pointing-and-clicking?

2. Break out the paper and pen/cil.
Designing your user interface before coding will (most likely) make it more cohesive and better designed. All of the Web2.0 properties you know were designed on paper first, that RIA goodness didn’t come with instantly sitting down with a WYSIWYG.

3, Learn MigLayout.
There’s a reason Mikael Grev’s session on MigLayout made him a 2008 JavaOne Rockstar. MigLayout gives all the flexibility and power of all the core layouts without cumbersome, unreadable constraints like ZoneLayout. It’s part of the reason my version of jFlubber was about 50% smaller than the Java Matisse version.

4. Use Swing(X)Builder for your layout even if the application is Java-centric.
Seriously, like you expected me to say otherwise.

5, Separate UI and action code.
Doing so, especially in the Groovy context, will make your code more MVC and DRY-like.