1on1の勉強でへぇーってなった話
どうもみなさん、こんにちは。 豊田です。 早いもので2021年も残すところ僅かになりました。 「今年何やったっけ...？」と何も思い出せないのは、本当に何もやってないのか。それとも歳のせいなのか... いずれにしても来年を気持ちよく迎えられるように、2021年も最後までがんばります！ WYRD、1on1やるってよ 弊社も細々と採用活動を行なっておりまして、おかげで最近は若手メンバーも増えてきました。 立派なエンジニアに育ってもらうべく、技術面で成長してもらう（そのためのフォローをする）のは当然のことですが、最近は弊社でも**人間的な部分の成長もフォロー大事だよね。**という（今更感さえある）話題がHOTになっています。 「1on1は有名企業が取り組んでいるーーー」なんて、テンプレートっぽく取り上げられているくらい最近はよく聞くフレーズになりましたよね。 ノウハウがWebで公開されていたり、書籍もたくさん出回るようになり、後発組のWYRDはありがたく取り入れさせてもらいます。 ありがてぇ。ありがてぇ。 ソーシャルスタイル 1on1をやるにも、やっぱりある程度の知識は必要ということで、私は「実践！1on1ミーティング」という書籍を買って勉強をしました。 その中で「ソーシャルスタイル（理論）」という興味深い理論があることを知りました。 今回の記事では、この「ソーシャルスタイル」について、簡単に解説したいと思います。 ※今回の記事では1on1に関する具体的な話はありません ソーシャルスタイルって何よ （この辺りの話も、ググればいくらでも出てくるので何番煎じかわかりませんが、一応書きます） ソーシャルスタイルとは、1968年にアメリカの産業心理学者が提唱したコミュニケーション理論のことで、「感情表現」と「自己主張」を軸とし、その強弱によって他人とのコミュニケーション時の特徴を4つのタイプに分類するものです。 4つのタイプ ソーシャルスタイルは以下の４つのタイプに分類されます。 Expressive（エクスプレッシブ） 人間関係を重視する 自分自身が特別であることが大事 Driving（ドライビング） 合理性を重視する 結果やスピードが大事 Amiable（エミアブル） 人間関係を重視する みんなとの調和が大事 Analytical（アナリティカル） 合理性を重視する プロセスや根拠が大事 ざっくりとしたイメージはこんな感じです。 それぞれのタイプは共存するもので、実際には１つのタイプのみに当てはまることはありません。**「そういう一面が強い傾向にある」**程度に捉えるのが良さそうです。 それぞれのタイプをもう少し掘り下げてみます。 Expressive Expressiveな人の特徴は「人間関係重視・自己主張強め」です。 喜怒哀楽の感情が豊かで、物事はハッキリ伝えます。 周りの人と違う主張をして目立つことを好み、それによって多くの人から称賛されたい。特別扱いされたい願望を持っています。 感情表現において同じ方向性のAmiableとは、「自分のため」（Expressive）か、「周りのため」（Amiable）かの違いがあります。 自己主張において同じ方向性のDrivingとは、「自分を輝かせるため」の主張（Expressive）か、「結果を出すため」の主張（Driving）かの違いがあります。 Driving Drivingな人の特徴は「合理性重視・自己主張強め」です。 合理的な成果を求める上で、喜怒哀楽などの感情は不要。成果を出すために必要なことはズバッといいます。 何よりもスピーディに成果を出すことを大切にしており、何事も自分で決めたい、スピードを出せるなら過程は二の次と考える傾向があります。 感情の起伏が少なく、ハッキリ物事を言うため、一見すると怖い人に見られがちです。 感情表現において同じ方向性のAnalyticalとは、「スピーディな結果」が重要か（Driving）か、「納得いく結果を得るための過程」が重要か（Analytical）かの違いがあります。 Amiable Amiableな人の特徴は「人間関係重視・自己主張弱め」です。 感情表現豊かで温和な印象を与えます。何よりも調和を重視しており、自分が褒められることよりもチームが褒められることを喜ぶ傾向があります。 周りとの調和を重視するので、自己主張はほとんどしません。周りが楽しんでいるか、悲しんでいる人はいないかという点に心を砕きます。 自己主張において同じ方向性のAnalyticalとは、「みんなとの和」重視（Amiable）か、「理路整然としていて完璧であること」を重視（Analytical）かの違いがあります。 Analytical Analyticalな人の特徴は「合理性重視・自己主張弱め」です。 良い結果・納得できる結果を出すためにはどうしたら良いかを、時間をかけて考えながら物事を進めます。 いい加減なことは言いたくないので、自分のペースで納得するまでじっくり物事に取り組みます。 すぐに成果を求められることを嫌う傾向にあります。 で、これが何に役立つのか 効果的な1on1を実施するには、日頃から良好な関係を構築する必要があります。（見知らぬ人・信用ならない人から何を言われても伝わらないですもんね） これを、「ラポールを構築する」と言うそうです。 例えば、Amiableな上司が、熱心に仕事をしているAnalyticalな部下に対して「おー。頑張ってるじゃん。今どんなことしてるの？何か困ってたりする？」と話しかけたとします。 Amiableな上司としては、「みんなの和」のために何気ない会話をしただけのつもりなのですが、Analyticalな部下からすると「色々考えてたところに話しかけないで欲しいんだよなぁ...どっかいってくれないかな...」なんてことになったら困っちゃいます。 知らぬ間に信頼を失ったりしないように、日頃から気をつけないといけませんね。 前述したとおり、誰が100%どのタイプ。という分類はできませんが、「この人はこの傾向が強いから、こういう接し方しよう」という気遣い方は必要な気がしてきますよね。 まとめ で、じゃあ実際そういう接し方ができてるか。と言われると、これがなかなか難しいんですよね。 人間関係の構築は一朝一夕でできるものではないですし、根気強く取り組んでいかないといけないなぁと思わされました。 ちなみに、ソーシャルスタイル理論は別に仕事に限った話ではないので、家庭や友人との間でも当てはめることができます。 身近なひとを「この人はどのタイプかなぁ」なんて考えるのも意外と楽しいかもしれません。 ちなみに私は多分Amiableです。
こんな機能あったんだ 〜GitHub Suggested changes篇〜
こんにちは。浅野です。 寒くなってきて、お鍋が美味しい季節ですね。私はおでんが食べたいです。おでんの美味しいお店があれば教えてください。 さて今回ですが、GitHubの便利機能を教えてもらったので、それについて書いていきたいと思います。 タイトルにも書きましたが、GitHubのSuggested changesをご存知ですか？ざっくり説明すると、レビュアーが提示してきたコードの修正案を画面上の操作だけで取り込めてしまう、という機能です。要は「エディターで修正して、コミットして、プッシュする」という過程を取らずに、修正案を反映させることができます。 具体的な使い方を見ていきましょう。まずプルリクエストに対して、修正案を提示する方法です。コメントを記述する画面から、赤枠の箇所をクリックしてください。 すると、コメント欄に該当箇所のコードが反映されます。 これに手を加え、修正案を記述します。書き終わったら、通常のコメントと同様に送信します。 その結果、以下のように表示されます。ビフォーアフターが分かりやすいですね。 ここまでで修正案を提示することができました。続いて、修正案を採用する場合を見ていきましょう。なんと以下のボタンをクリックするだけです。これがそのままコミットになるので、コミットメッセージを変更したい場合はこの画面で編集してください。 無事、修正案が取り込まれました。 びっくりするくらい簡単ですね。こうした機能を活用して、開発スピードをアップさせていきたいです。 他にも使える便利機能があれば、ぜひ教えてください。 参考記事: https://docs.github.com/ja/github/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
EC2インスタンスにAWS EC2コンソール経由でアクセスしてみる
みなさん、こんにちは。 小林です。 早いもので、ブログを書き出してから１年が経ちました。 技術系の記事は適当なことは書けない(書きたくない)ので、元々裏どりを丁寧にする方ではありましたが、より丁寧にするようになったと実感しています。 それでは、今回のブログの内容はこちらです！！ つい先日、出先で突然、AmazonLinuxを触りたくなってしまったのです。 手持ちにはiPadがありましたがSSH接続できる環境が整っていなくて、困ってしまいました。 みなさんもそんな経験ありますよね？ そんな時に便利なのが、EC2 Instance Connectという機能です。 AWSコンソールからサーバにアクセスし、CLIにて操作することが可能になります。 C2 Instance Connect を使用した Linux インスタンスへの接続 今回は、EC2 Instance Connectを使用して、EC2インスタンスにアクセスできるようにするまでの手順を紹介します。 EC2 インスタンスを用意する 今回はほぼデフォルトの設定のまま、EC2インスタンスを起動させます。 リージョンは「オレゴン(us-west-2)」を使用します。 AMI 今回は、AmazonLinuxを使用したいので、AmazonLinux2用のAMIを使用します。 ちなみに、EC2 Instance Connectを使用できるOSに制限があり、以下のOSである必要があります。 以下に挙げた、サポートされている Linux ディストリビューションに対し、EC2 Instance Connect をインストールできます。 Amazon Linux 2 (すべてのバージョン) Ubuntu 16.04 以降 参考：EC2 Instance Connect セットアップ#Limitations インスタンスタイプ 特に希望がなければ、無料枠のt2.microで問題ありません。 インスタンスの詳細 ブラウザからEC2 Instance Connectを使用するためには、パブリックIPv4アドレスが必要になります。 ユーザーがインターネット経由でインスタンスにアクセスする場合、インスタンスにパブリック IP アドレスがあり、パブリックサブネット内にある必要があります。詳細については、Amazon VPC ユーザーガイドの「インターネットアクセスを有効にする」を参照してください。 参考：EC2 Instance Connect セットアップ#タスク 1: インスタンスへのネットワークアクセスを設定する ネットワーク関連の項目に以下を設定してください。 サブネット：パブリックなサブネット デフォルトのものを使用するのであれば、どれでも可 パブリックなサブネットに関しては、以下にて言及していますので参考までに AWS 踏み台サーバ(ネットワーク)の構築 自動割り当てパブリックIP：有効 もちろん、後から設定することも可能です。 ストレージの追加、タグの追加 この項目は特に指定がないので、デフォルトのまま使用します。 セキュリティグループの設定 EC2 Instance Connectを使用するにあたり、必要な設定は後述しますので、ご自身の必要な設定にしてください。 今回はブログ用なので、新しく作成し、デフォルトで設定されているSSH用のルール(0.0.0.0/0)も削除してしまいます。 これで、使用するインスタンスの準備は一旦完了です。 EC2 Instance Connectをインストールする 使用するインスタンスにEC2 Instance Connectをインストールする必要があります。 が、以下の条件を満たす場合、すでにインストールされているので、今回はスキップします。 それ以前のOSを使用する場合、下記のリンク先に手順が記載されていますので、そちらを参照してください。 以下に挙げる AMI は、EC2 Instance Connect に事前インストールされており、いずれかを使用してインスタンスを起動する場合には、このタスクはスキップできます。 Amazon Linux 2 2.0.20190618 以降 Ubuntu 20.04 以降 参考：EC2 Instance Connect セットアップ#タスク 2: (条件付き) EC2 Instance Connect をインスタンスにインストールする EC2 Instance Connect CLIをインストールする ブラウザを経由せず、自身のコンピュータを利用する場合には、EC2 Instance Connect CLIが必要になりますが、今回はブラウザからアクセスしたいので、スキップします。 詳細手順は、以下のリンク先を参考にしてください。 参考：EC2 Instance Connect セットアップ#タスク 3: (オプション) EC2 Instance Connect CLI をお使いのコンピューターにインストールする セキュリティグループの設定を行う ブラウザからアクセスする場合、EC2 Instance ConnectというサービスからのSSHでのアクセスを許可する必要があります。 (Amazon EC2 コンソールのブラウザベースのクライアント) インスタンスに関連付けられているセキュリティグループで、このサービスの IP アドレス範囲からのインバウンド SSH トラフィックが許可されていることを確認します。 参考：EC2 Instance Connect セットアップ#タスク 1: インスタンスへのネットワークアクセスを設定する SSH接続の許可 先ほどEC2に設定したセキュリティグループを開き、インバウンドに以下の設定を追加します。 ソースに設定する値は、以下から取得することが可能です。 https://ip-ranges.amazonaws.com/ip-ranges.json 参考：AWS IPアドレスの範囲 上記にアクセスするとJSON形式で記述されていますが、全リージョン、全サービス分が記述されているため、以下の項目で絞り込みます。 region: us-west-2 service: EC2_INSTANCE_CONNECT 絞り込んだら、ip_prefixに設定されている値をセキュリティグループのソースに設定します。 EC2 Instance Connectを利用するための許可を与える EC2 Instance Connectを利用するには、利用したいIAMユーザに対して、許可を与える必要があります。 IAMポリシーの設定 以下のポリシーを利用させたいIAMユーザにアタッチしてください。 サービス アクション リソース リクエスト条件 備考 EC2 Instance Connect SendSSHPublicKey 対象のインスタンス 条件キー: ec2:osuser限定条件: リクエストの任意の値演算子: StringEquals値: ec2-user リクエスト条件には、接続したいユーザ名やそのほかの条件を追加します { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ec2-instance-connect:SendSSHPublicKey", "Resource": "arn:aws:ec2:<リージョン>:<アカウントID>:instance/<インスタンスID>", "Condition": { "ForAnyValue:StringEquals": { "ec2:osuser": ["ec2-user"] } } } ] } 参考：EC2 Instance Connect セットアップ#タスク 4: EC2 Instance Connect の IAM アクセス許可を設定する これで準備は万端です。早速、接続してみましょう。 EC2 Instance Connectを使用してみる 対象のEC2インスタンスを選択し、接続ボタンを押下します。 EC2 Instance Connectを選択し、ユーザ名に対象のユーザ名を指定します。 そして、接続ボタンを押下します。 あら、不思議。EC2インスタンスにブラウザ経由でアクセスできるようにになりました。 インターネットに接続さえできれば、EC2インスタンスにアクセスし操作することができるようになりました。 これで、急にAmazonLinuxを触りたくなっても問題ありません。 他にも「セッションマネージャー」や「EC2シリアルコンソール」といった機能があるので、どういった機能なのかは今後調査していきたいと思います。
複数環境に対応したRailsアプリケーションの設定方法
Railsには RAILS_ENVと呼ばれる環境を切り替えるための環境変数が用意されています. 最初はこれだけでも十分ですが開発が進むと環境毎に切り替えるプロジェクトがよくあるので備忘録として自分がよくやる対応をまとめてみました. config_for config/database.ymlの様に環境毎で切り替える設定はconfig_forというメソッドがあるのでこれを使うとスッキリ書けます. Rails6 であれば、 shared でマージされるのでデフォルト値が手軽に設定できます.Rails5を使ってるのであれば、YAMLのAnchors and Aliasesを使ってマージすると便利です. # config/foo.yml --- shared: key3: "shared value" base: &base env: <%= Rails.env %> key1: "<%= ENV['MY_APP_KEY1'] || 'default' %>" key2: "hello %{user_cd}" production: <<: *base # config/application.rb module MyApp class Application < Rails::Application config.foo = config_for(:foo).deep_symbolize_keys end end ### ruby Rails.configuration.foo[:key1] # => default Rails.configuration.foo[:key2].gsub('%{user_cd}', 'dummy1') # => hello dummy1 Rails.configuration.foo[:key3] # => shared value # if Rails6 # => nil # if Rails5 設定より規約を活用して設定を減らす 普通にconfig_forを使ってるとYAMLの設定ファイルの運用が進むにつれて数が増えてきます.もしくは、既存のシステムがあるとすれば既に膨大な設定になってるかと思います.そこで設定より規約を使って最初から規約寄りにしておいた方が良いでしょう. YAMLでは値にkey1: nullとあるとNULL値(Rubyだとnil)になります. key1: 'null' の様にクォートで囲むと文字列の"null"になります. これを利用して以下の様にしていきます. # config/foo.yml --- production: key1: <%= "'#{ENV['MY_APP_KEY1']}'" || 'null' %> # config/application.rb module MyApp class Application < Rails::Application config.foo = config_for(:foo).deep_symbolize_keys end end ### something ruby implements def config_foo_key1 "${Rails.configuration.foo[:key1] || 'default'}" end config_foo_key1 の様に実装側にデフォルト値を用意することで、YAMLの設定ファイル自体がコンパクトになります. baseやshared にデフォルト値を寄せても良いと思います. このケースの良いところは全ての環境が規約だけで運用できる様になった時、YAMLファイルが不要になるところにあります. 既存のハードコードされた設定があるのであれば、これらの方法を使って減らしていくと良いと思います. bundle exec rails runner -e development 'puts config_foo_key1 'default' MY_APP_KEY1=foo bundle exec rails runner -e production 'puts config_foo_key1 'foo' 環境変数にも規約をつける アプリで固有で使う環境変数にも MY_APP_KEY1 の様に接頭辞MY_APP_の様に規約をつけると良いでしょう.grepした時に探すのも楽になるし、直感的にアプリ固有の環境変数だということがわかります. 環境毎にユニークな名前空間を使う ここでの名前空間は以下の様なものを指しています. AWS S3のバケット名 ディレクトリのパス データベース名 全文検索のインデックス名 キャッシュのキー名 通常、プロダクション環境だと、複数環境が相乗りになることは無いはずですが、デモ環境や開発環境は複数環境が相乗りになることがあります. 含める変数 Railsでは 環境変数 RAILS_ENV があるし、parallel_tests では ENV['TEST_ENV_NUMBER'] を使って並列に動作できるようにしています. さらにアプリ固有の環境変数もある場合もあります. これらを含めた名前空間にすることで開発環境の様に developmentとtestが同じPCで動かせる様になります. 例えばS3のオブジェクトのキーを考えてみましょう. 環境変数とデモ環境などの実際に動作する物理的な環境であれば MY_APP_ENV の値には demo,prd,stg, qa そして dev の様な値が入るとします. 名前空間は "#{Rails.env}#{ENV['TEST_ENV_NUMBER']}/${ENV['MY_APP_ENV']}" の様な規約にしておきます. これらの変数の組み合わせが展開されると以下の様になります. 名前空間が重なってないため柔軟に同じサーバや開発環境内に同居できる様になります. RAILS_ENV TEST_ENV_NUMBER MY_APP_ENV name space development dev development/dev production demo production/demo production prd production/prd production stg production/stg production qa production/qa test dev test/dev test 2 dev test2/dev
QUICご存知ですか？
連日暑い日々が続いていますが、みなさんいかがお過ごしでしょうか。 WYRDの豊田です。 最近は日傘とハンディ扇風機を常に携帯するようになりました。 マスクをしながら、この酷暑を乗り切るのは今年で最後にしたいところですね。 さて今回のブログでは、HTTP/3を実現する上で合わせて策定され、5月にIETFにより承認された"QUIC"（クイック）というプロトコルについて書いていこうと思います。 HTTPの歴史 QUICを説明するには、まずHTTPの変遷について理解しておく必要があります。 HTTP/1.1 HTTP/1.1は、1997年に最初のRFCが発行されて以来、これまで何度も拡張を繰り返し、現在も利用され続けています。 近年のインターネットの目覚ましい発展により、HTTPには通信データ量の増加、通信速度の高速化が求められるようになりました。 ここでHead of Line Blockingという問題が表面化します。 HTTP/1.1には「リクエストとレスポンスは送受信の順番を一致させる」というルールがあり、処理に時間のかかるリクエストをすると、その処理が終わるまで次のリクエストは処理を待たされます。 これを(HTTPレベルの)Head of Line Blockingと言います。 クライアント サーバー | | |--------- req_1 -------->|---- | | ^ | | | | | この間req_2を送っても処理されない | | | | | v |<-------- res_1 ---------|---- | | いくつかの回避策（HTTPパイプラインやコネクション多重化）は考えられましたが、どれも根本的な解決にはなりませんでした。 通信の効率が落ちてしまうこの問題は、発展を続けるインターネットの世界で悩ましい問題だったと言えるでしょう。 HTTP/2 2015年5月、HTTP/1.1の抱える問題の解決を図るため、新たなRFCが採用されます。これがHTTP/2です。 HTTP/2では、ひとつのTCPコネクション内にストリームという通信の単位が与えられ、リクエスト-レスポンスをセットで管理するようになりました。 個々のストリームを独立した通信として管理することで、あるストリームで発生した遅延が他ストリームに影響を及ぼすことはなくなりました。 これで(HTTPレベルの)Head of Line Blockingは解決されました。 ※HTTP/2ではヘッダの圧縮など、他にもさまざまな点で効率化が図られましたが、今回は割愛しています HTTP/2にも問題があった HTTP/2の登場により、全て解決...とはなりませんでした。 次に問題になったのは(TCPレベルの)Head of Line Blockingでした。 TCPとは、HTTPのプロトコルスタックにおいて、下層で利用しているトランスポート層のプロトコルです。 TCPは通信の信頼性（データの欠落や誤りが無い）を保証します。 その性質上、通信（パケット）に問題が発生した場合、その問題が解決されるまでTCPレベルで通信が止まります。 HTTPはTCPの上で動作するプロトコルなので、TCPレベルで通信が止まると、当然HTTPも通信が止まります。これが(TCPレベルの)Head of Line Blockingです。 多くの場合TCPの信頼性の担保はOSレベルで行われるため、アプリケーション(HTTP)は問題が解決するまで待つしか無いのです。 QUIC登場 2013年、Googleが独自に開発を進めていた QUICというプロトコルが発表されます。 当時はトランスポート層とアプリケーション層のプロトコルが混在し、プロトコルスタック上では明確に分けられていなかったようです。 TCPレベルのHead of Line Blockingに対する解決が試みられていたこのプロトコルは、2016年にIETFワーキンググループが発足し標準化が進められることになります。 QUICの特徴 QUICはトランスポート層のプロトコルですが、下位プロトコルに同じトランスポート層のUDPを利用しているという特徴があります。 UDPは通信の信頼性を保証しませんが、上位のQUICが通信の信頼性を保証するための拡張を行います。 TCPでは手の届かなかった痒いところをUDPの拡張により解決した感じですね。 2020年時点で、QUICにはGoogle QUICとIETF QUICという**"似て非なるプロトコル"**が混在している状況ですが、Googleは順次IETF QUICに対応していくことを明言しています。 ChromeではすでにHTTP/3が？ QUICと並行して策定が進められているHTTP/3は、現在草案34版がでていますが、正式なRFCにはなっていません。 ただし、最新のGoogle Chromeを使ってGoogleのトップページへアクセスすると、すでに（部分的に）HTTP/3が利用されていたりします。（Protocolが "h3" となっている） 最後に QUICはTLS（暗号化）なども一手に引き受けることで、コネクション確立を効率化したり、トランスポート層の通信内容まで暗号化できるなど、他にもさまざまな改善が盛り込まれています。 ただ、世界にはすでにたくさんのTCPで動作する機器が存在していることもあり、すぐにQUICが主流となることはなさそうです。 環境と仕組みが相互に発展を続けていく、というサイクルの象徴的な出来事と言えるかもしれません。