「とりあえずSelenium」のときはChromeを使ったほうが楽かもしれない
2016 年 7 月 19 日 火曜日 by 山平スクレイピングなど、とりあえずSeleniumで結果を確認しながら作りこみたい場合、利用するブラウザはFirefoxよりもChromeのほうが、余計な手間がかからなくて良いかもしれない、とおもった出来事があったので備忘録として残します。
スクレイピングなど、とりあえずSeleniumで結果を確認しながら作りこみたい場合、利用するブラウザはFirefoxよりもChromeのほうが、余計な手間がかからなくて良いかもしれない、とおもった出来事があったので備忘録として残します。
前回、Jekyll(Octopress)の記事生成時に、記事用のディレクトリと、画像用のディレクトリを作成しました。
折角、画像用のディレクトリを作成しても、パスの指定までは面倒見てくれないので、あまり便利になった実感が沸きません。
そこで今回は、画像のパスを勝手に指定してくれるように手を加えていきます。
それなりにイケてる静的サイトが簡単に作れるJekyllはとても便利です。
さらにちょっと面倒な下準備まで済ませてくれているOctpressが私のお気に入りです
Jekyllにはちょっとだけ気に入らないところがあって、記事を1つのディレクトリ内に延々と書き溜めていかなければならない点でした。
過去にテキストベースでCMSを自作した際に、同じ問題でとても苦労したことがあったからです。
ところがある日以下のような記事を見かけました。
なんと。。
ちゃんとソースを読まないとダメですね。。
最近…でもないですが、Ruby界隈ではBundlerを使って環境を保証するのがトレンドのようです。
前回、enchant.jsの当たり判定がイケてない理由を説明しました。
回転する矩形同士の衝突判定を自前で実装することを目標に、考察を進めていきます。
使いやすい和製ゲームエンジンenchan.jsですが、当たり判定がイケてないようです。
画面周りのちょっとした処理をjavascriptで関数化することはよくありますが、規模が大きくなってくると本来のロジックが見えにくくなってしまってあまりよろしくないなあ、と思うことが多々あります。
過去にjQueryプラグインのソース解析に挫折したことがあって作るのも難しいと思い込んでいたのですが、実はとっても簡単でしたのでご紹介します。
前回、イベントの仕組みで状態管理を実装した例を解説しました。
今回は管理する項目を減らすために、できるだけオブジェクトによろしくやってもらう仕組みについて解説します。
どんなに美しい3Dクラフィックスであっても、基本的にゲームはパラパラ漫画のようにヒトコマずつ処理されます。
enchant.jsにも、「フレーム」という概念があります。
フレームが始まるごとにイベントが発生するので、作り手はフレーム内の処理を書くだけでゲームっぽいものが作れます。
ゲーム開始後つまり「ゲーム中」についてはこれだけでも十分ゲームが実装できます。
しかし、規模が大きくなるにつれて「ゲームの開始前、終了後」など管理項目が増えてきます。
これらの処理をフレームイベント内だけで記述しようとすると、だんだん無理がでてきます。
今回はイベントドリブン的な実装を行なった部分について、解説してみます。