『Vue.js入門 基礎から実践アプリケーション開発まで』読んでのメモ
有休消化中なので時間をかけて手を動かしながら読み進めた。
メモ
1 ~ 7章
JSFiddleで動作を確認しながら読み進めるスタイル、非常に便利でよい。
過去の経験から上記はすんなり。下記の部分はVueに関しては初見だったので楽しめた。
- 親子間でのデータやイベントのやり取り
- Slot
- ミックスイン
- Vuexでのステート管理
Angularでも確か一緒だった気がするけどイベント内でemitを使う/プロパティに入れる、などで親子間のやり取りする理解。 そういえばFluxに則るフレームワーク触ったことは無かった筈だけどVuexに関する説明が分かりやすいのですんなり馴染めた。そもそも単方向になるというのを知っていたからかもしれない。ミックスインはまんまという感じだけど、Slotはあまりピンときてないので実践でより掴んでいくか。
8 ~ 10章
- Vue CLIを使って簡易アプリケーションのログイン周りを実装する
丁寧に書きすぎじゃないかと思うほどなので進めるのは容易だろう。ただ、読んでるだけでは分からないことがあるのでぜひ手を動かして欲しい。ローカル環境のChromeとchromedriverバージョンが合わずe2eテストが動かないなど…未経験者は多分そこで詰まるだろうな。
Appendix
- jQueryからの移行ポイントの例やNuxtJSについて
今回はVueそのものの理解を重視したのでAppendixについては手を動かしていない。フレームワーク類はどれか1つ触れておけば他のものの習得も容易になるので、フロントエンドフレームワーク未経験者はNuxt触っておいて損はないだろう。
所感
本書とローカル環境の差分によるエラーを潰せる程度の経験者であればまったく問題はない。React/Vue/Angularのいずれかの経験者であればまったく問題ないだろう。1から7についてはVueの公式サイトでも割と学習できるが、本書のみでがっつりというのもよい選択肢だと思う。あまりに久々にのぞいたからそう感じただけかもしれないが、Vue公式ってこんな充実してたっけ。
交流会が苦手な理由を考えてみる
言語化の訓練を兼ねて。
先日ある交流会(パーティーという表現だったかも)に参加した。
他人と話すのはそもそも苦手だが、今回はある理由で参加すべきだろうと考えた。
結局知らない人と話した回数は数えるほどだった。
観察していたが、人が集まる人もいれば、当然私みたいな人もいた。 こういう場を苦手と感じるのはなぜか、理由を考えた。
一言で表現すると、価値を感じられないということに尽きる。興味の湧かない買い物に付き合わされる感覚に近い。たとえばある製品を購入するという明確な目的があればよいが、特に目的なく話すことに何の価値も感じられない。
人間は立場により豹変するものなので、その場に目的や価値を見いだせる属性を持った場合には振る舞いが変わると考えている。
元財務官僚が5つの失敗をしてたどり着いた これからの投資の思考法
年末年始の休暇に読もうと考えてたけどそれ以前の移動中に読了。
ロボアドバイザーを使った投資としてWealthNaviとTHEOの2つに早い段階から手を出していた。
最近WealthNavi1本に絞ったタイミングでこの本の存在を知って購入。
所感
本書で著者は、自身の体験を交えながら、長期・積み立て・分散の原則で金融資産を増やすことの重要性を説いている。定期預金に預けておくだけで老後の年金と合わせて充分な資産を形成できた現在のお年寄りと異なり、現役世代にとっては必須だと私も考えている。
本書だけでなく折りにつけ目にする r > g
の式は本当に残酷だが、事実である。その為、富裕層でない段階からrを意識した投資行動をしなくてはならない。
私の過去の経験上、 リバランスやリスクについて人間の脳が正しい投資行動を取るのが難しい
という意見には同意せざるを得ない。恥ずかしながら高く買って安く売るのを幾度となく経験してしまっている。
AIを通じ、富裕層のみが受けられるプライベートバンキングサービスを現在の保有資産に関わらず受けられるようになるなら素晴らしい。ロボアドバイザー投資がその役目を果たすか否かは今後気になる。
お金は大事だけどそれ自体が幸せではない
のは確か。お金により得られる自由が一番重要。
まとめ
- まだ実験的とは思うが、プライベートバンキングサービスとして考えるなら1%の手数料は妥当だと考えるようになった
- WealthNaviのようなロボアドバイザー投資がマス層に対するプライベートバンキングの役割を果たしてくれることを望む
- 次いく会社はやはり興味がある方面(健康 or お金)に関われるところにしようかな
プロダクトマネージャと組織の壁(20~30人)についての解釈
ここ半年くらい悩んでいたが結論が出たので書く。
プロダクトマネージャそのものに関しては方々の記事で書かれているので省略する。
組織の壁が現れる経緯
創業当初は数人なので全員が自分のやるべきことに集中していればそれが事業の成果として現れやすい。 しかし、数十人規模になってくるとそれまでのように成果が現れづらくなる。 また、ビジネスとエンジニアの不要な衝突が目につくようになる。
全員が仕事に対しこれまで通りに全力で通り取り組んでいるつもりだが、方向性が同じでなくなっているからだ。 経営陣が全員にビジョンを共有しているつもりになっているだけの場合にまま起こる。
プロダクトマネージャの必要性とやること
しかし、経営陣がより現場に入るということになっては事業の拡大は望めない。 拡大が不要な場合はそもそも人数増やさなければよい。
よって経営と現場の仲立ちをしながらプロダクトを発展させるプロダクトマネージャが必要になる。
彼のやることで最も重要なものは よいプロダクト(サービス)をリリースし続けること
である。
そのためには次のことを行う必要がある。
経営・現場などあらゆる場所に存在するステークホルダーを鑑みて
よい
の指標を定義する- ボラティリティの低い指標を複数用意する
- 課題の優先付けに利用し、ビジネスとエンジニア間の不要な衝突を避ける
- 外部環境の変化など必要な変更は随時行う
指標を取得する方法を検討する
- 設計段階からデザイナ・エンジニアと話す
- エンジニアはデータ分析基盤を構築する
指標を元に改善を行う
- 全員がデータを認識、意識して行動するように持っていく(データを見る文化を育てる)
- これが無い場合、よいプロダクトを提供していると誰も言えない
プロダクトマネージャをどのように組織に組み込むか
この問題が発生している場合はそもそも相応しい人物が社内にいることは少なく次の三択になると思う。
- 社外からスカウト
- 外部専門家を活用 + 候補社員を育てる
- 候補社員が必死に頑張る
いずれをやるにしても経営陣が必要な権限と責任を委譲できるかがポイント。あと、おそらくついていけないメンバーも現れる。ただ、その場合には採用をすでに失敗しているだけだと思う。
私の場合には最後の選択肢(候補社員が〜)は無いとは思うが、さてどうなるか…
RubyKaigi 2018 1st day
参加したのでメモ
Keynote by Matz
- 名前重要
Q&A
- 今後、静的型付けをRubyの機能として組み込む方向になるのか? #=> するつもりはない
Analyzing and Reducing Ruby Memory Usage by Aaron
日本語で講演するとかほんと尊敬に値する。
Rubyでメモリ使用量を抑えるにはという内容。
- コード読め
- malloc stackをトレースせよ
の2つにアドバイスは集約される。
- ObjectSpace
- AllocationTracer
- GC::Tracer
を使う。ただし出力したログによるディスク容量圧迫に注意する。
=>mallocをcallする箇所とその量を特定するのが重要
次の2つは何でメモしたか覚えてない
- Direct iSeq Marking
- Ruby 2.6に上げることをお勧めする
Hijacking Ruby Syntax in Ruby by joker1007 and tagomoris
楽しそうに喋ってた。
を使えば例えば with (Python) や defer (Go) のまねごとができるという話。
ただしデバッグが超面倒
All About RuboCop by bbatsov
lint is not replacement for common sense という手元のメモがあるだけ。
RubyGems 3 & 4 by hsbt
現行2.7のRubyGemsが今後どうなるかという話。
3.0
- 移行バージョン的な位置づけ
- Gem::Deprecate便利
- depreacatedにする or 削除する場合、gem-codesearchを使って調査
4.0
- 3以下と非互換にする
- conservable
- user-installのデフォルト化
Exploring Internal Ruby Through C Extensions by Yuryu
- CRuby内ではVALUE type (ポインタや値を格納) がよく使われている
- メモリ利用量のチェックには Valgrind が使える
- Hash操作に関してはRubyは充分早い
- C拡張を使うケース
- x: パフォーマンスを理由に使う
- o: Rubyから外部ライブラリを使うI/Fを用意するために使う
所感
- メンテナは本当に大変だろうし仕事でやってない人は気の毒に感じるようになった。年のせいか。
LINE BOT APIの署名検証
検索すると、やってみた系の記事は見つかるものの、Pythonで署名検証してるものが見当たらなかった。
動作確認まで完了したので、検証用の署名生成メソッドを書いておく。
import base64 import hashlib import hmac def generate_signature(http_request_body, channel_secret): digest = hmac.new(channel_secret, http_request_body, hashlib.sha256).digest() return base64.b64encode(digest)
LINE Developers - BOT API - BOT API Trial quick start guide にはJavaとRubyの例のみ記述あり。