しかし、この「三種の神器」はすでにいずれも機能拡張は終了しています。例えばエディタである SEU は V6.1 以降進化しておらず、最近の言語拡張には対応していません。このため、 V6.1 以降に RPG Ⅳ に追加された言語的な変更は、SEU を使って入力すると文法エラーとして認識されてしまうことになります。これではせっかくの最新機能も使うきっかけを失ってしまうことになりかねません。そこで今回は、この SEU に変わる最新のエディタを含む開発環境である RDi という製品を取り上げ解説していきます。
RDi とは
RDi の正式名称は「IBM Rational Developer for i」で、Eclipse プラットフォーム上に構築された統合開発環境（IDE : Integrated Development Environment）です。Eclipse 自体は Java で記述されており、もともと IBM がオープンソースで開発したものでしたが、現在では IBM のもとを離れEclipse 財団に移管されています。他言語（特に Java ）の開発では Eclipse が良く使われているようです。 IBM i では Java が利用できるようになったころから、いわゆる Web アプリケーション開発のプラットフォームとして WDSc（Websphere Development Studio client）が提供されるようになり、さまざまな機能拡張を経て現在の RD i へとつながっています。RDi には RPG や COBOL などの言語開発に必要な機能が IBM によって追加されており、最新技術への対応はこの製品に対して行われています。 ではこの WDSc の基本機能を通して RDi の仕組みを考えていきましょう。WDSc は 2002 年より利用可能になった、Windows にインストールして利用する GUI の開発環境です。基本は Eclipse なので、Eclipse の標準機能である RSE（Remote System Explorer）という機能が WDSc にも実装されています。RSE は一言で言うと「遠隔システムへの接続と接続後のリソースへのアクセス」のインターフェースを提供してくれるものです。WDSc の RSE には遠隔システムとして IBM i が追加されており、接続後にアクセスできるリソースとして、ライブラリー、オブジェクト、およびソース・ファイルが選択可能です。勘の良い方でしたらもうおわかりだと思いますが、5250 の PDM と同等の機能を提供してくれると考えてもらえると良いでしょう。 WDSc から（つまりクライアント PC の開発環境から）IBM i にアクセスするには、この RSE を経由して全てをおこなうことになります。RSE のインターフェースには Windows の Explorer が採用されており、マウスを使ってオブジェクトなどの IBM i のリソースにアクセスできます。また、アクセスしているリソースに応じた利用可能なアクションがマウスの右クリックで表示されるなど、5250 インターフェースでは実現できない、GUI ならではの操作性を実現しています。Windows のインターフェースに慣れている方（ほとんどの方が該当すると思いますが）であれば、RSE は短時間で使いこなすことができるでしょう。 IBM i のリソースの数は膨大になりますが、Explorer 上に表示させるものはサブセット可能であり、その条件をクライアントに保管しておくことができます。これにより、必要なリソースに最短でアクセスすることが可能になります。リソースにはコマンド・オブジェクトもありますので、RSE からコマンドを IBM i に投入したり、5250 画面に結果を表示させる、といった利用も可能です。Eclipse に関連する用語について
ここで、Eclipse ベースのツールで使用される独特の用語について触れておきたいと思います。RDi でももちろんそのまま使用されています。- ビュー
プログラム開発の用途ごとに用意されたウィンドウのことをビューといいます。「リモート・システム詳細」や「コマンド・ログ」、コンパイルの「エラー・リスト」ビューなど、非常に多くの種類があります。開発者は必要に応じてどのビューを利用するのかを選択することになります。 - エディタ
エディタは Eclipse 用語ではありませんが、プログラムのソースを編集する際に利用する特殊なビューです。言語毎に文法は異なりますので、それぞれ専用のエディタが必要です。RDi には RPG 用のエディタがあらかじめ用意されており、文法検査や入力補完機能などを提供してくれます。 - パースペクティブ
プログラムの開発にはさまざまなビューが必要ですが、それを作業ごとに毎回個別に選択するのは効率の良いやり方ではありません。そこで、コードの編集やデバッグ操作といった作業単位で、必要なビューをグループ化する機能が提供されています。これを「パースペクティブ」と言います。作業単位毎にパースペクティブを選ぶことで、その作業で必要なビューのみを一度に表示させることができます。パースペクティブは独自のものを作成することも可能です。 - ワークベンチ
Eclipse の画面全体のことをワークベンチといいます。ワークベンチには、メニューバーやステータス行、複数のビューやエディタなどが含まれます。ワークベンチ内の複数のビューやエディタは、パースペクティブを選択することで一度に切り替えることができるのはすでにお話したとおりです。 - ワークスペース
開発のプロジェクト毎にワークスペースを作成しておくことで、簡単に開発環境を切り替えることが可能になります。ワークスペース毎に Windows の専用ディレクトリが作成され、 RSE で定義した接続情報やどんなパースペクティブを使うか、前回の終了時の状態はどうだったかなどの情報がそのディレクトリに保存されます。ワークスペースは、RDi を開始するときや、ワークベンチのメニューから切り替えることが可能です。
SEU との共通点 / 相違点
ではここで RDi にあらかじめ用意されている LPEX エディタを紹介しましょう。LPEX エディタは、RSE からソースファイルを選択し、その中のメンバーをダブルクリックすることで起動されます。RSE から起動される場合は IBM i のソース・メンバーを直接オープンし、ソース・コードを RDi のエディタに表示します。 このエディタは SEU と同様の機能を提供します。例えばコピー、移動、削除などの行コマンドや、定位置記入形式のソース記述に必要なプロンプト・ビューの呼び出しなどです。もちろんソース内の文字列の検索や置換機能、構文エラーの表示なども行います。プロンプトおよび構文検査は RPGⅢ および Ⅳ の言語はもちろんのこと、ファイルや画面定義を作成する DDS にも対応しています。 LPEX エディタはワークベンチ上で複数同時に起動することが可能です。データベースと画面、およびプログラムのソースを同時に表示し、編集したいビューのタブをクリックすることで素早く切り替えながら開発が可能です。ワークベンチにはエディタ以外のビューも表示されていますが、各ビューのタブをダブルクリックすると、ワークベンチ内でそのビューのみを表示することが可能で、必要に応じて簡単に一つの情報（ビュー）に集中することができるように設計されています。 また、コピーやペースト、アンドゥ、ソースの保存などのショートカット・キーは Windows と共通なので、新しい操作方法を覚えることなく効率のよいプログラム開発すぐ始められます。 LPEX エディタに連動して動くアウトライン・ビューも便利です。このビューを通して、現在開いている（編集している）ソースの構造の概要を確認できます。ソース内で定義されているファイルや変数、プロトタイプ、サブルーチンやプロシージャの一覧などが表示され、さらに変数やサブルーチン名などをクリックすると、LPEX エディタ内でその変数やサブルーチンなどが定義された行にカーソルが位置づけられます。 SEU の機能はすべて提供しつつ、複数ソースの同時編集や、Windows ショートカット・キーの利用、アウトラインを表示させながらのプログラム・コードの編集など SEU では不可能だった多くの機能が提供されているのは注目すべきところでしょう。何より、5250 画面の制約（横80桁、縦24行）のない環境での開発は、使い始めたその瞬間から良さを実感していただけると思います。今回は紹介しませんが、定位置記入形式におけるインデント表示や、見た目のカスタマイズ、ショートカット・キーの割当変更などなど、便利な機能がたくさんありますので皆さんも試してみてください。i プロジェクト
先程紹介した RSE を使った開発は、IBM i に接続して RDi よりリモートのリソースを操作することが基本です。そのため、LPEX エディタでオープンするソースは、サーバー側で他のユーザーが同時に編集できないようにロックされます。RPG のソースコードをサーバーで管理されているユーザーの方はまだまだ多いと思いますので、この仕組みは多くの IBM i ユーザーにとってイメージし易いでしょう。 一方、他の言語の開発ではソースコードはサーバーではなくクライアントに保管されているケースがほとんどです。Java はコンパイラーもクライアント側で実行するので、コンパイル後のオブジェクトのみがサーバーに存在すれば良いですし、スクリプト言語である PHP なども実行サーバーとは別のマシンでソースコードを作成および修正し、実行時にサーバーに配置するといった流れが一般的でしょう。こういった言語の開発を Eclipse でおこなうためには、クライアント側のディスクにソースコードを保管し、それを RDi から操作するためのビューが必要になります。これを実現してくれるのがプロジェクトと呼ばれる機能です。 RDi には、i プロジェクトと呼ばれる RPG のソースコードをクライアント側に保管および管理する機能が提供されています。i プロジェクトを使えば、RSE で IBM i に接続することなくプログラムを開発することが可能になるのです。 しかしながら Java と違って、IBM はクライアント側で実行できる RPG 用のコンパイラーは提供していません。つまり、ソースコードがローカルにあればどこでも編集できますが、コンパイルする時は IBM i のディスクにコードを配置する必要があります。これに対応するため、i プロジェクトでは必要に応じてソースを IBM i のソース・ファイルにプッシュする機能が提供されています。RSE には複数のサーバーを登録することができるので、例えばテスト用と本番用の IBM i が存在する場合、ソース・コードの編集はクライアントのディスクで行い、テスト時はテストサーバーに、本番稼働時には本番用サーバーにそれぞれ RSE で接続した後でソース・コードをプッシュするなどの操作が可能となります。 i プロジェクトで管理するのはクライアント内のディスクのソースコードですが、編集に使用するエディタは LPEX エディタなので、編集時は RSE から起動されたのか、i プロジェクトからなのかには関係なく同じ機能を利用することができます。外部ツールとの連携
i プロジェクトを使用してソースコードをクライアントに保存することの本当の利点は、非接続環境で開発ができるということではなく、これから紹介する様々なバージョン管理システム（Version Control System）との連携にあると思います。例えば RTCi（Rational Team Connector for i）や、フリーの VCS である Subversion などとの連携です。SEU / PDM メインで開発を行う場合、最新のソースコードは常にサーバー上に存在しているため、ソースコードがクライアントに存在しているのが前提で開発された多くの VCS 製品を IBM i の開発プロジェクトで利用することはできませんでした。しかし、RDi で提供されるこの i プロジェクトを使うことで、一般的な VCS との連携が可能になったのです。では具体的な例を Subversion との連携を例に簡単に紹介しましょう。
IBM i におけるシステム開発は SE やプログラマーがチームを組んで行います。場合によっては何十人という大がかりなプロジェクトも珍しくないはず。プログラムのコードも日々更新され、場合によっては一つのソースコードを複数で編集することもありえます。SoR 実現のための言語である RPG であればなおさらその可能性は高く、最新のソースがどれなのか、というのはもとより、過去のどの時点で誰がどのステップを修正したのか、という記録をしていくことは欠かせません。この記録を一括管理するために VCS は存在します。
編集されたソースコードは VCS のリポジトリに必要に応じて記録されます。この行為をコミットと言います。コミットにより、誰がいつソースコードのどこを修正したかという情報がリポジトリに保管され、その修正を識別する番号（リビジョン番号）が割り当てられます。リポジトリの最新ソースコードはいつでも取り出すことが可能であり、開発者は常にリポジトリとクライアントに保存されているソースコードの同期を取りながら、自分が担当するプログラムのソースコードを編集してコミットするということを繰り返します。ソースコードの管理に関しては一切 IBM i が関わっていない点に注意してください。IBM i にソースコードが必要になるのは、そのソースをコンパイルする瞬間だけであり、管理は完全に VCS に任せることが大切です。
RDi から Subversion や Git などの VCS にアクセスするには、別途対応するプラグインを導入する必要がありますので、利用を検討する際には注意してください。
開発の流れと RDi の守備範囲
ここまで解説したことをまとめましょう。RDi でできる主なことは以下のとおりです。- 5250 の画面の制約を受けない環境の実現
- Windows と共通のインターフェースの利用
- 複数メンバーの同時オープン
- アウトライン表示
- VCS との連携
- ソースコードの編集と IBM i へのプッシュ
- コンパイル・コマンドの実行
- デバッグ
IBM i で稼働しているシステムでの問題点や新規案件などを BTS で管理すれば、担当者の明確化や進捗状況の把握などが今まで以上に確実に行うことができます。また、IBM i のシステム開発でもチケット駆動開発などを適用することも可能になるなど、RDi を開発作業のスタンダードにすることの利点は計り知れないものがあるのではないでしょうか。
おわりに
RDi は、開発環境が GUI になるという見た目だけの変化ではなく、i プロジェクトを前提としたソースコードのバージョン管理をきっかけに、他の言語開発で使用されているさまざまなツールを IBM i の開発現場に持ち込むことが可能になるという利点を提供してくれます。RPG Ⅳ の最新機能にも対応しているという側面だけではなく、他言語・他システムの開発者と同じツールを使った開発環境に近づくことで、多くの技術者が違和感なく IBM i の開発プロジェクトに参加できる入り口が整備されたことになりますね。SEU / PDM で開発している SoR システムのソースも RDi を使用して一日も早くバージョン管理を始めましょう。 スタンダードとは一般的には「標準」という意味ですが、ジャズの「スタンダード」は、「広く世に知られ親しまれ、あるいは多くのアーティストにカバーされるようになった楽曲のこと（Wikipediaより）」なのだそうです。RDi のベースとなる Eclipse もジャズと同様に「広く世に知られ親しまれ」たツールであり、様々なツールを IBM i の開発に持ち込んでくれるきっかけになってくれると思います。この「スタンダード」な開発環境が 一日も早く全ての IBM i のユーザーの「スタンダード」になることを願っています。 次回はオープンソースで提供される、IBM i で利用可能な開発環境、 Orion / Git について解説します。次回の記事もお楽しみに！おまけのコラム
先日、今年最初のハーフマラソン大会に出場してきました。１週間前の天気予報では、大会当日は曇り後雨だったのが、前日にはレース中に雨という予報に変化。当日は予想気温も低かったこともあって辛いレースをかなり覚悟していたのですが、幸いにもレース中は雨がふることはなく、結果的に楽しいレースとなりました。プロ選手ではないので当たり前とは言え、市民ランナーとしても圧倒的に距離を踏んでおらず、今回はせめて完走できれば満足ぐらいの気持ちで望んだのですが、結果的に前半は焦らず後半はペースを落すことなく走ることができました。結果も自分としては大満足のタイムでした。ちょうどその日はクイーンズ駅伝の中継もあったのでレース終了後すぐに着替えて自宅に戻り、急いでシャワーを浴びて軽く食事をしながらテレビ観戦。最初からハラハラ・ドキドキのレース展開でしたが、自分が走った直後にトップランナーの走りを見ると、やはりすごいなと感心しきり。その余韻も冷めやらない一週間後には福岡国際マラソン。この大会では不調と言われていた川内優輝選手が素晴らしい走りで日本人トップの3位と好成績でした。川内選手はこの大会がフルマラソン40回目だそうです。「マラソンを百回完走して、百戦錬磨になることが目標」とのこと。まさに継続は力なりですね。この季節は駅伝・マラソン中継から本当に目が離せません。 最近では、マラソンの世界でも練習スタイルが変わっているようで、いわゆる「距離を踏む」練習よりも「科学的トレーニング」が注目されています。大学駅伝でも実業団でも科学的トレーニングがどんどん取り入れられているように思います。最終的には人によって、あるいは成長過程においてそれぞれ適した練習方法があるので、どちらが良いのかという質問には答えがないと思っていますが、川内選手はいわゆる市民ランナーの枠なのでどちらかというと「がむしゃらに頑張ってここまできた」という印象が私にはあります。川内選手にとってのスタンダードな練習方法をこれからも追求して、東京オリンピックにもぜひ出場して欲しいと願っています。著者プロフィール
