プログラムを一般の人に説明するには料理に例えるとわかりやすい
プログラム（プログラミング）って何と聞かれたら？
「プログラム（プログラミング）」って何？ と聞かれたら何と説明しますか？
私はいつも料理に例えることにしています。
つまり
プログラム → レシピ プログラマ → レシピを書く人 プログラミング → レシピを書くこと プログラミング言語 → レシピの記載方法（言語） コンピュータ → レシピ通りに料理を作ってくれるシェフ
となるわけです。
プログラムを実行するとは？
プログラム（レシピ）をコンピュータ（シェフ）に渡して料理を作ってもらうことです。
ちゃんと正しくプログラムを書けば、コンピュータが美味しい料理を作ってくれます。 材料や分量を間違ったり順番を間違ったりすると、不味かったり、黒焦げになったり、生焼けになったり、そもそも得体のしれない何かになっちゃうわけですね。
また、レシピもシェフが理解できる言葉で書かなければいけません。レシピの書き方を間違うとシェフはこんなレシピはわからない。とさじを投げちゃいます。
プログラミングの難しさ
レシピの書き方自体はパターン化されているのでそう難しいものではありません。 本当の難しさはプログラマ（レシピを書く人）の意図通りを正しくシェフに伝えることにあります。
なにせこのシェフは融通がきかず、レシピの内容を忠実に一切の忖度なしに実行しようとします。 普通のレシピで多用されるような「適宜」とか「お好みで」といった曖昧な指定は一切受け付けてもらえません。
塩なら0.8gとか、胡椒なら1.3gとか、気温が何度だったら0.1g追加するとか、焼き加減についても「様子を見ながら」みたいな指定も受け付けてもらえません。 野菜や肉を「一口大に切る」といった曖昧な表現も駄目です。ちゃんと最大5cmに収まり、重さは25g以上30g以下のような指定をする必要があります。
レシピの書き方を間違うと、シェフは正しく間違ってくれます。全てはレシピを書いたあなたの責任です。 ここがプログラミングの難しさの最大のポイントであり、プログラミングの面白さでもあるのです。
ライブラリはなんとかの素や調理器具である
プログラミングに欠かせないのはライブラリです。
カレーのレシピを書くにしても、カレールー（粉）のレシピを書くのが面倒な場合は、出来合いのカレールー（粉）を使うことがよくあるでしょう。具材だってカレー用野菜セットを使うことも多いはずです。 野菜の皮を剥くのにピーラーを使ったり、煮るためには鍋が必要でしょう。
こういった、なんとかの素や調理器具はライブラリと呼ばれます。
プログラムはライブラリの塊でできている
プログラミングは普通の料理以上に、誰かが作ってくれたライブラリの塊でできています。 画面に点1つを表示するのにだって、ディスクから1バイトのデータを読み込むのだって、ネットに1バイトのデータを送信するのだって、キーボードから1文字の入力を受け付けるのだって膨大なライブラリが必要なのです。
プログラミングの7割は適切なライブラリを探すこと、そのライブラリを正しく利用することです。 1から全てを作ろうとしたら10年たってもレシピは完成できません。使えるライブラリは最大限利用する必要があります。
プログラミングの勉強の難しさとは
ライブラリの知識が不足していると、いくらプログラミング言語を勉強しても、実際の業務になると全く歯が立ちません。プログラマを目指す人の多くはここで躓くのです。
しかもライブラリは一度覚えればそれでOKということはありません。ライブラリには流行り廃りがあるからです。 特にJavaScriptはその勢いが激しく、つい最近までVueが全盛だったと思ったら、今はReactに置き換えられていこうとしています。そのReactも数年後には新しいライブラリに置き換わっていくと思います。
投資が進むと生活防衛資金は不要になっていく
投資を始めるときに口酸っぱく言われるのは「生活防衛資金を貯めてから」。
これは重要な指摘です。投資はあくまでも余剰資金でやるもの。万が一メインの収入が絶たれたときに生きるための資金は投資とは別に分けておくべきです。まさに命金です。
生活防衛資金はいくら必要？
この生活防衛資金は生活費の6ヶ月〜24ヶ月（2年）を確保する必要がある。と言われていますが、実際には本人のリスク許容度（独身か扶養家族がいるのか、会社員・公務員のような安定収入があるか、年齢など再就職のしやすさ）によって決めるのが良いと言われています。
6ヶ月を最低ラインとして、自営業者・フリーランスなどの収入が安定していなければ +6ヶ月、扶養家族がいる場合（とりわけ教育費用がかかるお子さんがいる場合）は+6 〜 12ヶ月すると良いでしょう。
生活防衛資金が24ヶ月分必要となると、相当なお金をためておく必要があります。 この額を抑えるためには1月の生活費を抑えることが重要です。まずは節約を心がけて不要な定期サービス・固定費を削っていきましょう。頑張って5万円節約できれば生活費防衛資金は120万低くすることができます。
とはいえ、資産総額が増えれば（現金としての）生活防衛資金は不要になっていく
さて、この生活防衛資金、私は2ヶ月分の現金（普通預金）のみを保有して残りは全部インデックス投資に回しています。
資産総額が増えると資産自体が生活防衛資金の役割を果たすからです。
インデックス商品は流動性が高いので、売却して2週間以内には現金化が可能ですから生活費の1〜2ヶ月分の現金（普通預金）があればインデックスを現金化するまでの時間を稼ぐことができます。
資産総額がいくらになったら（現金としての）生活防衛資金は不要になる？
保有している全てのインデックス商品の価格が半分になることはない。という想定であれば、総資産が生活防衛資金の2倍以上になれば現金としての生活防衛資金は不要になります。
ご注意
この話の前提は投資をインデックスオンリーで運用している場合に限ります。
個別株で運用している場合は価格が半値以下になることは十分有り得る話ですので、十分お気をつけください。
Rubyの unless は assert の代わりと思うとわかりやすい
unlessはいつ、どう使う？
rubyには条件分岐のために if 式があります。（文ではない）
if 式は条件が真である場合をひっかけるときに使用するのは皆さんご存知の通りです。
if (true_condition) {
...
}
if 式に対して unless 式も存在しており、条件が偽である場合をひっかけます。
unless (false_condition) {
...
}
なので
if (condition) {
...
}
と
unless (!condition) {
...
}
は等価であり相互に書き換え可能です。
さて、この if 式と unless 式はどう使い分けをすれば良いでしょうか。
そのヒントがC言語の assert マクロにあります。
C言語の assert マクロ
C言語には ANSI 標準の assert マクロがあって、式が 0（偽）であった場合に処理をそこで終了する機能を持っています。
int main(void) { int a = 2, b = 5, c; c = a + b; assert(c == 7); // c が 7 ではなかったら終了 }
要は「絶対真になるはず」という条件を指定しておいて、万が一そうで無い状況が発生した場合に（異常終了という形で）検知できるようにするためのデバッグ用マクロです。
単純な仕組みながら、こんなはずではなかった。というバグを捉えるのに非常に有用なマクロです。
unless は assert の代わりとして使うべし
ruby に assert はありませんが、 unless をその代わりと思うとその使い道がはっきりします。
先程の例をrubyのコードに書き換えてみましょう。
def main a = 2, b = 5 c = a + b raise AssertError unless(c == 7) # c が 7 ではなかったら終了 end
unless で真であるはずの c == 7 という条件が満たされなかった場合に例外を raise します。
if にすると、条件式が反転しちゃいますね。条件式に否定が入るのは混乱の元なので避けたいところです。
raise AssertError if(c != 7) # c が 7 ではなかったら終了
unless は assert の代わりと考えるとこちらのほうがわかりやすいですよね。
実際の unless のわかりやすい使い方
メソッドやループの最初で（真であるべき）前提条件をチェックする（いわゆるガード節）ために使いましょう。
非常に恣意的な例ですが、メソッドの引数が偶数であることを期待している場合はこんな風に書けます。
def even_only(n) return unless n.even? # 偶数じゃなかったら終了 ... end
ループの場合で、要素が偶数じゃなかった場合はスキップするという場合はこんな風に書けます。
def process_even_only(ns) ns.each do |n| next unless n.even? # 偶数じゃなかったらスキップ ... end end
（この場合は ns.reject(&:even?).each という書き方もありですが ）
もし、これを if で書くと
return if !n.even? # または n.odd? だけど、どちらもわかりずらい。
となってしまいます。わかりずらいですね。
上手に unless を導入しよう
全ての道具にはそれぞれ適切な使い方があります。 せっかくあるものは有効に活用していきたいものです。
もしチームの文化的に unless に慣れていなくて、いきなり使うのを躊躇するのであれば、意図をコメントとして追加しておくと良いでしょう。
投資信託乗り換えの税金を何年で回収できるか簡易計算機作ったよ
投資信託を長期で運用していると、投資対象はほぼ同じで信託報酬が安い投資信託が登場してきます。
「オルカン」で有名なeMaxisシリーズには投資対象がほぼ同じで名前に「silm」が付くものと付かないものがあります。 先進国株式の場合であれば
- ｅＭＡＸＩＳ 先進国株式インデックス （信託報酬: 0.66%）
- ｅＭＡＸＩＳ Ｓｌｉｍ 先進国株式インデックス （信託報酬: 0.09889%）
となり、投資信託のメインのコストとなる信託報酬は6倍の差があります。
信託報酬は保有期間ずーっとかかるコストですので、じわじわとボディブローのように資産を食いつぶしていきます。 今保有している投資信託をより信託報酬の安いものに乗り換えたくなるのは当然です。
信託報酬乗り換えのコストにご注意
ただし、ノーコストで乗り換えはできません。
通常の課税口座（特定口座）で購入している場合は売却時に含み益に20%の税金が発生するからです。（分離課税の場合・復興特別所得税分は無視）
乗り換え先投資信をどれくらいの期間保有すれば、税金を払っても信託報酬を下げたほうが得になるのでしょうか。
手で計算するのは面倒なので、簡易計算ツールを作ってみました。
税金は何年で回収できる？ 計算機
前提条件
- 税金は20%固定。
- 信託報酬以外のコストは考慮しない。
- 税金支払い後の全額を乗り換え先投資信託に一括購入。
- 乗り換え後の追加購入はしない。
- 乗り換え後の価格変動はない。
実行例
現在100万円の評価額（内10万円が含み益）で信託報酬0.6%の投資信託を保有していて、信託報酬0.1%の新しいファンドに乗り換えたときに何年で税金分を回収できるかは
となって、約4年ちょっと保有し続ければ税金分を回収できることになります。逆に4年以上このままだと信託報酬のコストで損をするということですね。
実際には（長期的には）価格は上がってくはずですので、コスト差はもっと大きくなり税金回収までの年数は短くなっていきます。この計算結果はワースケースといえるのではないでしょうか。判断材料の目安として使ってみてください。
RailsエンジニアからGoエンジニアになります。
自分への踏ん切りとして。
今、Railsで自社システムを運用している会社に就職していますが、Goで自社システムを運用している会社に転職することになりました。
Go言語は未経験で一応Go言語の経験は問わない。とのことだったんですけど、入社までの2ヶ月程度の間にGoの一通りの経験は積んでおきたいので、これ読んでこれから猛勉強します。
![初めてのGo言語 他言語プログラマーのためのイディオマティックGo実践ガイド [ Jon Bodner ]](https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/0041/9784814400041_1_2.jpg?_ex=128x128 "初めてのGo言語 他言語プログラマーのためのイディオマティックGo実践ガイド [ Jon Bodner ]")
