【AWS】【Let's Encrypt】Let's Encryptを使っての証明書発行をAWS Certificate Managerにして、お名前.comに設定する

はじめに

勉強がてらSPAで作成したWebサービスを作っており ドメインはお名前.comで取得、証明書を作れるLet's Encryptを使っていました。 とても便利で1年半ぐらいは使わせてもらっていました。

しかし、最近になり証明書更新のコマンドが動かなり
3ヶ月に1回更新するのにも疲れたのでAWS Certificate Manager(以下、ACM)を使ってみることにしました。

環境

  • maxOS Sierra
  • Route53でDNS登録して、CloudFront経由でS3にあるファイルをWebに公開している。

前提条件

  • AWSのアカウントがあり、ACMを適用できるサービスを使用している
    • 今回は、CloudFrontに証明書を設定します。
  • AWS以外でドメインを取得している。
    • タイトル通りお名前.comに対して操作をしますが基本一緒だと思います。
  • Route53を使ってDNS登録をしている。
    • この運用をしていたからであり初めて設定する場合、登録していなくても問題ありません。

対応する前の状態

f:id:fujikawa-y:20180204141656p:plain

f:id:fujikawa-y:20180204141748p:plain

※本当はAレコードも設定してあります。 ※NSレコードの内容をお名前.comに登録してありました。

やり方

証明書の発行

ACMに移動して「証明書のリクエスト」を押下します。
そうするとドメイン名を入力する画面が出てくるので入力します。
※今回は説明用にsample-acm.com としています。

f:id:fujikawa-y:20180204142503p:plain

ここでポイントなのが、ワイルドカードドメイン名とワイルドカードがないドメイン名を両方設定しておくことです。
これをやることにより

  • www.sample-acm.com
  • www.sample-acm.com
  • sample-acm.com

上記のようなURLがすべて適用されるようになります。

そして、次に行くと f:id:fujikawa-y:20180204142936p:plain

選択肢が2つあり、取得したドメインでメールを受け取る設定をしていなかったので「DNSの検証」を選択しました。
なお、DNSの検証は2017年11月からできた機能のようでAWSはこちらを推奨しているようです。

docs.aws.amazon.com

選択した状態で次に行き、確定とリクエストをします。 そうすると検証という画面になり、CNAMEレコードが表示されます。

f:id:fujikawa-y:20180204143316p:plain

このCNAMEレコードをお名前.comのDNS設定に転記します。

お名前.comの管理ページから下記ページに遷移して

f:id:fujikawa-y:20180204143613p:plain

以下を選択します。

f:id:fujikawa-y:20180204143828p:plain

次のページで入力するところがあるので、入力していきます。

f:id:fujikawa-y:20180204145524p:plain

※画面下に「DNSレコード設定用ネームサーバー変更確認」とありますが
チェックしてから次に進んで設定してください。

これでお名前.com側の設定が終わりで数十分待つと、ACM側が以下のようになります。

f:id:fujikawa-y:20180204145856p:plain

次にACMで作成したものをCloudFrontに設定します。

f:id:fujikawa-y:20180204145047p:plain

f:id:fujikawa-y:20180204145344p:plain

これで準備が完了しました。
しばらくしてサイトにアクセスするとSSLが有効なものになっているはずです。
そして証明書の内容を確認してみます。

f:id:fujikawa-y:20180204145734p:plain

ちゃんとAmazonが発行した証明書になっています。

まとめ

今までLet's Encryptでやっていたのは何だったのか・・・
やはり、AWSはすごい!と思わされる内容でした。

AWSを使ってやる場合、ACMを使っての証明書発行が1番速く確実だと思います。

参考

blog.serverworks.co.jp

qiita.com

tech.innovator.jp.net

【勉強会】VP of Engineering Meetup by CA #2 に参加しました

CTOというのは何となくわかるものですが
VP of Engineering(以下、VPoE)とはどういう役割で何をやるのか?
ということがわからないままでした。

そして、今の自分がやっていること、やりたいことはVPoEなのではないか?
という考えもあり参加することになりました。

申し込みした時期が遅く補欠でしたが無事に繰り上がり当選しました。

概要

cyberagent.connpass.com

内容

イベント趣旨説明

まず、参加者全員で「VPoEとはどういうものか?」というのを定義しました。 以下、メモした内容です。

素晴らしいマネージャーであり、偉大なチームビルダー
優秀なリクルーター、素晴らしいコミュニケータ、大きな問題解決者となる
エンジニアとしては、エンジニアリング組織を全員を成功させ、道を切開ること

CTOはTechに特化しているのに対して
VPoEは採用、育成、評価などを含むエンジニア組織全体のパフォーマンスを最大限出せるようにする

スライドにも書かれていましたが、VPoEの役割は組織全体に対してであり
手広くカバーをしなければいけない役割だと思いました。

『組織フェーズにおけるリーダーシップの変革』

speakerdeck.com

ベンチャーに近い状態の組織に参画して、そこでどうやったか?という話でした。
自分の立場上、こちらの内容が1番身近に感じられました。

以下、メモした内容です。

最初はエンジニアリーダーで、徐々にエンジニアリングマネージャーとなった。

組織コンテキスト
組織フェーズとリーダーシップ
エラスティックリーダーシップという本がその通りの内容。

・サバイバルフェーズ:めいれいさせろ
とにかく技術的負債をなんとかする
・アラートメールがたくさんくる
・デプロイフローなし
など

負債払拭のため合宿も行った。

負債払拭のまとめはスライドがあるためそちらを参照。

失敗談として、専門外は自分でもどうこうできなかった
なので、優秀な人を味方につけてやってもらった

・学習フェーズ:いろいろやろうぜ
エンジニアとマネージャーが揺れ動いたがマネージャーに注力した1年にした。
井の中のカエルにならないために他の会社の人とあったりもした。

ストレッチゾーンに導くミッション設定
・コンフォートゾーン
・ストレッチゾーン
・パニックゾーン
があり、うまくストレッチゾーンに導いてあげることにしていた。

目標設定ぐるぐる共有会
オフラインで目標設定をして、1つの目標を書いて
メンバー全員にコメントをもらう。
→ブログにまとまっているのでそちら参照

失敗談は1on1をまとめて3時間やっていた。
1on1は聴くなどとても集中力を使う場になってしまった。
毎日1人30分に変更した。

・自己組織化フェーズ:オーナーシップをだいじに
権限移譲をした。
推進責任者をしてリーダー以外にもオーナーシップを持たせる
チームのアイデンティティ強化してチームの中でミッションを持つ。

権限委譲はDelegationBoardを使ってやっていた。

よく言っていたのが「あなたのチームの組織フェーズはどこだろう?」ということ。
各チームにとってはまだまだなところもあるので、言語化していき意識させるようにした。

失敗談はエンジニア組織のことばかりに目がいってしまった。
組織全体を考えたアクションを実施できていなかった
 エンジニア組織だけ良い状態でも意味がない
 ビジ、テク、デザでシナジーを生むようにしている

まとめ
組織は生物で日々変化する
組織フェーズに合わせた、リーダーシップの柔軟性が求められている。

『チームビルディングの技術』

www.slideshare.net

エンジニアという立場ではないが、目線、やり方は1番インパクトがあった内容でした。

以下、メモした内容です。

ビジネスサイドのVPofE
20 〜 30人になったら他にチームを渡すような感じ。

チームビルドはワークさせるだけじゃない。
別のスライドに採用に関することが詳しく書かているのでそちら参照。

既存チームメンバーと合わない人はいれないのは当たり前だが
給料テーブルで合わない人も採用しない方が良い。

経営情報を共有することにより目標設定を設定しやすくなる。
また、自走する人が現れる。
ネガティブなこともできる限り伝えたほうがプラスに働くことが多い。
ビジョンでひっぱってもいいがビジョンは劇物なので、売上ベースが良い。

1on1は最初にたくさん聞いて、その人の問題点などを解決してあげることが大事。
その人が考えてること以外のアドバイスをしても意味がないし、聞いてもらえない。

まず、期待していることを伝える。

課題の解決と解消は違うので間違えないようにすること。

1on1は全メンバーに画一な面談をしなくてもよい。
飲みに行ったりしている人がいたらそれでOK。また同じゲームをやっているメンバーとか。

イグジットマネジメントでは
退職と異動でチーム力を落とさないことを念頭に置くこと。

ミスマッチな人が離れることはポジティブなこと。

絶対に出さない!というのはデメリットである。
属人化はマイナス要素になる。

NPSを取ったほうがいい。

無責任な離職や異動は怒るべき。

また出戻り組は貴重な採用ソース。

キーマンの退職は退職の連鎖を防がないといけない。
メンバー層を個別にケアをする。

※自分用メモ:スライドはいい話ばかりだったので、後で読み返すこと

『変革、組織づくりに責任者がまずやるべきこと』

www.evernote.com

こちらの発表もかなりインパクトがある内容でした。 徹底したやり方に凄みを覚えました。

以下、メモした内容です。

エンジニア120人レベルの会社
合宿でエンジニア全員と1on1を実施
 自分の略歴を書いて、相手に対して聞きたいことをすべて見せて話した。

定例や意思決定を特になにも言わず参加した。
 何をするか決める前に以下のことを実施
  組織に対してのいいこと悪いことをすべて出す。
  カテゴリ化
  カテゴリを解決方法を洗い出す。
  解の候補が解決できるインパクトと労力で優先付け
  1年、半年、3ヶ月がどんな状態になるかを定義する
  3ヶ月の細かい計画を立てる

 洗い出しのときは、できていることも上げていく
 わかりやすいワードでまず浸透第一にする
 1つの軸に対して3つのカテゴリにしてアクションを決めていくとやりやすい。かつ浸透しやすい
 やりたいことをとにかく言い続ける。またかというくらい言い続ける

変えるときは空気を読まずに変える。調整よりも変化の抵抗からの火消しが楽。
ボトムに合わせるのではなく、Topに合わせてそれがカッコイイと思うように。
自分を信じてやる。
行動してくれる理解者は抜擢する。変化をマジョリティにしていく。
全部は見れない。しばらく赤点にならないところは放っておく。

面談時
どんなに熟慮しても何だかんだ結論は決まっているから伸ばさない
スキルではなく、ノウハウだけで仕事しているケースは今後伸び悩む旨を危機感を与える対話をちゃんとする
エンジニアの行動で注意するところはちゃんと注意する

計画時
べき、ねばならないだけしか洗い出せてなければまだ足りない。できていることもちゃんと出す。
最適解だけを求めてもイレギュラーに弱くなる。解の候補をどれだけ持つかを意識して手札を充実させることを意識する。
アウトプットにより生まれるストーリーを考える
ストーリーを作るために必要なアウトプットを考える。
ルールを作るのは最終手段。期待にそれたらかっこ悪いという状況をどう作るかに注力して考える。

実行時
自分の報告が同じフォーマットこなすだけになって来たら変えるタイミング
報告受ける際、アップデート特になしの報告メンバは問題あり
ツール導入も人が重要で理解できていない場合アナログにまずやることを考える
ゴールさえぶらなきゃやり方はどんどん変化して問題ない。
3ヶ月に1回は最低振り返り、洗い出しをやる。
※途中書き漏れた
マイナスを0にした場合、前よりいいからと安心するメンバが出てくるから気をつける

全体を通しての感想

このような勉強会(Meetup)は答えがなくマネジメント寄りなところがあります。
なので、結構胡散臭い部分が出てくると思い価値ですが、VPoEとしての
役割や目線、課題などが参加者全員が一致していたようで
下手なものよりも充実していて、とても濃い内容でした。

また、今回のMeetupで聞けなかったこともいくつかあり
アンケートには書いたのでその辺も次回聞ければいいなと思います。

なお、次回開催も前向きなようで今後参加者も増えると予想されるので
今後も毎回参加して知見を得て共有していければと思いました。

ツイートまとめ

twitter.com

【雑記】今年の振り返り

まだ2017年が続くんじゃないか?と思うぐらい仕事をしていますが
今日でもう終わりと思うと昨年以上にあっという間の1年でした。

さて、今年を振り返ります。

今年の振り返り

部署異動

今年が始まり数ヶ月経ったころに部署を異動しました。
転職とは違いましたが、初めて出会う人たちと仕事をすることに
なるので最初はどうなるかと思いましたが、楽しく仕事を行うことができました。

出向

部署異動した後、諸事情になりグループ会社へ出向することになりました。
現在、出向先でサーバーサイドとクラウドインフラをやっています。
ちょこちょこ顔が出ているので知っていると思いますが、いろいろ聞きたければ
連絡をお願いします。

システム開発

Ruby on Railsでのシステム開発

異動した部署、出向先もAPIRailsで開発していて
それに携わることになりました。

仕様の理解とRubyの柔軟性にかなり苦労してしまい
一人前にまだRubyでご飯を食べられるような状態ではないことを
今年1年で痛感しました。

AWS, GCPに携われた

そんなにガッツリ!というほどではないですが
携われたことはとても大きく今後に繋がる内容だったと思います。

コンテナ技術

仮想マシンで十分だろう」と数年思っていたのですが
コンテナ技術を覚えなければならず、現在進行系でやっています。
Docker自体はそうでもないかな?と思ったのですが
Kubernetesを使うとかなり便利で使えるものだと実感させられ
来年はこの辺の知識をインプットしていければと考えています。

ブログ

実はこのブログ、月1で記事を書こうという目標があったのですが
結局、10 〜 11月は書くことができませんでした。

アウトプットを意識してのインプットができていなかった
時期だと思うのと良いインプットがなかったのでは?と反省です。

反省をしつつ来年は短いサイクルで振り返りを行い
意識して良いインプットをしつつ良いアウトプットを出していこうと思います。

プライベート

ウイスキー

今年の2月ぐらいにウイスキー検定3級を受けて無事に受かりました。
来年もあるのですが、ちょっと仕事方面に力を入れようと思うので
次、受けるのは再来年です。

ただ、来年はいろいろな種類のものを飲んで知見を広げるべく
1杯から飲めるところを巡ってみようと思います。

ゲーム機

3DSを買い換えることはあっても据え置き機はPS3を最後に買ってませんでしたが
今年は「Nintendo Swith」「PS4」を購入しました。

メジャータイトルはやりましたが、どれも中途半端に止まっている状況です。
せめてゼルダのエンディングだけはちゃんと見みます。

あ、PS4はモンハンワールドのために買ったので同じ人がいましたら一狩り行きましょう。

グラブル

昨年に引き続きグラブっておりました。
去年と同じように毎日コツコツとやっており中くらいのプレイヤーにはなったかな?
と思っていますが、ガチャは恐ろしい!

総評

仕事関連でいうとまさに怒涛の1年でした。
また、プログラマとして技術力がまったくついていっていないと
痛感する場面が今まで以上にあったのでマネジメントはやってきたので
来年は技術力アップを目指してやって行こうと思います。

後は、何事にも自信を持てる度胸を持つことです。

【Ruby】define_methodについて調べました

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、ライブラリの挙動を確認していたところ
define_methodが書かれており、復習も兼ねて調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

define_methodに関すること

実行

[1] pry(main)> class Animal
[1] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[1] pry(main)*     # 動的にクラスやモジュールを定義でき、defによるメソッド定義をしなくてもよい
[1] pry(main)*     # メソッド本体はブロックで記述する
[1] pry(main)*     define_method(name) do
[1] pry(main)*       message
[1] pry(main)*     end
[1] pry(main)*   end
[1] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[2] pry(main)>
[3] pry(main)> puts Animal.new.cat
にゃー
=> nil
[4] pry(main)>
[5] pry(main)> class Animal2
[5] pry(main)*   { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[5] pry(main)*     # ブロックにブロック引数を加えるとブロック引数がメソッドの引数になる
[5] pry(main)*     # ブロック引数:name
[5] pry(main)*     define_method(name) do |num|
[5] pry(main)*       message * num
[5] pry(main)*     end
[5] pry(main)*   end
[5] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[6] pry(main)>
[7] pry(main)> # メソッドの引数:2
[8] pry(main)> puts Animal2.new.dog(2)
わんわん
=> nil
[9] pry(main)> class Animal3
[9] pry(main)* end
=> nil
[10] pry(main)>
[11] pry(main)> { cat: 'にゃー', dog: 'わん' }.each do |name, message|
[11] pry(main)*   # ブロックをオブジェクトとして定義する
[11] pry(main)*   proc = Proc.new { |num| message * num }
[11] pry(main)*   # class_evalは、ブロックをクラス定義やモジュール定義の中のコードであるように実行する
[11] pry(main)*   # ブロックの戻り値がメソッドの戻り値になる
[11] pry(main)*   Animal3.class_eval { define_method(name, proc) }
[11] pry(main)* end
=> {:cat=>"にゃー", :dog=>"わん"}
[12] pry(main)>
[13] pry(main)> puts Animal3.new.cat(3)
にゃーにゃーにゃー
=> nil

まとめ

defでメソッド定義しなくてもメソッドを定義するという
初見殺しな面もありますが、メタプログラミングをする上で
扱うものの1つだと思うのでしっかり覚えておきます。

参考資料

define_method (Module) - Rubyリファレンス

【アジャイル】アジャイル(スクラム)をやり始めて5ヶ月ほど経ったので振り返る

はじめに

本エントリーは以下の続きです。

fujiyasu.hatenablog.com

fujiyasu.hatenablog.com

前回のエントリーから今まであったこと

  • プロダクトオーナー(以下、PO)が交代
    • POが認定POを取得
  • スクラムマスター(以下、SM)が交代
    • SMが認定SMを取得
  • チームが成熟されてきたときに起きたこと
    • プロダクトバックログリファインメントの改善
    • スプリントレビューの改善
    • T字型人材への促進
  • スクラムオブスクラムが始まる動きがある

簡単ですが、こんなところでしょうか。
それでは詳しく書いていきます。

プロダクトオーナー(以下、PO)が交代

前回のエントリーで

POがいない問題

というのを書きました。

前のPOも問題詩しており、解決策として
プロダクトに近い立場の人を新POにしました。
ただし、人が変わるということは会話の内容が変わってくるため
最初は認識合わせすることにかなり苦労しました。

しかし、開発をしていくごとに改善してきて
会話できる時間や量も増えて、スプリント中でも
スムーズに意思疎通をすることができるようになりました。

なお、この前後にPOは認定POを取得しており
POとしての基礎固めはできている状態となりました。

スクラムマスター(以下、SM)が交代

前SMが築き上げてきたものを筆者が引き継ぎ、新SMとなりました。
POのときと同様にそれぞれ認定SMを取得した状態です。

交代した理由は「認定SMを取得したのでやってみる」というのも
ありますが、もう1つの理由は「SMは思っている以上に大変」ということだと
思います。
常にチームを観察して、正しい方向に導き細かいタスクをやらなければならないので
1つのことに集中する以上に労力を使う立場です。
そのため、ずっとSMは現実的に難しいと思うので交代はありだと考えています。

また、前回のエントリーで

すでにローンチ済みのサービスのため、本番の調査依頼などが入ってくる

というのを書きましたが、POがすぐに対応できない場合
SMとして間に入ってSMがまず調査をすることにしていました。
どうしてもわからない、時間がかかる場合はPOに相談して
開発チームのリソースを使うということをしました。

チームが成熟されてきたときに起きたこと

プロダクトバックログリファインメントの改善

改善点

  1. 一つのストーリーに費やす時間が多かったのでキッチンタイマーを導入して10分の制限を設けた。
  2. 議論が白熱した際、SMが間髪入れず間に入って状況を整理する。
  3. リファインメントでは詳細な機能の話はしない。詳細に考えなければいけないのを含めてポイントを出す。
  4. 毎日1時間やっていたリファインメントを週にまとめて2時間にして効率化を目指す。

上記のおかげで今までストーリーポイントすらなかった状態が
見積もりされたバックログがある状態となってきました。

スプリントレビューの改善

改善点

  1. スプリントレビューのやり方を調べてチーム展開して、共通認識を行った。
  2. 大きなモニタを使って全員で画面を見れるようにした。
  3. 離れた場所から参加する人がいたので、TV会議システムを使い同じ画面を見れるようにした。

スクラム以外でもレビューというのは行ってきましたが
全員集まってレビューというのは勝手が違う感じがしたようなので
最初は戸惑いもあったようですが、改善をした結果確かな手応えを
チーム全体で感じられたようなので良かったです。

T字型人材への促進

開発メンバーは、それぞれ得意分野というのがあり
そちらを伸ばして行く人が多い感じでした。
しかし、それだけでは属人化してしまうため一部のメンバーだけですが
ペアプロを実施していくようになりました。

現在進行系でやっていましたが、とても効率的であり
楽しくプログラミングをやっている印象を受けました。

スクラムオブスクラムが始まる動きがある

実は、別のチームでスクラムをやっているところがあり
それぞれのチームの知見を共有しようという話になってきました。
チームの文化というのは同じスクラムでもまったく違うので
お互いノウハウを共有していければと思います。

この辺は。また展開があったときに書きたいと思います。

まとめ

本当はもっとあったと思うのですが
詳しく書いてしまうと、それぞれの内容で1つのエントリーに
なってしまうレベルなので簡単に書きました。

スクラムチームとなって3ヶ月以上が経って
そろそろ半年になるにあたり、成熟度も増してきたので
今後、さらに良いチームになっていくと思います。

最後にSMとなって、参考にした書籍を列挙しておきます。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

【Ruby】文字列リテラルのダブルクォートとシングルクォートの違いについて

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで
文字列リテラルのダブルクォートとシングルクォートの違いを調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

文字列リテラルのダブルクォートとシングルクォート

文字列リテラルのダブルクォートとシングルクォート

実行

[1] pry(main)> # ダブルクォート
[2] pry(main)> # ・バックスラッシュ記法と式展開が有効になる
[3] pry(main)> str1 = "式展開も試してみます"
=> "式展開も試してみます"
[4] pry(main)> puts "ダブルクォートのサンプル文字列です\n\nそして、#{str1}"
ダブルクォートのサンプル文字列です

そして、式展開も試してみます
=> nil
[5] pry(main)>
[6] pry(main)> # 文字列内でダブルクォートを使いたい場合、エスケープ文字を入れる
[7] pry(main)> # ※「サンプル文字」をダブルクォートで括ってみる
[8] pry(main)> puts "ダブルクォートの\"サンプル文字列\"です\n\nそして、#{str1}"
ダブルクォートの"サンプル文字列"です

そして、式展開も試してみます
=> nil
[9] pry(main)>
[10] pry(main)> # シングルクォート
[11] pry(main)> # ・\\ (バックスラッシュそのもの)と \' (シングルクォート) を覗いて、文字列の中身の解釈しない
[12] pry(main)> str2 = "式展開されないことを確認します"
=> "式展開されないことを確認します"
[13] pry(main)> puts 'シングルクォートのサンプル文字列です\n\nそして、#{str2}'
シングルクォートのサンプル文字列です\n\nそして、#{str2}
=> nil
[14] pry(main)>
[15] pry(main)> # シングルクォートの場合、中身の会社はしないのでエスケープ文字を入れなくてもそのまま表示される
[16] pry(main)> puts 'シングルクォートの"サンプル文字列"です\n\nそして、#{str2}'
シングルクォートの"サンプル文字列"です\n\nそして、#{str2}
=> nil
[17] pry(main)>

まとめ

ダブルクォートとシングルクォートの違いに気づかず、シングルクォートで式展開を書いてしまっていて
なぜ展開されない?と数分考え込んでしまったので、簡単ですがまとめみました。

基本、ダブルクォートを使うのが良さそうなのでこちらを使っていきます。

参考資料

リテラル (Ruby 2.4.0)

【Ruby】キーワード引数

はじめに

せっかく調べたのに忘れてしまうため、メモを残しておく。

今回は、メソッドの引数に関することで キーワード引数を調べました。

環境

前提条件

  • irbかPryが動作すること

やり方

キーワード引数(デフォルト値あり)

キーワード引数(デフォルト値あり)のサンプルソース

実行

[6] pry(main)> # 引数を元にメッセージを表示する
[7] pry(main)> def display_message(name: 'Smith', message: 'Sample')
[7] pry(main)*   p "#{name} : #{message}"
[7] pry(main)* end
=> :display_message
[8] pry(main)>
[9] pry(main)> display_message
"Smith : Sample"
=> "Smith : Sample"
[10] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[11] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[12] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):8:in `display_message'
[13] pry(main)>

デフォルト引数を定義することで、何も受け取らなかった場合
デフォルトのものが表示されていることがわかります。

また、引数を設定するとその値にとなり、引数の順番を変えても
問題なく表示されていて便利です。

ただし、引数の値だけではエラーとなってしまいキーワードは必須です。

キーワード引数(デフォルト値なし)

キーワード引数(デフォルト値なし)のサンプルソース

実行

[13] pry(main)> # 引数を元にメッセージを表示する
[14] pry(main)> def display_message(name:, message:)
[14] pry(main)*   p "#{name} : #{message}"
[14] pry(main)* end
=> :display_message
[15] pry(main)>
[16] pry(main)> display_message(name: 'John', message: 'Hello')
"John : Hello"
=> "John : Hello"
[17] pry(main)> display_message(message: 'Hello', name: 'John')
"John : Hello"
=> "John : Hello"
[18] pry(main)> display_message
ArgumentError: missing keywords: name, message
from (pry):16:in `display_message'
[19] pry(main)> display_message('John', 'Hello')
ArgumentError: wrong number of arguments (given 2, expected 0)
from (pry):16:in `display_message'
[20] pry(main)>

デフォルト値なしの場合、エラーとなってしまったので
こちらを使った方がいい場合もありそうです。

まとめ

今まで意識して使ったことなかったのですが、明確に記述したい場合などがあったら
積極的に使っていきたい機能だと思いました。

ただし、参考資料先でも書かれている通り、冗長になる可能性が十分あるので
適材適所として使っていきます。

参考資料

改訂2版 パーフェクトRuby

改訂2版 パーフェクトRuby

ruby-rails.hatenadiary.com

robots.thoughtbot.com