Joe Baumgarten asks an excellent question in the RPG discussion form: Why RDi 7.5? At a recent enablement training session, I had another business partner ask a similar question: "What are the key RDi features that sell RDi and what are the common issues customers raise about adopting RDi?" Both are excellent questions.
In the past I may have answered something like "PDM and SEU are old and Rational Developer for i is a modern tool for RPG and COBOL development." With the exception of a few leading edge IBM i developers, this answer generally doesn't go over very well (much the same way that I've learned "Because I said so" doesn't work that well with my kids). Over the past year I've transitioned to starting all RDi demos with two slides: What is RDi and Why use RDi? I'll explain the "Why RDi" here.
The short answer to why RDi can be summarized as:
If you're happy with short answers, and want to take my word for it, you can stop reading now. If not, here is the longer version.
I believe improved developer productivity with RDi comes from the following areas: modern development features, integrated tools, tools to help understand programs, and customizations.
Improving developer productivity is the number one reason why both developers and IT managers should consider switching to RDi. Earlier I mentioned that simply saying "RDi is modern tooling" doesn't work, which is true if that's all you say. But RDi is a modern development tool for RPG, COBOL, CL, and DDS and those modern development features do improve productivity. PDM and SEU were designed over 20 years ago. Over those 20 years there have been major advances in the area of application development tools. It still completely baffles my mind that SEU does not have an undo feature!
Here are some of those "modern features" that lead to improved productivity (a complete list would take way too long and is beyond the scope of this document):
There are many tasks a developer needs to do to develop software: search, edit source code, compile, and debug are just a few. These are not done in isolation, you may search to find a specific source member, then edit it. After editing you compile, fix any errors in the editor, and then may debug it. RDi integrates these tasks so developers can easily flow from one to the other. Here are some examples:
Now that the basic search, edit, compile, debug cycle is covered in the RSE we've started to branch out into other tools that can help developers understand the structure of their programs. At one end of the spectrum there is the "show block nesting" editor feature that draws lines in the editor margin to match up the beginning and ending of code blocks. There is also the outline view discussed above which can help understand the definitions and structure of the source member currently being edited. At the other end of the spectrum is the application diagram which can:
And of course, the application diagram is integrated with the editor so you can create a diagram from the contents of the editor, and quickly jump to definitions and calls in the editor by double clicking on entries in the application diagram.
RDi was designed to be customized. This includes customizations for specific development projects and personal customizations. Some examples of project customizations include:
Ultimately, customizations for both projects and personal preferences can make development more efficient.
Rational Developer for i is but one of many application development tools based on Eclipse. Others include:
Very few, if any, IBM i shops have only RPG / COBOL development projects. Most also have some type of Web, client/server, or application integration (SOA / services) development projects as well. Many of the solutions for these use Eclipse based tools. Take Web development for example:
If other teams in the organization are using Eclipse based tools, then using Eclipse based tools (Rational Developer for i) for RPG / COBOL development allows organizations to standardize on a common development tools platform. This opens up future avenues for implementing common processes and tools (testing, requirements gathering, change management) across all development projects regardless of programming language and runtime platform.
Improving developer skills is closely tied to the above idea of a common development platform. Developers can move to Rational Developer for i and continue working on the same development projects. In addition to the above benefits, this also increases the developer's skills: they are learning to use Eclipse based development tools. This provides a strong foundation for these developers to work on other Web, Java, or Web service projects in the future because these projects will also likely use Eclipse based tools. So the future learning curve is lowered; developers still need to learn the new technologies, but they don't have to learn a brand new development tool from scratch.
Using Rational Developer for i as your IBM i development environment can also help attract, and retain, new employees. The colleges that I know teach RPG programming do so using Rational Developer for i (which the students prefer over PDM and SEU). Showing these students a green screen development environment on the first day of work is not going to go over so well.
The original question posted by Joe was "Why RDi 7.5?" I think the main point of the question was why RDi, which I've hopefully answered above. But since it did mention 7.5 specifically, I'll include a short summary on that as well.
To be perfectly honest, RDi 7.5 does not have a lot of new features over RDi 7.1. Let me give some background:
When we originally designed the RSE, it was designed to be a framework for connecting to any type of remote system. Then it could be extended with system specific tools (IBM i tools in our case). This has been leveraged by 3 IBM products since the early days: Rational Developer for i (adds IBM i connection), Rational Developer for z (adds z/OS connection), and TPF Toolkit (adds TPF connection).
However, this requirement to connection to a remote system for development is not specific to IBM, so IBM made the RSE framework open source on Eclipse. This eventually became known as the Target Management subproject. As part of becoming an Eclipse project, the RSE framework had to be refactored to be more extensible, and follow common Eclipse and open source design and naming guidelines.
RDi 7.1 was still based on the older, IBM internal version of the RSE framework. For RDi 7.5 we rebased the IBM i extensions (which are not open source) on top of the open source RSE framework. Since this already required a fairly major porting effort, we decided to also take the opportunity to redesign and clean-up the internals of the IBM i RSE extensions.
So for RDi 7.5, here is the list of new things (other than a redesigned architecture which you can't directly see, but do benefit from in terms of improved performance):
I don't ever recall presenting or demoing RDi and having someone say that they just aren't interested. Normally developers and managers alike are excited about the features and possibilities that RDi offers. However, it often comes down to the learning curve. Developers go back to their desks, get caught up in the day to day things that come up and never get the time to try, or become proficient in, using RDi.
RDi is a new development tool for SEU / PDM users, and there is a learning curve to become proficient in any new tool. Based on some case studies we did with WDSC (but also apply to RDi), the expected learning curve is around 3 weeks. Around 3 weeks is when developers that were surveyed reported they were just as productive with the RSE and they were with SEU and PDM. Afer week 3 the productivity with the RSE went higher.
Of course these results will vary depending on factors such as commitment and existing skills. There are things you can do to shrink the learning curve and maximize productivity, such as formal training and regular team meetings to share questions and tips. These are also summarized in the case study article.
One of the concerns we often hear from developers is the time it takes to use the mouse. The mouse is the easiest way to learn RDi; by "clicking around" you can explore the user interface and find lost of the features it contains. However, power users want to use the keyboard to quickly navigate around. The good news is the RSE is full of keyboard shortcuts to enable those power users, the bad news is it takes time to memorize them so they just come naturally. I rarely use the mouse any more when working in the RSE (which becomes a problem when I have to demo and nobody can follow what I'm doing). A good place to start is the System i Developer keyboard shortcuts "pinup" (you should print it and pin it up beside your workstation).
There are many really cool features in RDi that developers like, but here I tried to focus on the business value of adopting RDi for RPG, COBOL, CL, and DDS development on IBM i. These are:
In the past I may have answered something like "PDM and SEU are old and Rational Developer for i is a modern tool for RPG and COBOL development." With the exception of a few leading edge IBM i developers, this answer generally doesn't go over very well (much the same way that I've learned "Because I said so" doesn't work that well with my kids). Over the past year I've transitioned to starting all RDi demos with two slides: What is RDi and Why use RDi? I'll explain the "Why RDi" here.
The short answer to why RDi can be summarized as:
- Improve developer productivity
- Common development tools platform
- Improve developers skills
If you're happy with short answers, and want to take my word for it, you can stop reading now. If not, here is the longer version.
Improve Developer Productivity
I believe improved developer productivity with RDi comes from the following areas: modern development features, integrated tools, tools to help understand programs, and customizations.
Modern Development Features
Improving developer productivity is the number one reason why both developers and IT managers should consider switching to RDi. Earlier I mentioned that simply saying "RDi is modern tooling" doesn't work, which is true if that's all you say. But RDi is a modern development tool for RPG, COBOL, CL, and DDS and those modern development features do improve productivity. PDM and SEU were designed over 20 years ago. Over those 20 years there have been major advances in the area of application development tools. It still completely baffles my mind that SEU does not have an undo feature!
Here are some of those "modern features" that lead to improved productivity (a complete list would take way too long and is beyond the scope of this document):
- Remote Systems LPEX Editor
- Color language tokenization: Source code is color tokenized based on language features so you can quickly (visually) see which lines are comments, whats language keywords, and whats user defined files, records, and fields.
- See more lines: When dealing with large (or even small) source members, the more source code you can see at once, the easier it will be to understand what the source code is doing. It also makes it less error prone to enter new source code because you don't have to guess (or page up / down) to see matching control structures.
- Outline view: The outline view serves many purposes. It provides a summary of the key definitions in the current source member: files, data structures, fields, key lists, subroutines and procedures (including definitions for records and fields pulled in from externally described files and data structures in ILE RPG). It provides quick access to cross reference information within the source member (ILE RPG only). Lastly, but just as important, it provides a quick way to navigate around the source member by clicking on definitions, or cross reference line numbers, in the outline view.
- Content assist and templates: You don't have to memorize the low level details for things like the order of parameters for keywords and built in functions(BIF), use content assist (Ctrl + Space) and the list of keywords (or opcodes, fields (ILE RPG only)) appears. Select the keyword or BIF you want and a hover dialog appears showing the required and optional parameters while you enter the values.
- SEU and workstation behavior: As much as possible, the Remote Systems LPEX editor has tried to implement SEU behavior to make the transition easier, and standard Workstation behavior. For example; you can use SEU prefix commands to copy and paste or you can use line selection and Ctrl + C / Ctrl + V.
- Undo and redo: All changes made in the editor since it was first opened can be undone using the standard workstation Ctrl + U keyboard shortcut. Undone changes can be redone using Ctrl + Y.
- Integrated i Debugger
- Use service entry points to easily attach to ILE programs or service program procedures running in any type of application (interactive, batch, stored procedure, Web, client / server). Note: the debugger can be used for both ILE and OPM, service entry points are a feature specific to ILE.
- Monitor the values of fields in real time as you step through your program.
- Create launch configurations for programs that are commonly debug to make it faster to start debugging them.
Integrated Tools
There are many tasks a developer needs to do to develop software: search, edit source code, compile, and debug are just a few. These are not done in isolation, you may search to find a specific source member, then edit it. After editing you compile, fix any errors in the editor, and then may debug it. RDi integrates these tasks so developers can easily flow from one to the other. Here are some examples:
- Developers can launch remote text searches from the RSE. The results (source members and specific lines) of the search are displayed in the Remote Search view. You can right click on either the source member or matching lines in the view to get context specific actions. Double-clicking on a matching line opens the editor and positions to the matching line.
- Press F1 on a language opcode, keyword, or column and the help browser opens with context specific language help.
- While editing source members, you quickly launch remote compiles using the Ctrl + Shift + C keyboard shortcut. The compile is submitted to batch and you can keep working. When the compile completes, the compiler messages are automatically displayed in the Error List view so you don't have to go look at the spool file. Double click an error message and the editor opens, positions to the line with the error and inserts the error into the editor. After you modify the line, a check mark appears next to the line in the Error List view so you know you've addressed that error.
- Set debug breakpoints in the editor before starting the debug session. The debugger uses the LPEX editor to view source, so you still have access to the outline view and other editor features while debugging.
Program Understanding
Now that the basic search, edit, compile, debug cycle is covered in the RSE we've started to branch out into other tools that can help developers understand the structure of their programs. At one end of the spectrum there is the "show block nesting" editor feature that draws lines in the editor margin to match up the beginning and ending of code blocks. There is also the outline view discussed above which can help understand the definitions and structure of the source member currently being edited. At the other end of the spectrum is the application diagram which can:
- Visualize subroutine, procedure, and programs calls for a selected set of ILE source members
- Visualize module and service program bindings for a selection of ILE programs and service programs.
And of course, the application diagram is integrated with the editor so you can create a diagram from the contents of the editor, and quickly jump to definitions and calls in the editor by double clicking on entries in the application diagram.
Customizations
RDi was designed to be customized. This includes customizations for specific development projects and personal customizations. Some examples of project customizations include:
- Defining multiple connections, one per application (or environment) and configuring the persisted library list settings to automatically setup the correct library list for compiling members for that application.
- Setting up application specific library, object, and member filters that appear only under the corresponding connection(s). The RSE enables filter specific actions like searching and building an application diagram, allowing you to leverage these filters beyond just quickly getting access to the objects and members.
- Customizing compile commands and user defined actions specific to an application.
Ultimately, customizations for both projects and personal preferences can make development more efficient.
Common Development Tools Platform
Rational Developer for i is but one of many application development tools based on Eclipse. Others include:
- Rational Application Developer
- Rational Business Developer
- Rational Software Architect
- IBM InfoSphere Data Architect
- Zend PHP Studio
- MyEclipse
Very few, if any, IBM i shops have only RPG / COBOL development projects. Most also have some type of Web, client/server, or application integration (SOA / services) development projects as well. Many of the solutions for these use Eclipse based tools. Take Web development for example:
- HATS
- Enterprise Generation Language (using Rational Business Developer)
- JavaServer Faces using Rational Rational Application Developer
- PHP using Zend Studio
If other teams in the organization are using Eclipse based tools, then using Eclipse based tools (Rational Developer for i) for RPG / COBOL development allows organizations to standardize on a common development tools platform. This opens up future avenues for implementing common processes and tools (testing, requirements gathering, change management) across all development projects regardless of programming language and runtime platform.
Improving Developer Skills
Improving developer skills is closely tied to the above idea of a common development platform. Developers can move to Rational Developer for i and continue working on the same development projects. In addition to the above benefits, this also increases the developer's skills: they are learning to use Eclipse based development tools. This provides a strong foundation for these developers to work on other Web, Java, or Web service projects in the future because these projects will also likely use Eclipse based tools. So the future learning curve is lowered; developers still need to learn the new technologies, but they don't have to learn a brand new development tool from scratch.
Using Rational Developer for i as your IBM i development environment can also help attract, and retain, new employees. The colleges that I know teach RPG programming do so using Rational Developer for i (which the students prefer over PDM and SEU). Showing these students a green screen development environment on the first day of work is not going to go over so well.
Why RDi 7.5?
The original question posted by Joe was "Why RDi 7.5?" I think the main point of the question was why RDi, which I've hopefully answered above. But since it did mention 7.5 specifically, I'll include a short summary on that as well.
To be perfectly honest, RDi 7.5 does not have a lot of new features over RDi 7.1. Let me give some background:
When we originally designed the RSE, it was designed to be a framework for connecting to any type of remote system. Then it could be extended with system specific tools (IBM i tools in our case). This has been leveraged by 3 IBM products since the early days: Rational Developer for i (adds IBM i connection), Rational Developer for z (adds z/OS connection), and TPF Toolkit (adds TPF connection).
However, this requirement to connection to a remote system for development is not specific to IBM, so IBM made the RSE framework open source on Eclipse. This eventually became known as the Target Management subproject. As part of becoming an Eclipse project, the RSE framework had to be refactored to be more extensible, and follow common Eclipse and open source design and naming guidelines.
RDi 7.1 was still based on the older, IBM internal version of the RSE framework. For RDi 7.5 we rebased the IBM i extensions (which are not open source) on top of the open source RSE framework. Since this already required a fairly major porting effort, we decided to also take the opportunity to redesign and clean-up the internals of the IBM i RSE extensions.
So for RDi 7.5, here is the list of new things (other than a redesigned architecture which you can't directly see, but do benefit from in terms of improved performance):
- Improved scalability and performance: The redesign in 7.5 should lead to performance and scalability improvements for large lists of libraries, objects, and members.
- More asynchronous tasks: More RSE tasks now run asynchronously so developers don't have to wait for long running operations. In RDi 7.1 we moved refreshes of the outline view to be asynchronous so developers can continue editing while the outline view refreshes. For 7.5, resolving filters and opening editors now are also asynchronous so you can continue working while these happen.
- Eclipse 3.4 support
- Improved extensibility: This is more for ISVs and business partners that write RSE extensions. Being able to download the RSE framework source from Eclipse can help a lot in finding examples and debugging problems.
Questions and Concerns About Adopting RDi
I don't ever recall presenting or demoing RDi and having someone say that they just aren't interested. Normally developers and managers alike are excited about the features and possibilities that RDi offers. However, it often comes down to the learning curve. Developers go back to their desks, get caught up in the day to day things that come up and never get the time to try, or become proficient in, using RDi.
RDi is a new development tool for SEU / PDM users, and there is a learning curve to become proficient in any new tool. Based on some case studies we did with WDSC (but also apply to RDi), the expected learning curve is around 3 weeks. Around 3 weeks is when developers that were surveyed reported they were just as productive with the RSE and they were with SEU and PDM. Afer week 3 the productivity with the RSE went higher.
Of course these results will vary depending on factors such as commitment and existing skills. There are things you can do to shrink the learning curve and maximize productivity, such as formal training and regular team meetings to share questions and tips. These are also summarized in the case study article.
One of the concerns we often hear from developers is the time it takes to use the mouse. The mouse is the easiest way to learn RDi; by "clicking around" you can explore the user interface and find lost of the features it contains. However, power users want to use the keyboard to quickly navigate around. The good news is the RSE is full of keyboard shortcuts to enable those power users, the bad news is it takes time to memorize them so they just come naturally. I rarely use the mouse any more when working in the RSE (which becomes a problem when I have to demo and nobody can follow what I'm doing). A good place to start is the System i Developer keyboard shortcuts "pinup" (you should print it and pin it up beside your workstation).
Summary
There are many really cool features in RDi that developers like, but here I tried to focus on the business value of adopting RDi for RPG, COBOL, CL, and DDS development on IBM i. These are:
- Improved developer productivity
- Common development tools platform
- Improved developers skills
Average User Rating
(1 rating)
There are no comments on this document
