【Kubernetes】Kubernetes 用語やコマンドの調査メモ

はじめに

業務で Kubernetes を使った環境構築が必要となったため
調べたことをメモっていたら記事にできる量になっていたので
ブログに掲載します。

環境

  • macOS Sierra
  • Google Cloud Platform
    • この環境で確認したものもあるため

前提条件

  • Docker, docker-composeにローカル環境が構築できる知識レベルであること

Kubernetes(クーべネティス または クーバーネティス) 略して k8s

一言で言うとコンテナ周りのことをよろしくやってくれるもの。
横文字で言うと「オーケストレーションツール」。

基本構成

  • 複数サーバでのコンテナ統合管理
  • コンテナ間のネットワーク管理(IPアドレスの管理/ルーティング)
  • コンテナに割り当てるストレージの管理
  • コンテナの負荷分散
  • コンテナの監視
  • 無停止でのアップデート

サーバ構成

マスターサーバ(Kubernetes Master)

Kubernetesクラスタ内のコンテナを操作するためのサーバ。
kubectl コマンドを使ってクラスタを構成したりリソースを操作する際は
マスターサーバがコマンドからのリクエストを行って処理を行う。

ノード(Node)

  • Dockerコンテナを動作させる仮想(物理)サーバ
  • ノードを複数用意して、クラスタを構成する
  • ノードの管理は、マスターサーバが行う

バックエンドデータベース(etcd)

etcd と呼ばれる Key-Value Store(KVS) を使って
クラスタの構成情報をまとめて管理する。

レジストリサーバ(Docker Registry)

クラスタ内で起動するDockerコンテナのもとになるDockerイメージを管理するためのサーバ。
Docker Registry を使って構築することもできる。

用語

クラスタリング

複数サーバを束ねて、利用者や外部のシステムに対して
全体で1台のコンピュータであるかようにみせる技術のこと。

ただし、Dockerコンテナでのクラスタリングの考え方は異なる。
コンテナが稼働するサーバを複数用意して、それぞれのサーバで複数のコンテナを並列稼働する。
何らかの理由で、サーバ上のコンテナが正常動作しなくなった場合、他のサーバで該当の
コンテナを起動し直すことで、アプリケーションのフェイルオーバーを行う。
上記のことやヘルスチェックをオーケストレーションツールによって行われる。

Pod

仮装NIC(プライベートIP)を共有するコンテナ郡をまとめたものをPodと呼ぶ。
k8sはPodの単位でコンテナの作成/開始/停止/削除といった操作を行う。
Pod内のコンテナは同一のノード上に配備される。
また、Pod内のコンテナで共有するディレクトリを配置することも可能。
たとえば、アプリケーションが稼働するコンテナとログ収集ツールを導入したコンテナを
1つのPodにまとめて起動すれば、localhost経由での通信、あるいは、共有ディレクトリを介して
ログ情報をやり取りすることが可能。

Replication Controller

同一構成のPodが指定の数だけ起動している状態を作り出す。
Webサーバが稼働するPodを負荷分散用に複数起動するような際に利用する。

Podを起動する際は Pod単体か Replication Controller 経由で起動するか選べるが
Pod単体で起動した場合、Podの数は動的に増やせない。
なので、本番環境で稼働させるときは、Replication Controllerから起動すること。

Deploymentの設定ファイルを通して、Replication Controllerの設定/管理をする。

なお、今は Replica Sets が次世代のものとなっている。

Deployments

Deploymentsはアプリケーションインスタンスの作成と変更を担う。

Service

Podを起動しただけでは、外部からアクセスできない。
起動中のPodに対して、Serviceを定義することで外部からアクセス可能をIPアドレスを用意される。
複数のPodに対して、これらをまとめた1つのServiceを定義する。
Serviceに対応するIPアドレス+ポート番号にアクセスすると、複数のPodに対する負荷分散が行われる。

新規にPodを起動すると、既存のServiceのIPアドレスとポート番号は、環境変数として
参照できるようになる。また、GKEの環境では、クラスタ内部のDNSを用いて、独自のサービス名による名前解決もできるようになっている。

Ingress

通常、ServiceとPodだけでサービスを稼働させることは可能だが
Ingressを定義することによりInternetとServiceの間に入り接続のルールをまとめることができる。
例えば、HTTPSの負荷分散をすることができる。

秘密情報の管理

k8sでID、パスワードなどの秘密情報を管理する場合 Kubernetes Secrets を使って管理する。

例:staging環境のものを確認

# staging環境のクラスターに接続するための準備
gcloud config set project sample-staging
gcloud container clusters get-credentials sample-cluster --zone asia-northeast1-a

# 秘密情報を確認
kubectl get secrets

# 表示結果
NAME                 TYPE                          DATA      AGE
sample               Opaque                        2         174d
sample2              Opaque                        7         202d
以下略

# 秘密情報の内容を確認
# 例:adminの内容を見る
kubectl get secret sample -o yaml

Helm

Helmとはk8sのパッケージングマネージャーという位置づけ。
apt-get , yumrpm, Homebrew と同等です。

よく使う、使ったコマンド

Kubernetes

コマンド 意味
kubectl run [deployment name / pod name prefix] --image=[image]:[tag] [cmd] クラスタ内でコンテナを作成
kubectl expose [deployment name / pod name prefix] [コンテナ名] --type=[サービスタイプ] サービスを外部公開できるようにする
kubectl get [ingress, services, deployments, pods, secret] リソース一覧
kubectl get secret [リソース名] -o yaml リソース内容をyaml形式で表示
kubectl describe [ingress, services, deployments, pods, secrets/[リソース名]] リソースの詳細情報表示
kubectl exec -it [コンテナ名] /bin/bash Podのコンテナ内でコマンド実行
kubectl proxy ローカルプロキシが起動され、現在参照しているk8sの内容を http://localhost:8001/ui/ で確認できる
echo "[エンコードされた文字列]" | base64 --decode エンコードされた文字列を表示

参考文献

【Rails】ローカル環境の開発でサブドメインがある場合「localhost」ではなく「lvh.me」を使う

はじめに

Webサービスを開発していて、初めて知ったのでメモ。

環境

前提条件

Rails Engineで管理画面を作成していて、以下のように記述してあること。

mount Admin::Engine => '/', constraints: { subdomain: 'admin' }

また、Dockerが起動していて localhost:3000 にはアクセスできること。

詳細

よくある記事では localhost:3000 が記述されており
通常はこれで問題ありません。

しかし、サブドメインを含めた形にすると localhost ではできなくどうしたものか?と考えていました。

そこで調べて出てきたのが lvh.me です。 参考サイトには以下のように書かれています。

lvh.meというドメインを持っている人が開発用に127.0.0.1DNS登録してくれている. localhost以外のドメインサブドメインのテストでローカルの開発環境のアプリにアクセスしたいときに使えるというもの. http://tech.clickyourstyle.com/articles/30

こんな便利なものがあるとは。 ということで、早速 lvh.me を使ってみると以下のURLになります。

まとめ

今までは /admin でやったりしていたのですが
これでローカルでも気軽にサブドメインの開発ができて捗りそうです。

参考

lvh.meというループバックドメイン:Technical tips:Media hub

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

前回に引き続き参加してきました。
自分もプログラマなので、プログラマ関連の話はすぐに聞けますが
マネジメント周りの話はなかなかなく、他社の事例を聞けるため
勢い良く参加しました。

※メモはスライドに書かれている内容を書かず
なるべく登壇者が話した内容をメモするようにしています。
なので、飛び飛びなところもあります。

概要

cyberagent.connpass.com

内容

イベント趣旨説明

まず、参加者全員で「VPoEとはどういうものか?」というのを定義しました。

前回と同じ流れだったので特にメモはしていないのですが
個人で定義が曖昧なので、この説明は毎回必須だなと思いました。

スライドの内容は前回と同じだったはずなので
前回開催されたブログを一時的に掲載します。

developers.cyberagent.co.jp

『成果を出し続けるエンジニア組織を目指してやってること』

speakerdeck.com

登壇者がやっている内容を共有していただきました。

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

ウエパはエンジニア管轄とディレクター管轄があり
エンジニア側のマネージャーにいる。
そして、各種特化したチームがあり、全体で20人強

CTO, VPoEの役職はない。
マネージャーがVPoE的役割
技術ボードがCTO的役割

VPoEの定義は
成果を出し続けられるエンジニア組織を作っていくこと

じゃあ、何を目指してやるものか?
ビジネス的に動けるエンジニア組織となること

マネージャー業務に関して一例をあげられた
特に時間を取っているのは「他部署のマネージャーや担当執行役との定期的な情報共有やMTG」
組織的に解決したいことがあった際に呼ばれる。

問題に当たったら先人の知恵を借りて物事を進めている。
1人で解決できなかったことがないくらい先人の知恵を借りている。

メンバーとの対話ポイント
1on1
 No雑談、目標進捗を話すことは少ない
 週ごとにテーマを決めての会話(10枚程度カードを用意していて、成果や不満、悩みが書かれており、1回につき2, 3枚ピックアップして話す)
 雑談から話すよりもしっかりテーマが決まっているのでスムーズに進む。
 やる側としてコーチング時間であることを意識している。

参考書籍は「ドラッガーさんに教わったIT技術者が変わる50の習慣」
技術スキルと人間スキルが成長のための両輪であることを参考にした。

内発的動機を1on1を通じて加速させるようにしている。

対話ポイント
 権限委譲
  マネージャーレベルだけでなく、メンバーレベルで意識してもらうことが大事。
  若手ほど権限委譲で「伸びる!」マッチして掛け算レベルで成長する。

参考書籍は「経営者の条件」
仕事を「人」に合わせること

成果へのありがとう
 これは難しい。
 感謝の「ありがとう」の言葉より、同調が大事。
 メンバーからは一歩引かれた形に見られてしまう。

マネージャーは真摯な態度が大事。

個人ビジョンに沿う目標の設定
 3ヶ月毎に実施。マネージングで会社の目標と個人目標をマッチングさせること。

コトに向かう
 コトを成すことに精一杯取り組む。

チーム作りで「カンバン方式」がオススメ。
 仕事が見える化された。
 タスクの流れが明確になった・・・などメリットがあった。
上記をやってから施策をやっていくのが良い。

経営層の考えをメンバーに伝達
 経営層の端的な言葉を、まず自分で噛み砕くことをして下に伝えるようにする。

途中のスライドまでしかメモがないのは、時間がなくなったためです。
逆に時間がなくなるぐらいたくさんのことをやっていて共有したいことがあるという現れだと感じました。

『組織をシステム化するReactive Management』

www.slideshare.net

タイトルの発想がとてもユニークだと思いました。
また、内容も的を得ているなと思うものでした。

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

VPoEはマネジメント?
複雑な人間関係、自分でコントロールできないところもある。
Cyberでも定義が曖昧だが、必ず必要な役割である。

VPoEに必要なところをカテゴライズして、直列化することにより
ビジネススピードを拡大させる必要がある。

リアクティブマネジメントとは?
元はリアクティブ宣言
マネジメント対象の行動を常に観察し、行動に対してフィードバックを即座に返す
マネージャーは「観察」が重要である。

マネージャー自身は多数の「仕事の定義」を持ち「観察」を行い、何か(イベント)があれば即応する。
半年前のことを言われても「今更その話」となってしまう。
参考書籍:パフォーマンス・マネジメント

採用・退職・ヒューマンマネジメント・開発プロセスをKPTを使った振り返りでカイゼンすることによりチームの耐障害性を高める。

スキルや経験は人に宿るため「その人」だからできることがある(Not その人にしかできない)
どんな人がいるチームかによってフォーメーションは弾力的に変える。

開発責任者は結果論で決まるので、柔軟に決めていく。

自分がボトルネックになってはいけない。自分からpullしていたらもたない。
Evernoteに会話メモを残し、メモリスタックをどこでもロード可能にする。
外部にタスクスケジューリングを任せる。

マネージャーの評価はどうされるべきか?
そのまま評価指標・基準に利用することも可能
 ・即応性
 ・耐障害性
 ・弾力性
 ・メッセージ駆動
マネージャーとしての価値はその再現性(immutability)の高さ
いつでも、どこでも、どんな状態でもReactivityを出す。

今プロダクトを作っているチームと同等のものを違う人、地域で作れるようにしないといけない。

組織というのは自分の思っているより3期ぐらい遅れてやってくる。(後追いで来る)
人は誘導できないから、後からついてくる形となる。
マネージャーは常に次のチャレンジをし続けるようにして「次も任さればいいチームを作る」という認識を持ってもらう。

VPoEは結局マネージャーである。
アイデンティティとして「自分はエンジニアである」と考えていることが重要

Web世代の人は技術をクリアした上でマネージャーとなっているため
一昔前のマネージャーとは違うもの。
名刺にもマネージャー、エンジニアとも書かれている。

エンジニアにアイデンティティを持っていて、いつでもどこでもどんな状況でもReactivityを再現できることに強みを持つ
Webエンジニアが作るマネージャーの再定義
マネジメントは技術である

エンジニアでやっていることをマネージャーになっても同じことをやればよい。

ガッツリなマネージャー論かと思いきや
エンジニアでもわかるような内容だったと思います。

『ゼロからのエンジニア組織作り(仮)』

speakerdeck.com

スタートアップから携わっていて、会社の成長につれての話を聞くことができました。

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

設立期は事業の立ち上げが最優先、安定した品質のゲームをいかに速くリリースできるか?にフォーカス

人数が少なかったので、1人1人の当事者意識が自然と高まった。
キーマンの採用が速いかった。
コミュが密。

採用担当者同士で採用基準、判断基準のすり合わせ
有識者にとにかく聞く、巻き込む
1人で判断しない

設立的には技術面の魅力が語りにくい(魅力的な技術よりも事業立ち上げが最優先だったため)

成長期
うまく行ったこと
 新たなリーダーの抜擢、成長
 若手の活躍、成長
 月イチの1on1を開始
  事前にシートを記入して面談する
  ただし工数が非常に重く感じていてカイゼンを考えていくところ
 1年目限定新卒朝面談
 読書会の開始

変革期
新たな技術の習得が必須になった。
既存コードを捨てて再設計(サーバサイド)
技術チャレンジを事業成果に
技術的負債の返済を積極的に

VPoEとしてどの部分を意識してやってきたのか?を絡めて話してもらえれば
もっとわかりやすいと思った。

具体的な業務内容を期ごとに書かれており
とてもわかりやすかったです。

LT

メモを取れる状態ではなかったので、スライドだけ共有します。

speakerdeck.com

speakerdeck.com

後1つスライドあったのですが、見つからなかったため
掲載され次第ここに追記します。

全体を通しての感想

今回も他社の事例を聞くことができて、とても参考となりました。
また参考書も豊富だったので読んでみようと思います。

後、自分の会社でやっていることを他社でもやっていてちょっとやり方が違うだけ
というのもいくつか見られたので、そろそろまとめられるのでは?と思いました。
VPoEだったら、これはやっとけ!みたいなものです。

そして、アンケートに書き忘れましたが
VPoEはエンジニア出身が多いと思うので、どのようにビジネスサイドに入っていって
ビジネス側とエンジニア側を円滑に回しているのか?というのも聞きたいと思いました。

また次回も参加します。

【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の役割は組織全体に対してであり
手広くカバーをしなければいけない役割だと思いました。

スライドの内容が開催ブログに上がっていました。

developers.cyberagent.co.jp

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

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リファレンス