馬鹿につける薬

統合開発環境は次の時代へ

2010-03-13T12:01:00.003+09:00

上の動画は，ブラウン大学のAndrew Bragdon氏らによって開発された統合開発環境"Code Bubbles"のデモだ。プログラミングと統合環境に興味のある人は，とにかく一度見てみて欲しい。とてもインパクトのあるデモだ。

というわけで、見てみたんだが、相当広いデスクトップが無いと辛いんじゃないか？これは。

現行の統合開発環境は，いまだにファイル単位でのエディットを基本としており，それが様々な不便を生み出している。Code Bubblesはその不便を解消するべくデザインされた，まったく新しい形の統合環境だ。

eclipseのパッケージ・エクスプローラにJavaのソースファイルが並んでいるのが気持ち悪かった（あそこにはソースファイルではなく、クラスが並ぶべきだろう）のだが、同じような疑問を持っていた人は結構大勢いるのだろうか？

前述した通り、相当広いデスクトップが無いとこのCode Bubblesとやらは使いにくいような気がするが、ファイル単位で物考えるのはやめねえか？というアプローチはありだろう。

少なくとも、eclipseはファイルシステムがそのまま見えているだけに等しいパッケージ・エクスプローラをどうにかして抽象化するべきだ。開発者が記述しているのはファイルではなく、コードなのだ。

CORBA

2009-10-17T14:47:00.001+09:00

さて、次の仕事が始まったんだが、SOAPでGo!だと思ってたら、一部のサーバとはCORBAで通信するらしい。　CORBAって前世紀の遺物だと思ってたんだが、そうでも無いらしいな。

なので、CORBAについて調査させられたんだが、ハッキリ言ってよく分かりません。　OMGのサイトで仕様が公開されてるんだが、個々の仕様のつながりとバージョンとの関連がまったく分かりません。　それに、Javaでのデファクトスタンダードなライブラリって無いの？　JDKのCORBAのパッケージはCORBA 2.3のまま止まってる感じだし、OpenORBはCORBA 2.6だし……。　最新のバージョンはCORBA 3.1なのに最新のバージョンに追従しているライブラリって存在しないのかな。

仕事で使ってる人はなにを使ってるんだろう。　あと、CORBAの仕様書の和訳ってどこかに転がってないかなあ。

Eclipse + WTP + Axis2　その7

2009-10-17T14:24:00.000+09:00

さて、結構駆け足でやってきたんだが、いくつか問題と要検討な課題がある。　その前に、作成する必要があるファイルとツールによって生成されるファイルをまとめておこう思う。

AutoGeneratesの定義ファイル
ファイル名	概要
java2wsdl.build.properties	interfaceクラスからWSDLを作成するためのbuild.xmlのためのプロパティファイル。
java2wsdl.build.xml	interfaceクラスからWSDLを作成するためのbuild.xmlファイル。

AutoGeneratesでツールによって生成されるファイル
ファイル名	概要
SampleService01.wsdl	java2wsdlコマンドによってinterfaceクラスから生成されるwsdlファイル。

Skeletonsの定義ファイル
ファイル名	概要
wsdl2java.build.properties	WSDLファイルからサーバ側スケルトンのJavaソースファイルを生成するbuild.xmlのためのプロパティファイル。
wsdl2java.build.xml	WSDLファイルからサーバ側スケルトンのJavaソースファイルを生成するためのbuild.xmlファイル。

Skeletonsでツールによって生成されるファイル
ディレクトリ名	ファイル名	概要
src/com/example/soap/	SampleService01MessageReceiverInOut.java	用途不明。
src/com/example/soap/	SampleService01Skeleton.java	スケルトン本体。
src/com/example/soap/	Test01.java	パラメータが格納されるBeanクラスを格納するBeanクラス。メソッド名と同じになる。
src/com/example/soap/	Test01Response.java	戻り値を格納するBeanクラスを格納するBeanクラス。メソッド＋Responseという名前になる。
src/com/example/soap/xsd	ExtensionMapper.java	用途不明。
src/com/example/soap/xsd	RequestMessage.java	パラメータを格納するBeanクラス。
src/com/example/soap/xsd	ResponseMessage.java	戻り値を格納するBeanクラス。
resources/	SampleService01.wsdl	スケルトン生成に使用したWSDLファイル。内容はAutoGeneratesのWSDLと同一。
resources/	services.xml	Axis2が使用するサービスとJavaクラスを紐付けるための定義ファイル。
/	build.xml	生成したファイルをaarファイルにまとめるためのbuild.xmlファイル。wsdl2javaコマンドが生成する。

Stubsの定義ファイル
ファイル名	概要
wsdl2java.build.properties	WSDLファイルからクライアント側スタブのJavaソースファイルを生成するbuild.xmlのためのプロパティファイル。
wsdl2java.build.xml	WSDLファイルからクライアント側スタブのJavaソースファイルを生成するためのbuild.xmlファイル。

Stubsでツールによって生成されるファイル
ディレクトリ名	ファイル名	概要
src/com/example/soap/	SampleService01CallbackHandler.java	用途不明。
src/com/example/soap/	SampleService01SampleService01HttpEndpoint.java	インターフェース。
src/com/example/soap/	SampleService01SampleService01HttpEndpointStub.java	スタブクラス。サーバ側とRESTアーキテクチャで通信をする場合に使用する？
src/com/example/soap/	SampleService01SampleService01HttpSoap11Endpoint.java	インターフェース。
src/com/example/soap/	SampleService01SampleService01HttpSoap11EndpointStub.java	スタブクラス。サーバ側とSOAP 1.1で通信をする場合に使用する？
src/com/example/soap/	SampleService01SampleService01HttpSoap12Endpoint.java	インターフェース。
src/com/example/soap/	SampleService01SampleService01HttpSoap12EndpointStub.java	スタブクラス。サーバ側とSOAP 1.2で通信をする場合に使用する？
src/com/example/soap/	Test01.java	パラメータが格納されるBeanクラスを格納するBeanクラス。メソッド名と同じになる。
src/com/example/soap/	Test01Response.java	戻り値を格納するBeanクラスを格納するBeanクラス。メソッド＋Responseという名前になる。
src/com/example/soap/xsd	ExtensionMapper.java	用途不明。
src/com/example/soap/xsd	RequestMessage.java	パラメータを格納するBeanクラス。
src/com/example/soap/xsd	ResponseMessage.java	戻り値を格納するBeanクラス。

さて、今回はパッケージの階層が以下のような形になった。

com.example
- soap
  - xsd
- services
- client
- business

クライアント側はcom.example.client.SampleService01を使用し、サーバ側の実装はcom.example.business.SampleService01Implに実装を記述するようにしている。　しかし、クライアント側で使用するクラスのパッケージとサーバ側で実装を記述するパッケージは同じであるほうが望ましいと思われる。

なぜなら、サーバ側でcom.example.services.SampleService01を実装し、クライアント側でcom.example.services.SampleService01を使用している、もしくは使用しているように見えるほうが意味論として正しいだろう。

そこで、SampleService01をinterfaceとして、サーバ側とクライアント側それぞれの実装を個別に用意し、DIコンテナ等を使用して実行時に依存性の注入が行われるようにすることで、サーバ側ではサーバ側の実装クラスがロードされ、クライアント側ではクライアント側の実装クラスがロードされるようにしたほうが良いだろう。

com.example
- soap
  - xsd
- services
  - SampleService01
  - SampleService01ClientImpl
  - SampleService01ServerImpl

ちなみにcom.example.soap.SampleService01Skeletonクラスを継承してcom.example.services.SampleService01を作成していたが、SampleService01Skeletonは本当にスケルトンで中身はメソッドが一つ定義されているだけ、処理は何一つないクラスなので、別に継承する必要は無い。

そのため、com.example.soap.SampleService01クラスを新規に作成して、このクラスからcom.example.service.SampleService01を呼び出すようにし、services.xmlを修正してやれば十分だろう。　というわけで、ソース生成後に新規に作成する必要があるクラスは以下になるだろう。

com.example/
- soap/
  - xsd/
  - SampleService01Invoker.java
- services/
  - SampleService01.java
  - SampleService01ClientImpl.java
  - SampleService01ServerImpl.java
  - SampleService01Request.java
  - SampleService01Response.java

Eclipse + WTP + Axis2　その6

2009-10-17T14:23:00.000+09:00

とりあえず、以上でサーバ側とクライアント側が用意で来たので、実際に動かしてみよう。　まずはServiceAプロジェクトでサーバの起動を行う。　次にクライアント側だが、今はただの試験なのでJUnitのテストケースでも作成してクライアント側SampleService01#test()を実行してやる。　ちなみにエンドポイントはhttp://localhost:8080/ServiceA/services/SampleService01となる。

SampleService01#test()をコールしてやると、おそらくは「名前空間が違うぞ」というエラーになるはず。　これは最初にinterfaceからWSDLを作成した際に、インターフェースのパッケージがcom.example.soapだったので、WSDLでの名前空間が"http://soap.example.com"になっているのに、サーバ側でSampleService01を公開した際のパッケージがcom.example.servicesだったので、実際に公開されているサービスの名前空間が"http://services.example.com"になってしまっているからだ。

なので、WSDLからサーバ側スケルトンを作成した時に一緒に作成されたservices.xmlとSampleService01.wsdlをservicesディレクトリに配置してやる。

ServiceA/
- src/
- build/
- WebContent/
  - axis-web/
  - META-INF/
  - WEB-INF/
    - conf/
    - lib/
    - module/
    - services/
      - SampleService01/
        
        com/
        
        META-INF/
        
        SampleService01.wsdl
        
        services.xml
    - servces.list
    - version.aar

services.xmlはちゃんと上書きしてやること。　これで、サーバを再起動して、クライアントを起動すればちゃんとSOAPで通信が行われているはず。　なお、com.example.business.SampleService01Implで戻り値をちゃんと設定してやら無いとぬるぽとか出ちゃうので注意。

Eclipse + WTP + Axis2　その5

2009-10-17T14:20:00.000+09:00

さて、サーバ側はとりあえず形になったので、次はクライアント側を作成する。　こっちはサーバ側と異なり、それほど悩む必要も無い。　まずは、AutoGeneratesプロジェクトにあるWSDLファイルを元にしてクライアント側スタブを作成するためのプロジェクトを新規に作成してやる。

Stubs/
- src/
- JRE System Library/
- Referenced Libraries/

次にWSDLからクライアント側スタブを生成するためのbuild.xmlとbuild.propertiesを作成する。　内容はスケルトン作成時のbuild.xmlとほぼ同じだ。


<?xml version="1.0"?>
<project default="w2j.stub" basedir=".">
 <!-- 使用するプロパティファイルを設定する -->
 <property file="wsdl2java.build.properties"/>

 <!-- パスの設定 -->
 <property name="wsdl.uri"
  value="${eclipse.workspace.uri}/AutoGenerates/wsdls/${service.name}.wsdl"/>
 <property name="build.src" value="." />

 <!-- Axis2関連設定 -->
 <property name="axis2.lib" value="${axis2.home}/lib" />

 <!-- ライブラリパスの設定 -->
 <path id="lib">
  <fileset dir="${axis2.lib}">
   <include name="*.jar" />
  </fileset>
 </path>

 <!-- スタブコード出力 -->
 <target name="w2j.stub">
  <echo message="Target WSDL : ${wsdl.uri}"/>
  <java classname="org.apache.axis2.wsdl.WSDL2Java" dir="." fork="yes">
   <classpath>
    <path refid="lib"/>
   </classpath>
   <arg line="-uri ${wsdl.uri}" />
   <arg line="-u" />
   <arg line="-ap" />
   <arg line="-p" />
   <arg line="-d adb" />
   <arg line="-o ${build.src}" />
  </java>
 </target>
</project>


# Eclipse Workspace
eclipse.workspace=C:/home/bobo/development/java/nem
eclipse.workspace.uri=file:///C:/home/bobo/development/java/nem

# Axis2 Home
axis2.home=C:/Applications/apache-axis2-1.4.1

# Target Service
service.name=SampleService01

WSDL2Javaに渡すオプションが微妙に異なっているので、注意したい。

これで、antを実行するとsrc配下にクライアント側スタブのJavaソースファイルが、Stubプロジェクト直下にbuild.xmlが作成される。

Stubs/
- src/
  - com.example.soap/
    - SampleService01CallbackHandler.java
    - SampleService01SampleService01HttpEndpoint.java
    - SampleService01SampleService01HttpEndpointStub.java
    - SampleService01SampleService01HttpSoap11Endpoint.java
    - SampleService01SampleService01HttpSoap11EndpointStub.java
    - SampleService01SampleService01HttpSoap12Endpoint.java
    - SampleService01SampleService01HttpSoap12EndpointStub.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd/
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java
- JRE System Library/
- Referenced Libraries/
- build.xml
- wsdl2java.build.xml
- wsdl2java.build.properties

どうも、必要ないスタブまで作成されているようだけど、この辺はWSDL2Javaのオプションを精査すれば作成させないようにもできるだろう。　なので、今は気にしないことにする。

スタブはスケルトンとは異なり、*Stubクラスのインスタンスを生成してメソッドをコールしてやれば普通に使えるので、スケルトンほど考えることが無いんだが、クラス名が～Stubだったり、パラメータがTest01クラスに格納されていたり、戻り値がTest01Responseに格納されていたりするので、多少の整形は必要だろう。

というわけで、パラメータの取り出しやStubクラスの実行、戻り値の格納を行ってやるSampleService01Implクラスを作成することにする。

Stubs/
- src/
  - com.example.business/
    - SampleService01Request.java
    - SampleService01Response.java
  - com.example.client/
    - SampleService01.java
    - SampleService01Impl.java
  - com.example.soap/
    - SampleService01CallbackHandler.java
    - SampleService01SampleService01HttpEndpoint.java
    - SampleService01SampleService01HttpEndpointStub.java
    - SampleService01SampleService01HttpSoap11Endpoint.java
    - SampleService01SampleService01HttpSoap11EndpointStub.java
    - SampleService01SampleService01HttpSoap12Endpoint.java
    - SampleService01SampleService01HttpSoap12EndpointStub.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd/
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java

ちなみにSampleService01RequestとSampleService01Responseはスケルトン作成時に作成したものをそのままコピーしてきた。　サーバ側とクライアント側でパラメータと戻り値は同じ型の方が良いだろう。

というわけで、クライアント側は特に悩む必要も無く、これでおしまい。

Eclipse + WTP + Axis2　その4

2009-09-21T12:08:00.001+09:00

さて、aarファイルの作成だが、wsdl2javaコマンドがaarファイル作成のためのbuild.xmlをSkeletonsプロジェクトの直下に作成しているはずなので、それを使用する。

だが、その前にservices.xmlを修正する必要がある。　services.xmlを開いてみれば分かるが、name属性がServiceClassのparameter要素の内容がcom.example.soap.SampleService01Skeletonになっているので、com.example.service.SampleService01に変更する。

そして、build.xmlでantしてやればSkeletonsプロジェクトの直下にbuildというディレクトリが作成されて、aarファイルその他のファイルが作成される。

ここで、残念なお知らせが。　build/classes/配下にはaarファイルの中身に相当するファイルが配置されているんだが、ここにcom.example.services.SampleService01Implのclassファイルが配置されてしまっている。　業務の実装クラスまでaarファイルにまとめられてしまうわけにはいかないので、何とかしてやる必要がある。

というわけで、com.example.businessパッケージを別のプロジェクトに移動させることにした。

antしたら山ほどエラーが出た。　まぁ、com.example.businessパッケージがSkeletonsプロジェクトに無いから当然なんだが……。　この辺、どうにかならないかなあ。　どうにかなれば、チームBにはaarファイルだけ提供して「後はよろしく」といけるんだけどなあ。

とりあえず、今は諦めてツールで生成したソースと新規に作成したソースをServiceAプロジェクトにコピーすることにする。

Skeletons
- src/
  - com.example.business
    - SampleService01.java
    - SampleService01Impl.java
    - SampleService01Request.java
    - SampleService01Response.java
  - com.example.services
    - SampleService01.java
  - com.example.soap
    - SampleService01MessageReceiverInOut.java
    - SampleService01Skeleton.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java
- resources/
  - SampleService01.wsdl
  - services.xml
ServiceA
- src/
  - com.example.business
    - SampleService01.java
    - SampleService01Impl.java
    - SampleService01Request.java
    - SampleService01Response.java
  - com.example.services
    - SampleService01.java
  - com.example.soap
    - SampleService01MessageReceiverInOut.java
    - SampleService01Skeleton.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java
- build/
- WebContent/
  - axis2-web/
  - META-INF/
    - MANIFEST.MF
  - WEB-INF/
    - conf/
      - axis2.xml
    - lib/
    - modules/
    - services/
      - services.list
      - version.aar

これであらかたの準備が整ったわけだが、この状態でTomcatを起動しても残念ながらSampleService01は公開されない。　Webサービスとして公開するためにはWebContent/WEB-INF/services/配下にaarファイルを配置するか、classファイルとxmlファイルを格納したディレクトを配置する必要がある。

xmlファイルだけなら手作業で配置しても良いんだが、classファイルも配置しなくてはならないので、手間がかかる上に必要なclassファイルの選別等が面倒くさいので、Eclipseに頼ることにする。

サービスとして公開するJavaのソースファイル（この場合はcom.example.services.SampleService01）を右クリックして、[Web Service] -> [Create Web service]としてEclipseにやってもらう事にする。　これで、servicesディレクトリの配下にサービス名の付いたディレクトリが作成され、services.xmlとclassファイルが格納されているはずだ。

ServiceA
- src/
- build/
- WebContent/
  - axis2-web/
  - META-INF/
  - WEB-INF/
    - conf/
    - lib/
    - modules/
    - services/
      - SampleService01/
        
        com/
        
        META-INF/
        
        services.xml
      - services.list
      - version.aar

これで、Tomcatを起動してやれば、SampleService01が公開されているのが確認できる。　とりあえず、ブラウザからhttp://localhost:8080/ServiceA/axis2-web/index.jspにアクセスしてServicesリンクをクリックしてSampleService01が見えていれば良しとしよう。

さて、次はクライアント側のJavaソースの生成に行こう。

Eclipse + WTP + Axis2　その4

2009-09-21T12:05:00.000+09:00

さて、とりあえず、スケルトンは生成されたわけだが、このままチームBにポイするのはあんまりなので、整形してやることにする。　整形の基本方針としては大まかに以下の二種類が考えられる。

SampleService01Skeletonクラスを直接整形する。
SampleService01Skeletonクラス自体には手を入れない。

SampleService01Skeletonクラスを直接整形するとAPIに変更が入ってスケルトンを再生成するたびに実装を書いてやる必要があるので、馬鹿馬鹿しい。　ここはツールで生成されるソースには手を入れないほうが良いだろう。

というわけで、スケルトンクラスを継承したクラスを作成してパラメータの取り出しや戻り値の格納等を実装してやることにする。

java.lang.Object
- com.examle.soap.SampleService01Skeleton
  - com.example.service.SampleService01

SampleService01SkeletonとSampleService01でパッケージが異なるのには理由がある。　将来的にプロトコルがSOAPからCORBAになったり（今更これはないか）、RESTになったり（これはありそう）した場合、SampleService01のスーパークラスを変更してやるだけで対応可能にするためだ。

そして、ここでも道は二つに分かれる。　業務ロジックを実装するチームBはこのSampleService01をどう扱うべきかということだ。　この時点でSampleService01にはパラメータの取り出しや戻り値の格納がチームCによって実装されている。　そのソースファイルを直接チームBに渡して「後はよろしく」とやるのはやっぱり不細工だ。　チームBにとって本質的ではないようなコードが記述されているのは迷惑だろうし、下手に弄られても困る。

ではどうするか。　SampleService01を継承したクラスを作成し、それをチームBに渡すか、SampleService01から業務ロジックを記述したクラスを呼び出してやるかの二択になるだろう。

SampleService01を継承したクラスを作成した場合、一つ問題がある。　それは、たとえばSampleService01LogicとSampleService02Logicで共通の処理があった場合、AbstractSampleService等というクラスを作ってスーパークラスとして実装したいだろう。　しかし、SampleService01を継承したクラスに実装を記述してもらう方法だとこういう柔軟な対応ができなくなる。

というわけで、柔軟に対応可能になるのはSampleService01から業務ロジックが記述されたクラスを呼び出す方式になるだろう。　また、DIコンテナ等を使用して業務ロジックが記述されたクラスをロードするようにすれば、未実装時やテスト中は業務クラスのスタブに切り替えてやることもできる。　ついでなので、引数と戻り値になるbeanもcom.example.businessパッケージ配下に作成して、詰め替えてやる。

java.lang.Object
- com.examle.soap.SampleService01Skeleton
  - com.example.service.SampleService01
- com.example.business.SampleService01
- com.example.business.SampleService01Impl
- com.example.business.SampleService01Request
- com.example.business.SampleService01Response

これで、com.example.business配下をチームBに渡して「後はよろしく」と言っても不細工なことにはならないと思われる。

AutoGenerates/
- src/
- JRE System Library/
- wsdls/
Skeletons/
- src/
  - com.example.business/
    - SampleService01.java
    - SampleService01Impl.java
    - SampleService01Request.java
    - SampleService01Response.java
  - com.example.service/
    - SampleService01.java
  - com.example.soap/
    - SampleService01MessageReceiverInOut.java
    - SampleService01Skeleton.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd/
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java
- JRE System Library/
- Referenced Libraries/
- resources/
  - SampleService01.wsdl
  - services.xml
- build.xml
- wsdl2java.build.properties
- wsdl2java.build.xml

さて、ようやく、aarファイルの作成にいけるが、それは次回。

Eclipse + WTP + Axis2　その3

2009-09-21T12:02:00.000+09:00

さて、WSDLファイルが作成されたので、次はスケルトンを作成してみよう。　そのためにはまず、スケルトンを作成するためのプロジェクトを作成してやる。　AutoGeneratesプロジェクト内でスケルトンを生成しても良いのだが、スケルトンとスタブで生成されるソースが被るので、スケルトンを生成するためのプロジェクトを新規に作成することにする。

AutoGenerates/
- src/
- JRE System Library/
- wsdls/
Skeletons/
- src/
- JRE System Library/
- Referenced Libraries/

次にAutoGeneratesプロジェクトにあるWSDLファイルを使用してJavaソースファイルを作成するためのbuild.xmlとbuild.propertiesを作成する。


<?xml version="1.0"?>
<project default="w2j.skeleton" basedir=".">
 <property file="wsdl2java.build.properties"/>

 <!-- パスの設定 -->
 <property name="wsdl.uri"
  value="${eclipse.workspace.uri}/AutoGenerates/wsdls/${service.name}.wsdl"/>
 <property name="build.src" value="." />

 <!-- Axis2関連設定 -->
 <property name="axis2.lib" value="${axis2.home}/lib" />

 <!-- ライブラリパスの設定 -->
 <path id="lib">
  <fileset dir="${axis2.lib}">
   <include name="*.jar" />
  </fileset>
 </path>

 <!-- スケルトンコード出力 -->
 <target name="w2j.skeleton">
  <echo message="Target WSDL : ${wsdl.uri}"/>
  <java classname="org.apache.axis2.wsdl.WSDL2Java" dir="." fork="yes">
   <classpath>
    <path refid="lib"/>
   </classpath>
   <arg line="-uri ${wsdl.uri}" />
   <arg line="-ss" />
   <arg line="-sd" />
   <arg line="-ap" />
   <arg line="-d adb" />
   <arg line="-o ${build.src}" />
  </java>
 </target>
</project>


# Eclipse Workspace
eclipse.workspace=C:/home/bobo/development/java/nem
eclipse.workspace.uri=file:///C:/home/bobo/development/java/nem

# Axis2 Home
axis2.home=C:/Applications/apache-axis2-1.4.1

# Target Service
service.name=SampleService01

build.propertiesにワークスペースのパスがフルパスで記述されてるのが、ダサい、超ダサいんだが、wsdl2javaにWSDLの場所を教えてやる際にURIで渡す必要があるので、しょうがなく……。　eclipse.convertPathを使用すればresourcePath属性を使用してプロジェクトの絶対パスを取得できるんだが、file.pathが“\”になっちゃうので、使用できず……。　この辺、そろそろファイルシステムに直結したパスの記述は根絶させて全てURIで記述するようにならないものかなあ。　相対パスの記述方法がなくなるかもしれないけど。

なにはともあれ、これで、src配下にJavaソースが、resources配下にWSDLとservices.xmlが、そしてSkeletonsプロジェクト直下にbuild.xmlが作成される。

AutoGenerates/
- src/
- JRE System Library/
- wsdls/
Skeletons/
- src/
  - com.example.soap/
    - SampleService01MessageReceiverInOut.java
    - SampleService01Skeleton.java
    - Test01.java
    - Test01Response.java
  - com.example.soap.xsd/
    - ExtensionMapper.java
    - RequestMessage.java
    - ResponseMessage.java
- JRE System Library/
- Referenced Libraries/
- resources/
  - SampleService01.wsdl
  - services.xml
- build.xml
- wsdl2java.build.properties
- wsdl2java.build.xml

Skeletonプロジェクト直下に生成されたbuild.xmlは生成されたJavaソースファイルをコンパイルしてaarファイルを生成するためのものなので、とりあえずおいておく。

さて、これで、あらかた必要なJavaソースとxmlが生成されたわけだが、この状態でチームBに渡して「後はよろしく」とやっちゃうのはあんまりだ。　なんせ、業務ロジックを実装する対象となるクラスはSampleService01Skeletonなんて名前だし、APIのパラメータであるRequestMessageはTest01#localParam0に格納されていてTest01#getParam0()で取得しなきゃならんし、戻り値となるResponseMessageはTest01Response#set_return(ResponseMessage)を使用してTest01Response#local_returnに格納してやらなきゃならん。　そこら辺はチームCが隠蔽してやるのが筋だろう。

というわけで次回に続く。

Eclipse + WTP + Axis2　その2

2009-09-21T11:59:00.000+09:00

さて、プロジェクト分けができたので、それで上手くいくか試してみよう。

まずはAutoGeneratesプロジェクトを作成する。　これは普通のJavaプロジェクトで良いだろう。

AutoGenerates/
- src/
- JRE System Library/

次はsrc/配下にinterfaceを作成する。　今は定義書とかないので、手で書いちゃう。　以下のようなしょっぱいので十分だろう。


package com.example.soap;

public interface SampleService01
{
 public ResponseMessage test01(RequestMessage requestMessage);
}


package com.example.soap;

public interface RequestMessage
{
 public void setParamInt(int a);
 public int getParamInt();
 public void setParamBool(boolean b);
 public boolean getParamBool();
 public void setParamString(String c);
 public String getParamString();
}


package com.example.soap;

public interface ResponseMessage
{
 public void setParamInt(int a);
 public int getParamInt();
 public void setParamBool(boolean b);
 public boolean getParamBool();
 public void setParamString(String c);
 public String getParamString();
}

AutoGenerates/
- src/
  - com.examle.soap/
    - RequestMessage.java
    - ResponseMessage.java
    - SampleService01.java
- JRE System Library/

次に、これらのinterfaceからWSDLを作成するためのbuild.xmlを作成する。　ついでに、build.propertiesも作ってやる。


<?xml version="1.0" encoding="UTF-8"?>
<project default="j2w" basedir=".">
 <!-- 使用するプロパティファイルを設定する -->
 <property file="java2wsdl.build.properties"/>

 <!-- パスの設定 -->
 <property name="path.src" value="./src" />
 <property name="path.bin" value="./bin" />
 <property name="path.wsdl" value="./wsdls" />

 <!-- タスク定義：Axis2-Java2WSDL -->
 <taskdef name="axis2-java2wsdl"
  classname="org.apache.axis2.tool.ant.Java2WSDLTask">
  <classpath>
   <fileset dir="${axis2.home}/lib" includes="**/*.jar"/>
  </classpath>
 </taskdef>

 <!-- WSDL出力 -->
 <target name="j2w" description="Java2WSDLを実行します。">
  <echo message="Target Class : ${service.class}"/>
  <axis2-java2wsdl
   classname="${service.class}"
   outputfilename="${path.wsdl}/${service.name}.wsdl">
   <classpath>
    <pathelement location="${path.bin}" />
   </classpath>
  </axis2-java2wsdl>
 </target>
</project>


# Axis2 Home
axis2.home=C:/Applications/apache-axis2-1.4.1

# Target Service
service.class=com.example.soap.SampleService01
service.name=SampleService01

ちなみに、org.apache.ws.java2wsdl.Java2WSDLではなく、org.apache.axis2.tool.ant.Java2WSDLTaskを使用してやらないとEPRが作れないよとかいうエラーが出ちゃう。　理由は不明。　なお、axis2-java2wsdl要素にはlocationuriやservicename等の属性を指定できる。　この辺はJava2WSDLTaskのAPIリファレンス見れば分かるだろうし、java2wsdlコマンドの引数と対応してるだけだろうから後でちゃんと調べることにする。

また、作成されるWSDLファイルを格納するためのディレクトリもついでに作ってやる。　これで、antを実行してやればwsdlsディレクトリにWSDLファイルが作成されるはずだ。

AutoGenerates/
- src/
  - com.examle.soap/
    - RequestMessage.java
    - ResponseMessage.java
    - SampleService01.java
- JRE System Library/
- wsdls/
  - SampleService01.wsdl
- java2wsdl.build.properties
- java2wsdl.build.xml

さて、これで、「ねんがんのWSDLをてにいれた」ので、次はスケルトンとスタブを作成してやる。

Eclipse + WTP + Axis2　その1

2009-09-21T11:53:00.000+09:00

さて、次のお仕事はSOAPだそうで。　どういうスタイルと手順で開発するのが良いのか良くわからないので、連休中に色々と考えてみようと思う。

前提条件として、次のプロジェクトは以下のような構成になるらしい。

サーバは二台（サーバA、サーバB）
クライアントマシンからはサーバAに接続
サーバAはSOAPでサーバBのAPIを呼び出す

きわめてオーソドックスな構成だと思う。　そして、プロジェクトのチーム分けとしては以下の三つに分けられるそうだ。

サーバAのビジネスロジック実装（チームA）
サーバBのビジネスロジック実装（チームB）
サーバAとサーバBでのSOAP通信を実装（チームC）

二チームでええやんとも思うんだが、チームCが作られちゃうらしい。　チームBがWSDL作ってチームAに渡してやれば良いと思うんだがなあ。　そのほうがチームBとしては柔軟に開発できるような気がするだよな。

でもまあ、チームCに配属されちゃうそうなので、致し方なし。　チームCでスケルトンとスタブとWSDL作って両チームに提供することになる。

そこで、どのような手順でスケルトンとスタブとWSDLを作成するかを考えてみた結果、以下のような流れが妥当だろうと判断した。　本当はもっと良いやり方があるのかもしれないが、今のところこれが妥当だろう。

Excelで作成したSOAPインターフェース定義書からJavaのinterfaceクラスを作成する（ついでにコンパイルも行う）。
コンパイル済みのinterfaceクラスを元にAxis2のjava2wsdlでWSDLファイルを作成する。
WSDLファイルを元にAxis2のwsdl2javaでサーバ側スケルトンを作成する。
WSDLファイルを元にAxis2のwsdl2javaでクライアント側スタブを作成する。
最初に作ったinterfaceクラスは破棄する。

すでに実装されたクラスを元にWSDLを作って、クライアント側スタブを作ったり、最初にWSDLを作成してスケルトンとスタブを作ったりせず、interfaceクラスからWSDLを作る理由は、そうする事でWSDLの記述の揺らぎを抑えて統一感を持たせるためだ。　また、定義書のマクロでinterfaceクラスを作成するのも揺らぎを抑えて統一感を持たせる助けになるだろうと思う。

この流れは結構普通なんじゃないだろうか。　最後にinterfaceクラスを破棄するかどうかはスケルトンとスタブの実装によるだろうけど。

次にEclipseのプロジェクトをどう分けるかについてたが。　interfaceクラスの作成後はEclipse上で実施できるほうが便利だろうと思うので、プロジェクトは大まかに二つに分けられるだろう。

AutoGenerates（Javaプロジェクト）: interfaceクラスを配置して、build.xml等でWSDLを作成する。　基本的にテンポラリとして使用し、WSDLの作成が終わったら不要なファイルは削除する。
Skeletons（Javaプロジェクト）: WSDLからサーバ側スケルトンを作成する。　基本的にテンポラリとして使用し、Javaソースの作成が終わったら不要なファイルは削除する。
Stubs（Javaプロジェクト）: WSDLからクライアント側スタブを作成する。　基本的にテンポラリとして使用し、Javaソースの作成が終わったら不要なファイルは削除する。
ServiceA（動的Webプロジェクト）: サーバAの実装。
ServiceB（動的Webプロジェクト）: サーバBの実装。　AutoGeneratesプロジェクトからコピーされたスケルトンにビジネスロジックを実装する。

これも普通なやり方なんじゃないかなあ。

Pit

2009-09-06T19:44:00.000+09:00

snakaさんのブログの簡易クライアントが何度やっても動かず、twitter.comは延々とレスポンスコード401を返し続けたので、はまった箇所のメモを残しておくことにする。

そもそも、Pitってモジュールがなんなのか分かってなかった。

例によって例のごとく、「ユーザ名とパスワードは自分の物に書き換えて実行してね（はぁと」なサンプルコードだとばかり思ってたら、全然違うでやんの。　puts config["username"]とかやって、設定したはずのユーザ名とパスワードが出力されないのを確認してやっと、なんかおかしいと気付いた。

「アカウント情報を管理するコマンド pit」を読んでやっと理解した。

$EDITORが起動しねえ

で、pitは当該情報が設定ファイルにない場合はエディタを起動して入力させるようになってるんだけど、ここでエディタが起動しねえの。　原因は複合的なものでDOS形式なファイルパスで無いと受け付けてくれないらしいことと、環境変数の値を"で括っちゃイカンということ。

拡張子関連付けを手作業で行うときの癖で、パスに半角スペースが含まれる時は"で括っちゃってたんだが、これがいけなかったらしい。　SET EDITOR="c:\progra~1\gvim\vim.exe"等とやると動きませんでした。

というわけで、大変恥ずかしいはまり方をしていたので、公開して羞恥プレイしてみる。

Growl for Windows

2009-09-06T19:41:00.000+09:00

Macユーザにはおなじみかもしれないが、アプリケーションからの通知を一手に引き受けてユーザに通知する「Growl」なるアプリがMac OSには存在する。　で、これのWindows版クローンとして「Growl for Windows」をインストールしてみた。

元々何がしたかったかというと、Twitterのタイムラインを通知して欲しかったわけだ。　プアなPCで作業をしている時にTwitterのために常にブラウザを立ち上げておきたくない、かといって常駐するクライアントも入れたくない。　極力PCに負荷を掛けないアプリがないものかと思って探していた時にGrowlに出くわした。

これを使って、タイムライン取得してGrowlに投げたら即座に終了するようなアプリと組み合わせればPCへの負荷を極力減らせるんじゃないかと思った。

そこで、早速インストールしてsnakaさんのブログで公開されている簡易クライアントで試してみたところいい感じに動いたので、「おおぉ、動いた動いた」とキャッキャと喜んでいて、はたと気付く。　こいつを定期的に起動してタイムライン取得するようにならないと駄目でしょ、と。

Growlそのものにはアプリケーションをスケジューリングする機能はない（Growl自身が持ってても良いような気はするけど）。　Windows 2000ではスケジューラーがOS標準であったよね？　と思ってXPで探してみたんだけど、ねえでやんの。

一応、似たような機能としてタスクってのがあるんだけど、こいつは30分おきに実行するとかいう設定はできないようだ。

というわけで、思惑は外れちゃったので、次はWindows版cronでも探してくるかな。　atコマンドなるものもあるらしいけど、ATコマンドってモデム制御するためのコマンドじゃなかったっけ？

新東京タワーの名称募集

2008-03-20T21:29:00.001+09:00

さて、すっげえ久しぶりにエントリを書くわけだが、特に技術的なお話というわけではない。

東京の墨田区に完成予定の新東京タワーについて、その名称が学識者らによって六つの案に絞られた。そして、四月一日からの投票で正式に決定されるらしい。

その六つの案というのが以下のものなんだけど……

東京EDOタワー
東京スカイツリー
みらいタワー
ゆめみやぐら
ライジングイーストタワー
ライジングタワー

はっきり言って、どれもこれもダサいと思う。

普通に「新東京タワー」とか「第二東京タワー」とかで良いと思うんだけどねえ。

と、ここまで思って、気が付いた。「新東京タワー」って名称は、三つ目のタワーが出来た時に困っちゃうよな。「墨田タワー」ってのも墨田区にもう一個電波塔が作られたら困っちゃうよな。

というわけで、この問題、実は「クールなURLにするためには」ってのと同じ問題を孕んでるんじゃないだろうか？

Mozilla Sunbird使ってみた

2008-01-19T18:25:00.000+09:00

さて、RESTネタは考える時間が必要なので、軽いネタで。

特にたいした予定はないんだけど、書籍の発売日やCDの発売日やゲームの発売日を記録して管理するためにPIMアプリを探しててたどり着いたのがMozillaのSunbird。一週間ほど使ってみたので、気になった点を書いてみる。

まず、この手のスケジューラーで日付ではなくもっと大雑把な単位で予定を入力できるツールを見たことがないんだけど、誰も不満に思わないのだろうか。たとえば「2008年春　ライブ開催予定」とかいう形で発表された場合、どうやってスケジューラに登録するんだ？とりあえず4月1日の予定として登録しておいて、正確な日付が発表されたら修正するとかいう使い方をしてるの？そういう使い方すると、「本当に4月1日の予定」なのか「日付が確定していないので4月1日に仮登録している予定」なのか見分けがつかなくならないかなあ？

日付が確定していない予定に対して、大雑把な「時期」だけで、登録しておき、正確な日付が確定するまでは別管理できるような仕組みがスケジューラーには必要なんじゃないかなあ。

次に、イベントとタスクしか登録できないことについて。そういう使い方は想定してないとか言われそうだが、せっかくカレンダーが付いてるんだからそれぞれの日付にメモを残せる仕組みがあってもいいんじゃないの？イベントでもタスクでもなく、メモ。そのメモのカテゴリを健康としてその日の体重とBMI値を登録するとかいう使い方もできるようになる。

カレンダーに対してメモを貼れるようになるだけで、使い道が格段に増えることになると思うが、どうだろうか？

もう、すでにAdd-ons等で実現されているかもしれないけどね。

あけましておめでとうございます

2008-01-12T14:19:00.000+09:00

いまさらですが、あけましておめでとうございます。

今年から作業場所が変わり、今までのような暇な状態ではなくなったので、しばらくは更新頻度は激減するだろうと思います。

また、年末にRESTについて何本かエントリをアップしましたが、これの続きにいつ取り掛かれるかわかりません。気長にお待ちください。「RESTful Webサービス」を買って通勤時間中に読んでるので、その感想等は書くかもしれませんが。

それでは、今年もよろしくお願いします。

Bloglines BETA が生き返った

2007-12-21T11:35:00.000+09:00

そして、一部が日本語になってる。　のは良いんだけど、ピンのところにある「暗証番号」ってなんだ？

あと、トップページは前のほうがシンプルでよかったと思うぞ。

Bloglines BETA が死んでいる

2007-12-19T15:45:00.000+09:00

おそらくは18日くらいからBloglines BETAが500を戻している。

旧バージョンは生きてるので、一応、使えるんだけど、どうなっているんだろう。　機能追加したよってニュースが流れているので、普通に使える人もいるみたいなのが、よくわからない。

それにしてもさっぱり話題にならないあたり、諸行無常よのう。

実際に設計してみようその3

2007-12-13T15:10:00.000+09:00

さて、前回で、RESTというスタイルで考えた場合、既存のシステムとは異なるURL体系になることがわかった。

これは何もおかしなことではなく、既存のwebアプリではアプリケーション（というよりもインターフェースか？）が前面に出ており、実際に操作したいリソースはDBという形で見えなくなっており、RESTではそれを覆して、リソースを前面に押し出し、アプリケーション（インターフェース）をプロトコルの中に格納したからだろう。

というわけで、URLについてもう少し考えてみることにする。　まずは先送りにした検索について考えてみようと思う。

会議室予約システムを考えた場合、検索したいのは「空いている会議室」だけだろう。　そこで、空いている会議室を検索する方法（URL）についてのみ考えてみる。

まず、既存のシステムだとどのようになるだろうか？　多分こんな感じになるんじゃないだろうか？


http://intranet.example.co.jp/meetingroomreserve/search.php?unreserve=true

これをRESTなスタイルで考え直してみた場合、こんな感じになるんじゃないかな？


http://intranet.example.co.jp/meetingroom/?unresereve=true

これは会議室というリソースの集合に対して「空いている会議室」という問い合わせを行っている事になる。　要件が「空いている会議室の検索」なので、問い合わせをすること自体は問題ないのだろうが、実際に行いたいことは「検索」という動作ではなく、「空いている会議室」というリソース、もしくはその集合の取得なのだ。　検索という要求に引きずられて、何のために検索するのかを見失うとここが見えてこなくなる。　というか、見えなかったために躓いたり迷子になったりしたのだ。

では、上記のURLは「空いている会議室」のリソースとして適当だろうか？　おそらくは否だろう。　なんせ、問い合わせを行っている。　「空いている会議室」のリソースを取得したいのであれば、「空いている会議室」のリソースの識別子をもって取得してやればいい、こんな感じになるだろう


http://intranet.example.co.jp/meetingroom/unreserve

これなら会議室というリソースの集合の中の「開いている会議室」というリソースの集合を表す識別子としては適当だろう。　また、各階の会議室のリソースの集合に対しても「各階の空いている会議室」というリソースを表すことができる。　こんな感じだろう。


http://intranet.example.co.jp/meetingroom/8F/unreserve
http://intranet.example.co.jp/meetingroom/9F/unreserve
http://intranet.example.co.jp/meetingroom/10F/unreserve

ということで、RESTというのはどこまでもリソースが主体なのだ。　なので、RESTなスタイルでサービスを構築する際、設計の最初で行うことは、「どのようなURL（識別子）にするのか？」を決めることになるのではないだろうか？　今までのように必要に応じて問い合わせ文字列（パラメータ）を増減させていてはどこかで破綻することになるような気がする。

やらかしちゃった勘違い

2007-12-06T17:07:00.000+09:00

さて、以下のコードがどのような出力結果になると思いますか？

#include <stdio.h>

#define DEF_STRING01 "hoe /* hoge */ moge"
#define DEF_STRING02 "hoe %s hoge %s moge"

int main(int argc, char* argv[])
{
  fprintf(stdout, DEF_STRING01);
  fprintf(stdout, "\n");
  fprintf(stdout, DEF_STRING02, "/*", "*/");
  fprintf(stdout, "\n");

 return 0;
}

結果は普通に以下のようになる。

hoe /* hoge */ moge
hoe /* hoge */ moge

コメントになるのかと思ったよ……orz

map.resourcesすげえ

2007-12-04T23:03:00.000+09:00

Rubyさわった事ないけど、map.resourcesってすげえ。

http://localhost:3000/api/divisions/1/employees/2というURLをControllerクラスにマッピングできちゃうらしい。　Ruby on Railsって凄くね？

だけど、これってdivision=1、employees=2が.../api/divisions/1/employees/2にマッピングされるってことはRoR的には.../api/1/2というURLは考慮してないってことか？

ブログ等でよくあるexample.co.jp/entry/2007/12/04/1とかいうURLをマッピングする時はどうやるんだろう？　.../entry/year/2007/month/12/day/04/post/1とかいうURLにしなくちゃ駄目なんだろうか？　そんなわけないよね？

ということで、Rubyのお勉強を始めてみることにした。　スクリプト言語はBシェル以外さわった事ないので、前途多難なんだけど楽しそうではある。

参考リンク

「たのしいRuby」なる本を買ってみた。　今のRubyってCygwinなくても使えるの？

GoogleとSNS

2007-12-03T23:22:00.000+09:00

facebookしかり、mixiしかり、最近はSNSが花盛りである。

SNSはインターネットというインフラの上に、アカウントを持っていないとアクセスすることができない、もうひとつのネットワークを構築しているといえる。　いわば、VPNのようなものだ。

当然、SNSで公開された情報は、そのSNSのアカウントを保有していないと取得することができない。

それがどういうことかというと、SNSで公開された情報はGoogleにインデックスされないということだ。

いや、それが利点でしょ？　不特定多数の人に見せたく無いからSNS内に引きこもるんだし。　と利用者からは言われそうだが、Googleにとってはそれでいいのだろうか？　SNSがこのまま普及し、SNS内で情報が完結してSNS内で閉じてしまうような状況が発生したらどうなるだろうか？

たとえば、新聞社がSNS内でのみニュースを配信するようになったら？　amazonがSNS内でのみ店舗を構えるようになったら？　今はまだ、顧客の大部分を切り捨てることになるため、そのようなサービスは存在していない。　しかし、すでにmixi内でのみ公開されているコンテンツは存在する（ドラマだったっけ？[※1]）。　今はインターネット上で広く公開されているこれらの情報がSNS内に引っ込んでしまったとき、Googleの検索エンジンではこれらの情報にたどり着けなくなってしまう。

それは検索エンジン最大手としてのGoogleの支配力を消滅させてしまうことになるのではないだろうか？

先月の初めにGoogleからOpenSocialというAPIセットが公開されたが、これがそんな状況へのGoogleの対応策なのだろうか？　と思ったらどうも違うっぽい。　どうも、GoogleはコンテンツがSNS内で完全に閉じてしまうことは無いと考えているようだ。　本当にそれで大丈夫だろうか？

というわけで、出版社の人はmixi内部で新刊の最初の数ページだけ公開してみたり、いっそのこと長編の一巻目だけを公開してみてはどうだろうか？　また、新聞社の人はmixi内部で記事を公開しコメントを付けられるようにしてみてはどうだろうか？　インターネット上で公開してコメントを付けられるようにするよりも荒らしには対処しやすいと思うんだが。

そしてそういう状況を推し進めたとき、Googleがどういう手段を講じてくるか興味がある。

※1: コンテンツの内容をインデックスすることのできない動画情報なので無視することにする。

実際に設計してみようその2

2007-12-03T22:24:00.000+09:00

今回は、会議室という物理的なリソースをネットワーク上でどのように表現するか考えてみようと思う。とりあえず、会議室は以下のようになっているとする。

階数	部屋番号
8F	0801
9F	0901	0902
10F	1001	1002	1003

ここからわかることは以下のとおりだといえると思う。

会議室というリソースは六つある。
8Fの会議室というリソースの集合には0801という一つの会議室が含まれる。
9Fの会議室というリソースの集合には0901、0902という二つの会議室が含まれる。
10Fの会議室というリソースの集合には1001、1002、1003という三つの会議室が含まれる。

つまり、会議室というリソースは以下のような階層構造をしているといえる。

会議室
- 8F
  - 0801
- 9F
  - 0901
  - 0902
- 10F
  - 1001
  - 1002
  - 1003

ということは、これをそのままURLに置き換えてやれば、とりあえずは大丈夫だろう。

intranet.example.co.jp/meetingroom/
- 8F/
  - 0801
- 9F/
  - 0901
  - 0902
- 10F/
  - 1001
  - 1002
  - 1003

実際にアクセスする際のURLは以下のようになるだろう。

http://intranet.example.co.jp/meetingroom/
http://intranet.example.co.jp/meetingroom/8F/0801
http://intranet.example.co.jp/meetingroom/9F/0901
http://intranet.example.co.jp/meetingroom/9F/0902
http://intranet.example.co.jp/meetingroom/10F/1001
http://intranet.example.co.jp/meetingroom/10F/1002
http://intranet.example.co.jp/meetingroom/10F/1003

これで、リソースおよびリソースの状態を操作するための識別子（URI）は作成することができた。　しかし、このままではこのリソースの「いつの時点」の状態なのか不明だ。　まあ、常識的に考えれば「現時点での状態」ということになるのだろう。

というところで、前回示した既存のシステムでのURLと比較するとずいぶん違うことがわかる。　わかったところで、今日はここまで。

JavaScriptでオレオレ言語

2007-11-25T15:52:00.000+09:00

JavaScript界隈が面白いことになってる。

ECMAScript4に対して、「Webの世界には新しい言語が必要である！」と言う人もいますが、そうではない、オレオレ言語を作れと！！（笑）

ECMAScriptは使うための言語じゃないんです。プログラミング言語を作るための言語なんです。
OreScript時代の幕開け

すげぇ。　別の言語で書いた処理をパースしてJavaScriptに翻訳して実行しちゃおう、とかとんでもないこと考えてるなあ。

ドキュメントをXMLで記述してXSLT使ってHTMLやTEXTに変換して出力するってのと根っこの部分でつながる話のような気がするなあ。　生データはみんなオレオレ言語やオレオレマークアップで記述しておいて、クライアント側で変換しなさいね、変換する方法は別途教えてやるから。　という方向に進めば時代に合わせて生データを加工しなくても、変換する方法だけを時代に合わせて変えていけばいいことになる。

まあ、みんなオレオレになると破綻するかもしれないけど。

で、そうなるとオレオレ言語のMIMEタイプとかどうするの？　という話になるけど、こんな感じらしい。

オレオレ言語の MIME タイプは application/x-script-name という形がお勧め。

IANA に登録するなら、私的ツリーかベンダツリーが簡単。

Active Script エンジンを提供するなら、text タイプの使用もやむをえない。ただし、IANA に登録するなら application タイプも忘れずに。

オレオレ言語の MIME タイプ

へえ、vnd.は知ってたけど、prs.なんてのもあるんだ。　vnd.ツリーはともかくprs.ツリーでもレビュー受けたほうが良いんだ。　つか、どんな観点でレビューするんだ？

それにしてもIEの下記のような仕様はおかしくないか？　なんでそんなことになってるんだ？

IE が script 要素を処理するとき、まずは type 属性を見ます。type 属性の値が text/script-name だった場合、IE は Windows レジストリの HKEY_CLASSES_ROOT\script-name を探し、そこに Active Script エンジン (ActiveX スクリプティングインターフェースを実装するスクリプトエンジン) が登録されていれば、そのエンジンを用いてソースコードを実行します。application/script-name だった場合は何も実行しません。
オレオレ言語の MIME タイプ

トップレベルタイプがapplicationのときこそエンジンに食わせるべきやん。　IE7やVistaでもこうなのかなあ。　FirefoxやOperaはどうやってんだろう。　それもちょっと気になるな。

実際に設計してみようその1

2007-11-21T16:44:00.000+09:00

さて、前回まででとりあえず、大枠は理解したということにしておこう。　これ以上は実際に設計しながら考えていくしかないだろう。

さて、私自身は職業プログラマなので、RESTというスタイルが仕事で使えるかどうかが大事だ。　これが、まったくもって向いてません、じゃあ困る。

というわけで、イントラネット上で公開する小規模な業務アプリを考えてみることにする。　で、考えてみた結果、「会議室予約システム」とかどうよ？

前回までで、「RESTとはリソースおよびリソースの集合への操作であると見つけたり」というところに落ち着いた。　ということは、物理的なリソースへの操作のほうがRESTとの相性が良いんじゃないだろか？　で、考えてみた結果が、「会議室というリソース」への「予約」という操作だ。　まったく、新鮮味がないあたりが時代遅れで浦島太郎な私らしいが、それはおいといてほしい。

今までのスタイルに従って会議室予約システムを構築すると、以下のような「会議室予約システムのURL」にブラウザで接続することになるだろう。

http://intranet.example.co.jp/meetingroomreserve/index.php

そして、実際に予約するときは以下のようなURLに対してPOSTで必要な情報（会議室の部屋番号、予約する時間帯、予約者の連絡先等）を送信することになるだろう。

http://intranet.example.co.jp/meetingroomreserve/reserve.php

で、現在の予約状況を確認する場合は、以下のようになるだろう。　そして、この場合も確認する会議室の部屋番号等はPOSTを使用して送信するだろう。

http://intranet.example.co.jp/meetingroomreserve/view.php

これをRESTとというスタイルにしたがって構築するとどうなるか考えてみよう。　だが、その前に、会議室という物理的なリソースについて、もう少し詳細を仮決めしておこう。

会議室はビル内に複数あることとする。
会議室は各フロアに複数あることもある。
会議室のないフロアもあることとする。

このようなかたちで存在する会議室というリソースに対して、以下の操作が行えれば、おおむね満足だろう。

会議室の予約状況を確認する。
会議室を予約する。
予約を解除する。
会議室を増やす。
会議室を減らす。

行いたい操作が決まれば、次は、これらの操作がHTTPのどのメソッドに該当するかを考えてみよう。

会議室の予約状況を確認する。: これは、もう、会議室というリソースの「ある時点での状態」の「取得」だから、GETで決まりだろう。
会議室を予約する。: 会議室というリソースの「ある時点での状態」を「空き」から「予約」に「変更」する操作なので、PUTで良いだろう。
予約を解除する。: 会議室というリソースの「ある時点での状態」を「予約」から「空き」に「変更」する操作なので、PUTで良いだろう。
会議室を増やす。: 会議室というリソースを追加する操作なので、POSTだろう。
会議室を減らす。: 会議室というリソースの削除なので、DELETEだろう。

並べてみて、会議室の増減ってめったに無いやんと思ったんだが、気にしないでおこう。　とにもかくにも、これで、HTTPのメソッドを使用してRESTなスタイルで「会議室予約システム」は構築できそうだ^（※1）。

というところで、今日はここまで。　次回は会議室という物理的なリソースをどのようにネットワーク上に展開するかを考えてみようと思う。

※1: 「空いている会議室を検索する」という操作については意図的に省いてみた。　検索についてはいまだに不安だ。

RESTの入り口で迷子になる

2007-11-16T22:39:00.000+09:00

RESTの入り口で溺れるにおいて、SEARCHとかいうメソッドが必要なんじゃね？　とか書いたが、どうにももにょるつか、気持ち悪い。　というわけで、もう一度REST 入門を読み直してみることにした。

まずはリソースについて。　リソースは以下の特徴を持つとされている。

全ての情報はリソース

リソースは識別子(URI)を持つ

リソースの状態は時間や条件とともに変化する可能性がある

リソースの意味は時間や条件が変化しても不変である

REST 入門(その3) 全てはリソースから

そして、この「リソースのある時点での状態の表現を（ネットワークを介して）転送する」というのがRESTだと説明されている。

ふむふむ、「リソースの状態」ではなく「リソースの状態の表現」となっているのは、リソースの状態を表す手段がHTMLだったりXMLだったりするからだと。　ということは同一のリソースの同一の状態の異なる表現を同じURIで取得することもできるということか？　コンテント・ネゴシエーションとか呼ばれてるやつのことか？

つまり、HTTP GETとは「リソースのある時点での状態の表現を取得（GET）する」ことだと。そして、PUTは「リソースの状態を変更する」ことであり、DELETEは「リソースを削除する」ことであり、POSTは「リソースを作成する」ことだと……。　POSTとDELETEは「リソースそのもの」への操作であり、「リソースの状態」への操作ではないということだな。

PUTとPOSTの使い分けは、POST と PUT についてを読めと。　で、こんなことも書いてある。

今回の POST, PUT, DELETE と、前回の GET はある点で大きく異なります。それは GET がリソースの状態に影響を与えないのに対して、それ以外の三つの動詞がリソースの状態に何らかの影響を与える可能性がある点です。このような性質を副作用(side effect)といいます。
REST 入門(その5) 四つの動詞 -- GET, POST, PUT, DELETE

ここまでは、前回読んだときもすんなりと理解できた。　問題はここからだ。　はてなブックマークに検索インターフェースを付けようというところで、こんな記述がある。

ここで登場するリソースは、「検索結果」リソースです。検索結果リソースはこれまでみてきたリソースとは少し趣が異なります。たとえばキーワード "REST" を検索した検索結果の URI は以下のようになります。
REST 入門(その6) ハイパーリンクと XML

検索結果リソースが検索という動作を行う前に存在しているというのが気持ち悪かったわけだ、だからSEARCHというメソッドを追加して、リソースに対して検索することで「検索結果リソース」を作成し、レスポンスのLocationヘッダで新規に作成された「検索結果リソース」の識別子（URI）を指定したほうが良いんじゃねえかと思ったわけだ。

ただし、このやり方だと、GET、POST、PUT、DELETE以外の操作が必要になるたびにメソッドが増えていくことになるので、美しくないなあというのが気持ち悪かった理由だ。

しかし、これ、チェックボックス等の方法で条件を絞り込んでいくタイプの検索の場合はあらかじめ検索結果リソースを作成しておくことができることに帰宅中の電車の中で気が付いた。　あらかじめ、想定されうる全検索結果について検索結果リソースを作成しておき、検索結果リソースの集合を示すリソースを作成する。　そして、検索結果リソースの集合に対して、検索条件をパラメータで指定したGETを行えばよくね？

で、「検索結果リソースの集合」なんてものよりも「リソースの集合」に対して、取得条件を指定してGETできれば十分じゃね？　で、リソースの集合に対してPOSTすれば、リソースの集合にリソースが新規に追加されればよくね？

というところまで行き着いた。　しかし、良いのかねえ、こんな理解の仕方で……。

rel-tagについて

2007-11-16T00:36:00.000+09:00

Webサービスのお勉強をしてみようとか言っておきならが、microformats関係ばっかり調べてる。　だってこっちのほうがお手軽そうなんだもん。　というわけで、microformats関係のFirefoxのAdd-onとbookmarklet。

Add-ons

Bookmarklet

いろんなページで試してみたけど、どうにも日本語のページはまだまだ対応しているところが少ないね。

で、いろんなページを見てて気になったことがひとつ。　タグクラウドってrel-tag使って良いのか？ってこと。　Voxにもブログを持ってるので、調べてみたらタグクラウドでrel-tag使ってるっぽい（Bookmarkletでは見つからなかったけど、ソースを見ると使ってる）んだよね。　そういうものなのかなあと思って調べてみたら、microformats.orgにこんなのがあった。

rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:

don't use rel-tag in Tag Clouds

rel-tag-faq - Microformats

はっきり、タグクラウドでは使うなと書いてあった。　そうだよな、やっぱり。　他にもCreatorの吐くコードを見ているとabbr要素にclass="dtstart"やclass="dtend"を適用してるけど、これもどうなんだ？　abbr要素って略語に使用してtitle属性でその正式名称を指定するものじゃないの？　microformats自体が今あるものを使用して無理やり隙間を埋めようとする仕組みだからしょうがないんだろうけど、一定のコンセンサスがとれるようになるまでしばらくかかりそうな気がしてきた。

参照リンク

徐々に使われるようになってきたとはいえ、やっぱりmicroformatsを利用したサービスが出てこないとまだまだ、パッとしないなあ。

Mozilla Prism

2007-11-13T00:57:00.000+09:00

二〇〇七年十月二十四日にMozilla Foundationが“Prism”という妙なものを発表していたようだ。

Webアプリケーションをブラウザからではなく、デスクトップアプリケーションとして利用できるようにしようという試みのようだが、それってHTAじゃねえの？　と思ったら違うようだ。　フォームから直接、レンダリング・エンジンを使用しましょう、ブラウザとしてのUIを持たないので、戻るボタン等を考慮しなくても良いですよ、ということらしい。　Firefoxのナヴィゲーション・ツールバーをマスクして見えなくしただけっぽいんだけど、誰が得するんだ？　つか、誰をターゲットにしてるんだ？

Adobe Systemsが“AIR”でデスクトップで直接Flashを使用できるようにしようとしているのに比べると非常にしょぼいような気がするんだけど、どうなんだろう。

現状ではウェブアプリが別画面で表示されるというくらいのことしかできませんが、それでもそれぞれのアプリは別プロセスで立ち上がっていますので、Firefox がクラッシュしても影響を受けないというメリットがあります。
ウェブアプリを単独で起動させる Mozilla “Prism”

なんてのは別に利点じゃねえよなあ……。　現状では拡張機能が使えないらしく、本当に別ウィンドウでWebアプリが起動しているだけなんだよなあ。

いずれ、拡張機能が使えるようになるとして、2ちゃんブラウザがやっているようにHTTPレスポンスを拡張機能がフックして加工して出力することができれば、特定のWebアプリについてそのインターフェースをチューニングして使い勝手を向上させることができるだろう。　現在のヴァージョンが0.8なので1.0になった時にその将来性が見えてくるだろう。　また、ウェブサイト側はウェブサービスとして構築してひたすらXMLを送出するだけににし、全ての操作はローカルで行うといったことも可能になるのかもしれない。　もし、そこまでやる気があるならちょっとしたパラダイム・シフトになる可能性もあるだろう。　今後に期待しようと思う。

microformats

2007-11-10T00:03:00.000+09:00

ここのところ、激しく暇なので、一年ほど前から気になっていたmicroformatsについて調べてみた。

Main Page-ja - Microformats

要するにマークアップしたデータに対してメタデータを付与して、意味づけを強化しましょうということのようだ。　詳しくはmicroformats ってなんだ？やMicroformats の夢を読めばよくわかるだろう。

はっきり言って、現在はCGM全盛の時代であり、タグをチマチマと手で打ってるのは一部の数寄者だけでなので、CGMのツールが対応しないことにはまったく流行らないだろう。　実用段階になっているのはrel="nofollow"くらいなものだし、これにしたところで、Googleというツールが対応したことが大きい。

Firefox 3で何らかの動きがあるようだが、これにしたところで、肝心のサイト側が対応していなければ意味がない。　やはりブログが対応しないことには進まないと思う。　Google Reviewsを見る限り、ブログが対応するだけで検索精度が大幅に向上するだろう事は容易に想像がつく。　hReviewとrel-tagについてはすぐにでも効果を発揮することができるだろう。

参考リンク

Role属性といいmicroformatsといい、時代はメタ情報なんだろうか？

XHTML Role属性

2007-11-04T16:27:00.000+09:00

XHTML Role属性モジュールなるものの策定が進められているらしいことを下記のページで知った。

Taken SPC : role 属性値を基にノードを選択する

で、最終草案（Working Draft）が出されており、早速和訳も行われている。

で、Role属性という名前から推測できるように、「要素の役割を示す」ための属性のようなんだが……class属性とどう違うのか、どう使い分けるのか、良くわかりません。　草案を読んでも良くわからない。　「4. XHTML Role属性」の章に乗っている標準roleをみんなで使用してドキュメント中の役割をわかりやすくしましょうって事なんだろうけど……。　そのうち拡張されてどえらい量になったり、誰かが勝手に追加したroleがデファクト・スタンダードになったりするんだろうなあ。

そもそも、QNameとかCURIEってなんじゃい？　という自分のアホさ加減が嫌になっちゃったりするわけだが、XML系の仕様って膨らみすぎてないか？

参考リンク

それにしてもHTMLの時はあまり使用されなかった（見た目の制御には使用された）、要素の属性という概念がXHTMLの時代になって急に脚光を浴び始めたような気がする。

半画面プログラムのテトリス

2007-11-03T23:01:00.000+09:00

久しぶりに感動的なコードを見た。

「往年の名作「スーパーマリオブラザーズ」、あの濃い内容でわずか40キロバイト」で紹介されたJavaScriptのテトリスだ。　わずか565バイト（79文字＊7行）で実現されている。

仕事でこんなコード書いた日にはコードレビューで半殺しにされるわけだが、往年の一画面プログラムを知っている世代にとっては懐かしさのあまり走馬灯が見えそうになる。

で、案の定、全国のショート・コーダーの皆様の琴線に触れたらしく、方々で話題になっている。　さらに縮めようとするひとまで現れてる。　失敗したみたいだけど。

こういうのを見ると富豪的プログラミングはプログラマから職人魂を奪っていく考え方なんだというのが良くわかるなあ。

参考リンク

ところで、マリオについては「マリオ研究」なるページがあるんだが、これを見るとスーパーマリオブラザーズは奇跡の産物ではなく、周到に計算された努力の産物だというのが良くわかる。

日産とポリフォニーデジタルが共同開発

2007-10-30T00:38:00.000+09:00

こないだのCell+Rubyでデジタル家電向けGUIで以下のようなことを書いた。

デジタル家電とやらのUIを見てて思うのは、リモコンのような物理的なUIではなく、ディスプレイ(TV)に表示するGUIについては家電メーカよりもゲーム業界のほうがノウハウを持ってそうな気がする。　となると、SCEを抱えているソニーが有利な気もするが、Play Station のシステム画面を見てると使いやすさよりも見た目っぽいんだよなあ。

とっくに日産がやっちゃってたらしい。

【東京モーターショー】SCE子会社が明かすGT-R開発秘話，「多機能メーターを共同開発した」：ITpro

その中で山内プレジデントはGT-Rの「マルチファンクションメーター」を，日産自動車とポリフォニー・デジタルが共同開発したことを発表した。

SCEの子会社だったのは知らなかったが、ポリフォニー・デジタルってのはグランツーリスモ作ってるところだ。

ただ、記事を読んでもマルチファンクションメーターとやらの写真を見てもゲームメーカのノウハウが生かされてるかどうかさっぱりわからなかったんだけど……。　日産にとってはどんなメリットがあったんだろうか？　そこら辺を突っ込んで取材しなかったんだろうか？

ステートレスってたとえばどんなの？

2007-10-29T22:13:00.000+09:00

というわけで、RESTについて調べていると必ず出てくるステートレスとステートフル。　なんとなく理解はできるんだけど、他者に説明する際に適当なたとえが思いつかなかったところにいい説明を見つけた。

yohei-y:weblog: ステートレスとは何か

おおぉ、なるほどぉ。　で、これを踏まえてステートレスな世界でステートフルのように見える世界を実現するためにCookieが導入される。

404 Blog Not Found:ステートレスなお買い物

最初は受け取り票ではなく買い物のメモそのものが店員と客の間でやり取りされていたんだが、当然、そのメモを盗み見られてしまうと買い物時に店に提供した情報がすべてバレてしまう。　そこで、店員と客の間でやり取りする情報には受け取り票となる番号札だけに絞り、買い物の詳細は店側が保持するようになったと。　で、店側は番号札に対応する買い物の詳細を店員にしか見えない場所に掲示しておくことで、異なる店員でも商品の受け渡しを行えるようになる。

しかし、店員でも客でも無い第三者が客の持っている番号札を奪うもしくは偽造することで、客に成りすまして店員とのやり取りを継続してしまうことが可能だ。　これがセッションハイジャックなのだろう、多分。　また、店員でも客でもない第三者が店員に成りすまして以下のようなことをすることもできる。

客: A店に偽装した店舗に買い物に来る
偽店員: いらっしゃいませ。
客: 黙ってメモとクレジットカードを渡し、暗証番号を入力する「ハンバーガーセットをポテトとジンジャーエール(M)を100個。クレカと暗証番号はこちら。」
偽店員: 黙って釣りと伝票を渡す。「受取表:2007-10-28 18:00 Foo様」　そして裏口から本物のA店に行って買い物をする。
客: 黙って伝票を出す。「受取表:2007-10-28 18:00 Foo様」
偽店員: 黙って商品を渡す

こうすることで、偽店員はめでたく（？）客の暗証番号を手に入れてしまえる。　で、これがマン・イン・ザ・ミドル（中間者）攻撃と呼ばれるのだろう、多分。　で、A店に偽装した店がフィッシング・サイトになるのだろう、多分。

これを見れば店の場所（URL）はちゃんと確認しましょうというのも納得がいくし、その店員が本物のA店の店員かどうか調べるために、自分が信頼する第三者に保証してもらおうという発想が認証局という仕組みだというのも理解できそうだ。

ところで、マン・イン・ザ・ミドル（Man in the middle）攻撃のManについてフェミの皆さんは抗議しないんだろうか？　「中間者攻撃は女性も行うのだからPerson in the middle攻撃と呼ぶべきだ！」とか。

WITH句について

2007-10-25T23:01:00.000+09:00

WITH句とやらについて試してみたんだけど……。

with TMP_TABLE_NAME (TMP_COLA, TMP_COLB) as (
    select
    ……略……


という記述はできないっぽいよ？　なんで？

ORA-32033: 列はサポートされていません。

なるエラーが出ちゃうよ。　で、原因は「WITH句の列のエイリアシングはサポートされていません。」なんだそうだが……。　これはORACLEが対応してないだけでSQL99の仕様ではOKなのか？　MySQLやDB2はサポートされているのか？



共通表式WITH句ってなんだ？
2007-10-25T00:01:00.000+09:00
いまだかつて無かったほどに暇なので、勤務時間中にお勉強してたら、SQLにWITH句なるものがあるらしい。


新しい業界標準「SQL99」詳細解説


すげぇ。　外部結合する際等にうまく使えば、ずいぶん高速化されるような気がするが、どうなんだろう。　メッチャメモリ食いますとかだったら死ねるが、試してみる価値はありそうな気がする。


参考リンク


新しい業界標準「SQL99」詳細解説
ＯＲＡＣＬＥ／オラクルＳＱＬリファレンス（WITH句）





Cell+Rubyでデジタル家電向けGUI
2007-10-21T16:55:00.000+09:00
CEATEC 2007で東芝がRubyで構築されたデジタル家電向けGUIを発表したようだ。　プロセッサにはCellを使用して。

【CEATEC続報】CellでRubyを動かす，東芝が家電向けUIを試作

工場もかっちゃたし、東芝は本気でCellを推し進めようとしているようだ。　Play Station 3 がポシャッたから積極的に使用することで費用を回収したいんだろうなあ。
というような話はおいておいて。　Cellを使用したのはある意味当然としても、Rubyを使用する必要がどこに有ったんだろうか？　ruby-listに投稿されたなかのひとの発言を読むと、スクリプト言語でやりたかっただけのようだが。
ところで、GUIを開発する言語としてRubyはどうなんだろう、オレのようなおじさんにはTcl/Tkじゃねえの？　とか思っちゃうわけだが。　Linuxの上でRubyとCairoとDirectFBという構成のようだが、DirectFBってなんだ？
デジタル家電とやらのUIを見てて思うのは、リモコンのような物理的なUIではなく、ディスプレイ(TV)に表示するGUIについては家電メーカよりもゲーム業界のほうがノウハウを持ってそうな気がする。　となると、SCEを抱えているソニーが有利な気もするが、Play Station のシステム画面を見てると使いやすさよりも見た目っぽいんだよなあ。
まあともかく、現状のRubyのまま出荷って線はないだろうな。

参考リンク


オブジェクト指向スクリプト言語 Ruby
cairographics.org
directfb.org



ところで、デジタル家電ってTV以外に何があるんだ？



RESTの入り口で溺れる。
2007-10-20T01:09:00.000+09:00
というわけで、早速。
今年の一月からスポットで入っているプロジェクトの内容がひたすらレガシーなので、まったく刺激のないまま十ヶ月も過ぎてしまった。　その前のプロジェクトも最先端かといえばそうでもないんだが……三年も続くと古びてくるし。
このままでは浦島太郎になっちゃうよ、と思って色々と勉強を再開してみることにした。
で、前から興味のあったWebAPIについてちょいと調べてみようと思い立ったんだけど、調べれば調べるほどよくわかりませんと言うことに。
WebAPIといえばSOAPとか言うのがあったんだっけ？　とか思いながら調べていくと「SOAP」と「REST」の対立場面に出くわすことになった。　SOAPは難しすぎてよくわからなかったので、いったん諦めてRESTとかいうものについて調べてみることにした。　そこで、出くわしたのが以下のページ。
yohei-y:weblog:REST入門
大変わかりやすかった。　そうか、特定のAPIの仕様じゃなくてアーキテクチャのスタイルのことだったのか。
へぇ～、と思いながら読んでいくと「 REST 入門(その6) ハイパーリンクと XML」で引っかかることに……。　新規登録、変更、削除まではちゃんとHTTPのメソッドに合致しているのに検索だけが微妙なことになってる。　このページでの説明では「検索結果リソース」に対してGETを「適用」させることでリソースの状態を取得するわけだが、なんかおかしくないか？　「検索結果」ってのは「動作」の結果、生じる状態のはずだ。　検索という動作によって発生した状態を取得するなら、リソースに対して検索という動作を行うのが筋だ。
というわけで、RESTはHTTPを拡張してSEARCHとかいうメソッドを追加するべきじゃないだろうか？　以下のように、RESTの概念にはSQLのクエリが対応するのだからSELECTに対応する何かが必要なんじゃないだろうか？


POSTはINSERT
PUTはUPDATE
DELETEはDELETE

GETは状態を取得するメソッドなので、この場合だと主キーでSELECTするようなものか。
しかし、現状、PUTが有効に活用されているサービスはあるんだろうか？



ブログ始めました。
2007-10-20T00:53:00.000+09:00
voxにもうひとつブログ持ってるんだけど、あっちではあまり技術的なことができそうにないので、こっちでやることにする。

馬鹿につける薬

統合開発環境は次の時代へ

CORBA

Eclipse + WTP + Axis2 その7

Eclipse + WTP + Axis2 その6

Eclipse + WTP + Axis2 その5

Eclipse + WTP + Axis2 その4

Eclipse + WTP + Axis2 その4

Eclipse + WTP + Axis2 その3

Eclipse + WTP + Axis2 その2

Eclipse + WTP + Axis2 その1

Pit

Growl for Windows

新東京タワーの名称募集

Mozilla Sunbird使ってみた

あけましておめでとうございます

Bloglines BETA が生き返った

Bloglines BETA が死んでいる

実際に設計してみよう その3

やらかしちゃった勘違い

map.resourcesすげえ

GoogleとSNS

実際に設計してみよう その2

JavaScriptでオレオレ言語

実際に設計してみよう その1

RESTの入り口で迷子になる

rel-tagについて

Mozilla Prism

microformats

XHTML Role属性

半画面プログラムのテトリス

日産とポリフォニーデジタルが共同開発

ステートレスってたとえばどんなの？

WITH句について

共通表式WITH句ってなんだ？

Cell+Rubyでデジタル家電向けGUI

RESTの入り口で溺れる。

ブログ始めました。

Eclipse + WTP + Axis2　その7

Eclipse + WTP + Axis2　その6

Eclipse + WTP + Axis2　その5

Eclipse + WTP + Axis2　その4

Eclipse + WTP + Axis2　その4

Eclipse + WTP + Axis2　その3

Eclipse + WTP + Axis2　その2

Eclipse + WTP + Axis2　その1

実際に設計してみようその3

実際に設計してみようその2

実際に設計してみようその1