彼らはHTMLファイルにコードを書くことをなんとも思ってないんだね。もちろん、プログラマからすればその方が早いのかもしれないけどね、私には「HTMLはプログラマのものなの？」という思いがあります。

ちょっと古い記事を目にしてしまった。。
これについて、 ちょっと語ってみる。

この記事に書かれている。

1. デザイナをプロとして尊重する。
2. プロダクトに於いて、デザインは重要。
3. ビジネスにおいては、成果を挙げる為には、デザインが優れている事は重要。

僕もそう思っている。

では、デザイナとは何であろうか？ 会社のロゴマークや商品のパッケージ もそうだが、デザインとは芸術的創造物とは ちょっと違う。

個人のセンスを表現する場所ではなく、 ユーザにとって価値のあるものを創造するという 視点が重要だと思う。

優秀なWEBデザイナは本当にすごいと思う。

そのプロダクトのコンセプトにマッチていて、 心地良さすら感じさせてくれるデザインをする。

そして良く見れば、そこには徹底的に拘り尽くされた 様子さえ垣間見る事ができる。

デザインとはそういうものだと思う。 だから、「デザイナはHTMLとCSSで勝負しているんだ！」と、決め付けてしまうのは良くない。 (そういう人が居る事は事実だが。) Windowsのクライアントアプリケーションの画面デザインや、 Flashでの画面デザインなど、 画面という物一つとってもあらゆる手段とツールがある。

だから、JSPにしろWikietにしろRailsにしろ 画面デザインの領域に必要な構造化やスクリプトは あってよいのだと思う。

何も、HTMLとCSSだけを 生業とする人の為だけに、 分離をがんばってやったり、 その為にプログラマの負担を増やしたりする必要は無いと思う。 つまり、「HTMLとCSSが出来る人が、WEBデザイナであり、 それ以外ができなくてもＯＫ」という考えを改めるべきだと思う。

「別に、JSPのタグが入っていてもＯＫですよ。」 というデザイナが居たっていいし、多分それよりはるかに 複雑なコーディング(デザインの世界では、HTMLを作成する事をコーディングと呼ぶらしい)をしているデザイナーは山ほど居る。

それに、そもそもJavaScriptは良いのかという話にもなる。

多分もうすぐ、 というかもうなってるかも知れないけど、
jQuery等JSライブラリはデザイナーは必須の知識になるのではないだろうか。

そうなれば、JavaScriptが良くてJavaが駄目な理由はないだろう。

重要な事は、 デザイナだって作りながら確かめながらを、 繰り返すわけで、その作業に弊害のない環境を 用意する事

そういう意味で、JSPは実行させるための手順が多く、 敷居が高い気がする。 デザインツールとEclipseを同時に起動するってのもつらい気がするし。。

Rubyならツールの支援はさらに、まだまだ感が強い。 でもそれは、需要の問題だから、欲しい人がいれば出来るのも 時間の問題でしょう。

当然ながら、普通のHTMLとしてあつかえ、ブラウザで起動すれば 表示を確認できるという、Wiketが、そのような点において優れている事については何の異論もない。

でも、フレームワークて、そういう要因だけで決められるほど 単純なものじゃないよね。
ひとつの要因ではあるけど。

社内にRailsが得意な人が居て、
HTMLとCSSが得意な人が居たら、
別にRails止めさせる必要ないだろうし、 デザイナが頑張ってERB覚えた方が、絶対良いよね。

だから、ビジネス的に考えるなら、 あまりそこに拘らないほうが良いよという話。

HTMLはデザイナだけの物でもないし、
プログラムはプログラマだけの物でもない。

Javaのソースからコメントを削除する正規表現

けど完全じゃない。。。 リテラルの中の/* xxx */ の部分を削除してしまう。

あと、gsubを２重にしてるのもやめたい。

class JavaSource
  def initialize( file_path )
    if file_path && file_path =~ /\.java/
      open( file_path ) {|file|
        @text = file.read
      }
    end
  end

  def comment_strip
    return nil unless @text
    return @text.gsub( %r{/(\*.*?\*/)}m, "").gsub( %r{(//.*$)}, "")
  end

end

src = JavaSource.new( ARGV[0] )
puts src.comment_strip

前も同じようなタイトルで書きましたが、

多重ディスパッチ

スクリプト言語でプログラミングするようになってから、 この手の、「あれ？これ出来なかったんだっけぇ？！」 というシチュエーションが良くある。

記事内のオーバーロードしたメソッドが 実行時の型によって選ばれないという件。

昔は気にならなかったのは、多分できないのが、 当たり前だという脳回路が出来上がっていたんだと思う。

普通は感じる事ができないし、出来ないからこそ 恐ろしい「思考停止」という状態を 過去の自分に感じる事ができた。

これは貴重な体験だ。

それは置いておいて、

記事内の現象自体は、Javaはインタフェースに対して メッセージングをするという概念で考えれば、 納得できるが、それでは、やはり思考停止だと思い、 今の自分だったらどう実装するだとうという観点で 考えてみた。

Java的には、 Animalにenterメソッドをつける方法が一番 エレガントな気がするけど、 やりたい事がシンプルに書けてない感じが残る

(この感じがスクリプト言語から得た感覚なのかも。。)

結局今の自分なら以下のように書くかなぁという 内容です。

import java.util.ArrayList;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.List;

public class TestMultiDispatch {
  public static void main(String[] args) {
    Zoo z = new Zoo();
    for( Animal a : new Animal[]{new Cat(), new Dog(), new Cat()}){
      z.enter(a);
      a.say();
    }
  }
}
class Zoo{

  Hashtable h = new Hashtable();
  public Zoo()
  {
    h.put(Dog.class, new ArrayList());
    h.put(Cat.class, new ArrayList());   
  }
  public void enter(Animal a){
    List list = (ArrayList)h.get(a.getClass());
    list.add( a );
  }
}
abstract class Animal{
  abstract public void say();
}
class Cat extends Animal{
  public void say(){
    System.out.println("にゃ〜");
  }
}
class Dog extends Animal{
  public void say(){
    System.out.println("わん!");
  }    
}

流れるようなインタフェース

名付け親は、ファウラーさん。
Martin Fowler's Bliki in Japanese - 流れるようなインターフェース

で、どんな実装かっていうのは上のリンクを見てもらうとして、 つまりDSLを実現しようとしているような感じ。

昔、まだオブジェクト指向とJavaを知って 興奮しながらコーディングしてた時に 同じような発想をした事がある。

実際にコードを書き始めたが、その時は挫折した。
なぜかというと、設計が難しい。 システム内のいろんな局面でそれをやろうとすると、 クラス(インタフェース)の数が膨大になる。

この実装のポイントは、
ある目的を達成する為の手続きの為に、 インターフェースを細かく設計し、 それぞれのメソッドをうまく融合させて、 １つの事が実現する。
という事だと思う。

オブジェクト指向では、クラス中心に システムを設計していき、クラスの役割を、 「１つの事を上手に行う」という発想で 設計していく。これはクラス中心の発想。

流れるインタフェーススタイルはその中の メソッドにフューチャーしていて、
「１つの事を上手に行う為に、 次の仕事の案内を戻り値のインタフェースによって伝えながら、 対話的に行う。」
という事になる。 さらに、案内は選択肢が多くても意味がない。

そう対話的なのです。 つまり、完結しないメソッドを実装する事になります。

Statement st = 
 generator.select("id, hoge, mage")
          .from("orders")
          .where("xx=hoge");

IDEでエラーになるから、楽だよ。 的な発言もあるけど、やってみればわかると思うけど、 かなり設計が難しい。 失敗すると間違いなくカオスになるから、 むやみにやらない事も大事だと思った。

仮に、近い将来このスタイルが流行ったとしても、 開発プロジェクトとしてはあまり幸せじゃない 結果をもたらす気がするなぁ。

しかし、これをどこかで、実装したくてウズウズする自分もいる。 静的言語でも、DSL行けるんじゃねぇか。 今ならできるかもみたいな。。