kuntalog

頭の整理と書く練習。師匠募集中。

Firebase AuthenticationとVuexの合わせ技バグでハマった

TL;DR

  • Vuexのstoreにobjectを渡すときは気を付けよう。
  • Vuexのstoreにはできるだけ即値(って呼び方でいいのか?)を入れる。

内容

Firebase authenticationとVuexを使ってこういうのを書いてた。

export default {
  // ...
  created() {
    firebase.auth().onAuthStateChanged((user) => {
      this.$store.commit('setCurrentUser', { user });
    });
  },
  // ...
};

するとChromeのdevtoolが真っ赤になった。

Error in callback for watcher "function () { return this._data.$$state }": "Error: [vuex] Do not mutate vuex store state outside mutation handlers."

しかもこのエラーメッセージ無限に出続ける。
内容はmutationsハンドラ以外からstateをいじるんじゃないとのこと、それはそう。それはそうなんだけど上のコードを見ると分かる通りこれはちゃんとハンドラを通して(commitを使って)stateをいじっている。このcommitの行を消すとエラーも出ないのでこいつが原因らしい。これに結構ハマった。

やったこととか

strictモード外すと消えるけどすげーもにょるのでなんとか考えてた。
似たような問題を調べてて `v-model` だと元のstateが書き換わってそれが問題だとか、取得したstateをそのまま書き換えてるとかはあったけど全然関係ない。

結局エラーログをちゃんと読もうって気持ちになって読むとスタックトレースが `auth.esm.js` とかから始まっている、あれ?
しかもその上の方で `Vue.store._vm.$watch.deep` で死んでるっぽいと言うのが分かる。つまりこれってobjectを渡してるのが原因なのではと気づいてコードを変えてみた。

export default {
  // ...
  created() {
    firebase.auth().onAuthStateChanged((user) => {
      const { uid, displayName } = user;
      this.$store.commit('setCurrentUser', { uid, displayName });
    });
  },
  // ...
};

要はobjectを直接渡さないようにしてる。これで直った。
つまりはFirebaseのUserオブジェクトってのにいろいろListenerやらObserverとかが生えてて、値が勝手に変わってしまっていたことが原因っぽい、多分。詳しいことはソース読まんと分からん。

これにつきっきりだったわけでもないけど、これのせいで一時間近く進まなかった。

学び

  • 認知負荷高めのときは簡単なものにも気づけないので自分を疑う(850394598310239474502938457回目)
  • エラーログをちゃんと読もうな。
    • とは言いつつエラーメッセージで調べたほうが早い場合もあるので難しい。)
  • エラー箇所の特定をちゃんとやる
    • エラーログをちゃんと読めば分かったこと
    • とはいえ経験の浅いものを組み合わせて使っているので仕方ないかなとも思う。そういうときのエラー対処に時間かかるのはいつものことなのでうまいルーティンがほしいところ。勘に頼ってちゃだめだ。慣れてるならいいけどね。

開発合宿行ってきた

開発合宿

ゴールデンウィークの前半に開発合宿に行ってきました。最高でした。

mokumoku-onsen.connpass.com

 

きっかけとしては、フロントを全くやったことがなく、ちょっとずつやるにも億劫な感じがあり、まとまった時間使って多少の強制力というか圧がある環境で出来ればなと思っていたというのがあります。

最初は一般枠で参加するつもりだったのですが、 ゴールデンスポンサーの皆さんのご厚意で費用は出して頂けました。かっこいい大人はかっこいい。本当にありがとうございます!!

合宿での自分の目標

上2つは知らないとは言え見たことはあるのでできるだけ速く済まし、Reactにどれだけ時間を使えるかの勝負。

様子

集合は9:30に東京駅。そこから目の前に来るバスに乗り続けていると勝手に例の宿に到着しました。(大体12:00)

土善旅館[弓道合宿・開発合宿]

もうそこからはほぼ全てにおいて自由です。ご飯の時間は8:00, 13:00, 19:00にみんなで食べると決まっているもののそれ以外は完全に自由でした。(この合宿のポリシーというかがそういう感じらしいです)

開発部屋にはお菓子と日本酒とレッドブルとソフドリを用意して、それらを好きに摂取しながら開発ができます。あとこの土善旅館さん、聞いたことはあったけどやばかったです。ディスプレイにプロジェクタ、なんか敷くと椅子がいい感じになるやつ、人をダメにするクッション、猫などなどが貸してもらえます。開発中はなんの不自由もなかったです。

f:id:iamkuntao:20180501215849j:plain

後ろのでかいプロジェクタではシュタゲやらゆるきゃんを流していたのでそれを見たり、日本酒を無限に飲んだり、VRゴーグル被ってアクションゲームしたり、がっつり集中して作業する人もいればゆっくりと休みなが進める人もいて、いい塩梅の緊張感でもりもりと作業が進みました。流していたものの中では「russian car crash」とぐぐると出て来る動画がめっちゃ好きでした。

f:id:iamkuntao:20180501215548j:plain

他にも24時間温泉入れるし、開発部屋と就寝部屋がちゃんと分かれているのでそこも自分の好きなようにできるのはストレスフリーですごいよかったです。散歩がてら近くの海に行った人もいるみたいでした。

自分の勉強内容に関してかなりの初心者だったので進め方に不安があったのですが、ご飯食べてるときとかに聞いたりとかできるのがすごく助かりました。集まってやる強みですね。代わりに自分は最近得たCFnの苦しみの話をしました。温泉とかでも他の人と技術書展や出版の話を聞いたりわいわい感があってとても良かった。。

(ここまで良かったしか言ってないですけど実際そうだったのだから仕方がない、それと猫な。やっちょるかー?みたいな感じで見回りにやってくる)

f:id:iamkuntao:20180501215637j:plainf:id:iamkuntao:20180501215717j:plain

そんなこんなで自分は7:00~24:00みたいな生活をして結局progateというサイトでhtml/cssの講座を2つと、この本を全部読んだのとreactのチュートリアルを終わらせたので一定の進捗ありという感じでした。裏目標として設定していたjQueryとかの歴史からReactとかVueの設計思想を知るみたいな部分に踏み込めなかったのだけが悔しいですが、とりあえずは今まで抱えていた様子が分からなくてめんどくさい感じは抜けられたので良しとします。

あとはやたらと長時間続けるときの脳みそとか精神のコントロールをもっとうまくやりたいですね。。。

おわりに

開発合宿に参加するのは初めてだったのですが、まじで最高でした。なかなか手を出せないでモヤモヤしたものを抱えている人は一度日々の仕事を忘れて集中できる開発合宿に参加してみてはいかがでしょうか。最後にうまかったものと癒やしの写真を乗せて終わります。

f:id:iamkuntao:20180501220101j:plain

f:id:iamkuntao:20180501215932j:plainf:id:iamkuntao:20180501215956j:plain

f:id:iamkuntao:20180501220025j:plainf:id:iamkuntao:20180501220044j:plain

オブジェクト指向のこころ(3)

前の章で書いてた手順を具体例で試すっぽい

エキスパートシステム : 外的に依存しないといけないものをまとめてこう呼ぶっぽい。高度な制御、処理を行っているようなもの。

あれ?終わった。。

オブジェクト指向のこころ(2)

UML

Unified Modeling Languageですね。

分析工程

  • システムとやり取りを行う 実体 を洗い出す。(???)
  • プログラムのロジックフローではなく、 問題領域ドメイン領域とかの同義語?)のフローを考える。

なんかこの辺は前の章で言ってた機能分解をやめようってのと似てるように見える。

オブジェクトの相互関係を洗い出す

洗い出す

クラスに落とし込む

まだ実装には入らずインターフェースの実装をする。

クラス間の関係の種類

  • is-a : 継承で表されるやつ
  • has-a
    • あるオブジェクトが別のオブジェクトの一部、構成要素となっている場合(e.g. 車とエンジン) コンポジション と呼ぶ。
    • 独立した別のオブジェクトを持っている場合(e.g. 空港と飛行機) 集約(aggregation) と呼ぶ。
  • uses-a
    • e.g. 車はガソリンスタンドが必要(依存)
  • 他のクラスを生成している( ファクトリ

usesが依存って言葉遣い的にピンとこないな。構成要素って方を依存と呼ばないのはそれが可換ということを表しているからか? 相互作用図もよく分からん。「オブジェクトの寿命」とかキーワードっぽいものは出てるけど図のどういう要素がなんの指標になるかとかが全く見えてこない。

オブジェクト単位で

状態遷移を考える

配置図

この本では解説を行っていません。配置ってなんや。

おまけ

和訳の技術書、頼むから固有の使い回しをする単語は原文も載せてくれ、全然英語文献を調べられない。。

オブジェクト指向のこころ(1)

オブジェクト指向以前のプログラミング

機能分解から始める既存の構造化プログラミングの問題に触れる部分からスタート。 アンチパターンとして

  • 問題領域に存在する実体と出て来る動詞を書き出してしまう方法
  • オブジェクトをメソッド一緒になったデータと考える事

機能分解をすると個々の機能自体やそれらを呼び出すための手順を把握したオーガナイザー的なものが必要になる。オーガナイザーが複数の機能を扱うということはそれだけ多くの責任を持っているということ。機能の変更の際は機能自体だけでなくその操作を行うオーガナイザーに関しても修正を必要とする。 機能分解分解をすると

  • 凝縮度(Cohesion)が下がる
    • ある機能を叶えるために必要なコード群がいろいろな場所にあること
    • 明快度(Degree of Clarity?原文だとなんてなってるんだろ)が下がるとも言える
      • 色々な場所を見る必要があり見通しが悪い
    • 副作用(unwanted side effect)を引き起こしやすい
      • 変更の際に全てを網羅できずバグを生む

オブジェクト指向やっていき

単一の責任だけを持つように責任の移譲をしたい

  • 責任の移譲をするということはつまりは相手を信頼し機能を任せているということ
  • 任せるというのは相手のやり方や手順(実装やアルゴリズム)に関して一切感知をしないという意味(とりあえず機能を叶えてくれればそれでよい)
  • これによってオブジェクト間で「汚れのついた皿を集め洗剤とスポンジを用意してこすったり泡を流したあと乾かしてくれ」とかやんないといけなかったのを「"皿洗い"をしてくれ」という抽象的なやり取りに簡単化できる
  • "どうするか"ではなく"なにをするか"
  • 例えば「手順のみを知っているやつ」や「どうするかだけを知っているやつ」にするってこと?

考えるレイヤーによってオブジェクトの捉え方は変わる

  • 概念 - 登場するオブジェクトを洗い出し何に責任をもつものなのか考える
  • 仕様 - オブジェクト間のインターフェースを決定する
  • 実装 - どうやって自分の責任を達成するか。責任の分離が出来ているので他のオブジェクトのことは考えなくてもいい(そうなっているはず)

カプセル化

変わり得る(と考えられる)部分(データだろうが振る舞いだろうが)を他のオブジェクトから隠蔽すること。他のオブジェクトからは特定の部分(公開インターフェース)にだけ依存させるようにする。 もしカプセル化が出来ていない場合は依存している部分が変更されてしまったときに修正箇所を増やすことになる。

ポリモーフィズム

異なる振る舞いを持つオブジェクト群に共通のインターフェースをもたせ同じように扱えるようにする。継承によってインターフェースの共通化を行い、そのインターフェースに紐づく挙動を個々のオブジェクトに任せる

おまけ

オブジェクトは自分が何の責任をもつクラスから作られたものなのかを知っている必要があるってのが明示的に書いてあったのが気になった。 オブジェクトが自分が誰なのか知ってるのは当たり前なのだけれどこういうのをはっきり書くのは理論屋さんとかが考えるときの公理みたいな扱いになってるからなのかな