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.

Labels: Photography, Photoshop

posted by Bryan at 11:30 PM | 0 Comments

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.

posted by Bryan at 7:10 PM | 0 Comments

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.

Labels: Programming

posted by Bryan at 7:03 AM | 3 Comments

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

Labels: Programming

posted by Bryan at 2:57 PM | 0 Comments

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.

Labels: Programming

posted by Bryan at 8:24 AM | 0 Comments