雀巽の日記帳

雀巽が綴る日常の記録

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

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 で混乱したのでまとめる

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

ということですね。

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

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

オブジェクト指向設計実践ガイド 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

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

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

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

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

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

全体像が把握できるもの

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

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

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

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

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

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

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

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

再度まとめると、

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

みたな感じですね!

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

なるほどー。

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

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

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

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

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

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

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

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

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

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

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

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

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

「データベース・リファクタリング」を読んだ

「データベース・リファクタリング データベースの体質改善テクニック」を読みました。

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (53件) を見る

内容はタイトルの通りで、前半は発展型データベース開発の概念と手法の基本、後半は各リファクタリングのリファレンスです。

データベースの質を高めるために、一通り「こんなことができるんだ」と知っておくと良いと思える内容でした。

データベースの修正は「面倒」で「怖い」と言った理由で避けられがちですが、 この本を読むと、それに立ち向かうための武器や考え方が得られるんじゃないかと思います。

以下、個人的に印象に残った点について書いてきます。

移行期間を設ける

当然といえば当然なんですが、Web API やライブラリの場合と同じで、 移行期間を設けることで、保守コストはあがりますが、移行がしやすくなります。

移行期間中は新旧両方のコードが動くので、大規模デプロイを避け、少しずつ対応を進めることができます。

小さい変更を少しずつ反映していくほうが安全で確実ですね。

確実に動く小さな変更を早めにマスターに反映していくことができれば、 他の人の作業とぶつかる可能性も下げることができます。

リファクタリングの意義

コードは情け容赦なくリファクタリングしなければならない。 というのも、質の高いソースコードを扱っているときが、一番生産性があがるからだ。 コードに新しい機能を追加するときには、まず「このコードはこの機能を追加するためにもっとも良い設計になっているだろうか」と考えなければならない。

同意しかないので特に追記することはありませんが、「作業前に周りをキレイにする」という作法はもっと広まってほしいなと思います。

データベースの不吉な臭い

本に記載されていた「臭い」は以下の通りです。

  • 複数の目的に使われるカラム
  • 複数の目的に使われるテーブル
  • 冗長なデータ
  • カラムの多すぎるテーブル
  • 行の多すぎるテーブル
  • 「スマート」カラム
  • 変更の恐怖

噛み砕くと One Fact in One Place が守られており、かつ理解しやすい設計になっているかが鍵だと思います。

コードの場合は単一責任原則が守られており、かつ理解しやすい設計になっているかが鍵だと考えているので、 コードでもデータベースでも、「不吉な臭い」の根幹は似ているなと感じました。

この辺の嗅覚を上げるには SQL アンチパターン が非常に有効だと思います。

necojackarc.hatenablog.com

設計とドキュメントの関係

設計がきれいなほど、必要なドキュメントは少なくなる

なるほど確かに、と思いました。

ドキュメントやコメントが不要だとは考えていませんが、コメントやドキュメントで説明が多く必要なときは、 そもそも設計自体が不適切な場合は多いと感じます。

データベース・アクセスのカプセル化

カプセル化されていれば、当然変更箇所が少なくなるので、データベースの変更コストが少なくなります。

これはいわゆる、結合度を下げる(凝集度をあげる)とメンテナンスコストが下がるのと同じです。

例えば Rails の場合、where を外から呼ばず scopeを使い、 ActiveRecord 外にデータベースの詳細を染み出させないようにする、などが一例として思いつきました。

データベース・リファクタリングと政治

組織にデータベース・リファクタリングを取り入れたければ「政治ゲームに参加する」必要もある

変革を起こすには、どうしても政治力が必要になりますよね。そりゃそうだ。

まとめ

コード・リファクタリングよりも、どうしてもコストはかかりますが、 データベース・リファクタリングも十分日常的に行える作業だと思います。

大事なのは、コード・リファクタリングと同じく、

  • 「不吉な臭い」を嗅ぎ取ること
    • 単一責任原則 / One Fact in One Place などの基本原則を抑える
  • 小さな変更を繰り返し適用すること
    • 安全性も確実性も高まり、更に環境を最新に保ちやすい

あたりだと思います。

唯一不変なものである変化に対応するには、継続的改善が必須です。

データベースも継続的改善を行っていきましょう!

Happy New Year 2017

あけましておめでとうございます。

昨年はありがとうございました。 今年もよろしくお願いします。

それでは、今年もまずは簡単に2016年を振り返りたいと思います。

necojackarc.hatenablog.com

去年のブログによると、2016年の目標は、

だそうです。

とりあえず一つずつ振り返ってみます。

英語

大学時代、英語が最も苦手な科目であり、英語で留年した*1と言ってもある意味過言ではないのですが、2016年は継続的に頑張りました。

necojackarc.hatenablog.com

最終的に TOEIC のハイスコアは870点まで伸びました。

また、オンライン英会話も継続的に行っており、調べてみたところ現時点で468回受講しているようです。

ただ、伸び悩みを強く感じるようになってきたので、今年は何かを変えないとダメだなと思います。

競技プログラミング

競技プログラミング全くしてない\(^o^)/

これは興味が「コンピューターサイエンス」から「ソフトウェアエンジニアリング」に盛大に推移したのが原因です。

競技プログラミングというか、データ構造とアルゴリズムについては、自分の弱いところだなという認識もあるので、 どっかのタイミングでテコ入れしたいなとは考えていますが、どうも後回しになっています。

その代わりに優先した IT 周りのこととして、

などの、Web サービスの設計や開発で重要になる技術が挙げられます。

健康

ここ数ヶ月は生活リズムが非常に安定してきており、いい感じです!

ただ、健康診断で尿酸値アウトだったり痔瘻になったりしたので、微妙な感じです。

やっぱりいちばん重要なのは健康だと思うので、まずは食生活と睡眠リズムを安定させたいです。


目標を基準に振り返ってみましたが、なんとも微妙な達成率……。

次はさっくり時系列順に振り返ってみます。

去年のブログを見ると、

2016年は地力を底上げする成長の年にしたいなと思います。

と書いてあるのですが、これは達成できたかなと思います。

2016年は新規事業を任されたおかげで、学びと実践を繰り返し行えたのが非常に良かったです。

2015年は変化、2016年は成長ときたので、2017年は何か大きな挑戦ができたら良いかなと思います。

現時点で何に挑戦するかは特に決める気はありませんが、何か挑戦したと言える、そんな年にしたいです。

というわけで、2017年の指針は、

  • 挑戦
  • 英語
  • 健康

にしたいと思います。

加えて2015年のブログに、

将来の自分が過去の自分に向かって胸張れる存在になれるようにマイペースに生きていきたい

とありますが、この方針はもちろん変更なし!

あと、イチロー選手の『小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道』という言葉が強烈に頭に残ってるので、 これも今後の方針としてきっちり組み込んでおきたいと思います。

それでは2017年、楽しんで行きましょう!

*1:フランス語にも殺されました