WScore：展望（2013年9月）

WScoreフレームワークの開発方向について、考えてみる。

１）現状のスタイルを踏襲する

一番無難。
また新しいことを試すのも楽。

なので、WScoreの開発は続けてゆくと思う。
DIをどうするか（Ray.DIに乗り換えるか）など、結構基本的な部分で悩みがあるのだけど、そういうのも含めて、自分の勉強のためになると思っている。

本音を言えば、最初はフルスタック可能なフレームワークを作る気はなかった。それが、勉強のためという理由で自分で開発したり、１００行ぐらいでできそうかも、と思ってしまったとかで、機能が膨れ上がっていった。 

でもコード量は１万５千行ぐらいと比較的小さめなFWだと思う。

２）Cena on Doctrine 2

Cena技術は、本来どんなORMの「薄いマッパー」として動く、はず。
なのでDoctrine 2上でCenaを開発してみたい。

実は、これを最初に検討した。
エンティティの状態が知りたいので、UnitOfWorkの3000行のコードを見ているうちに、気がついたらwsCoreというレポジトリをgithubで作っていたのだった…

あれからDataMapperやCenaについての知識も増えたし、もう一度試してみたいと思う。

もう一度Doctrineのコードを見たら、「getEntityState」というメソッドを発見。これを使えば楽に作れる気がしてきた。どうして一年前に見つからなかったのか謎ではあるが。 

でも、Cena on Doctrineができたら、WScoreを使ってくれる人はいなくなるなぁ、と思いつつ、どちらにしろ使ってくれる人は殆どいないと思うので、これが正しい道だと思う。

３）クライアント側の開発（JavaScript）

クライアント側のライブラリを開発する。
つまりJavaScriptを書くということ。

前にCena-DTAというのを作ったことがある。
初めての本格的JS開発ということで、jQueryのプラグインとして開発したので、複雑な動きに対応しづらくて大変だった。また当時はWebSqlしか使えなかったので、SQLを使って作った。

今ならBackboneかAngularを利用して、モデルか何かのプラグインみたいな形で開発してみたい。それとIndexed Databaseを使ってみたい。


４）XaaS

開発は楽しいのだけど、世界はすごいスピードで進んでいる。
BaaS（Backbone As a Service）など、こういうところでCenaを使ってほしいと思ってたレイヤーがサービス化している。

今のペースで間に合うような気はしないが、何かはしてみたい。

WScore：フレームワークを自作する理由

わざわざフレームワークを自作するのはなぜか？
なぜ面倒なフレームワークづくりを続けられるのか？

フレームワークの自作は大変なだけで、既存のものを使うか利用するほうがはるかに楽だと思います。大体動くところまではできますが、細かなバグを見つけたり、きちんとテストを書くのは大変な作業です。


自分の場合は、明確な理由が一つ。

Cenaデータ転送という技術を思いついてしまったたから。
ハマりすぎて特許まで取得してしまった。

これで何ができるのか見てみたい。
そして周りにデモを見せたい。

ちなみにこんなサイトでCenaについて書いています。

世界で唯一の技術（かもしれない）と思うと、不思議とやる気が湧いてきて、開発を続けています。高揚と幻滅を繰り返しながら、少しずつ機能を追加してゆく作業は、なかなか楽しいです。


もちろん、他にも理由はあります。

まずは、勉強のため、というのがあります。

例えばDIコンテナとはなにか？
実際に作って、そして使ってみることで理解できた気がします。

やはりフレームワークを作るとなると、いろいろなデザインパターンを使う場面が増えてきます。そういう意味で、自分のプログラミング能力を伸ばすのに最適な気がします。

もっとも勉強なら、既存のフレームワークを使って何かサービスを立ち上げるほうが広い範囲の技術を覚えられるので、フレームワーク自作よりおすすめな気がする。

自分の仕事のためのライブラリづくり。

自分の思い通りに動くのは気持ちがいい。

と言うのはありますが、大事なのはサポート期間が無期限なこと。
これがメリットなのか、大変なだけなのかはわかりませんが。

SymfonyのLTSが3年と聞いて、短いなと感じました。
自分の仕事だと、ほとんどは5年以上動いている。最長で10年のプロジェクトがあるので、サポート期間としては5年ぐらいはほしいところ。

他の人はどうしてるのだろう？
まぁサポート期間が切れて動かなくなることはないし、そんなに気にしなくてもいいのかな？

正しく作れば、サイトのコアとなるドメインコードはフレームワークから独立するので大丈夫、となるのだろうか？

WScore開発を始めてから1年。

ふとgithubを見返したら、wsCoreの最初のコミットが2012年9月5日。
早いもので、開発を始めてから1年が経過した。

その後2月頃にcomposerを使ったコンポーネントベースに移行。
また名前もWScore.*に変更。
「＊」は、各コンポーネントの名前。

特徴は：
・Cenaデータ転送技術がある！
・コンポーネント・ベースでフルスタック可能、
・小さい（16,000行ぐらい）、
といったところ。

開発の現状は、ほぼアルファぐらい。

大まかな機能は実装できた。
明らかなバグ・不具合もなし。
ただテストは足りない。
微妙に機能が足りてない（i18nなど）。

今後は、細かな構成やAPIを調整したい（見返すと汗が出る箇所が幾つかある）ので、状況としてはアルファぐらいかなと思う。

もう少しAPIを煮詰めてベータと言えるぐらいにはしたい。