Leo's Chronicle: java

inputから、output(+副作用）を作る

というメソッドと同じparadigm(パラダイム: 枠組み）にまとめたいわけです。この形にすると、コードをメソッドの形に書き直して、再利用することが簡単になります。グローバル変数を多く使っているコードは、依存関係を即座に判断するのが難しく、メソッドに纏め上げるのが大変なので忌み嫌われています。

一方、DRYの原則に従ってメソッドやクラスとして一箇所にまとめられたロジックは、使うユーザーや使われる場所が増えるため、依存関係を増やします。使う場所が増えないなら、メソッドやクラスにまとめる理由は、コードにわかりやすい名前（alias)をつけるくらいの意味しかありません。例えば、あちこちで頻繁に使われる文字列型(string)の最初の文字のindexが0ではなく1に変更されたら、大惨事になるでしょう。

プログラマって、依存関係を減らそうと努力しているかと思えば、一方で依存関係を増やそうと一生懸命になる、とても不思議な生き物です。入力から出力を作る枠組みでしか物事を考えられない、可哀想な生き物でもあります。

変数のスコープを最小に抑えると、リソースを解放するタイミングを明確にできる利点がありますが、GC(garbage collection) を搭載した現代的な言語実装では、不要になったらメモリを即解放というわけにはいかないので、スコープが多少ずれていても、さほど深刻ではありません。

プログラマは空気を読む学生向けにプログラミングの講義をしていたときに学んだのは、ソースコードを追う能力の乏しい段階の学生さんは、抽象化されたコードの「意味」ではなく、「動作」を追ってしまう、ということ。

例えば、SQLなどは高度に抽象化されたコードの典型例でしょう。（これを宣言型という人も多いですが、抽象化の度合いの違いにすぎません）。以下のSQL文、

SELECT * FROM t1, t2 WHERE t1.id = t2.id

を見て、「2つのテーブルt1とt2でidが同じ値の行を結合する」、と読み取れたなら、おめでとう！もうあなたは立派に優秀なプログラマです。

例え内部で、lexer, parserからなるSQLコンパイラが動いていて、テーブルとクエリの静的型チェックをし、問い合わせスケジュールを組み立て、テーブルのデータ分布に基づいてスケジュールを最適化し、B+-treeとsequentialレコードを、ページロックを取得しながらserializabilityが保証されるようなプロトコルに従って検索して、必要ならライトウェイトロックで管理されたキャッシュにディスクページを保存しつつ、テーブルの結合にディスクを介したhash joinやexternal merge sortを実行していたとしても、そんなことは気にしてはいけません。SQLという入力から得られる結果の意味、つまり空気を読むことが大事です。

プログラミング言語は空気を描くものどのプログラム言語を極めたらいいかって？空気を読みやすくて、自分の空気を描けるもの。できなければ拡張するか、作る。これが言語を極めるということでしょう。作るのは割に合わない？使いやすいプログラミング言語とその実装・ライブラリが出来上がるのを待つリスクが割に合うなら、のほほんと偶然の産物を待つのも一興でしょう。

(追記 10月29日)

考えることを減らせるように書く

長くなったのですが、同じラボにいた川中君がきれいにまとめてくれました。

「考えることを減らせる様に書く」

メソッド（関数）によるコードの整理や、オブジェクト指向による実装の隠蔽、プログラミング言語のなりたちなど、プログラミングのすべてはこの動機から始まります。すばらしい。

2008年10月21日火曜日

[SQLite JDBC] Javaで始めるSQLiteデータベース入門

SQLiteデータベースは、Cで書かれた軽量データベースです。「軽量」というのは2つの意味があって、全体のコード数が10万行程度という点（PostgreSQLは100万行に近づいています）と、データベースを保存するファイルが1つに納まっているのがSQLiteの特徴です。他のシステムだと、複数のデータベース用のファイルがあって管理が面倒なのですが、SQLiteのデータベースはファイル1つで、しかもOS互換フォーマットで保存されているので、簡単にOSをまたがったデータベースのコピーを作成することができます。

そもそもリレーショナルデータベース（日本語では関係データベースと訳すことが多いです）って何？という方は、初心者向けに用意した以下の講義資料を参考にしてください。

データベースアプリケーション入門「データベースって何？」

Javaでデータベースアプリケーションを作成するには、JDBC (Java Database Connection)というAPIを使います。ただし、データベースを使うには、まずシステム側にデータベースシステムをインストールする必要があり、ここが慣れた人でもデータベースシステム（英語では、Database Management System: DBMSと言います）の設定でつまづいたり、面倒なことが多いのが難点でした。

このような問題を解決するために、SQLiteの軽量さを生かしたJava用のライブラリ（jarファイル）を作成しました。

Xerial: SQLite JDBC Driver

このSQLite JDBC Driverでは、Mac OS X, Windows, Linux (i386, amd64)などよく使われるOSでSQLiteをインストールなしで動作させるために、それぞれのOSでコンパイルしたSQLiteのバイナリをjarファイルの中に埋め込んであります。これは、SQLiteが軽量だからなせる技です。プログラムの実行時に、自動的にjarファイルの中から、OSに応じたSQLiteのバイナリを取り出し、Java側でロードして使えるようにしています。

もし、少々特殊なOSや、CPUを使っていても安心です。SQLiteのCのコードを完全にJavaで動作するように置き換えたpure java版のSQLiteもライブラリに含めているので、上記以外のOSでもきちんと動作します（CをJavaコードに書き換えるのに少々無理があるので、動作は遅くなりますが）

JavaでSQLiteデータベースを使うには次の手順で行います：

sqlite-jdbc-(version).jar をここからダウンロードします。2008年10月現在の最新版は3.6.4です。（Maven central repoのミラーからもダウンロードできます。）
下にあるサンプルプログラム(Sample.java)は、JDBCを通してデータベースの作成、検索をする例です。これをコンパイルします。
Javaを実行するときに、上記のJARファイルを以下のようにクラスパスに含めます。
```
java -classpath ".:sqlite-jdbc-(VERSION).jar" Sample
```
これだけでJavaでDBMSが使えるようになります。お手軽！

Sample.java

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;


public class Sample
{
 public static void main(String[] args) throws ClassNotFoundException
 {
   // load the sqlite-JDBC driver using the current class loader
   Class.forName("org.sqlite.JDBC");
  
   Connection connection = null;
   try
   {
     // create a database connection
     connection = DriverManager.getConnection("jdbc:sqlite:sample.db");
     Statement statement = connection.createStatement();
     statement.setQueryTimeout(30);  // set timeout to 30 sec.
    
     statement.executeUpdate("drop table if exists person");
     statement.executeUpdate("create table person (id integer, name string)");
     statement.executeUpdate("insert into person values(1, 'leo')");
     statement.executeUpdate("insert into person values(2, 'yui')");
     ResultSet rs = statement.executeQuery("select * from person");
     while(rs.next())
     {
       // read the result set
       System.out.println("name = " + rs.getString("name"));
       System.out.println("id = " + rs.getInt("id"));
     }
   }
   catch(SQLException e)
   {
     // if the error message is "out of memory",
     // it probably means no database file is found
     System.err.println(e.getMessage());
   }
   finally
   {
     try
     {
       if(connection != null)
         connection.close();
     }
     catch(SQLException e)
     {
       // connection close failed.
       System.err.println(e);
     }
   }
 }
}

やや高度な内容ですが、MavenをJavaの開発に使っている人は、mavenのcentral repositoryにsyncされているこのSQLite JDBCライブラリを使うことができます。pom.xmlファイルに以下のような記述をするだけで自動的にダウンロードされます。

<dependencies>
<dependency>
 <groupid>org.xerial</groupid>
 <artifactid>sqlite-jdbc</artifactid>
 <version>3.6.4</version>
</dependency>
</dependencies>

SQLiteではファイルにデータベースを保存せずにメモリーの上でデータベースを構築することもできるので、データベースのテスト用にも最適です。

2008年10月16日木曜日

優秀なウェブ開発者の見極め方

「Webアプリケーション技術者の見極め方（Java）」こんな記事を見かけましたが、使えるツールやフレームワークの種類云々を聞くより、単刀直入に欲しい人材を見抜く質問はこれ。

「JavaでWebアプリケーションを開発する利害得失を述べよ」

もちろん、「Java」の部分をRubyなり、PHP、Perlなどに置き換えても良いです。僕なりの解答はまた後日。

（関連リンク）

2008年9月9日火曜日

Google Web Toolkitを本格的に使う

昨日、Google Web Toolkit (GWT)に触れたので、備忘録という意味も含めて、もう少し詳細を書いてみます。僕自身、GWTを使って、ゲノムブラウザを作ってみたり、講義のレポート提出用サイトを作成するなど、ここ数年大活躍しているツールで、GWTによるWebインターフェースで、5万行は優に超えるだけのコードを書いています。

Google Web Toolkitは、JavaからJavaScriptに変換するコンパイラと、ブラウザで表示するHTMLを生成するWidgetクラスを含んでいます。Javaの構文でプログラムを記述すれば、Webブラウザで動くJavaScritpコードを作成してくれるというものです。

実際の開発ではHTMLを書くことはなく、FlexTable, Buttonなど、HTMLでよく使うtableやformタグをクラスとして表現してくれているので、再利用可能な形でHTML要素を設計しやすくなっています。GUIインターフェースのプログラミングと似た感覚でウェブアプリケーションの開発ができる、と考えるとよいかもしれません。Perl、PHP、Ruby on RailsなどHTMLのテンプレート中心の開発と趣が異なるので、テンプレートに慣れた人にとっては最初のうちはコードを組みにくいかもしれませんが、HTML生成のまどろっこしい部分を気にせず開発できることに真価があります。

コンパイル後の最終的なコードはJavaScriptになるのですが、GWTではJavaの標準的なライブラリをエミュレーションすることで、JavaのArrayList, HashMapなどよく使うデータ構造を使えるようにしてくれています。GWT1.5からは、JavaのGenericsの構文や、forループの簡略記法を使えるようになったので、ますます開発が簡単になりました。

3種類のJAR GWTにおける開発では、3種類のJARファイルを使います。

gwt-user.jar GWTでは、client（ブラウザ上で実行されるコード）と、sever(サーバー上で実行されるservletなどのコード）の2種類のフォルダ（Javaのパッケージ）を使って開発します。サーバーとの通信に必要なservlet周りのパッケージ(javax.servlet)がgwt-user.jarに同梱されていて、自分でTomcatをインストールしてこれらのライブラリをclasspathに設定する手間が省けます。gwt-user.jarは開発時のみに使うものです。
gwt-servlet.jar 一方、こちらは、TomcatなどのWebサーバーに作成したWebアプリケーションを設置するときに、WEB-INF/libフォルダに含めておくものです。gwt-user.jarから、javax.servletのパッケージを取り除いたものです（javax.servletはTomcatに標準装備されているパッケージです）。deploy時には、gwt-servlet.jarのみを使います。
gwt-dev-windows.jar, gwt-dev-mac.jar, gwt-dev-linux.jar これらのJARファイルには、GWTのコンパイラが含まれており、JavaコードをJavascriptに変換するときに使います。また、GWTのコードをコンパイルせずにJavaコードのまま実行するための、GWT Shellが含まれています。GWT ShellはTomcatサーバーをローカルに立ち上げるGUIプログラムなので、OS毎に必要なJARファイルが異なり、gwtの配布パッケージに含まれている.dll、.jnilib、.soなどが実行するのに必要になります。デバッグ時には、クラスパスの先頭にgwt-dev-*.jarを追加しておきます。（gwt-user.jarなどはJavaScriptコードを含んでいるので、Javaとしては動作しません）

GWTのアプリケーションをデバッグしたり、コンパイルするには、ソースコードのフォルダ(srcとか、src/main/javaなど）と、Javaのソースコードクラスが含まれているフォルダ(binとか、target/classesなど）がクラスパスに含まれている必要があります。これはJavaのソースコードそのものがコンパイルなどに必要なためです。

GWTのためのJAR作成したがって、GWTのコードをJARのライブラリにして再利用するときも、ソースコード（*.java)もclassファイルと同じ位置に含めて作成する必要があります。普段から、ソースコード同梱のJARを作っておくと、EclipseでJARのソースコードがすぐ参照できるというメリットもあります。

GWTによる開発を即座に始めるこう並べてGWT開発の注意事項を並べて書くと、はまりどころが多くて、設定もとても面倒なのですが、僕はこれらの設定を含めて、GWTによる開発を数秒で始めることができるようにしています。

現在開発中の、UTGB Shellというゲノムブラウザを作るためのツールでは、utgb create, utgb gwtのコマンド2つで、GWT、データベース、サーブレット機能を含めたプロジェクトの雛形を作成します。埋め込み型Tomcatサーバーを立ち上げることで、Tomcatなどのインストールなしに、ローカルマシン上でJavaによるWebアプリケーション開発ができるようにもなっています。現在は、生物系の研究者が、面倒なしにゲノムブラウザを作れるようにする趣旨のツールなのですが、僕自身、ゲノム関係以外の一般のWebアプリケーション開発にも使っています。

UTGB Shellの舞台裏ではMaven（パッケージ管理ツール）が動いています。そのインストール作業を省くために、Maven自身もUTGB Shellに埋め込まれています。また、gwt-dev-*.jarのライブラリも、本家で配布されているものとは違って、dllなどのライブラリも同梱させています。これによって、OSごとに１つのJARファイルをダウンロードするだけで済むのですが、これらのライブラリをOSの種類に応じてダウンロードしたり、展開したり、GWTのコンパイラを起動するなどもすべてMavenのスクリプトとしてまとめているので、ユーザー、開発者が、詳細を気にする必要がありません。本番用サーバー上のTomcatへのdeployもコマンド一つでできるようになっています。

このような複雑なプロジェクト管理ができるようになったのも、Javaの魅力の１つ。C++などバイナリのOS・コンパイラ間の互換性が乏しい言語の場合は、ソースコードの最新版をネットからダウンロードして、dllをコンパイルする必要があります。コンパイルエラーがでる、実行時にリンクエラー、multi-threadライブラリのタイプが一致していなくてメモリリークが起こるなど、など、慣れていない人には解決しようのない、はまりどころもたくさんでてきます。

Javaではこのような面倒が軽減され、Mavenのようなパッケージ管理ツールのおかげで、典型的な作業を繰り返さずにすむようにできるようになったのが嬉しいですね。

2008年9月8日月曜日

Google Web Toolkitでcanvasを使って画像を描く方法

Google Web Toolkit(GWT)は、Java言語からJavaScriptのコードを生成するものです。ブラウザ間のJavaScriptの動作の違いを吸収してくれるなど、ウェブアプリケーション開発の苦労をかなり軽減してくれます。GWTはもう十分実用的なのですが、まだまだ成長途中でgwt本体のtrunkに正式に組み込まれる前の機能などは、Google Web Toolkit Incubatorというプロジェクトで開発されています。

gwt-incubatorの中で目玉なのが、GWTCanvasというライブラリ。これは、次期HTML5には標準搭載されるはずのcanvasタグの機能を使って、ブラウザ自身に画像を描画させるというものです。こちらのデモを見てもらえれば、意外と複雑な図が描けたり、アニメーションが作れるなど、そのすごさがよくわかると思います。Flashプラグインなどを使わない限り、今まで画像をブラウザで見せるにはサーバーから画像データを直接送る以外に方法がありませんでしたが、今後は描画のために必要な座標、色などの情報をサーバーが送るだけで、画像を描くなどサーバーにとって重い処理はブラウザ側に任せてしまえるようになります。

実はこのcanvasという機能、IEはサポートしていません。けれど、IEにはVMLという独自の画像を描くための仕様があります。GWTCanvasは、IEのときはVMLを使って画像を描き、canvas機能が既に使えるFirefox, Google Chrome, Safari, OperaなどのWeb標準を大事にするブラウザでは、canvasを直接使う、というトリックを使って、ほとんどのブラウザで画像を描くことを可能にしています。ただし、IEのVMLを使った描画は動作が重いのでご注意。

厳しく言えば、IEがWeb標準を追おうとしてないから、こんなライブラリが必要になっている節があります。どのOS・ブラウザでも動くことを大事にするWeb Developerにとって、IEは本当に憎らしい存在。Webアプリケーションを作る動機って「どこでも動くアプリケーション」を作ることに尽きますから。IEのためだけに必要なwork aroundのなんと多いことか。

ソースコードからjarファイルを作るにはこちらを参照して、ant distとすればいいですが、僕がJARパッケージにしたものもこちらからダウンロードできます（GWT1.5.2用です）canvasで遺伝子構造を描いてみたりしています。ブラウザで画像を描き始めるとGoogle ChromeのJavaScriptの動作が本当に速いことがよく実感できます。

2008年8月26日火曜日

JARファイルの中にJARを埋め込む

以前、「Leo's Chronicle: Fat Jar: Jarファイルの中にJarを埋め込む」で、JavaでFatJar plug-inを使って、Jarファイルの中にJarを埋め込む使う方法を紹介したのですが、最近は事情が変わってきています。

たとえば、Eclipse3.4からは、Runnable Jarの作成がサポートされ、依存関係にあるすべてのJARファイルの中身を展開して、1つのJARにまとめてくれる機能が標準装備だったり、Mavenユーザーなら、assembly pluginを使って、jar-with-dependenciesを指定する方法もあります。

ぱっと試したいなら、Runnable Jarを作成するのが速くて楽。このようなJARを頻繁に作成するなら、Mavenのassemblyで書いてしまうのが良いです。

関連記事：JARファイルの作成方法

2007年12月31日月曜日

SQLite JDBC Driverをv038にupgrade

Leo's Chronicle: SQLite JDBC Driver

本家のsqlitejdbcドライバーがupdateされていたので、こちらもv038 (sqlite3.5.4)に対応させました。
http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

ちょっとした改善点は、jarファイルから抽出した*.dll等のファイルを、目立たない場所に置くようにした、という点。SWT3.3から導入されたテクニックと一緒ですね。Win, Linux, Macに完全対応なので、動作が極端に遅くなるPure Java版を敢えて使う必要がなくなると思います。

ライセンスもApache License 2.0に対応させました。ビジネス、私用、共に自由に使えます。時間ができたときに、本家を完全に取り込むとよいかなぁ。僕的に、これはあまり優先度は高くないけれど。

OSごとにpackageを作って、v037, v038を別々にreleaseする作業って、mavenを使っていると、わりと楽にできます。ただ、いつも思うことですが、必ずしも「便利になる」イコール「楽になる」ということではないんですよね。

便利になるということは、仕事の敷居が低くなるということ。つまり、できることが増えるわけえす。そうすると、今までやろうともしなかったことをすることになるので、仕事量はあまり変わりません。mavenの仕組みを学んで、慣れるまでに、相当の時間を費やしているので、結果として、まったく楽にはなっていないです。

次にどれだけプロジェクトを作るか次第で、ここで払った勉強コストが有益かどうかが変わります。たぶんプロジェクトは、今後どんどん増えていくのですが、そうとわかっていても、苦労するのは今なわけですから、長期的な価値判断に基づいて行動するのは、人間にはなかなか難しいものですね。

「喉もと過ぎれば熱さを忘れる」　ということわざにもありますが、後になって、初期の投資がどれだけ大変だったか評価するのも難しい。さてさて。

関連：[SQLiteJDBC] Javaで始めるSQLiteデータベース入門

2007年10月15日月曜日

SQLite JDBC Driver

SQLiteのデータベースをJavaから扱うのは、意外と不便でした。

Pure-Java JDBC driverもあって、それはjarファイルをclasspathに含めるだけで良かったのですが、sqliteのコードを完全にJavaに変換して作成されているので、クエリの種類によっては動作が極端に遅くなることもありました。

sqliteをdllなどにして、C APIをJNDI経由で操作する、native版のライブラリもありますが、dllをインストールしたり、パスの設定しなくてはいけなかったりと、いろいろ面倒でした。

そこで、dllもろともを一つのjarの中に押し込めたまま使えるようにしたSQLiteのJDBCドライバを作成しました。
http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC

dllを自動的にjarの中から取り出してくれて、パスの設定なども行ってくれます。これでJavaから、sqliteを気楽に使えるようになりました。

ぜひ、使ってみてください。

関連：[SQLiteJDBC] Javaで始めるSQLiteデータベース入門

2007年9月18日火曜日

Eclipse Maven plugin (eclipse m2 plugin)　と　Struts2　の組み合わせではまる件について

http://livingash.wordpress.com/2007/08/16/struts-2-and-sun-micros-toolsjar-in-eclipse-wtp/

上のブログを見つけるまで、？？？の状態でした。

mavenで、struts2を使うために、dependencyを設定したところ(org.apache.struts:struts2-core-2.0.9)

"com.sun:tools:jar:1.5.0" がrepositoryからdownloadできない

とeclipse上の、m2plugin様に怒られます。

struts2のpom.xmlが、${java.home}/../../tools.jarを参照しているという変なところも問題なのでしょうが、とりあえずの解決方法は、

eclipse -vm "C:/Java/jdk1.6.0_01/bin"

として、eclipseを起動！

（mavenを知らない人にはさっぱりわからない内容だなぁ。。）

2007年8月24日金曜日

[Mac] Eclipse Subclipse plug-in 用のlocale設定

[] Subclipse plug-in用の設定

以前上ののような記事を書いたのですが、版だと少し事情が違います。

http://www..org/articles/Article-Speak-The-Local-Language/article.html
ここに書いてある手順で、.appを右クリックして、中に含まれているInfo.plistというXMLファイルに、の設定を書きます。

<string>-nl</string><string>en_US</string>

eclipse.iniに設定を書いてもMacのEclipseだと反映されないんですよね。
どうしてだろう。

2007年4月2日月曜日

[Eclipse] Subclipse plug-in用のlocale設定

でsubversion plug-in (Subclipse)を使っていると、日本語のメニューになったり、$Date$タグの置換が、日本語の日付（何月何日、何曜日）などとなってしまって、英語中心の開発では、困ることが多いです。

の設定は、実は、
> .exe -nl "en_US"
というコマンドラインオプションでできることを発見。これでメニューが全部英語になって、和訳や誤訳などに惑わされないですみます。

日本語で書かれたプログラミング言語の解説書やマニュアルが何故分かりにくいかというと、英語で書かれている用語や概念が、それと１対１に対応しない日本語に訳されているという点。

最初から全部日本語なら、問題ないのだけれど、日本語の文書はたいてい後発だし、上手に訳せて、かつ技術に明るい人なんて、そうはいないだろうから、開発環境は全部英語にするのが実は、労力が少ないのです。

2007年2月20日火曜日

Fat Jar: Jarファイルの中にJarを埋め込む

Fat Jar Eclipse Plug-In

Javaで開発していて、他のライブラリのアーカイブ(Jar)を使っている場合、自分のプログラムもJarとして配布するときに、manifestファイルに適切に外部のJarへのreferenceを書いておかないと正しく動作しません。

通常は、classpathの設定を含めた実行スクリプトを一緒に配布することが多いみたいです。でも、スクリプトを用意するのは面倒ですよね。

そんな煩わしさを取り除くのが、Fat Jar。Jarの中にJarファイルを埋め込んでプロジェクト全体を１つのファイルとすることができます。

Fat Jarは、通常は、外部で参照しているJarを展開してJarの中に埋め込むのですが、One-Jarオプションを選ぶと、jarファイルを展開せずにそのままjarの中に埋め込みます。こちらの方が、構成内容がよくわかります。

Fat Jarを使うと、今まで、
java -cp lib/somelibrary.jar -jar myprogram.jar
などとしていたところを、

java -jar myprogram.jar

と実行するだけでよくなります。意外と知らない人がいると思うので、紹介しました。おすすめです。

最近はJARの作り方も事情が変わっています。2008年８月 http://leoclock.blogspot.com/2008/08/jarjar.html

2007年1月28日日曜日

[Mac] Macを使っていて…

開発者として一番がっかりしているのは、EclipseのMac版がどうにも洗練されていないこと。フォントも思ったように指定できないし、半透明色が使えなくてMacらしさがでなかったり…。なにより、動作がやや重い。Boot Campで、別パーティションのWindowsからEclipseを使っている分には、そのような不快さは感じないので、まだEclipseのコミュニティがMac版の開発に力をいれていないのかと思います。　

逆にすごいと感じたのは、OS自体の言語環境切り換えがスムーズなこと。普段英語圏のアプリケーションを使用することが多いので、OSのインターフェースを英語に切り替えたくなったりするのですが、 Windowsでは英語版をインストールしなくてはいけないのと違って、Macでは設定一つで瞬時に使用言語を切り替えることができます。過去の遺産をあまり引きずっていないから、最初から他言語に対応できるようにするなど、柔軟な設計ができているのかもしれませんね。