Code Review editor for Eclipse

I'm a big fan of peer code reviews. I don't think anything helps raise the average code quality of a project than requiring each line of code be reviewed by at least one other developer. When we know that what we're writing is going to be reviewed, we all write better code.

But I've never really found a code review tool for Eclipse that worked how I wanted. The holy grail of review tools (well - my holy grail anyways) was to have a tool that works much like MS Word's review feature. Where you can add and see comment in a margin on the right of the document. At ElementRiver, since we didn't find one that had that feature, we wrote one ourselves.



This editor is currently part of our beta SourceMate plugin for Flash Builder 4, but we plan on pulling it out into an independent product. It is designed to work with any language that Eclipse supports.

Features:

• Comments are added and updated all on the right margin. You never have to switch contexts (i.e. switching editors, looking down at a view, etc). It all done with your code front and center.
• Comments are color coded by reviewer and each color can be customized.
• Comments are shown in the code itself, in the right hand comment margin, and in the smaller overview ruler.
• Comments can be marked resolved. When resolved, comments are still shown but they're faded out.
• and more

My Flex 2010 Wish List

I can't believe 2009 is already over. But now that it is, its time to look forward to 2010. Adobe is planning on new releases of the Flex SDK, Flash Builder, and the 10.1 Flash Player this year so we all have reason to be excited. (Oh and don't forget SourceMate too). Its probably too late to influence these new 2010 releases, but I'm still going to throw out my Flex wish list for the future.

Fortunately my wish list isn't really very long. In fact, I only have two real items:

Full HTML browser within Flex

Today you can't really integrate HTML content into a Flex application. There are a few tricky solutions (mostly provided by floating an iframe on top of the Flash player). Unfortunately these have all kinds of problems. First, we have to change the wmode of the player for these to even work - and that immediately prevents screen readers from working. So enterprise applications where 508 compliance is required can't even contemplate these solutions. And even when we can use them, we're still stuck with other limitations as the actual HTML content is floating above our app and not really inside it.

To some people this might not seem like a very important feature request, but I've found quite the opposite. Every customer or potential customer I speak with runs into this. Portals/portlets are still all the rage (right or wrongly). Customers want a portal application where they can embed both HTML/JS portlets and Flash portlets. These customers have to choose HTML as their main platform (i.e. the container) rather than Flex. Other times, customers have an existing Java-based web app that they'd like to transition over to Flex. The keyword is transition. They can't just throw away their existing app and start over. They need to replace it bit by bit. But the architectures of Flex and the Web 1.0 world of these legacy Java web apps don't mix well. Ideally, they could rewrite the main frame of the application in Flex and pull in pages (say in a tab folder or something similar) of the old web app. Right now, thats not really feasible.

This is the #1 reason (in my experience) why organizations don't choose Flex.

Flex Compiler Performance Improvements

The Flex compiler is slooooow. Its been improved noticeably with Flex4. But its still too slow. On large projects its horrendously slow. This is one aspect where Flex and Flash Builder do not compare favorably with HTML/JS (obviously no compiling there) but also with Java or any other platform I've had recent experience with. I still believe developing with Flex, due to the productivity of the architecture, Actionscript language, and Flash Builder IDE is levels of magnitude better than AJAX. Yet, I can't stand the constant interruptions while I wait for the Flex compiler to finish. Fast is a feature!

To Adobe's credit, they do appear to be working on it. I just hope the work done in the Flex 4 cycle is the beginning and not the end of the improvements.


These two changes arise from the experience of Java developers moving to Flex - both my own experience, and what I've gleaned from talking to customers and their developers about moving to Flex. If Adobe resolves these, I think we'd see more Java developers happily using Flex in the future.