車輪を再発明 / koba04の日記 このページをアンテナに追加 RSSフィード Twitter

2014-03-03

さようならはてなダイアリー、ありがとうはてなダイアリー

はてなブログに移行するかなーと思いつつ、色々考えてOctopress+GithubPagesでやることにしました


http://blog.koba04.com/ (これを機に独自ドメインに)


これからはこちらで書いていくのでRSSに登録してもらってる人は登録しなおしてもらえると嬉しいです


このブログを書いていることでたくさんのものを得ることが出来たのでとても感謝しています。

ありがとうはてなダイアリー。

山田山田 2014/12/18 15:34 運営者 様

初めまして、山田と申します。
様々な分野でのメディア運営や大手企業様のWebプロモーションなどのサービスを提供している会社で勤務しております。
このたび、貴媒体から有料で広告リンク掲載して頂けないかご相談をさせて頂きたくご連絡差し上げました。(相互リンクが難しいため)

弊社は現在、クライアント様のウェブプロモーションをしております。
現時点ではクライアント名を述べることはできませんが、世間一般に名の通った大手企業様です。

そこで、有料契約にて貴媒体からの広告リンク掲載をお願いしたくご連絡差し上げました。
貴媒体は有用な情報を掲載されており、是非広告リンク掲載をお願いしたいと考えております。
クライアントも、貴媒体からの広告掲載・タイアップを熱望しております。

是非、掲載位置や料金等のご相談をさせて頂ければと考えておりますが、ご意向をお知らせ頂ければ幸いに存じます。
誠にお手数ではございますが、ご返信は下記連絡先にご連絡頂きますようお願い致します。
E-mail: yuki.yamada.1985@gmail.com  山田
(メールアドレス自動収集ロボットなどの対策のため、上記メールアドレスには全角の「@」を記載しております。
 お手数ですが、お返信の際は半角の「@」に変更してください。)

何卒宜しくお願い致します。

2014-01-26

Backbone Eyeが面白い(かも)

https://addons.mozilla.org/ja/firefox/addon/Backbone-Eye/?src=cb-dl-recentlyadded

  • BackboneEyeというBackbone.jsで作られたアプリケーションの情報をfirebug上で色々見ることが出来るものがあります
  • 面白そうだったので久しぶりにFirefoxを立ちあげて試してみました

ViewやModelやCollectionの状態を確認することが出来る

こんな感じでModelやCollectionやViewの状態をみることが出来ます

  • View

f:id:koba04:20140126162904p:image

  • Collection

f:id:koba04:20140126163032p:image


View、Collection,Modelがどう連携しているのかをみることが出来る

  • こんな感じでfetchやrenderやイベントがどう連携しているのかをシーケンス図でみることが出来ます

f:id:koba04:20140126161900p:image


ZombieViewを確認することが出来る

  • Zombiesというタブがあって、ZombieViewがあるとここに表示されるようです
  • が、試したみた限りちゃんと検出出来てないような気も...
  • ↓みたいにしてViewの切り替えをやってみるとApp._eventsの中にどんどんviewが古いViewが増えていくような実装で試してみたのですが、Zombiesの中には表示されない...
class View extends Marionette.ItemView
  onRender: -> App.on "xxx", @xxx, @
  xxx: -> console.log "xxx fire => #{@cid}"
    • ここは要調査かなと...

というわけで

  • 詳しくはこちらを!(iPhoneだとメニューが表示されっぱなしで見られなかったですが...)
  • 正直、実際の開発ではまだ使っていないので実際に使えるかどうかはわかりませんが、面白そうなので試してみようかなと思いました。

Backbone.jsのlistenToについて

  • Backbone.jsでviewの中でmodelのイベントを購読するときに「model.on("change", view.render, view)」のようなことをすると、modelからviewへの参照が残ってしまって、SinglePageApplicationやViewの切り替えを行ったりするアプリケーションではZombieViewが誕生してしまいます。
  • このような場合には0.9.9から追加されたlistenToメソッドを使って「view.listenTo(model, "change", view.render)」として「view.remove()」するといいのですが、listenToにするとどうなるのかということについてちゃんと確認してなかったので、DeveloperConsoleを使って確認してみました。


model.onの場合

viewとmodelのインスタンスを作った状態

f:id:koba04:20140126153051p:image

model.onでイベントを購読した状態
  • model._eventsの中にviewがcontextとして保存されています
  • この場合、modelにしかイベントに関する情報は入ってないので、viewからは解除することができません
    • viewがmodelを持っている場合はthis.modelとして参照することは可能ですが...。

f:id:koba04:20140126153052p:image

view.stopListening()した場合
  • viewからmodelへの参照は持っていないのでイベントはそのまま登録されたままです

f:id:koba04:20140126153053p:image

model.off()した場合
  • model.off()することでイベントの購読を解除する必要があります

f:id:koba04:20140126153054p:image



view.listenToの場合

view.listenToでイベントを購読した場合
  • _listenIdというものが購読対象(この例だとmodel)毎に発行され(この例だと"l70")て設定されています
  • さらにviewには_listeningToというオブジェクトが生成されて、その中に_listenId毎に購読対象(この場合はmodel)が入っています
  • イベントの購読自体は中でmodel.onが呼ばれているだけです

f:id:koba04:20140126153542p:image

view.stopListening()した場合
  • viewから購読対象(model)を取得することが出来るので、stopListening()でイベントの購読を解除することが出来るようになっています

f:id:koba04:20140126153543p:image

view.remove()でも解除できる
  • view.remove()中ではstopListening()が呼ばれているのでview.remove()すればイベントの購読を解除することが出来ます
    remove: function() {
      this.$el.remove();
      this.stopListening();
      return this;
    },

というわけでlistenToでイベントを購読することで、viewにlistenIdをキーにした購読対象(model)に対する参照が保持されるので、view.remove()の中でstopListening()が呼ばれて購読対象(model)からイベントの購読を解除することが出来るのでした

2014-01-25

テストでstubを使いすぎる問題

特にJavaScriptのテスト書いたりしてると、局所的にテストするためにsinon.jsのstubを多用するのですが、そうするとstub対象の仕様が変わった時にもテストがfailしなくなるので使い過ぎには注意しないとなぁと自分のテストコード見てて思いました。


コードにするとこんなイメージ

# Viewの実装
TestView = Backbone.View.extend
  :
  testMethod: (args) ->
    results = @model.veryComplexMethod args.value
    @render result: results[0]

# テスト
describe "testMethod", ->
  view = null
  beforeEach ->
    view = new TestView model: new TestModel()
    sinon.stub(view.model, "veryComplexMethod").returns ["return value"]
    sinon.stub view, "render"
    view.testMethod value: "test input"
  afterEach ->
    view.model.veryComplexMethod.restore()
    view.render.restore()

  it "should call model.veryComplexMethod with args.value", ->
    expect(view.model.veryComplexMethod.calledOnce).to.be.ok()
    expect(view.model.veryComplexMethod.args[0][0]).to.be "test input"

  it "should render with model.veryComplexMethod return", ->
    expect(view.render.calledOnce).to.be.ok()
    expect(view.render.args[0][0]).to.be.eql result: "return value"
  • model.veryComplexMethodの処理がHTTPリクエスト投げていたり、動作させるための準備が面倒なのでとstubにした場合、model.veryComplexMethodが返り値を配列から文字列に仕様を変えた時にもこのテストは通り続けます。
    • このコード自体は意図したとおりに動いているのですが、出来ればテストがfailしてほしいところです。
  • 他にはFakeServerを使った場合なども実際のAPIの仕様が変わってもテストがfailしなくなりますが、それは単体テストの範囲でないなぁと思ったりしていて、どれをstubとするのかが考えだすと難しいなぁと思ったりしています。
  • なるべくstub対象が局所的になるようにとは思っていますが、つい簡単にテストを書くためにテスト対象のコード以外の部分をガツッとstubにしてしまうことがあるので注意しないとなと思っています...。