While configuring developers’ workstations, ensure that each of them has at least 2 GB of RAM; otherwise, compilation by your IDE may take a large portion of your working day. As to what that IDE is, the choice is yours.
You can install Flash Builder either as a standalone IDE or as an Eclipse plug-in. The latter is the preferred choice for those projects that use Java as a server-side platform. Savvy Java developers install Eclipse JEE version or MyEclipse from Genuitec; both come with useful plug-ins that simplify development of the Java-based web applications.
Today, Flash Builder is the most popular IDE among Flex enterprise
developers. It comes in two versions: Standard and Professional. The
latter includes the data visualization package (charting support,
AdvancedDataGrid, and Online
Analytical Processing [OLAP] components). Besides offering a convenient
environment for developers, Flash Builder has room for improvement in
compilation speed and refactoring.
IBM’s RAD 7.5 is a commercial IDE built on the Eclipse platform. RAD feels heavier when compared to Flash Builder. It can substantially slow down your developers if they have desktops with less than 2 GB of RAM.
For many years IntelliJ IDEA was one of the best Java IDEs. IntelliJ IDEA supports Flex development and is more responsive and convenient for Flex/Java developers than Flash Builder. The current version of IDEA, however, does not allow the creation of Flex views in design mode, which is clearly a drawback. It does not include the Flex profiler, which is an important tool for performance tuning of your applications. On the other hand, if you prefer Maven for building projects, you will appreciate the fact that IDEA includes a Maven module.
At the time of this writing, Flash Builder is the richest IDE available for Flex developers. Flash Builder 4 is going to be released in early 2010. Besides multiple changes in the code of the Flex SDK, it’ll have a number of improvements in the tooling department: for example, a wizard for generation of the Flex code for remote data services, project templates, autogeneration of event handlers, integration with Flash Catalyst, a FlexUnit code generator, a Network Monitoring view, better refactoring support, and more.
In some enterprises, developers are forced to use specific IDE and application servers for Flex development, such as RAD and WebSphere from IBM. We believe that developers should be able to select the tools that they are comfortable with. Some are more productive with the Flash Builder/Tomcat duo; others prefer RAD/Resin. During development, no such combinations should be prohibited, even if the production server for your application is WebLogic.
Likewise, members of a Flex application group may be physically located in different parts of the world. Third-party consultants may be working in different operational environments, too. They may even install the Flex framework on different disk drives (C:, D:, etc.).
All this freedom can lead to issues in using version control repositories, because Flash Builder stores the names of physical drives and directories in the property files of the Flash Builder project. Say Developer A has the Flex framework installed in a particular directory on disk drive D:. He creates a project pointing at Tomcat and checks it into a source code repository. Developer B checks out the latest changes from the repository and runs into issues, because either her Flex framework was installed on the disk drive C: or her project was configured to use WebSphere. In addition to this issue, developers will be reusing specific shared libraries, and each of the Flex modules may depend on other shared libraries as well as the server-side BlazeDS or LCDS components.
To simplify the process of configuring the build path and compile options of the Flex projects (developers may have different deployment directories), use soft links rather than hardcoded names of the drives and directories (this is the equivalent of what’s known as symbolic links in the Unix/Linux OS).
For implementing soft links in the Windows environment, use the junction utility, which is available for download at http://www.microsoft.com/technet/sysinternals/FileAndDisk/Junction.mspx. This utility is a small executable file that allows the mapping of a soft link (a nickname) to an actual directory on disk.
For example, run the following in the command window:
junction c:\serverroot "c:\ Tomcat 6.0\webapps\myflex"
It’ll create a soft link C:\serverroot that can be treated as a directory on your filesystem. In the example, c:\serverroot points at the application deployment directory under the Apache Tomcat servlet container. Similarly, another member of your team can map C:\serverroot to the deployment directory of WebSphere or any other JEE server.
From now on, all references in the build path and compiler options will start with C:\serverroot\ regardless of what physical server, disk drive, and directory are being used. By following these conventions, all Flash Builder projects will be stored in the source control repositories with the same reference to C:\serverroot.
We recommend at least two soft links: C:\serverroot and C:\flexsdk, where the former is mapped to a document root of the servlet container and the latter is mapped to the installation directory of the Flex SDK. An example of creating a soft link C:\flexsdk is shown here:
C:\>junction C:\flexsdk "C:\Program Files\Adobe\Flash Builder 3 Plug-in\sdks\3.0.0"
When Flex SDK 4.1 or even 5.0 becomes available, this should have minimal effect on your build scripts and Flash Builder projects: just rerun the junction utility to point C:\flexsdk to the newly installed Flex framework.
By now, your team has selected the IDE, come to an agreement on the use of soft links, and considered various recommendations regarding Flex code, such as embedding into HTML, testing, build automation, and logging.