前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
某所に提出するように昔作ったもののコア部分を詰めて作ったんだけど、興が乗ったので今日そのまま作りこんでみた。 同時にログインして相手に近づいて殴ったらHPバーが減って死ぬ。死ぬと4秒でリポップする。 まだマップを実装したりモンスターを徘徊させたりしてない。実質一日で作ったものなので現状この程度。 ガワはenchant.jsで書いた。はじめてまともにつかってみたが、意外と複雑な構成に耐える印象。とくにアニメーション部分はavatar.enchant.jsの仕組みにほぼ乗っかっているのだが、サーバーサイドでステートを決定してクライアントで受け取っている。こんなこと自分以外はやっていないと思う。 一応Githubに置いた。グワーッと作りたかったので、まだテストコードを書いていない。 mizchi/node-mmo https://github.com/mizchi/node-mmo git cl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
