Arkの今後

Q：Arkの今後のロードマップ，展開について教えてください。

A：いろいろ考えていまして，大きく4点の検討事項があります。

自社サービス向けにモバイル対応

まず，社内からの要望として挙がったものとして，モバイル対応があります。すでに自社のモバイル開発チームによってモバイル用のArkコンポーネントが整備されているので，次のアップデートではこのモバイル機能を取り込む予定です。

また，CGIやテンプレート機能の拡張を予定しています。とくに先ほど挙げたText::MicroTemplateを常用できるように拡張したいです。

その他，Javaのjarファイルのようにアプリケーションをパッケージ化してアップロードできるような仕組みも実装する予定です。

受託案件向けのワークフローや規約の策定

次に，受託案件で使えるような規約の策定，さらに複数メンバーでの開発に耐えられるようなワークフローの準備をしたいですね。Perlフレームワークは自由にCPANモジュールを組み合わせて使用できるように、あえて規約がゆるいものが多いため，開発者の書き方や癖によるコーディング内容の差異が大きくなります。それを防ぐような仕組みを用意したいです。また，可能な限りArkにサンプルを付属させて，それを参考に開発してもらえればと思います。

サンプルアプリケーションの準備

今の話にも繋がりますが，Arkで作ったサンプルアプリを弊社ラボにアップしていきます。それらは参考用としてぜひ使っていただきたいですが，あくまでサンプルですので，実装については開発者の皆さまご自身のアイデアを盛り込んでいただきたいですね。

Arkの拡張ドキュメント

最後に，これはArk開発時の目標の1つでもありますが，ドキュメントの拡充です。今後は，モバイル対応などをしたうえでそれらのドキュメントやArkプラグインの書き方など，応用的な使い方に関するドキュメントを用意していく予定です。

Javaプログラミングから―初めてのプログラミング

Q：続いて，村瀬さんご自身についていくつか質問させてください。まず，初めてプログラミングをしたのはいつ頃でしょうか？

JDKでGUIプログラミング

A：PCに触ったのは15年ぐらい前，中学の時ですね。当時Windows 95が出たころでした。それから，プログラミングを行ったのは高校に入ってから，まさにJavaが出たときです。初めてのプログラミングはJava 1.0（JDK 1.0.2）だったと思います。

古くから開発をされている方はご存知かと思いますが，当時のJavaと言うとブラウザ上で稼働するAppletが主流でした。しかし，僕はApplet開発ではなくて，Windows上で動くGUIアプリの開発をするのが好きでしたね。無料でWindowsアプリを開発できることが大変魅力的でした。

転機を迎えたblosxomとの出会い

それから，大学に入ってUNIXを触り，LinuxでC言語開発をするという流れだったように思います。そのころ，ちょうどブログブームがあったかと思うのですが，当時触れたblosxomに影響を受けたことを強く覚えています。

blosxomは，Perlベースのブログエンジンでオープンソースで提供されていました。blosxom自体はとてもシンプルで，拡張するには自分でプラグインを書いたりHackする必要があったのですが，その思想がとても格好良く思えたのです。このプロダクトの思想というのは，今回発表したArkでも踏襲しています。

こうして，blosxomにはまっていくうちに，Perlに触れ，他の方が作ったプラグインやコードを読むことでPerl開発の知識の習得を行っていました。

Perlの学習について

少し質問から離れますが，僕は今お話ししたように他の方をコードを見たりドキュメントを読んでPerlを学習してきました。そのため，あまり本を読んで勉強することが少ないのですが，その中でも2冊ほどお勧めしたい本があります。1冊は『Perlベストプラクティス』（⁠オライリー・ジャパン⁠）⁠，もう1冊が『モダンPerl入門』（⁠翔泳社）ですね。

どちらもPerlをきちんと覚えるための内容が，体系立てて紹介されています。ぜひ推薦したい書籍です。

Djangoがおもしろい

Q：村瀬さんというと，Perlデベロッパの印象が強いのですが，ご自身で他のLL（Lightweigt Language）に触れる機会はありますか？ あるいは気になる言語などがあれば教えてください。

A：もちろんPerl以外の言語にも触れた経験はあります。実はPerlの前にRubyに触れていました。

フレームワークとしては，PythonフレームワークのDjangoの独自性がおもしろいと思っています。一般的にフレームワークというのは開発効率を高めることが目的となり，（⁠機能で見ると）画一的になる部分が見られますが，Djangoは独自性が強く,他のフレームワークにない機能を実装していて、かつそれが他のフレームワークでも取り入れたらいいのではないかと言うものが多く，注目しています。

ただPythonとPerlを比べるとやはり，TMTOWTDI（There's More Than One Way To Do It. “⁠やり方はひとつじゃない⁠”⁠）というスローガンに見えるようなPerlの自由さが好きですね。

もちろん，自由の裏返しとして，人によってコードの書き方が全然違ってしまう，といった面もありますが，個人的には逆にそれが面白いと思っているので，これからもPerlに注力していきたいです。

フレームワークのメリット・デメリット

Q：今，フレームワークに関してのお話が少し出ました。村瀬さんが考えるフレームワークのメリット・デメリットがあれば教えてください。

A：最大のメリットは，やはり開発効率の向上，つまり開発スピードが上がる点ですね。たとえば，ログイン処理など同じ実装であれば何度も同じコードを書く必要がなく，フレームワークとして提供されていれば良いわけです。

一方で，画一的になる部分があるため，複数のサービス同士で同じ機能が出てきてしまうことがあります。フレームワークを使うにあたっては，開発者自身のクリエイティビティやマインドをどう反映させられるかこれが大切です。この2点を意識しないと（できあがったものが）皆同じようなアプリケーションになってしまったり，ユーザにとって魅力的ではないものになる危険性があると感じます。

Arkに関して言えば，自分用の雛形を用意することができるため，先ほどのログイン処理のように共通して使える機能など，自分が欲しい機能だけをあらかじめ用意しておき，あとは自由に開発を行えるという柔軟な開発が行えます。

それから，これは“⁠Perlの⁠”フレームワークという条件になるのですが，Perlは自由に開発がしやすい分，規約の作り方が大事になります。とくに複数メンバーでの開発をするとなったときはもちろん，これからPerlを開発したい人に対して，見やすいコードを書くというのはけっこう難しかったりします。これらの課題は，ArkやCatalystなど，Perlのフレームワークが解決することでもあり，また，解決できると思っています。