2013年9月24日火曜日

WScore:展望(2013年9月)

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

1)現状のスタイルを踏襲する

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

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

本音を言えば、最初はフルスタック可能なフレームワークを作る気はなかった。それが、勉強のためという理由で自分で開発したり、100行ぐらいでできそうかも、と思ってしまったとかで、機能が膨れ上がっていった。 
でもコード量は1万5千行ぐらいと比較的小さめなFWだと思う。


2)Cena on Doctrine 2

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

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

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

もう一度Doctrineのコードを見たら、「getEntityState」というメソッドを発見。これを使えば楽に作れる気がしてきた。どうして一年前に見つからなかったのか謎ではあるが。 
でも、Cena on Doctrineができたら、WScoreを使ってくれる人はいなくなるなぁ、と思いつつ、どちらにしろ使ってくれる人は殆どいないと思うので、これが正しい道だと思う。


3)クライアント側の開発(JavaScript)

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

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

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


4)XaaS

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

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

2013年9月19日木曜日

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

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

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


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

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

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

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

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


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

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

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

やはりフレームワークを作るとなると、いろいろなデザインパターンを使う場面が増えてきます。そういう意味で、自分のプログラミング能力を伸ばすのに最適な気がします。
もっとも勉強なら、既存のフレームワークを使って何かサービスを立ち上げるほうが広い範囲の技術を覚えられるので、フレームワーク自作よりおすすめな気がする。


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

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

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

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

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

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

2013年9月17日火曜日

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

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

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

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

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

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

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

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