2017-04-01

社会人5年目突入

ビジネスライフ日常生活

大学卒業して丸4年たったとか信じられませんが、どうやら丸4年たったようです。

ちなみに1年前の記事はこちら。

necojackarc.hatenablog.com

丸4年ということは、エリート大学生が大学を卒業するまでの時間が経過したわけですね。

わざわざエリートとつけたのは、留年しない人はエリートだからです。てきとーです。

というわけで、このままてきとーにつらつら書きなぐります。

社会人生活4年間どうだった？

大学の時とあまりかわらず、なんだか好き勝手してる気がします。

ただ、高校のときも大学のときも大して勉強しなかった反動か、社会人になってからのほうが自発的に勉強してる気がします。

でもまだ、おじさん達が「学生のうちにちゃんと勉強しとけよ」という気持ちはよくわかりません。というかそもそも、「あの時ああしとけばよかった……」と後悔してることがほぼ無い気がします。

あまり自覚はありませんが、もしかしたらクソポジティブ人間なのかもしれません。

一番古い記憶からこれまでぼんやり振り返ってみても、なんかずーっと楽しんでる気がします。

仕事の文句言ってた時期もあったような気がするけど、行動したら改善したし、なんか思い出してみても「あれはあれで楽しかったわ！ガハハ！」みたいな感情が浮かんできます。

都合の良い脳みそだ！

次は何する？

高校2年生のときに、ニュージーランドに2週間ホームステイしたことがあります。

その帰りに「2週間じゃ全然足りん！絶対また英語圏に行く！今度はもっと長期間行く！」と思ったきり行ってないので、そろそろ行ってみますかね。

最高に楽しんでいきましょう！ぴーす！

2017-03-27

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

日常生活読書生活

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

ファスト&スロー(上) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

作者: ダニエル・カーネマン,村井章子
出版社/メーカー: 早川書房
発売日: 2014/06/20
メディア: 文庫
この商品を含むブログ (24件) を見る

ファスト&スロー(下) あなたの意思はどのように決まるか? (ハヤカワ・ノンフィクション文庫)

作者: ダニエル・カーネマン,村井章子
出版社/メーカー: 早川書房
発売日: 2014/06/20
メディア: 文庫
この商品を含むブログ (14件) を見る

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

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

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

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

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

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

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

2017-03-16

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

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

Git Lens

スーパー高機能な Git 拡張です。

デフォルトのまま使うと、エディタ上に編集者、直近の変更、カーソルがあるラインの最終コミットを出してくれるようになるのですが、個人的には必要なときに必要な機能を起動したいので、以下の設定をし、少々おとなしくさせています。

{
 "gitlens.codeLens.authors.enabled": false,
  "gitlens.codeLens.recentChange.enabled": false,
  "gitlens.currentLine.enabled": false
}

HTML (JSX)

Auto Rename Tag

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

Auto Close Tag

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

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

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

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

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

JavaScript

npm Intellisense

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

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

ESLint

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

Ruby

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

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

$ gem install fastri rcodetools

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

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

slim

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

設定管理

Settings Sync

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

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

EditorConfig for VS Code

EditorConfig の VS Code 用拡張です。

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

necojackarc.hatenablog.com

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

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

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

2017-03-12

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

ITライフ

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

インストール

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

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

Github Gist を利用した設定共有

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

Settings Sync

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

Steps To Get the Github Key - Settings Sync

準備が整ったら 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

Key Bindings for Visual Studio Code

2017-03-11

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

ということですね。

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

2017-02-28

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

ITライフ読書生活

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

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

作者: Sandi Metz,?山泰基
出版社/メーカー: 技術評論社
発売日: 2016/09/02
メディア: 大型本
この商品を含むブログ (1件) を見る

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

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

Effective Ruby は Ruby 力をあげる本、リファクタリング 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

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

2017-02-25

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

ITライフ

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

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

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

全体像が把握できるもの

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

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

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

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

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

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

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

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

再度まとめると、

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

みたな感じですね！

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

なるほどー。

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

社会人生活4年間どうだった？

最近の仕事どう？

次は何する？

オススメ基本設定

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

インデントガイドを表示

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

最終行に改行を追加

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

大文字小文字変換

複数行を1行にまとめる

オススメ拡張機能

コーディング全般

HTML (JSX)

設定管理

関連記事

インストール

Github Gist を利用した設定共有

設定の自動同期を行う

感想

Tips

SOLID

TRUE

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

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

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

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

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

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

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

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

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

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

おわりに

全体像が把握できるもの

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

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