arveltのソフトウェア技術メモ

Arvelt's software technology memo

ファクトフルネスを読んだ

1日1ドル未満で暮らす子どもたちは増えただろうか。減っただろうか。
初等教育を受けられる低所得の女性のの割合は3割だろうか。6割だろうか。
紛争で亡くなる人は増えただろうか。減っただろうか。

 
これらのことがわからないのならば読んでみていいと思う。  
人はみな、自分が見たいものを見ている。 そうならないためにどうすればいいかを教えてくれる本だ。
 
単にこれらの事象そのものだけにとどまらず、物事の見方ということを考えざるを得なくなる。
 

  • 大半の人がいるところを探す
  • 悪いニュースの方が広まりやすい
  • 直線も曲がる
  • リスク計算する
  • 数字を比較する
  • 分類を疑う
  • 変化はゆっくりと起きている
  • 1つのことが全てに応用できるわけではない
  • 犯人探しでは解決しない
  • 小さな一歩を重ねていく

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

エンジニアの知的生産術読書メモ

読んでたけどメモほっぽりっぱなしだったので放出。エンジニアなら大なり小なりやっていることを、明確に言語化せしめたのは素晴らしいことだと思う。間違いなくエンジニアに限らない、誰でもためになる良書。なにかに取り組む前にさっと目を通して備えられるように、自分の中に積みあげておきたく感じる。

学び

  • やる気の維持
    • 小さいゴール
  • 良い参考書を選ぶコツ
    • 大学の講義の参考図書に選定されている
    • 正誤表が充実
    • 改定されたロングセラーである
  • 学習のサイクル
    • 情報収集→モデル化→検証
  • 情報収集
    • 知りたいと思うところから学ぶ
    • ソースコードの読み方 by Matz
      • 全体を読もうとしない
      • 目的を持って読む
    • 達成可能な目標。明示的な目標を掲げる
    • 大雑把に全体を把握する
    • 写経が再び必要になるとき
      • 写経の必要もなくすんなり理解できたとおもったのなら、それはすでに学んだことで構成されていて、新しいことを学べていないということ
    • どうやって抽象化するか
      • 比較する。同じ箇所と違う箇所の間を見る
      • 例える。どこが同じでどこが違うのかを明確にする
      • 違いに注目する
      • 歴史から学ぶ。以前と以後で何が変わったか
      • すでに抽象化されたパターンから学ぶ。ただし、自分の言葉で、自分の経験として、自分の目的に使えるか?

やる気

  • やる気がでないのは、やることを絞れていないせいである
  • 絞るためにはまず全体像を把握する
  • 優先順位付け自体が難しい
    • トレードオフスライダー
    • 探索と利用のトレードオフ → 不確かなときは楽観的に
    • フィーチャーの判断基準。金銭価値、コスト、新しい知識、リスク
    • 緊急と重要のマトリクス
  • タスクが大きすぎる

記憶

  • アウトプットで記憶が鍛えられる
    • 覚えている自信がなくてもテストを繰り返すと成績は高くなる
  • 忘れてから復習するのは長期の記憶に役立つ
    • ライトナーシステム
    • supermemo
  • 間隔反復法
  • 知識を構造化する20のルール

読書

  • 「読んでない本」は、先に概要を調べる・読んだ人に聞くなどして、読むべきかどうかの判断ができる
  • Whole Mind System
    • プレビューする。
      • 5分ほどで目次やキーワードについて把握する。
    • 質問を作るためによむ。
      • ○○せよと書いてあるが、これは具体的にどういう行動か?
    • 答えを探すために読む
    • マインドマップでメモする
  • フォーカス・リーディング
    • 読む速度をコントロールすることで理解度を測る
  • どちらも見出しに注目する
  • 難解な本を読む技術
    • 本棚を見て分野の全体像をスケッチする
    • 読書ノートを作る
      • わからないことを記録する
      • 何度も出現する単語を記録する
      • 概念や理由の関係性を矢印でつなぐ
    • わからないことを解消するために読む
  • 読むという行為の目的はなにか
    • 必要なときに読み返せるように頭の中に地図を作る
    • 本の内容とそのほかの知識を結びつけるために読む。Syntopic Reading
    • 概念の名前を知ることで思考の道具を手に入れる
  • 復習のためのメモを作る

思考

  • 書き出し法
    • テーマに対して書き出す
    • 質ではなく量
    • 重複も気にしない
  • 情報をまとめる
    • KJ法
    • ふせんに書き出し並べて一覧性を上げる
    • 関係ありそうなものをまとめる。
    • グループ化して表札をつける
    • 分類できないと思ったときは分類の基準が間違っている。
    • 既存の分類を使うのではない
    • 階層は作らない
  • 短縮化
    • 表札は作らずとも良い
      • 中断可能であるように工夫する。ふせんをはるのはA4用紙にするなど

ひらめき

  • 3つのフェーズ
    • 耕す
    • 芽生える
    • 育てる
  • 「アイデアのつくりかた」ジェームズ・W・ヤング
    • 資料集め
    • 資料の加工
    • 努力の放棄
    • イデアの誕生
  • 「発想方」川喜田二郎
  • 情報を収集する
    • 言語化を促す
    • 言葉になっていないもの
  • 磨き上げる
  • 最小限の実現可能な製品
  • 他人の視線

2018年を振り返って

前年度たてた目標

コードリーディングする
 Django
 Goole App Engine SDK
 自社製品のコード
周辺環境やライブラリについて調べる癖をつける
 アップデートしたりメンテナンスしたりできるようになる
漫画を書く
 例大祭冬コミ

目標を達したか

  • コードリーディングする
  • 周辺環境やライブラリについて調べる癖をつける
    • 全然やってない
  • 漫画を書く

所感

漫画しか書いてねえなこいつ…(1年ぶり二度目
プログラミングができなくて困っているのだが、できるようになる道筋はもはや見えない。なんでプログラマになったのか。なのでプログラマ以外の職業へと転職を考えてはいるのだが年齢がいきすぎてもはや機会を逸している。苦痛なプログラミングといかに向き合っていくのかということを考えていかなければならない。
10年やってプログラミングが身につかなかったという事実から自分の才能をすでに見限っているのだが、ことWebに関して言えばまだ触れ始めて5年であるともいえる。できる人は半年もすれば全てを掴んでしまうのであるが、そこは凡人以下の私であるので天才の 1000倍時間がかかったとしても驚きはない。

という風に将来を悲観しているのだが、仕事で完全新規のAndroidアプリを一人で作ったりしていた。そういうのはできるようだ。もしかしてWebよりもネイティブモバイルのほうが性に合っていたかとかそういう話なのだろうか?
ならWebやめてモバイルやるかーと思ったが、これも年齢のせいで転職はできない。作れるだけなら若い人間でいいわけで、プラスアルファーが必要という話である。とはいえアプリ作るの意外と嫌でなかったので勝手に勉強するのはやぶさかではない。
これはそういう勉強のやり方ばっかりやってたのでそうなったのだと思う。つまり新しい技術のプロトをさっと作るという方面には可能性があるようだ。ただこれ正社員ポジションでやることじゃないんだよな…。
そうはいっても今いるのはWebの会社なので。Webの中でやれるようなことを探していく必要があるのだが、技術側は諦めて人間寄りの方を模索するのも1つだなと気づいた。好きじゃないけど。私は好きと得意がかけ離れるタイプの人間のようなのでおそらくやってやれないことはないのだろう。
組織寄りプロダクト寄りビジネス寄り、技術を理解できる人間がそっち方面で果たせる役割というのを探ってみたいと思う。
漫画描き。好きではないがわりかしこなせるというだけでプログラミングをやっているので大変なストレスと苦痛と共に過ごしている。そこでストレス解消のために全然別のクリエイティング行為であるところの漫画がハマったのではないだろうか。まんがかくのたのしいかみえしになりたい

来年の目標

  • モバイルアプリ勉強する
    • これは単純に興味あるので
  • 新しい技術をいち早く試す
  • コードリーディング
    • Web関連のコードを読んだ絶対量が少ない問題
  • 技術プラスのスキルの模索
    • 一番地続きはプロダクト方面。仕様や設計には適正がなかったので、運用とか改善の方面
  • 漫画を書く
    • 例大祭。それと夏か冬のどちらか

kotlin fest 2018に行ってきた話

最近Androidアプリをkotlinで書こうとしています。ちょうどkotlin fesがあったので行ってきました。 スライド公開されているのでだいたいこの辺から見ることができます。

kotlin.connpass.com

「Kotlinアプリのリファクタリングポイント」と「Kotlin コルーチンを理解しよう」あたりが私に良かったなぁという気がします。 実際kotlinでモバイルやろうとすると、それはAndroidの仕組みの話なの?Javaの話なの?kotlinの話なの?みたいのが混ざってしまいさっぱりわからなくなってしまいがちです。

結局Javaなので詰まったらJavaまで降りていかないと行けないみたいなときもあるっぽいので、絶対に降りないように凝ったことするくらいならその仕様にNoを突きつけるくらいでいきたいですね。大変な思いをするためにプログラミングをやっているわけではないのでツラさを押し付けてくるなら殴り飛ばしてやるからなまじでおまえまじでこの野郎おまえ

あとyahooブースでモブプログラミングとか初めて見ましたけど。昔ペアプロもそんなうまくやれなかったし。ほんとに効果あるんでござるかぁ?みたいな気持ちでいます。ああいうの合うタイプと合わないタイプがあるんですかね。ペアプロとかモブプロって優秀な人がさらに加速するための装置であって、普通の人が普通のことをやるには向いてない気がします。でもOvserber.delegate()でしたっけ?は初めて知ったのでありがとうございます。

あとwebDB pressの特集でkotlinがきたり、kotlin盛り上がってますねー

f:id:arvelt:20180825105757j:plain f:id:arvelt:20180825125253j:plain f:id:arvelt:20180825105745j:plain

Androidアプリを手動で別の端末にインストールする

Androidアプリを手動で別の端末にインストールする。 OculusGoのVRビュワーが使いにくいので一番使いやすいと思ったやつをOculusGoで動かせるか試したりしたので覚書。ちなみに動きませんでした。ですよねー

$ adb devices
List of devices attached
XXXXX17510009999    device

$ adb shell pm path se.chai.vrtv.free
package:/data/app/se.chai.vrtv.free-1/base.apk

$ adb shell cp /data/app/se.chai.vrtv.free-1/base.apk /storage/emulated/0/Download

$ sudo adb pull /storage/emulated/0/Download/base.apk
/storage/emulated/0/Download/base.apk: 1 file pulled. 23.4 MB/s (15921479 bytes in 0.650s)

$ adb devices
List of devices attached
XXXXX8177   device

$ adb install base.apk
Success

Linuxのしくみを呼んで

Linuxのしくみの読書メモ。ていうかこれほぼ目次だ

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

Inspired: 顧客の心を捉える製品の創り方 を読んで

Inspired: 顧客の心を捉える製品の創り方 の読書メモ。だいぶいい本だったのでおすすめ。実際に積んだ人間が、こうしたときはうまくいったよ。というのを教えてくれる。

ベストプラクティス

  1. プロダクトマネジメントの役割
  2. ユーザーエクスペリエンスの役割
  3. 製品の市場性評価
  4. ユーザーモニター制度
  5. 製品原則
  6. ペルソナ
  7. 製品のアイデアを見つけ出すことに集中得する
  8. プロトタイプの活用
  9. ターゲットユーザーとプロトタイプをテストする
  10. 改善するためにはデータを使う

プロダクトマネージャーの懸念事項リスト

  1. この製品は、ターゲット顧客の心に届いているだろうか
  2. 私達は、出来る限りのことをやり尽くしてこの製品を使いやすいものにしただろうか
  3. この製品は、競争に勝てるだろうか。今現在の競争ではなく、製品をリリースする時点での競争に勝てるだろうか。
  4. 私は、この製品を実際に買ってくれる顧客のことを理解してるだろうか。私が望んでいる製品ではなく、自分たちが作ろうとしている製品を買ってくれる顧客のことである。
  5. この製品は、本当に差別化できているだろうか。どう差別化できているかを、会社の経営陣には2分で、頭の良い顧客には1分で、業界アナリストには30秒で説明できるだろうか
  6. この製品は、実際に動くだろうか
  7. この製品は、欠けているところがなくあるべき製品として全体となっているだろうか。顧客はどう思ってこの製品を買うだろうか。それは私達が計画した売り方と一致しているだろうか。
  8. この製品の強みは、顧客にとって大切なことと一致しているだろうか。私たちはその強みを積極的にアピールしているだろうか
  9. この製品にお金を払う価値はあるだろうか。それはいくらで、理由はどうか。顧客はこの製品に代わるものを他でもっと安く手に入れることができるだろうか
  10. 私は製品開発チームのメンバーがこの製品のどこが優れていると思っているかを理解しているだろうか。それは私の考えと一致しているだろうか

市場調査

  • 現実にユーザーはだれなのかを理解しているか?
  • ユーザーは製品をどんなふうに使っているのか?
  • ユーザーは製品をどうやって使うかを理解できているか?ユーザーはどこでつまずくだろうか?
  • なぜユーザーはこの製品を使うのか?
  • ユーザーは製品のどこが気に一致得るのか?
  • ユーザーは製品のどこが気に入っているか?
  • ユーザーが製品にあればいいと思っていることや、変えてほしいと思っていることは何か?

製品仕様

  • 仕様書には、ユーザーエクスペリエンスが全て記載されていなければならない
  • 仕様書には、ソフトウェアの動作を正確に表現しなければならない
  • 仕様書はそれぞれの立場にとって必要な内容が全部盛り込まればならない
  • 仕様書はアップデートされなければならない
  • 曖昧さ、混同を避けるため、マスターを1つ用意する必要がある
  • これらを満たすのはハイファイプロタイプである。ハイファイとは提案されているユーザーエクスペリエンスを正確に再現することである

製品仕様の検証

  • 実現可能性の検証
  • 使いやすいかどうかの検証
  • 買いたいと思ってもらえるかどうかの検証

製品における感情の役割

  • 顧客に製品を買う気を起こさせる感情にどんなものがあるか
  • 自分たちの製品以外には他のどこでその欲求を満足させることができるか

個人向け製品で大切なこと

企業向け製品で大切なこと

  • 使いやすさ
  • ちゃんと動くこと
  • 特別仕様
  • ユーザーモニター制度
  • 顧客vsユーザー
  • 製品のインストール
  • 製品の設定・カスタマイズ
  • 製品のアップデート
  • 販売プロセス

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方