「寄付」は英語でDonationかContribution?

ちょっと英訳をしていて。

英語で寄付といえば「Donation」とばかり思ってたが、
「Contribution」という言い方もあると知った。
http://ejje.weblio.jp/content/寄付

何が違うのだろう？
と調べてみたら、

Donation refers to a gift to a charitable organization whereas a contribution is generally associated with a gift to a common fund or collection.

つまり「Donation」は慈善団体に寄付するときに使い、

それ以外の組織に対する寄付の場合は「Contribution」になると。

http://www.usingenglish.com/forum/ask-teacher/63524-contribution-vs-donation.html

Dictionary.comで「Donation」調べてみたが、はっきりとは書いてないなぁ。DonationはContributionでもあると書いてあるし。

確かにContributionの方が広い意味があり、Donationのように善意を受け付けるというより自分たちに賛同する人の助けを（お金として）受け取る、という使い方になるのかもしれない。

ということで、今回は「Contribution」を使うことにした。

Marvericks上でVirtualBoxが不安定に。

どうやらMacのOSをMarvericksにアップデートしたら、VirtualBoxが不安定になったようです。

参考：

https://forums.virtualbox.org/viewtopic.php?f=8&t=58058
http://blog.offline-net.com/2013/10/27/virtualbox-mavericks-update-error/

■症状は、

VirtualBoxを走らせた後、仮想マシーン（VM）を立ち上げようとすると

Kernel driver not installed (rc=1908)
Make sure the kernel module has been loaded successfully.

とエラーメッセージが出てVMが立ち上がりません。

■対応方法１

このエラーが出たら、VirtualBoxを再インストールするしかないようです。インストール作業は５分もかからないのですが、面倒です。

再びVMを立ち上げると、動きました。

VMのイメージ自体は問題ないようです。

よかった。

とは言え毎度再インストールは、本当に面倒です。

■対応方法２

原因は、マックのウィンドウの赤い「×ボタン」、名前なんて言うんでしょうね？を使うと問題が出るようです。つまり、VMが正しくシャットダウンされてない状態になるようです。

なので、＊nix系であれば、

sudo shutdown -h now

とコンソールからシャットダウンすれば問題ないようです。

【追記：2013/10/30】
本日また同じ問題が発生。どうやら、上記の対策では対応できないようです。残念。こうなると、↓ですか。

■Oracle様待ち

Marvericksに対応したVirtualBox修正版がリリースされるまで待つしかなさそう。

時代は「CYOFW」

時代は「CYOFW」。
BYOFWは「Create Your Own FrameWork」の略ということで。

自分が言ってるのではなくて、SymfonyやComposer、PSR-3、そしてBEAR.Sundayが何を達成しようとしているかを考えれば、この方向に未来があると思う。

好みのコンポーネントを組み合わせて、自分のFWを作る。Laravel風も、FuelPHPだって、CodeIgniter風も作れるはず。


■コンポーネントが輝く

そうなると、コンポーネントが競争し始めると思う。Smartyかtwigか、プレーンPHPのどれ使うか悩むよね、程度の話なんですが。

いまさらフレームワークを新しく作るより、キラリと光るコンポーネント作ったほうが使われる気がする。

全く新しい機能を提供できれば一番。

それが難しくても、早い＆小さい、あるいは、使いやすい、といった面で特徴を出せる方がいいのかなぁと。

理想のコンポーネントは、簡単で小さくて使いやすく、その上、必要になれば様々な機能を簡単に追加できる、なんていうことができれば文句はないだろう。

自分で言えばCenaは他にはないコンポーネント。

と考えると、今後はCenaに集中すべきだろう。

一方、Requestやテンプレートは、今更作ってもと思う。


■グルー（糊）をどうするか

コンポーネント間をつなぐのがグル〜、つまり糊なのだけれど、コンポーネント間、あるいはコンポーネント内の依存性は、どう解決すべきなのだろう。

DI対応しているのが前提で、コンテナをどうするのか？

JSR-330のように、PHPでのDIの仕方も標準化されるのだろうと思う。

■FWってなんだろう？

CYOFWとなると、FWってなんだろうと思う。
さすがに全てのPHPerがFW自作するとも思えないので、有名なFWを使うという状態は変わらないと思う。なので、あまり意味のない疑問かもしれないが。

何を持ってFWというのか？
何がSymfonyで、どこからSilexになるのだろう。

FWがアップデートしても、それまで書いたものが無駄にならない、というのがFWを特定するものだとすると、

• 設定の仕方・手順、
• MVの分け方（コントローラーの書き方）、

あたりがFWの肝になるのかな。

WScore：逡巡（2013年10月）

先月、「展望」というエントリを書いていて、

今「逡巡」してるということで、迷走中です。

せっかく作った自作WScoreフレームワーク。

勉強のためという言い訳で、Http、Router、Templateまで作ってしまった。全部で1万5千行ぐらいとはいえ、仕事の合間に自分ですべてをメンテナンスするのは無理だなぁと。

少なくとも、今の全自作から少しずつ良さげなコンポーネントに入れ替えてゆくべきだろう。

そもそも自作FWにこだわる必要はあるのか？

SymfonyやfuelPHPなど、有名＆確実なFW使えばいいのでは？

そんなことを思っては逡巡する最近。

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を煮詰めてベータと言えるぐらいにはしたい。