Scruffles.net

Springy

Bryan — Fri, 25 Apr 2008 00:43:00 +0000

How long do you need to work with Spring Webflow before it clicks and you wonder how you ever lived without it?

I only ask because I desperately look forward to that day. Today I'm still doing repetitive text searches through a half-dozen xml files to find out what happens when the user presses the OK button.

Parleys Flex Client

Bryan — Fri, 18 Jan 2008 03:33:00 +0000

I consume a lot of technical media, and one of my favorite sources is Parleys.com. They provide recorded presentations from Javapolis, SpringOne and other shows. They recently rolled out a beta Flex version of their site and a companion Air desktop app. It's a very cool application, offering a lot of long awaited features including local downloading of video and full screen viewing.

Parleys is making this release just as I'm pushing out the first milestone of a small flex app at work. I may post a little about Flex after I've had a little time to absorb it. Right now, I'm well within the honeymoon period, and don't think I can give a real balanced viewpoint.

Lines Of Code

Bryan — Wed, 16 Jan 2008 13:44:00 +0000

There is a reoccurring misconception that I've seen at several job sites now. Developers seem to be proud of their API, Framework or Library because of how few lines of code the user needs to write, without concern for how many concepts a user must understand. A well written Library will expose as little of its implementation as possible. It will provide a single mental model for the user and a consistent way of interacting with it. While generally, this results in less repeated code, the success of the library cannot be judged on a strict line count.

Too many times, I've seen internals of a library exposed for the sake of removing a 2-3 lines of code from the caller (usually a simple if or for loop). The result is often obviously messy APIs, and a lot of learning on the user's part. It seems that when developing APIs for use internal to their company, developers simply don't have much regard for usability.

Microsoft Volta

Bryan — Tue, 15 Jan 2008 01:40:00 +0000

I first heard about Volta on the Java Posse (#154). It was carelessly referred to as a GWT rip-off. Being a long-time listener (and fan) of the Java Posse, I was well aware that opinions expressed about Microsoft products are seldom well researched. I did a little more reading and was interested in what I found.

While Volta does generate Javascript, it does so in a slightly different way than GWT. While GWT reads Java code and compiles to Javascript, Volta reads bytecode (.NET IL) and compiles to Javascript. And while GWT defines its own UI APIs, Volta uses the existing .Net APIs. This means, you can write an app in C# or VB using the form designer, add some annotations to tell the system which parts are client code, and compile the same source to both a thick client and a web app.

Of course, while I can't attest to how well it works (like those at the Java Posse, I don't own a Windows PC), I do think it give us some interesting things to think about in the Java community.

If GWT read bytecode rather than source code, it could support Groovy as well. For those who haven't tried, Groovy builders are a very clean way to write Swing code. They could have been helpful for GWT as well.
Could a single set of UI APIs apply for Applets, Applications and GWT-like Web apps, like Microsoft's Avalon APIs span Silverlight, Windows Apps and Volta UIs?
How many interesting ideas do we miss because we don't watch developments in competing environments?

Applets Still Suck

Bryan — Thu, 13 Dec 2007 22:11:00 +0000

Despite all the effort Sun announced at the last Java One, applets still suck. They have for years, so why would it matter? Because JavaFX Script, Sun's latest whiz-bang technology still needs a container to run in. Embed one in a web page, and they still have all the disadvantages of an Applet.

Recently, I've worked on a web project that took advantage of both Applets and Flash technology. The difference in user experience is clear. And despite a complete rewrite of the Java plugin in Java6 Update 10, Sun is still a day late and a dollar short.

First the good news: Sun's version detection scripts work fairly well. The rewrite of the plugin for Firefox was sorely needed and will make a dramatic difference. And although I haven't seen the results, I suspect the modular nature of the new JRE will make for a much lighter weight experience for users.

So what's still missing?

The Applet framework has not been altered in any way. An Applet is still heavy-weight. It still makes an OS call to draw its window. This means that applets (and by extension JavaFX scripts) embedded in your web site will not play nice with CSS Z-orders. You cannot open a CSS dialog or popup on the same page as your applet, as your applet will always be on top.

Although the new plugin will be available as part of Java 6 (beginning with Update 10), it will need to be manually enabled by the user from the control panel. I assume this is because Sun doesn't want to ship new features in an update, which seems reasonable. But because of this, it won't be safe to assume your users can view your applet in a reliable way until Java 7 is widely available. Of course the new plugin won't work in Firefox 2 anyway. It requires Firefox 3. Oh, and it doesn't support Safari. If you run Safari, your at the mercy of Apple. Lets hope none of those JavaFx libraries get compiled to Java 6, because Apple doesn't seem to have plans to support my Powerbook with Java 6... ever.

What about the current plugin? Using the existing plugin can cause unpredictable results. In Firefox, resizing the applet can cause your applet to re-initialize (not just fire events, or call start() again). I've also seen the plugin randomly ignore the page layout and get stuck in an odd place on the screen. Refreshing the page usually fixes the problem, but that isn't something I really want to tell my end user to do. And of course the current plugin has none of the performance improvements made to the new plugin.

With all the excitement over JavaFx lately, I thought it might be a good time to remind people that there isn't a JavaFx plugin. JavaFx in the browser will still suck for all the same reasons Applets do. I expect them to continue to suck, as I see no evidence from Sun that they plan to follow through and actually fix any of this.

JLINQ - Lame

Bryan — Fri, 24 Aug 2007 01:39:00 +0000

Wow.

IBM has outdone themselves. I'm struggling to find words to express what I think of their latest announcement. IBM has released a new Eclipse plugin that they call JLinq. It's essentially an O/R mapping tool that does most of its work using design time code generation. It generates SQL from beans or beans from SQL. It's essentially a bunch of Eclipse wizards that generate code. Not especially impressive, and a surprising direction after all the recent hype about JPA, Hibernate and EJB 3.

Of course bad software being released from IBM is nothing new. What I find truly exasperating about JLinq is the name. Surly a Java technology named JLinq would have some resemlence to Microsoft's LINQ technology. It's not only the same acronym, but it stands for the same thing in both technologies: "Language Integrated Query". But while Microsoft's LINQ, is a query language integrated into the programming language (go figure), IBM's LINQ is a code generator integrated into an IDE. WTF?

These kinds of projects are not just an embarrassment to IBM, but might be harmful to the Java community as well. Too many Java developers are completly ignorant of advancements outside thier own community. This kind of confusion isn't helpful. How many developers are going to assume this is a Java port of LINQ, and judge LINQ on the merits of IBM's 3rd rate Eclipse plugin?

LINQ ScreenCast

Bryan — Sat, 07 Jul 2007 17:30:00 +0000

The Screening Room has a great screencast on LINQ. It's a little early to get too excited about LINQ, but the demos are very impressive. The combination of declarative type-safe queries and object oriented code makes many of our hot new trendy languages and language features seem like dirty hacks. Specifically many of the new Java features and JSRs take advantage of EL or queries embedded in Strings to get the job done -- effectively dropping down into a dynamic language. While dynamic languages may be the most pragmatic solution today, its nice to see someone is working on a more practical permanent solution.

On a related note, O'Reilly has a good shortcuts book on the under-pinnings of LINQ (LINQ: The Future of Data Access in C# 3.0). My interest in it wasn't about learning about LINQ itself, but what language features had to be added to support it. It does a good job of showing how ambitious this project is.

Bob on Design

Bryan — Sun, 01 Jul 2007 04:22:00 +0000

Bob Lee had some interesting comments on the advantages of using annotations rather than XML for configuration. I didn't find the original post as interesting as the comments that followed. Among them was a little pearl of wisdom I think deserves to be embroidered on a pillow:

Contrary to Spring's philosophies, I think very few design decisions are "a matter of taste." Some ways of doing things are provably better than others, and one way of doing something is almost always better than two. Otherwise, you end up with the Perl of frameworks.

Ok. So it would have to be a big pillow. But I've regularly had to deal with co-workers who write code with all public members or write extra methods that are never called -- just in case. They almost always plea 'a matter of taste'.

Hand Coded

Bryan — Wed, 20 Jun 2007 02:24:00 +0000

Josh Marinacci recently wrote about using a tool vs hand coding your Swing UI. While I don't completely disagree with all of his arguments, he tries to make a couple of points that burn me a bit.

1) He tries to argue that you don't have to worry about vendor lock-in with Matisse because its open source
2) Because the files generated by Matisse are hand-hackable, you don't need to be concerned with lock-in

In my 8 years of Swing programming, I've used 5 visual editors for writing Swing GUIs. While Matisse is currently the leader, I don't see any reason why it would still be the best next year. The previous 4 visual editors didn't last long, I fail to see why Matisse's open source license is going to keep it in the number 1 spot throughout eternity.

Also, each of the 5 visual editors I refer to generated hand-hackable code. While we could always survive without our old GUI tools, the crap code generated by those tools were never really maintainable.

While standardizing the XML format Matisse uses won't hurt anything, I really don't see how it would help either. It's not as if Eclipse, IDEA and JBuilder are all going to start playing nice with Matisse-generated code.

We need more than just a defacto-standard JavaBeans editor. We need a well thought out component model.

New Lens

Bryan — Mon, 21 May 2007 03:40:00 +0000

Last week I got a macro lens I've been looking at for quite a while (Canon EF 100mm f/2.8). I have mixed feelings about it so far. It does its job very well, but I'm a little frustrated at how completely useless it is outside of macro photography. With my other lenses, I can work a little outside their area of expertise when a good shot presents itself, but because this lens is fixed at 100mm, using it for a casual photo in a pinch is a bit of a pain. That aside, I really love what it does with macro photos. It gives me a decent working distance from the subject and the short focal distance, while a little difficult to work with, can really make a photo stand out.

The detail in the Frog's eye is great (check out the full size version on flickr). What you can't really see from this picture, is that the entire frog is about the size of my thumbnail.

I cropped this one a little. Keeping the ant's head in focus was a bit tricky with a monopod. I may need to start using my tripod a bit more often.

Distributed Version Control

Bryan — Fri, 18 May 2007 03:27:00 +0000

Linus gave a presentation on git, his distributed version control system. I've heard a lot about git and bitkeeper, but hadn't paid much attention until this presentation. If you haven't taken the time to learn about distributed version control, you should take an hour tonight and watch the presentation.

Thanks to Kyle Cordes for posting the link on the JUG mailing list.

Building the IDEA Groovy Plugin

Bryan — Sun, 13 May 2007 03:19:00 +0000

It took me a little effort to get Idea's Groovy Plugin built, so I thought I'd share my experiences for those who don't want to fall in the same traps.

I started from some instructions on the forums, but still had trouble. Some filenames were wrong, and working on the mac changed some of the details. Here are my revised instructions:

Update to a new EAP of IDEA. The plugin wasn't built for IDEA 6
Checkout the project from http://svn.jetbrains.org/idea/Trunk/groovy/
When you first open the project, you may be asked to make a variable association. I pointed the templates variable to ${project}/resources/fileTemplates
I had to create a new Intellij IDEA SDK pointing it to my IDEA installation
Add tools.jar (on windows) or classes.jar (on the mac) from your JDK installation to the SDK classpath
Add idea.jar from your idea installation (on the mac, the file is /Applications/Selena-6951.app/lib/idea.jar) to your SDK classpath
There are already two ant scripts in the ant window. Run the one called generate lexer from groovy
Run the build>make command from IDEA's menu
Run the build>Prepare Plugin Module 'groovy' for deployment command from IDEA's menu
A zip file will be generated to the project directory. Copy it to IDEA's plugin directory and unzip it.
Restart IDEA

I've attached the file for those daring enough to install software from some stranger's blog: groovy.zip

JavaFX in Perspective

Bryan — Thu, 10 May 2007 03:47:00 +0000

The large number of discussion about JavaFX over the last few days seems be very polarized. So far I have only read two opinions repeated over and over:

JavaFX is the competitor to Flash and SilverLight that we've all been waiting for.
JavaFX is a weak attempt to cash in on the recent SilverLight announcements and has no chance for success.

What most people don't seem to get, is that JavaFX isn't even in the same market as Flash and SilverLight. It's much more appropriate to compare JavaFX with XAML or Flex (just the markup language, not the action script, runtime environment, multimedia support or animation).

Both Adobe's product line and Microsofts are made up of several packages:

A runtime environment - The Flash VM and the .Net Runtime
A declarative UI language including widgets - Flex and a light version of XAML
A declarative animation language - Flash and XAML
A scripting language for procedural logic - Action Script and JavaScript
A development environment for each of these three languages
Multimedia components - video and audio playback is supported well as first class components in both frameworks

Of course JavaFX runs on the Java runtime environment, and it defines a very nice language for declarative UI building and a decent language for animation... but that's all it tries to do.

Sun has yet to show any interest in completing the rest of the picture.

It could be argued that some work would need to be done to the JRE before it could be light enough to compete with Flash or Silverlight as a runtime environment (at least ease of installation could use some work).
JavaFX has no equivalent to JavaScript. Although one could theoretically use Java, Groovy, Javascript or some other language for procedural code, the binding isn't nearly as nice as the integration the other two frameworks have with their scripting languages.
Netbeans provides some syntax highlighting and code completion for the language, but it's barely better than notepad when compared to the authoring tools being offered by Adobe. To take on the competition, Netbeans will need timeline driven animation and Matise-like component layout from day one. On day two, we need vector drawing tools to compete with Illustrator and Expression (tie-in with existing tools might be a nice stop gap).
Multimedia support has always been a weakness in Java. JavaFX is the neon sign pointing out one of Sun's often ignored weakesses.

With all that said, JavaFX compares very nicely to Flex and XAML when ignoring their sister technologies. Feature for feature it compares nicely. Without the rest of the package, of course, it's all pretty academic. Assuming Sun is really serious about taking on Adobe and Microsoft, they still have a lot of work ahead of them.

WPF & Flex

Bryan — Tue, 20 Mar 2007 02:35:00 +0000

I went to a .Net User's Group meeting about WPF tonight. The speaker was Walt Ritscher. The presentation was a pretty decent intro. I was expecting it to be quite a bit more in depth. I guess I figured .Net developers would already be up to speed on WPF and an intro presentation would be beyond them at this point. I seem to make a habit of setting my expectations a little too high for most user group presentations.

I recently signed up for a membership at lynda.com, which provides instructional videos on many technical topics. The subject matter tends to lean towards creative tools (Photoshop). I've been watching the Flex training videos and I can't help notice the similarities to what Microsoft is doing with WPF. Macromedia really seemed to have missed the boat by brining application development to Flash so late in the game, but they seem to be catching up well now that Microsoft has put some fear into them. Since Adobe took over, they've kept going strong.

Of course both Flex and WPF/E are both proprietary technologies that have fairly useless free SDKs and $600 development environments for the serious user. I haven't seen any free alternatives with anything close to the capabilities. Both SVG and F3 have similar capabilities, but F3 isn't open and lacks the development tools and SVG lacks good browser support.

Oh well... guess we'll have to put up with Ajax for a few more years.

IntelliLang

Bryan — Thu, 15 Mar 2007 05:50:00 +0000

IntilliLang is a very cool plugin for Idea that (among other things) allows stringified code to be parsed as any other code. This means those regular expressions and html fragments you store as a Java String can be parsed, checked and auto-completed as a first-class citizen.

Jetbrains shows some very cool examples including regular expressions, javascript and el. It still has some rough edges, but once its cleaned up a bit, it could be a great tool for HQL queries and embedded SQL.

Lightroom

Bryan — Mon, 26 Feb 2007 05:30:00 +0000

I had been using the beta of Lightroom since its first release. Initially I wanted to use it rather than Apature because of Apature's lack of good Photoshop integration. Ironically, Lightroom didn't play well with Photoshop either. My biggest complaint was that Bridge and Camera Raw didn't recognize edits made from Lightroom. Although this is fixed in Lightroom 1.0, at the time I had to work in either Bridge/Camera Raw/Photoshop or Lightroom/Photoshop.

I like the Bridge/Camera Raw workflow because it's filesystem based. I don't like applications managing my files. But Camera Raw, as powerful as it is, is a clunky tack-on dialog where I really want an emersive tool. When I'm editing my photos, I work on them for hours at a time. I don't want to jump around between dialogs and have to save copies of my files.

After a couple months, I gave up completly on Bridge/Camera Raw. I was soon using Lightroom for all my post-processing, and doing touchups in Photoshop. As sad as it might be, I was using Photoshop solely for removing zits and cleaning up tape marks on my son's face (because of medical issues, he uses oxygen at night. His cannula has to be taped to his face). $600 of image processing power, devoted to removing tape and pimples.

And then Lightroom 1.0 was released. One of it's new features: Spot Removal. Here's the twist. Rather than saving a copy of the RAW file to edit in Photoshop, Lightroom's edits are lossless changes to the RAW file. While the Photoshop tool is more like a raster based brush, in Lightroom all the corrections are circles with source and destination references. Those references can be altered or cleared at any time in the future.

In the example above, I've made several corrections. The active one is represented by the two circles at either end of the arrow. The arrow is saying "copy everything in this circle to this one". At first it seemed rather limiting to have to use circles rather than a brush, but after a little time, I've found it to be very powerful.

What's more, this single tool has completely eliminated Photoshop from my regular workflow. While I still use Photoshop from time to time for other projects, I don't really need it for photo processing any more.

Thoughts On Music

Bryan — Thu, 08 Feb 2007 01:10:00 +0000

For those who haven't read it, Steve Job's article denouncing DRM is a good read. I was expecting typical corporate finger pointing related to the problems Apple is having in Europe, but Jobs makes some very good points. He also points out a pretty decent explanation to why the Zune doesn't use playsforsure DRM.

Swing and Vendor Lock-in

Bryan — Tue, 06 Feb 2007 13:03:00 +0000

10 years ago Sun introduced Swing, and with it, JavaBeans. JavaBeans were supposed to allow UI widgets to be defined as components. It would allow Swing developers to take advance of graphical layout editors without vendor lock-in. It failed.

Those who tried to develop Swing apps with their IDE's drag and drop editor forced their way through limitations and learned how to hand-code fixes that wouldn't break their IDE's code parsing. Then support would dry up for their favorite tool and they would be left with no alternative, but to hand-code their Swing apps. Others recognized the graphical tools as Microsoft-style lock-in and avoided it early on. For almost a decade, hand-coded Swing apps have been the norm.

10 years later, Sun is trying again. They seemed to have missed the point of their initial failure. They seem to be under the impression that had the first tools been of higher quality, people would have never resorted to hand-coding their Swing apps. In reality, it was the proprietary nature of the IDE-generated code that caused the failure. No matter how well the tools would have worked, Java developers have been conditioned to demand vendor neutrality.

Vendor neutrality is not something developers get from Netbeans and Mattise. As nice as the platform is, the code it generates is not parseable by any other platform. Because it doesn't generate code to a standard, such ad-hock compatibility wouldn't be enough anyway.

This problem has already been solved, of course. Ironically, one of the latest solutions is from Microsoft. Although XAML is a closed standard, it is a standard. It's well defined and parsable by multiple editors. A Swing solution wouldn't have to be as feature heavy as XAML. There are many open source solutions that fill the need. Of course they would need to be adoped by Sun (presumably via a JSR) and the IDE vendors to be a useful vendor-neutral solution. Until this happens, Mattise is just another way to lock your application to your IDE.

Saving Files

Bryan — Sat, 03 Feb 2007 20:57:00 +0000

I'm not sure when it happened, but at some point since I started using IDEA I lost the concept of saving my source code. Since version 2* IDEA has automatically saved changes when focus to the window was lost. I don't really know how long it took, but over time I stopped paying attention to file saving. From time to time, I would edit a text file in notepad or use someone else's IDE and bang my head against the wall as I tried to run without committing my changes. Apparently it was a common mistake. Eclipse eventually added a warning dialog: "You have unsaved changes. Would you like to save them before you run your program?". What the hell kind of question is that?!? Why would I have changed my code, and run my program if I didn't want to see those changes reflected in my application?!?

I guess having a warning is better than what notepad does... but then again, is that really the mark of a great IDE: "at least we're better than notepad!"

*version 1 of IDEA was a JBuilder plugin, so it might have been a little silly to do it then

Plain Old Java COMPONENTS

Bryan — Thu, 01 Feb 2007 14:24:00 +0000

I've been reading about the various proposals for adding properties and events to the Java language. In the process, I stumbled across an interesting blog entry by Richard Bair which he starts by describing why JavaBeans don't break encapsulation. For a long time, I've believed Javabeans were an abomination. Despite the intentions of the creators a technology is eventually defined by how it is used. With the exception of a couple dozen Swing components, the JavaBeans patterns is used by most developers as a loophole allowing programmers to break encapsulation.

When Richard describes the original purpose of JavaBeans, he's describing a framework that was needed very badly for allowing tools to interact with components. If properties and events are added to the language, it would go a long way towards cleaning up the interface between components and their tools.

What I don't see it helping with, however is the programmer's understanding of what they are doing when they make a component. When someone implements the JavaBean pattern, they are agreeing to an existing contract. I know very few programmers who understand that contract. None of them seem to understand that they are building a component. They have been told by the good people at Hibernate or the people who made their databinding framework that they were making plain-old-java-OBJECTS.

Plain Old Java Objects. Like every other Java object out there. But Hibernate doesn't work with just any Java object, does it? It only works with Java objects that strictly meet the contract set by the JavaBeans pattern.

Of course the market has picked the term POJO to emphasize the difference between today's tools and those requiring implementation of multiple interfaces and the addition of specific behaviors to your objects. As horrible as those frameworks were, they were object-oriented. Of course, since the buzz of the term object-oriented hasn't died down, we don't want to tell people that we've transitioned them to component-oriented programming already.

Cruise Control Montior

Bryan — Tue, 16 Jan 2007 05:01:00 +0000

When moving my blog to from Movable Type, I noticed a handful of posts that were still unpublished. One was a reference to a tool I put together about a year ago. It's a status screen for Cruise Control build results. If you're monitoring more than just one project, lava lamps are a bit of a pain.

Comicly Bad Code

Bryan — Sat, 13 Jan 2007 02:13:00 +0000

You're creating a button that toggles back and forth between two states. You want the button's text to change depending on the state it's in. Ignoring the obvious usability issues involved, how would you go about implementing that? It's a simple problem, so it should have a simple answer:

button.setText(isInWhateverState ? "text 1" : "text 2");

I just ran into some code that works a little different than one might expect. It uses two buttons, each with different text. Each button has a complicated set of lazy initializers and it's own listeners. The two buttons are on a panel with a CardLayout. Pressing either button switches the card layout making the other visible.

Sometimes writing really bad code takes a bit of creativity.

Moving to Blogger

Bryan — Fri, 12 Jan 2007 04:32:00 +0000

After 4 years of maintaining Movable Type on my web server, I've decided to switch to Blogger. Moveable Type was just becoming a maintenance nightmare, and it was easier to move than to get it back into working condition. I'm still maintaining my son's blog in Movable Type, but I'm shutting down my photography blog. Since I started using flickr, I really hadn't been maintaining it anyway. I may start posting pictures here instead. My thoughts so far:

The author's interface in Blogger is a decade ahead of MovableType. That alone made it worth the switch. The blogger interface is similar to that of most Google services. Very smooth and clean.
None of Bloggers templates were wide enough to display landscape flickr images. Altering an existing one to fit took about an hour of tinkering (resizing images, took most of the time). Now I won't be able to switch themes again without sitting back down in front of Photoshop. Kind of a pain.
There were a lot more publishing options with Blogger than I expected. I haven't used a free hosting service since before Geocities was bought up by Yahoo. I hadn't expected it to cater to secure-ftp or hosted domains.
The help on Blogger is pretty good, but I would have loved a feature matrix showing the pros and cons of each hosting method. I had find out which to use by trial and error.

I'm looking forward to getting rid of this template and putting something together that's a little more personalized, but for now, at least I'm not spending time removing spam from my comments.

IDEA 7 Milestone 1 Roadmap

Bryan — Fri, 05 Jan 2007 16:27:00 +0000

Intellij has made their roadmap for version 7 available. I don't see anything real exciting at this point, but I'm usually more impressed by their implementation than their feature list.