日常

ケ・セラ・セラ

表参道.rb #27 ~ RubyKaigiのおさらい

ruby .rb

RubyKaigi のブログ記事をまだ書けていない...。ヴァル研究所の見学ツアーにも行ったのだけど、それもまだ書けていない...。という感じの近況です。

brainf*ck のオレオレ実装をやってみたので、その発表をした。最初は Quine の発表をするつもりで準備したけれど、間に合わなくて内容を変更した。あまり RubyKaigi のこととは関係無い発表になった。

途中で某 RubyKaigi Speaker が来てくれて、いろいろな話が聴けてとても良かった。

その他には、ブログに書かないと gem 使ってもらえない。という話だったり、本を書く人の大変な様が良くわかった。

github.com

自分が登壇した勉強会のことぐらいは書いていこうと思う

diary

ブログはここのところ全然書いていなかったけれど、自分が登壇や運営に関わった時のことぐらいは書いていこうと思っている。 koic さんや sue さんがちゃんとブログに書いているのを見たり、hsbt さんが毎日書き続けてるのを見てなんとなく思った。

特に railsdm の運営のことなんかは、自分にしか書けないことなどもあるのだからそういうのこそ書くとよさそうだ。

とりあえず 6/3 以降というと、こういうことをしていた。いろいろあった。

  • 20170622 railsdm2 LT と 運営
  • 20170706 omotesandorb24 LT
  • 20170720 railsdm3 運営
  • 20170729_tokyurubykaigi11 LT
  • 20170803_omotesandorb25 LT

slide は全部 GitHub にあがっている。

github.com

読書メモ　『アポロ13』に学ぶITサービスマネジメント

book

様々な流れから読もうという気になって、時間が無いのでとりあえず 1h で読み切った時のメモ。あまり感想かけていないけれどもうそのまま残す。雑ですまん。でも書かないよりマシでしょ。

kindle からコピペすると崩れるけど直すほどのモチベーションは無くそのままです。

推薦のことばから

  • 本書 の 最大 の 特徴 は、 ITIL や アポロ 計画 の こと を よく 知ら なく ても 読み 進め られる こと、 そして 非常 に わかり やすい こと

ほうほう

  • ITSM の 本質 を 知る こと が できる はず です。 ITSM の 本質 とは、 IT サービス の 本質 でも あり ます。

ほうほう（以降、感想がほうほうの場合は省略）

はじめにから

  • しかし、 日本 において は 未だ IT サービス マネジメント の 理念 や 考え方 が 正しく 広がっ て いる とは 言え ませ ん。 そこで 本書 では、 IT サービス マネジメント の 理念 や 考え方 をより 具体的 に 楽しみ ながら 理解 できる よう に、 映画『 アポロ 13』 を 題材 に し た 手法 を 採っ て い ます。

chapter1 IT サービスマネジメントとは

サービスについての説明がされている。サービスとはとか。自転車、 バイク、 自動車 などと、電車やバスとの対比とかで説明している。電車に乗る権利。

  • サービスにおける価値、２つの側面。有用性と保証についての説明。
  • IT サービスマネジメントについての説明
  • こういうの多分、こういう本を引用したりしないと。有名人の言葉とか。個人が同じこと説明しても雰囲気悪くしたり取り合ってもらえない状況って多そう。うまく伝わるなら良い場だな。
  • IT サービスマネジメントの教科書 ITIL
  • 段階。それぞれ「 サービスストラテジ（ 戦略）」、「 サービス デザイン（ 設計）」、「 サービストランジション（ 移行）」、「 サービス オペレーション（ 運用）」

chapter2

  • アポロ計画の歴史
  • 宇宙開発の過程と絡めて説明してる
  • 社会的な背景も絡んできた
  • ビジネスも背景が重要という話
  • 映画アポロ13 の登場人物紹介
  • 宇宙船の仕組み

ここから2部 サービスストラテジ

chapter 3

  • PDCA が出てきた
  • 目的とは、目標とはの話
  • アポロ計画の戦略のはなし、戦術（行動計画）については本書では省略するの断り
  • small step quick win
  • アポロ 計画 では、 アポロ 11 号 で 初めて 月 へ 到達 し、 無事 に 地球 に 帰還 し まし た。 すなわち、 いきなり 月 に 行っ た わけ では あり ませ ん、 1 号 ～ 10 号 までは、 段階 的（ Phase ごと） に 実行 さ れ まし た。

だいじですよね

  • 問題管理について。インシデント管理は 6章で。とのこと
  • プロセスの標準化と整備、テストとリハーサルの話。冗長化の徹底。アポロ計画における測定の話。

この辺りもう、開発ですね。

chapter4

chapter 5

  • アポロ計画とサービス
  • アポロ計画は複数サービスの集合的な説明をしてる。
  • サービス を 提供 する 側、 すなわち サービス・プロバイダ 側 から する と、 それぞれ の サービス を きちんと 設計・構築 し て おく 必要 が あり、 障害 が 発生 し た 場合 の 対応 や 変更 の 要求 にも 応え なけれ ば なり ませ ん。
  • しかし、 顧客 と ユーザ、 この 場合 は アメリカ 大統領 と 3 人 の 宇宙飛行士 の 側 から すれ ば、 すべて の サービス が「 アポロ 13 号 計画」 という １つ の 巨大 な サービス に 見え て い た こと でしょ う。

ありますよね

3部 サービスオペレーション

chapter6

  • インシデントの話だ
  • 大きく2つに分けられる。障害と問い合わせ。
  • ITIL では、 問い合わせ の こと を「 サービス 要求」 と 言い ます。
  • ワークアラウンドの説明
  • インシデント管理する上での原理原則３つ
  • それとアポロ13 における事例で対比で紹介している

開発してるとそのまま分かるところは分かるけど、エンジニアでなければ、これは分かりやすい説明だろうなあという感想。

chapter 7

  • サービスデスクのはなし。
  • SPOC とは、 Single Point of Contact の 略
  • インシデント管理との連携の話や、スタッフに求められる能力の話、エスカレーションの話

chapter 8

  • 問題管理のはなし
  • IT サービス マネジメント の 世界 では、「 問題」 という 言葉 を、 通常 とは 少し 違う 意味 で 使用 し ます。 端的 に 言え ば、 問題 とは、「 インシデント の 根本 原因」 の こと です。
  • 問題 管理 とは、 発生 し た インシデント の 根本 原因 を 究明 し、 可能 で あれ ば その 原因 を 取り除い て 再発 を 防止 し、 サービス 品質 と ユーザ 満足 度 を 一定 の 水準 に 保つ こと を 目的 と し た プロセス です。 問題 管理 の 目的 は もう １つ あり ます。 それ は、 今 まで 発生 し て き た インシデント の 傾向 を 分析 し、 その 根本 原因 を 考察 する こと で、 発生 する かも しれ ない 未知 の インシデント の 発生 を 未然 に 防ぐ ため に あらかじめ 対策 を とっ て おく こと です。
  • は、 慣れ た オペレーション（ 反射的 オペレーション） ほど、 よく 間違う もの です。 しかも 反射的 に 作業 を 行っ て いる ので、 自分 が 間違っ た 操作 を 行っ た、 という こと に 気づき にくい の です。

わかる

4部 サービスデザイン

chapter 9

  • SLA とは Service Level Agreement の 略 で、 日本語 では「 サービス レベル 合意 書」 と 呼ば れ ます。 顧客 と IT サービス・プロバイダ との 間 で 交わさ れる、 IT サービス の 内容 や 品質 に関する 合意 文書 の こと です。
  • インシデント発生した時の事業側と顧客側の対応の話とか
  • その他の文書の紹介

chapter 10

  • 可用性の話。公式とかも載ってる
  • 稼働率とか、可用性管理のはなし
  • 可用性の3要素、信頼性＋保守性＋サービス性で可用性。

chapter 11

  • 電力重要。キャパシティ管理のはなし
  • 各種制限にかんする説明

ちょっとつかれてきた

chapter 12

  • 継続性のはなし
  • 本来 ITSCM は、 事業 継続 性 管理（ BCM： Business Continuity Mana gement） の 一環 として 行わ れる べき もの です。 BCM とは、 事業 を 継続 し て いく 上 で 許容 できる 範囲 で リスク を 低減 さ せる こと と、 その リスク が 実際 に 発生 し て しまっ た 際 に 迅速 に 復旧 さ せる ため の 計画 を 立案 し、 ビジネス に 与える 影響 を 最低限 に 抑える こと を 目的 と し た 活動 です。 その BCM は さらに、 事業 継続 性 計画（ BCP： Business 　 Continuity 　 Plan） の 一環 で なけれ ば なり ませ ん。
  • SPOF

SPOF !!!

5部 サービストランジション

chapter 13

構成管理の話か 何を管理するか、資産管理と構成管理は違うので区別しよう。

chapter 14

変更とは。本書での変更の定義の説明。変更管理や用語説明

chapter 15

やっとリリースの話だ リリース管理、計画について

6部 継続的サービス改善

chapter 16

  • アポロ計画は改善の塊！たしかに。
  • KPI が出てきた。KPI（ Key Performance Indicator： 重要 業績 評価 指標） とは、 目標 を 達成 する（ ITSM 的 には SLA を 遵守 する） ため に 測定・評価 する ため の 指標 の こと です。
  • IT 投資 と ROI と SLA 判断についての話をしている
  • SLA とコスト改善

この辺に来るともう、落ち着いて2周目を読まないとだな。特に最後の方。

付録

ITIL の 資格 スキームについて

以上。

感想的なもの

開発的な話は、これでエンジニアでない方にはある程度は分かりやすく伝えられるのではないかと感じた。 でも、やっぱりエンジニア文化的なものが伝わるかというのは別の問題だと思った。 終盤はビジネスの話の方が濃くなってくるので、逆に自分はその辺りが消化不良。2周目でゆっくり読む必要はありそう。

日記です。 表参道.rb #23 ~ Ruby/Railsの学び方 ~ #omotesandorb

.rb

4月には書いていこうと意気込んだものの、5月は結局更新がないまま 6 月を迎えてしまった…。日記すら書けていない。

表参道.rb#23 に行きました。会場は Sansan さんです。

omotesandorb.connpass.com

先月に引き続き nolick さん、神速さんの発表を聞いたり、今回は飛び入りでの LT 発表者も多くて LT の時間が足りなくなる程だった。なんとか.rb 初参加、初 LT という方もいて、めでたい感もあった。

自分は今回は Rails よりも Ruby の学び方に寄った内容の発表をした。

https://284km.github.io/slides/20170601_omotesandorb/slides/#/

自分ごときが Ruby の学び方について語るのか？とか無くはないけれど、そうじゃなくて、自分が実際にやってきたこと、その中で感じたこと思ったことを発表する場なのである。そして共有することによってもし誰かの約に立てば御の字。という気持ちで資料を書いたり発表したりしていた。

スライドに現れない部分では、"今日この場に Rails というよりまず Ruby を学びたくて来ています" という方がどの程度集まっているか挙手して頂いた。5, 6 名程度の方が該当した様で、集まった人数の 5分の1 程度の割合でした。やはり Rails 関連の知識を求めている方が多いのだなと再認識した。

発表内容は要約すると、

  • 自分で実際に書くと覚えが良い
  • なので、Ruby で何か書く為の知識を素早く知りましょうの観点で各要素を紹介
  • Ruby 特有なもの、ハマりやすいと感じる部分の紹介
  • Rails は、Rails Tutorial 周回をおすすめ。Rails Guides も併用をおすすめ。
  • Rails Tutorial が難しく感じ、独学で聞ける頼れる人がいなければ Rails の教科書が良さそう。
  • 別の視点で、聞ける人が身近にいると、そういう関係を作れるとかなり効果が高いという話

発表を聞いた中で特に印象的だったのは、勉強会では実例を聞き、話し、議論することを意識しているという態度や、普段使っているばかり(OSS) なので、貢献していきたいのですという気持ちの話。完全に共感できるので、自分も仕事に押されてばかりいないで、それはそれで時間が無い中でのやり方としていずれ知見として発表できる様になれば良いなと思う。まずは小さくても続ける日々。量と継続は大事。そういう気持ちで、例えば昨日お昼の時間だけで出来そうなことをやった例などは紹介できる。

github.com

根本的に時間が作れる状態にして行くのが健全だとは思う。勉強会では時々こういう気持ちの高まりも得られたりする。とても良い会でした。

encrypted_secrets についてのメモ

rails

v5.1.0.rc2 を使ってみていた。encrypted_secrets について確認したことをいくつかメモしておこうと思います。

まあ主に使い方はここ railties/lib/rails/commands/secrets/USAGE を見れば書かれているのですが、簡単に補足を加えつつ日本語でいきます。

encrypted secrets を使うにはまず、secrets:setup します。以下のようになります。

$ rails secrets:setup
Adding config/secrets.yml.key to store the encryption key: 40dc6a0dcf24059ce1edf48b7a242518

Save this in a password manager your team can access.

If you lose the key, no one, including you, can access any encrypted secrets.

      create  config/secrets.yml.key

Ignoring config/secrets.yml.key so it won't end up in Git history:

      append  .gitignore

Adding config/secrets.yml.enc to store secrets that needs to be encrypted.

      create  config/secrets.yml.enc

For now the file contains this but it's been encrypted with the generated key:

# See `secrets.yml` for tips on generating suitable keys.
# production:
#  external_api_key: 1466aac22e6a869134be3d09b9e89232fc2c2289…

You can edit encrypted secrets with `bin/rails secrets:edit`.
Add this to your config/environments/production.rb:
config.read_encrypted_secrets = true
$

config/secrets.yml.key に secret key が、 その key で暗号化されたファイルが config/secrets.yml.enc です。

また、secrets:setup により config/secrets.yml.key は、.gitignore に追加されています。

secrets:edit で、$EDITOR を使い secret file の編集ができます。

secret file を読み込む為には、config.read_encrypted_secrets = true します。config/environments/production.rb には最初から設定されていますね。

railties/lib/rails/secrets.rb を見ると、暗号化は default では AES-128-GCM でします。以下の p-r でそう変わっています。

https://github.com/rails/rails/pull/28139

日記です。Meguro.rb#2 2017/04/20(Thu)

.rb

Meguro.rb#2 に行きました。会場はドリコムさんです。

megurorb.connpass.com

さっちゃんさんの司会業が素晴らしくて、発表の中でも参加者およそ 30 並列の ping に pong 返すなどすごくて、とても楽しめる運びをしているのが印象的でした。

LT では Pocke さんの Ruby がむずかしい話がおもしろくて、発表の中で使っていた bacon-cannon が便利と思いました。print(% % %%%%) の出力とか分からんですよね。

前回(#1) から参加していますが、Meguro.rb は最初に良い感じに輪になって乾杯と自己紹介するのは特徴ですよね。LT の後ピザなどがデプロイされ各々良い雰囲気で話して盛り上がりました。RubyKaigi の話をしたり、偶然光の戦士を発見したり、雑談の中で I18n 知見がまた得られたりと、とても良い会でした。

日記です。渋谷.rb[:20170419]

.rb

渋谷.rb[:20170419] に行きました。会場はピクスタさんです。

shibuyarb.doorkeeper.jp

発表を聞いたり、終わっていない諸々を片付けたりした後は、mastodon と向き合って過ごしました。

tweet しつつ読んでいたところ、後半は tyabe さん、kaiba さんとそれぞれ気になるところを緩く談話しつつやっていました。良く知らないものを読んでいく作業を複数人でやると、一人でやっているよりも情報交換しながら進める分効率が良いですね。コードから入って得た学びとしては、WebFinger protocol, OStatus API, Salmon protocol 辺りを認知したことでしょうか。これらは日常生活では意識することが無かったですし。

github.com

あとは、Ruby や Rails や Git や黒い画面のことや。人に教えるやり方について色々と話したり。4月っぽい話題もあっておもしろかったですね。

当日の様子です。