読者です 読者をやめる 読者になる 読者になる

雀巽の日記帳

雀巽が綴る日常の記録

「ファスト&スロー」が世界の見え方を変えてくれる正にバイブルだった

日常生活 読書生活

「ファスト&スロー あなたの意思はどのように決まるか?」を読みました。

心理学者にしてノーベル経済学賞受賞者のダニエル・カーネマンによる 「人間の意思決定がどのように行われているのか」について書かれた本です。

会社の役員にオススメの本を聞いたら「ファスト&スローが俺のバイブル」と返ってきたので読んでみたのですが、バイブルという意味が理解できました。

人間の意思決定が予想以上に合理的でないこと、かなりのケースで認知バイアスが働いており、かつそれから逃げられないこと、 それらがどういったシチュエーションで起きやすく、どういったパターンが存在するのかなど、色々なことが書かれていました。

これらについて自分がまさにエラーに陥る様を体感できるようにも書かれており、実感を持って知ることができます。

要は「世界の見え方が変化する様を体感できる本」です。

アマゾンのトップカスタマーレビューにも「世の中を見る目が間違いなく変わる」とあるのですが、全く同じ感想です。

是非、読んでみてください。

Visual Studio Code 入門~オススメ設定と拡張機能編~

ITライフ

Visual Studio Code のオススメの基本設定、キーバインド拡張機能を紹介します。

どちらかというと、言語ごとに特化した設定や拡張よりも、コーディング全般が便利になる設定や拡張を多く取り入れています。

一応補足ですが、普段は Ruby on Rails か React Redux を書いていることが多いです。

オススメ基本設定

タイトルにルート相対パスを表示

デフォルトだとファイル名しか表示されていないため、同名のファイルがある場合判別が難しくなります。

そのため、プロジェクトルートからの相対パスを表示するようにしています。

{
  "window.title": "${dirty}${activeEditorMedium}${separator}${rootName}${separator}${appName}"
}

インデントガイドを表示

その名の通り、インデントのガイドが表示されます。見やすいです。

{
  "editor.renderIndentGuides": true
}

80文字目と100文字目にガイドを表示

1行は80文字以内目標、100文字以内必須でコーディングを行っているので、80文字と100文字のところにルーラーを表示しています。

{
  "editor.rulers": [80, 100]
}

ちなみに、「現代のディスプレイは横に長いから1行の文字数はもっと多くて良い」という意見には真っ向から反対*1です!

最終行に改行を追加

POSIX のテキストファイルの定義だとファイル末尾は改行だと定義されている*2そうです。

改行で終了していない場合、Git の表示でもそれを強調してきますし、少々不便なこともあるので、ここは POSIX のテキストファイルの定義に自動で従ってくれるように設定しています。

{
  "files.insertFinalNewline": true
}

オススメ追加キーバインド

機能自体は用意されているものの、キーバインドが設定されていないもので、個人的に良く使うものを挙げます。

大文字小文字変換

Ctrl+u で大文字化、Ctrl+l で小文字化を行うようにしました。

[
{ "key": "ctrl+u", "command": "editor.action.transformToUppercase",
                      "when": "editorTextFocus" },
{ "key": "ctrl+l", "command": "editor.action.transformToLowercase",
                      "when": "editorTextFocus" }
]

複数行を1行にまとめる

Ctrl+j を割り当てました。

[
{ "key": "ctrl+j", "command": "editor.action.joinLines" }
]

オススメ拡張機能

オススメの拡張機能を用途別で紹介します。

コーディング全般

vscode-icons

ファイルやディレクトリのアイコンです。

種類が豊富で EXPLORER がとても色鮮やかになります。

{
  "workbench.iconTheme": "vscode-icons"
}

Path Intellisense

ファイルやディレクトリのパス入力の補完を行ってくれます。

Sort lines

その名の通り、ソートを行ってくれます。

大文字小文字無視、行の長さでソート、重複削除など、便利な機能が一式揃っています。

change-case

変数名や定数名などを色々な記法に変換してくれます。

キャメルケースからスネークケースにしたりできます。

Trailing Spaces

行末のスペースを強調表示や、削除が行なえます。

行末のスペース削除機能も、標準機能より機能が豊富で、編集した行のみを対象とすることもできます。

Bracket Pair Colorizer

括弧をカラフルに表示することで、入れ子になった括弧の対応関係の把握を簡単にしてくれます。

Code Runner

色々な言語のコードスニペットがサクッと実行できます。

REPL を起動するまでもないような動作確認などで活躍します。

Git

GitLens

機能てんこ盛りの拡張です。Features の数を見ていただければそのてんこ盛りさがわかると思います。 git blame がいい感じで見れたり、コミット間の diff が見れたり、色々します。

Blame Annotations がかなりイカしてます。

初期設定だと少々お節介すぎたので、あまり見ない情報をエディタ上に出さないようにしています。

{
  "gitlens.blame.annotation.activeLine": "hover",
  "gitlens.codeLens.recentChange.enabled": false,
  "gitlens.codeLens.authors.enabled": false
}

また、Linux ではいくつかの機能で xclip を利用しているので、そちらも導入しておきます。

# zypper install xclip

Git History (git log)

その名の通り、History に特化した拡張機能です。 GitLens だけだと手が届かない部分をカバーしてくれます。

Line History をサクっと見れるのが便利です。

HTML (JSX)

Auto Rename Tag

対応するタグも同時に編集してくれます。超有能。

Auto Close Tag

自動で閉じタグを入れてくれる拡張機能です。

デフォルトの設定だと Emmet 記法での入力時に余分な閉じタグが挿入されてしまうので、設定を変更しています。

{
  "auto-close-tag.SublimeText3Mode": true
}

デフォルトの挙動では > 入力時に閉じタグが挿入されますが、こちらの設定では </ 入力時に閉じタグが挿入されます。

実は Emmet との競合の有無は関係なく、こちらの挙動のほうが好きです。笑

JavaScript

npm Intellisense

npm モジュールの入力補完を行ってくれます。

コーディング全般の項目で紹介済みの Path Intellisence と同じ作者です。

ESLint

ESLint を自動実行し、エディタ上に警告を表示してくれます。

React Redux ES6 Snippets

その名の通り、React Redux の ES6 でのスニペットです。

スニペットのトリガーとなるプレフィックスがシンプルで、特に覚えることなく使えます。

Ruby

Ruby

てんこ盛り系の拡張機能です。

自動補完は以下の Gem*3 を導入することで有効になります。

$ gem install fastri rcodetools

現時点では Lint 機能を利用し、Rubocop を自動実行するようにしています。 こちらも ESLint と同様、エディタ上に警告を表示してくれます。

{
  "ruby.lint": {
    "rubocop": true
  }
}

ruby-snippet

Rubyスニペットが一式入っています。大体はこれでカバー可能だと思います。

スニペットのトリガーとなるプレフィックスがシンプルで、特に存在を意識することなく使えます。

slim

slim のシンタックスハイライトが有効になります。

設定管理

Settings Sync

Gist を利用した設定の同期が可能になります。

これなしだと複数環境ではやってられないです。

EditorConfig for VS Code

EditorConfig の VS Code 用拡張です。

詳細は省略しますが、EditorConfig を使うとエディタの基本設定を色々なエディタで共有することが可能になります。

関連記事

necojackarc.hatenablog.com

*1:全員が全員1ファイルを横長のディスプレイに全画面表示して作業をするわけではないですし、そもそも横に長過ぎると視線の移動幅が広すぎて大変です。Diff を縦分割で見る際も不便です。

*2:なぜ gcc はファイルの最後に改行がないと警告を出すのか?

*3:fastrircodetools 導入時に推奨されますが、必須ではありません。

Visual Studio Code 入門~導入から Gist による設定管理まで~

ITライフ

Windows 環境のエディタが Notepad のみという尖りきった環境だったので、Visual Studio Code を入れてみることにしました。

インストール

Setting up Visual Studio Code に従いインストールします。

今回は Windows 10 へ導入したので、インストーラーを落としてポチポチするだけでした。メッチャ簡単。

Github Gist を利用した設定共有

Github Gist を利用し、設定の同期を行う拡張機能を導入します。

Github の Personal Access Token も必要なので、作成します。

準備が整ったら Gist への初回設定アップロードを行います。

  • Shift + Alt + U を押し、Github の Personal Access Token を入力

これで基本は完了です。別のマシンで設定をダウンロードする場合は、

  • Shift + Alt + D を押し、Gist ID を入力

OK です。

設定の自動同期を行う

面倒臭がりなので、起動時に設定のダウンロードを行うようにします。

  • “Sync : Advanced Options > Toggle Auto-Download On Startup”

また、設定変更時にアップロードを行うようにもできます。

  • “Sync : Advanced Options > Toggle Auto-Upload on Setting Change”

個人的にはこちらは Off で良いかなと思います。

これで完了です!超簡単!

感想

Windows 環境に Vim を入れる気が起きなかったので入れてみただけなのですが、流石人気エディタだけあって色々快適です。

標準で Ctrl+K V で Markdown のプレビューが見れるのカッケェっす。

気が向いたら色々試してみようと思います。

Tips

Rails の Time#since で混乱したのでまとめる

ITライフ

Rails というか ActiveSupport の Time#since で混乱しました。

これまでに混乱した since の使われ方一覧はこちら。

time.since(2.days)
time.since(-2.days)
2.days.since

ぜ、全部わけわかんねぇ……。

とりあえず -2.days は疲れてた故の過ちだったぽいので良いです。 しかしやはり、time.since(2.days)2.days.since もぶっちゃけよくわかりません。

ActiveSupport の Time 拡張は、基本的に英語力に自信がなくても直感的に読める場合が多かったのですが、正直この since の使い方はよくわからなかったので調べました。

since(seconds)

Returns a new Time representing the time a number of seconds since the instance time

Also aliased as: in

Time#since

要するに、time.since(2.days) はこの説明通りに読むと、2 days since the time となるようです。

完全に場所が入れ替わってる……これはわかりにくいはずですね。

これの alias は Time#in らしいので、それを使えば time.in(2.days) となりスッキリ書けます。超わかりやすい。

で、次は 2.days.since のターン。これまた全然わからん。

というわけで、調べます。

since(time = ::Time.now)

Reads best with argument: 10.minutes.since(time)

This method is also aliased as from_now

Module: ActiveSupport::CoreExtensions::Numeric::Time#since

引数ついてると読みやすい的なことが書いてあるとおり、たしかに引数があるならわかりやすそうです。

ただ、引数がない場合は alias の from_now を使ったほうが遥かに意味が明瞭ですね。

まとめると、

time.since(2.days) # => time.in(2.days) or 2.days.since(time)
2.days.since # => 2.days.from_now

ということですね。

こっちのほうがわかりやすい!!

「オブジェクト指向設計実践ガイド」を読んだ

ITライフ 読書生活

オブジェクト指向設計実践ガイド Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方」を読みました。

端的に言うと、めっちゃ良かったです!

これは良書だー!って感じでガツガツ読み進めました。

Effective RubyRuby 力をあげる本、リファクタリング Ruby エディションはリファクタリング力をあげる本(というかリファレンス)という感じでしたが、こちらは純粋にオブジェクト指向設計力をあげる本という感じでした。

オブジェクト指向プログラミングに触れた早い段階で読んでおくと、良いんじゃないかと思います。

以下、印象に残っているところを抜き出してみます。

SOLID

オブジェクト指向設計で最もよく知られている5つの原則の頭文字です。

  • Single Responsibility
  • Open-Closed
  • Liskov Substitution
  • Interface Segregation
  • Dependency Inversion

TRUE

変更が簡単なコードが持つべき4つの性質の頭文字です。

  • Transparent
  • Reasonable
  • Usable
  • Exemplary

TRUE の第一歩は単一責任原則とのことです。

個人的には「単一責任原則 (Single Responsibility Principle)」は名前付けとも大きく関わっていると思います。

クラス、メソッド、変数などに「適切な名前がつけれない」ときは、責任が一言で説明できないときであり、この原則に違反している場合が多いです。

オブジェクト指向設計とは「依存関係を管理すること」

いかに依存関係を整理し、変更しやすく保つか、というのがオブジェクト指向で設計する意味、だと思います。

アジャイルが有効である理由は、ソフトウェアがかたちになる「前」に確かさを手に入れることはできないと認めたから

建築に例えられることは多いですが、建築との違いの一つは「正確な模型」が容易には作れないことかなと感じます。

かたちになる「前」に確かさを手に入れられない、というのは、ソフトウェア開発の難しさの一つですね。

第一にやるべきことは、深呼吸をして「シンプルであれと主張すること」

パターンを学んだばかりの人が陥るとされる「間違った問題に対してパターンを適用する」みたいな事例を思い出しました。

KISS の原則を思い出しましょう。

メッセージに基づく視点は、クラスに基づく視点よりも柔軟なアプリケーションを生み出す

メッセージがオブジェクト指向の本質だよと伝わってくるメッセージです。

オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する

という文や、

オブジェクトを関連づけるのは、それが何をするかではなく、その間で交わされるメッセージ

という文もあり、メッセージパッシングこそがオブジェクト指向!というのが伝わってきます。

シーケンス図を利用すると、設計の議論がメッセージ中心となる

メッセージが大事なので、メッセージ視点になれるシーケンス図を使おうという話でした。

ホワイトボードに描き、必要に応じて変更し、その目的を果たしたら消す

これくらい軽い気持ちで書けばいいんだよ!と言うアドバイスも印象的でした。良い。

新たな継承の階層構造へとリファクタリングをする際は、抽象を昇格できるようにコードを構成すべきであり、具象を降格するような構成にはすべきではない

具体的には、スーパークラスにサブクラスの情報が残るおそれがあるので、一旦具象クラスにすべて置き、確実に抽象(共通)だと言えるものをスーパークラスにあげる、ということです。

直面した問題がコンポジションによって解決できるものであれば、まずはコンポジションで解決することを優先するべき

かつて「継承は最終手段」とも聞いたことがあるのですが、それを思い出しました。

使われていないコードは、復旧するより残し続けるコストのほうが高い

汚物は消毒だー!

プライベートメソッドを大量に持つオブジェクトからは、責任を大量に持ちすぎた設計の臭いが漂う

コードの臭いです。コードの臭いを嗅ぎ取れるようになるのはすごく重要です。

そうするのが適切な問題であれば、恥ずかしいコードを書くことに自信を持つ

以下、少し長めに引用します。

短い期間で、かつ、そうするのが適切な問題であれば、恥ずかしいコードを書くことに自信を持つことで、資金を節約できます。 設計の決定を遅らせることが目的であるときは、今ある問題を解くために一番シンプルなことをやりましょう。 めちゃくちゃなコードは、考えられ得る限り最善のインターフェースの背後に隔離し、あとはもっと情報が来るまで、じっと待ちましょう。

これ、とてもいい話だなと思います。

完璧ではなく、現時点での最適を目指す、という基本を守っていれば、状況によってはこういうこともありますよね。

この本の作者と関連のある、以下の良記事を思い出しました。

18f.gsa.gov

おわりに

オブジェクト指向設計実践ガイドというタイトルどおり、非常に実践的なガイドだったと思います。

オブジェクト指向で設計する、というのがどういうことなのかが伝わってくる本です。

また、テストの章もしっかりと書かれていて、とても参考になりました。

ダックタイプやテストダブルを使う際のダブルのインターフェースのテストとそれの共有、これまで全然やってなかった気がするので、今後活用したいです。

これと合わせて、デザインパターン本を読んでおくと更に理解が深まり良いと思います。

necojackarc.hatenablog.com

現実世界の複雑さと変わりやすさを適切な設計で乗り越えていきましょー!

開発時に最低限必要な設計系ドキュメント

ITライフ

って、何なんだろうと友人に質問されたので、周りの人に聞いてみた結果をざっくりまとめてみました。

ちなみに、自社サービス開発をしている会社での事例です。 請負開発の場合やエンタープライズ系開発の場合もっと変わってくるかなーと正直思います。

大まかに、以下のドキュメントが揃っていれば、「いきなり知らないプロジェクトにぶち込まれてもなんとかなる」とのことです。

全体像が把握できるもの

  • インフラ構成図 / システム間連携図 / ER 図

業務ごとの関連モジュールが把握できるもの

  • 業務ごとに分けられた ER 図 / 業務ごとに分けられたクラス図*1
    • 具体的にどこを見ればいいのかを教えてくれるドキュメント

要件 / ユーザーストーリーが把握できるもの

  • ユーザーストーリーが書かれたチケット / 機能特性に応じたドキュメント
    • System of Record / System of Engagement などがヒントになりそう

一言でまとめると、全体像を把握し、実際に作業に関連のある場所を特定し、実現すべきことを理解するためのドキュメント群だと思います。

いずれもソースコードやテストコードからボトムアップで理解するのが大変な知識だなという印象です。

あとは、あまりにもコードが汚い場合、「それを補助するためのドキュメント」が欲しいとのことでした。 個人的には、あまりにもコードが汚いならコメント書こうぜとか、それが不要になるようなリファクタしとこうぜとか色々思うので、まぁ一旦おいておきます。笑

再度まとめると、

  • 全体像(一体全体どうなってるの?)
  • 業務ごとの全体像(具体的にはどこを見ればいいの?)
  • 仕様(どう動いてれば良いの?)

みたな感じですね!

確かにこれがわかれば、(あまりにも設計や可読性が崩壊してなければ)なんとかなりそうです。

なるほどー。

*1:ER 図があれば十分との意見もあり

「価格の心理学」を読んだ

読書生活 ビジネスライフ

『価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?』を読みました。

価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?

価格の心理学 なぜ、カフェのコーヒーは「高い」と思わないのか?

「はじめに」にある通り、この本は「価格に対する顧客心理をビジネスに活かす方法を、手順ごとにわかりやすく伝える解説書」です。 内容の半分くらいは、元々コンサルタント向けの研修マニュアルだったそうで、そのためか密度の濃い実践的な本となっていました。

行動経済学認知心理学に基づいた、価格特化のマーケティング本、という感じでした。

直近価格について何か決めることは特にないのですが、様々な心理作用とその実際の活用事例を知ることができて面白かったです。

価格決定やマーケティングに関わる人が読むと、即座に実践できそうなことがたくさんのっており、得るものが大きいかと思います。

また、特にそれらに関わらない人でも、世の中の商品の価格がなぜそうなっているのか、 どのような心理作用やメッセージがあるのかを考える切っ掛けになり、とても楽しいです。

認知バイアスからは逃れられないとは思いますが、「あーこれもしかして」と考えたり気づくきっかけになるんじゃないかと思います。

もし価格について考えたり決めたりする機会があれば、また是非読み返したいと思える本でした。

認知バイアスヤバイ。それを活かした行動経済学イカス。