続いて、複数のソフトウェアが絡むような少々手間のかかる環境の同期を実践してみよう。筆者にとってテキストエディタの次に重要なプログラミング環境を同期してみる。プログラミング環境といっても……主業務であるPCベンチマークテスト作業の効率を高める目的で作成しているもので、業務用まで深いものの事例でないのは容赦願いたい。
ベンチマークプログラムのうち、いくつかのソフトにはテスト結果をファイルとして保存する機能が備わっており、その結果ファイルはプログラム別に複数のフォーマットがある。単なるテキスト(TXT)ファイルを生成するもののほか、XML、CSV、あるいはベンチマークプログラム独自のファイル形式もある。TXTやXML、CSV程度であればエディタのマクロ機能のみでもさほど苦労なく集計・整形できるのだが、独自形式となると扱いは少々やっかいだ。
特殊なフォーマットの例を挙げると、3DMarkなどFuturemark系の結果ファイル(拡張子は.3dmark-result)は、複数のファイルをZIP圧縮した内容となっており、集計のため手動で中身を見るには、ファイルの拡張子を.zipにリネーム→ZIP解凍→必要なXMLファイルを取り出す→xmlファイルを分析する、といったそこそこ面倒な手順が必要になる。
1つだけならいいが、この作業を十数回繰り返すわけで、すべて手動ではいくら時間があっても足りないので、プログラムを組んで自動化するわけである。筆者は主にPerl(Practical Extraction Report Language)スクリプトでこれを処理している。
Perlのメリットは、正規表現とともにテキストベースのデータ取り扱いに向いていることと、モジュールを追加することでさまざまな機能を追加できる点にある。正規表現を駆使し、テキストファイル内文字列の検索・置換のほか、文字列の有無を条件分岐として利用できるので、ベンチマーク結果ファイルの解析と成形にとても都合がいい。後者に関しては、例えばZIPファイルを解凍する、Excelファイルとして出力するといったモジュールが公開されているので、これらを活用することで(筆者の範囲では)かなり利用範囲が広がる。
これをPCごとに運用する際の課題としては、Perl本体のバージョンとモジュールの導入やバージョンを統一することだった。PC毎にバージョンが異なると、場合によってはスクリプトが動作しなくなることもある。また、追加モジュールの数が増えるにつれ、それをPC間で統一する手間も増えることになる。
……ということで、プログラミング環境もクラウド同期する第1歩は、Perl本体とライブラリが同期という単純なコピーで動作するのかという点を調査すること。PerlにもWinポータブル版として「Strawberry Perl(PortableZIP edition)」があるが、今回は筆者が慣れている環境で実現したかったので「ActivePerl」の、それも通常版で同期ができるのかどうか実践してみた。
筆者が調べた限りでは、いくつか課題はあるもののActivePerl自身はクラウド同期が可能だった。フォルダを変更したとしても、いくつかモジュールを追加したとしても、筆者が使用するスクリプトの範囲では問題なく、もちろんDropbox経由でもクラウド同期が行えた。
「いくつか」と書いたのは、Windowsのシステム環境変数にPerl.exeへのパスは通しておく必要があるためだ。このパスは、コントロールパネル→システムの詳細設定→環境変数で指定するパスであり、この設定項目はクラウドストレージのみで運用する同期では実現できない。この部分のみPCごとにパスを記述するか、スクリプト起動用にバッチファイルなどを組み、実行ごとにPerl.exeへパスを通す方法をとる感じだ。
Perlの次は開発環境の導入を試そう。テキストエディタベースでマクロを組むくらいならここまでの手順だけで大丈夫だが、どうせならデバッグ機能を含めたIDE(統合開発環境)を導入した方が作業もはかどるものである。ポータブル版IDEとしては「Eclipse Portable」がある。Java開発のためのIDEとして開発されたEclipseのポータブル版で、EPICというプラグインを導入することでPerlプログラミングも可能になる。このEclipse Portableをクラウド同期するため、同期フォルダの配下にインストールしてみた。
Eclipseも、Perlを実行するにあたってPerl.exeにパスを通す必要がある。これは、Windows自体のPerl.exeへのパスとは別のもので、Eclipseで設定するもの。ここでも、パス内にWindowsユーザー名が含まれるとパスの文字列に不整合が起こるので、前述のように相対パスを指定して回避する。
なお筆者はこれまで自宅PCのWindowsユーザーアカウント名は適当に付けていたが……、今回のようにソフトウェアのクラウド同期を用いた運用方法を考えるなら、Windowsユーザーアカウント名はアルファベット表記のもので統一しておくのが賢明だ。合わせて、クラウドストレージサービスの同期フォルダをほぼ固有の文字列で統一できるCドライブ直下などに指定する方法もアリだろう。
さて、ここまでやっても、1つだけ解決できないところがあった。Eclipseでプロジェクトを開くとどうやらロックファイルを作成する場合があるようで、これが作られると、別のPCからEclipseを起動する際にエラーすることになる(オフライン状態で起動すれば大丈夫かもしれないが、コンフリクトを起こすとも考えられる)。ともあれ、同時に起動するのはどれか1台のみと限定するよう自身で気を付ければひとまず大丈夫という感じか。
同期そのものについては、EPICなどEclipse側のプラグインを含めて問題はなかった。ワークフォルダを同期フォルダ内に作成すれば、現在進行中のスクリプトについても同期され、業務環境向上のためのアイデアがひらめいたら、今使っているマシンでサッとスクリプトが書ける環境が整った。
このように、ソフトウェアや開発環境のクラウド同期にも、現時点では可能なものと不可能なものがあり、一部カスタマイズを要するなどいくつか壁はある。ただ、クラウドストレージサービスも単体ファイル(テキストデータ、写真/動画データ、Office/PDFデータなど)やフォルダの同期に活用するだけでなく、ソフトウェアを含む作業環境も工夫によって同期を実現できることも確認できた。
一応、クラウドストレージにソフトウェアの実行ファイルを置くことになるため、セキュリティにはより気を付けるよう心がけたい。実行ファイルを改鼠されると、同期している全てのPCに影響が及んでしまうからだ。なお、今回はDropboxを例にしたが、数十〜数百Gバイトクラスの大量のデータをまとめてクラウド環境で管理したいなら、自宅やオフィスのPC/サーバ環境にクラウドストレージサービスと似たネットワークアクセス環境を──個人PCユーザーであれば、例えば「ownCloud」やネットワーククセス機能を備えたNASを導入するなどの方法もアリだと思う。
さて、ノートPCとタブレット、2つの使い方を1台でカバーできる「dynabook R822」ならここまでの苦労はいらないかもしれない。ともあれ、主業務作業用のPC、営業ツールとして手軽に持ち出せるタブレット、「どうせならこの2つの特長を生かし、ズバッと業務と連携させたい」ならば、何となくでも今後につながるヒントとなれば幸いだ。
Copyright © ITmedia, Inc. All Rights Reserved.