HOME :: JOB LISTINGS :: ARCHIVES :: MEDIA KIT :: SUBSCRIBE


IDE Considerations for Remote Programming

by Jerome Lambourg, Senior Software Engineer, AdaCore

In today's tough economic climate, software companies must continually search for ways to reduce the costs of technology development, while maintaining the quality and efficiency of their products. Allowing programmers to work from home, utilizing expert subcontractors, or outsourcing software development to countries with less expensive IT personnel, are attractive, cost-saving options.  However, concerns about managing and controlling a remote development process prevent some companies from adopting this approach.

Project mangers require a controlled build and execution environment to ensure that the code that is tested will be exactly what is going to run when in production.  They also require a system that is easily maintainable and permits the development of portable software from desktop PCs to several platforms.  On the flip side, developers working remotely, and/or using a wide variety of platforms and compilers, need a seamless interface to access necessary servers from their desktop PCs. 

Fortunately, advanced Integrated Development Environment (IDE) technology has made it possible for development teams to work seamlessly together from disparate locations.  Today’s IDEs offer a plethora of features designed to ease code creation and speed up the development process, including code navigation, automatic error fixing, automatic indentation, smart completion, graphical debugging, dynamic help tool tips, and many other features.  Still, in order to take full advantage of the processing power and advanced development tools at your disposal, it is important to carefully consider available options when choosing an IDE for a remote development project.

What to Look for in an IDE

Nowadays, even low-end PCs come equipped with enough processing power and high-level functionality to compete with the capabilities offered by most traditional servers.  And yet, as desktop PCs and user interfaces become more advanced, maintaining the same level of functionality on all platforms has become more and more difficult.  In addition, servers are not always compatible with each other, and adding advanced functionality or running multiple instances of an IDE requires large network, memory and power resources, which can be problematic on certain older servers. 

As a software company providing an Ada compiler together with a complete IDE, we have customers confronted with this kind of situation. One customer in particular had to maintain a complex system – more than 1 million lines of codes - running on an old server platform. This platform has very limited capabilities concerning graphical applications: the X libraries provided are very old, and the most recent high-level graphical libraries could not be ported to it.

In order to still provide them our IDE technology, we came up with the 'remote programming’ facility. This facility allows IDE-related operations to be carried out on the local desktop computer using the local CPU, display and memory. As soon as a remote action is required, such as compilation, debugging or execution, the IDE automatically connects to the remote machine, synchronizes the files when necessary, and performs the action.

Mechanisms that Improve the Remote Development Experience

The 'remote programming’ facility uses commonly available external tools on the local desktop, such as ssh, rsh, telnet, or other custom tools integrated via an xml configuration file. Those tools allow the IDE to connect to the remote shell directly, sending commands and analyzing the responses. The shells supported are for now bash, sh, tcsh, csh, and Windows’ shell cmd.exe. This mechanism allows no specific installation on the remote machine.

Figure 1:  Remote programming architecture

Directly controlling a shell offers major advantages over just launching a remote execution as allowed by ssh or rsh.  First, the user has full control of the shell configuration before any execution occurs, allowing full setup of default paths, dependencies, global variables, and so on.  Second, there is no connection overhead, so the user only has to connect to the remote server once, thereby ensuring that consecutive remote operations are much faster.

Controlling the remote shell is one thing, but in order to execute completely, the remote programming facility requires that both client and server machines have access to the source code of your project. Two mechanisms can be used for that: either the project’s files are located on a shared repository – in this case the shared filesystem mechanism takes care of the synchronization – or the project’s files are local to the client machine. In the latter case, the remote programming facility takes care of file synchronization before and after every remote action, making sure that the correct files are compiled or executed, and that files modified by the remote action are correctly retrieved.

The result of these mechanisms is a great improvement in the remote development experience.  On the programmer side, all these remote operations are completely transparent to the user: once configured, you can hardly tell the difference between local and remote development.  On the server and IT side, this functionality only uses standard tools and requires no specific installation on the remote server.  The remote server’s resources, together with the network resources, are well preserved to handle only the essential functions.

Users Reap Benefits

With remote programming’s advanced functionality, working remotely becomes a much easier process, enabling and enhancing many user scenarios.  For example, when a single central server is used for compilation but several developers need to access it remotely from their desktop PCs, there are obvious advantages for using an IDE with the remote programming facility compared to using an IDE on a central server displayed via X-Window.  First, the network traffic is drastically lowered, and second, the memory and power resources of the server are preserved for essential operation, such as compilation and execution of the program. The advantage of using the remote programming facility over using direct command line inputs is also obvious.  The programmer gets a complete and modern IDE that greatly helps the development process, while utilizing the same amount of network traffic and server resources.   With such low network traffic and the use of secure connections via ssh or any other custom tool, it is even possible to continue the development on a remote platform with low network connection. No local network is necessary and a simple Internet connection is sufficient.

For many projects, portability of the application is essential.  With remote programming, changing the destination server for a project is a matter of one click, making the development of a single project on multiple platforms a very easy process. The fact that the programmer will continue to use a single IDE and a familiar environment - his local desktop - while developing on any remote server is also of great benefit as it shortens the learning curve for this new environment. With customization of the remote shells used for connecting to the server, it is also very easy to switch from one tool chain to another on a single server, making transitions between compilers a much easier process.

Companies working on projects requiring perfect control over the target platform typically do not have an IDE installed, nor do they require any specific installation on the remote server.  The remote programming facility allows the IDE to be taken out of the quality control process. It is also perfectly possible to compile a project on a remote machine (or on the local one) while the execution is done on another. The quality-controlled server will be reserved for execution or debugging while other machines can be used for compilation. This is particularly useful when the deployment platform is a scaled down version of the development machine - embedded versions of Windows or Linux, for example. This is also useful for application providers who need to validate or debug their tool in the customer context.

Conclusion

As we've seen throughout this article, the remote programming concept is very useful to both programmers and project mangers. For the former, working in a networked environment, remote programming provides a powerful tool on the local machine to directly accesses all the necessary servers.  For the latter, remote programming helps maintain server setup of strictly necessary tools, thus offering a controlled build and execution environment that is easily maintainable.

Working from home is now a possible and attractive solution, as well as debugging and recompiling a client application off-site. Calling an external expert, managing distant subcontractors, or using this functionality for outsourcing the hardware/ software development environment also becomes a very realistic possibility. Remember, when shopping for an IDE, be sure to consider all the factors, including remote programming.  Given the many benefits this feature offers, it is certainly worth a look.

Click here for printable PDF
(By clicking on this link you agree to Embedded Technology Journal's Terms of Use for PDF files. PDF files are supplied for the private use of our readers. Republication, linking, and any other distribution of this PDF file without written permission from Techfocus Media, Inc. is strictly prohibited.)

by Jerome Lambourg, Senior Software Engineer, AdaCore

December 12, 2006

[back to top]


RECENT COMMENTS ON WWW.JOURNALFORUMS.COM:

All material on this site copyright © 2006 techfocus media, inc. All rights reserved.
Embedded Technology Journal
Privacy Statement