Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書く - Qiita
Nightmare v2(Electron) でブラウザ上でES2015のコードを個別にrequireしてユニットテストを書くNightmareElectron 自分の開発環境では, nodeで単体テストと分離してモデル層を抽出出来たが、e2eほどではないがブラウザ上でテストしたいコードというのは結構ある。モーダル制御とか、ブラウザ上のイベントに依存する奴とか。 それらを Nightmare でテストするアプローチを紹介する。 概要 Nightmare はヘッドレステストランナーとそのDSLを提供する。v2でランナーがphontomjsから Electronになった。 コードはbabel/commonjsで書かれており、本番環境でJSは1つにまとまっているが、Electron の nodeIntegration を有効化して走らせることで、ビルド前のコードを個別にrequireできる。グロ
今一番JSで熱いゲームエンジン、RPGツクールMVのランタイムコードを読んでみた - Qiita
一昔前にCanvasが実用段階になった頃、JSのゲームエンジンが大量に出てきたことがありました。それらは大抵DOM/CanvasのFallbackを持っていたのですが、今現在の状況は、実際には非効率なメモリ消費やモバイルのブラウザのフラグメント化で実用に足るものがなかった、という辛い現状があります。 そんな中pixi.jsという描画ライブラリが台頭してきました。このエンジンは webglとcanvasの fallbackを持ち、(いくらかのバグはありつつも)DOMを切ったことで現実的なパフォーマンスの課題をクリアできるのでは？という期待感が高まっています。 Pixi.js - 2D webGL renderer with canvas fallback http://www.pixijs.com/ そして 2015年、RPGツクールMVが発表され、ブラウザ吐き出し対応がアナウンスされました
俺のJSライブラリの世界観(2014末版) - Qiita
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
cortex.js: 監視可能なネストできるオブジェクト - Qiita
mquan/cortex 副作用が加えられるとコールバックを発火するオブジェクトを作れる。ネストしたオブジェクトもとれる。 Vue.jsの$dataを知っている人は、getter/setterが専用に置き換えられたそれだと思えばよい。逆に言えばそれだけしかしないのだが。 何に使うの JSのMVW用のミドルウェア。README見る限り、Reactと一緒に使うのを想定しているが、APIを見る限り、別にそれに限ったものでもない。役割はモデル層だけに限定される。 とはいえ、ViewModel的に使うのが一番適していると思われる。 使い方 var Cotex = require('cortexjs'); var c = new Cortex({a:1, b: [1], c: {d: 2}}); c.on('update', function(c){ console.log('updated', c.
SVGと物理エンジンをマッピングするn個の方法 - Qiita
最近SVGにハマっている。ふとした思いつきで、SVGのcircle要素と物理エンジンをマッピングできたら、簡単にパーティクルが作れるのでは、と思ったのでやってみる。 PhysicsJS + Snap.svg(雑な描画マッピング) PhysicsJS + Snap.svg + 自力の差分管理 PhysicsJS + React 作るのは非常に雑な、こういうやつだ クリックしたらcircle要素が出現する 物理エンジンによって座標計算されて右方向に飛んで行く 50px 右に移動したら消える 物理エンジン的に面白い挙動とかはあとで考えることにする。 物理エンジンの世界を作る 今回はPhysicsJSを使うことにした。box2dはC++由来のAPIが古臭いし使いたくない。matter.js と PhysicsJSがメンテされててモダンな雰囲気がして試してみたのだけど、matter.jsは何かとおせ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
