リソースの調整は上司の役割だょ

GWの飛び石連休埋めようと思って年休申請したらまた上司と価値観の違いで衝突した。単純に、俺は飛び石連休あったら年休使って休むのが当然だと思ってるし、上司はそう思ってないってだけ。

ただ、それでも申請通してくれるあたりは公務員らしくちゃんとしてる。労働者の権利だもんな。

どれだけ価値観が合わなくても自分のコンセプトを話せるのは正直楽しい。向こうから新しいコンセプトを提供してくれれば取り入れるけど、今のところ目新しいものはないのが残念なところ。

その中でこんな会話があった。

「2日とも休むんじゃなくてKさんがこっち出たら自分はこっち出ます、って言おうとか思わない？」

「思いません」

そう思わないのはともかくとして何かが引っかかった。

で、たぶんそれは部下二人で対処するのが前提にあるからだ。本来、部下の仕事はすべて上司がやるものを請け負っているだけなので、俺が休んでKさんに負担がかかってるのは俺に責任がない。俺もKさんも自由に休めばいいし、それで部下二人に断られたら上司がやればいい。それで部下のクビを切るのも上司の自由だ。

「思いやりを持てば信用されるでしょ？」とも言ってたけど、そもそも信用は「人を動かす」ための手段のひとつなので、その人を動かそうと思ってないならそんなリソースは必要ない。なんでやりたくないことをしてまで必要ないものを手に入れる必要があるんだ？（年休の申請を通すだけなら信用を使わなくても労働基準法とかあるし）

本当に信用されなければならないのは上司なんだ。俺もKさんも自由に意思決定して、その上で上司が解決しなければならない問題に対して部下をあてがう。そのために、信用（人を動かすためのリソース）が必要、というだけ。信用は後払いの報酬（への期待）なので、信用がなかったら金品とかでもいい。

俺に信用があろうとなかろうと、俺が休んだときKさんを動かすのに必要なのは、上司がKさんに十分な報酬を支払えるかどうか。その一点に尽きる。まぁ、Kさんは俺と違ってクビは嫌だろうから損失を回避するために動いてくれるだろうけど。

mapstore

眠かったはずなのに風呂から出てずっとMapStoreいじってた。

github.com

とりあえずなんか適当なリストを出力するだけ。ImmutableJSの使い方がよくわからなかったからほぼ写経。そんでflux/utils使ってなかった頃に作ってたのと併せて修正した。

Flux楽しいんだけど、ImmutableJSはもうちょい覚えないとダメだわ。for-ofのとこ何使えばいいのかわからなくてチュートリアルそのままfor-of使った。なんかmapとかにしたかった。寝なきゃいけないしまた今度にしよう。

ひまなしごと

最近、職場で使われてるFileMakerっていうAccessみたいなソフトよく触ってる。まず日常的に使うことはないと思われるソフトだから意味はないんだけど、じわじわとできることが増えてて複雑。マクロなんかは全然触ってないけど、正直そこまでやるならAccess使いたい。まだ使うこと多いだろうし。

それにしても今日は1時間くらいしか働いてない。これバイト雇ってる意味あるのかなぁ。俺が上司だったら俺をクビにするけど。

flux/utils

flux/utilsの試しに数えるだけのアプリ作った。

https://github.com/uguisu-an/flux-counter-app

参考にしたのはFluxの公式サイトがほとんど。

わりとドキュメント整ってていい。むしろ元のネタはReduxのCounterだけど。

ReduceStore便利だけど、Containerちょっといまいち。Container継承して作れるようにしてほしいけどそうなるとfluxがreactに依存しちゃうのか。

flux

flux勉強してるんだけどactionとかいまいちわかってない感じ。

あとフレームワークはまだまだ群雄割拠でもう本家のfluxでいいんじゃないかと思った。Reduxもあんま変わらないような。

ただDispatcherはちょっとつらいから使いたくないのはわかる。

結局、Observerで繋がってるのがめんどいからObserverもっと根本的に勉強したほうがいい気もする。

Asynchronous

FluxのDispatcherとかStoreとか勉強してたとき非同期処理が出てきてよくわかんなかったから勉強した。

とりあえずPromiseとasync/awaitで、Generaterはもういいかなって。まぁ、async/awaitあったら要らんやろ。使用策定中のPresetまで入れなくても使えるのはいいんだけど。

結局、asyncで関数定義すると、そのまま実行したときはPromise.resolve(returnの値)、await付けて実行したときは非同期処理だけどそこだけ同期っぽく待ってreturnの値を返すようになるみたいね。先にPromiseの勉強しといてよかった。

PromiseのAPI自体は分かりやすかったけど、Promiseは定義したその場ですぐさま実行されるというか、Promiseオブジェクトが予約券になってそれだけ返ってくるというか、なんとなく把握してる感じ。あとイベント駆動なのにresolveでonFulfilledが呼ばれるって書かれてるとこが多くて混乱した。中ではそうかもしれんけども。

ES.next async/await + Promise で解決できる事、とES6 generators (yield) + Promise + npm aa (async-await) で解決できる事 - Qiita

この記事にも載ってるけど、async/await使ってても2本以上走らせるときはPromise.all生で使わないといけないのかな？

遊んだ結果が以下のファイル。

gist.github.com

event emitter

非同期処理とかやるときはEventEmitter使うみたいだからちょろっと勉強した。というかFlux勉強してたらStoreのとこで出てきてわかんなかったから仕方なく。
とりあえず、pub/subの思想を体現してるみたいだから思想そのものを調べたらすぐ理解できた。後でやることを先に決めとく、ってことだ。あとはトリガーが走るまで待ってるだけでいい。ちょっと楽しい。
非同期処理に使うメリットはいちいち「終わったよ」用のcallbackを渡さなくてもEventEmitterのインスタンスがあれば代わりに受け持ってくれるから、やたらcallback渡さなくてもいいってとこか。残念なことにPromiseはまだ勉強してないので試せない。次だ次だ。

ReactのGuidesもおおよそ読み終えて、まぁ、あんま新しい情報はなかったけどそれなりに使えるようになった。ちょっとstateを最上位だけに持たせて下にpropsで渡していくの、イベントがあるとだるい。これを解決するのがDispatcherとStoreってことだろうか。

StoreのEventEmitter#onでstateに値を返すようにするのかな。そのへんはまだ。でもそうすればDispatcherやStoreの動作が非同期でも終わったら勝手にViewが更新されるよね。たぶんそういうことだ。