wwwave'sTechblog |ウェイブのエンジニアブログ

株式会社ウェイブのエンジニアによるテックブログです。会社の話や Ruby、Vue.jsについてなど技術的な話をしていきたいと思います。

株式会社ウェイブの人事部ブログです。社内の雰囲気やイベント、福利厚生などについてお伝えいたします!

株式会社ウェイブのエンジニアブログです。 エンジニアの目線から会社の話や技術的な話をしていきます。

「railsのこのメソッドどこに定義されてるんだ?」

本日の担当:Coolmicエンジニア イシカワ
・2019年4月入社の新卒社員。
・水族館巡りが趣味。
・最近の行きたい水族館は四国水族館。

実装中

🙎🏼
「jsonに変換したいんだけど、to_json使ってるのになんだか上手くいかないなあ」
「ん?as_jsonっていうのもあるのか、、、これって何が違うんだ?」

検索中

🙎🏼
「えーと rails to_jsonで検索してrailsのリポジトリに飛んで、、、」
「毎回どこに書いてあるのかいちいち検索するのもめんどいなあ :innocent: 」

ブログさん ⭐️
「メソッドのsource探すならrails consoleでsource_locationを使うと便利やで」
「こんな感じであっという間や」

pry(main)> Title.find(1).method(:to_json).source_location
=> ["/app/vendor/bundle/ruby/2.7.0/gems/activesupport-6.1.5.1/lib/active_support/core_ext/object/json.rb", 37]

🙎🏼
「え、一発じゃん、、、こんな便利なメソッドあったの?」
「gemとかのメソッドとかも良い感じに表示されるんかな?」

pry(main)> RestrictedTitleResource.new(Title.where(id: 1),params: {field: %i[id]}).method(:serializable_hash).source_location
=> ["/app/vendor/bundle/ruby/2.7.0/gems/alba-1.6.0/lib/alba/resource.rb", 66]

「完璧すぎ」

ブログさん ⭐️
「ついでにな、source.displayでメソッドの中身まで見ること出来るんやで?」

 pry(main)> Title.find(1).method(:to_json).source.display
    def to_json(options = nil)
      if options.is_a?(::JSON::State)
        # Called from JSON.{generate,dump}, forward it to JSON gem's to_json
        super(options)
      else
        # to_json is being invoked directly, use ActiveSupport's encoder
        ActiveSupport::JSON.encode(self, options)
      end
    end

「こんな具合や!」

🙎🏼
「コンソールでメソッドの中身まで見れるの?」
「to_jsonでハマってこんな有益な情報が知れるとは、、、」


  • 今回はソースコードの場所を表示してくれるsource_locationとメソッドの中身を表示してくれるsource.displayのご紹介でした!
    to_jsonがうまく動作してなかったのはキャッシュが効いててそういう風に見えてただけでした、、、
    でも今回ハマったおかげで便利なメソッドが学べて良かったです! 😆

  • こちらのブログの方が分かりやすくまとめてくださっていたのですごく助かりました!
    https://tanaken0515.hatenablog.com/entry/2020/04/24/231922

SRE で AWS Well-Architected 輪読会を実施しました!

執筆者:SRE シラト
・最近、初めて野球観戦に行って大興奮しました。
・今のところ推しは、ソフトバンク 東浜。
・プロ野球チップスで当たるといいな。

今回のお話

SRE で AWS Well-Architected(以下、W/A)の輪読会を実施しました。
感想や実際にW/Aをどう活用していくべきかについて話し合いましたのでご紹介いたします!
※ SREは現在3名体制

実施背景

SRE の Roadmap に『AWS のベストプラクティス実装』を組み込みました。
W/A は、SRE全体で共通認識にした方が良さそうと判断し、輪読会の実施に至りました。

詳細

項目 詳細
頻度 1, 2週間ごとに3時間まとめて確保
ペース 一度に一柱
事前準備 一読(1時間前後)
進め方 ベストプラクティス一つにつき10分のペースでディスカッション。
課題意識があること、よくわからなかったこと等なんでもOK!

感想

1. ポジティブな意見

・可視化の重要性を再確認できた。
・課題意識のすり合わせができた。
・すぐにアクションに結びつく項目があった。
例)スクラム、NSM、Cfn gitops導入等
・最初の方に単語の意味をすり合わせしてよかった。
例) ワークロード = ComicFesta, Coolmic等プロジェクト単位

2. その他の意見

・一周だけでは、断片的な内容しか覚えていない。
・一人で読むのは辛いので、チームで苦労を共にするのがおすすめ。
・やることが多すぎてどこから手を付けるべきか判断が難しい。
・そもそもすべて対応することが現実的なのだろうか。
・難解な記述があり、原文の方がわかりやすい場合がある。

誤解していたこと

輪読会を終えて、個人的に誤解していたことが2点ありました。

1. SRE だけが W/A を理解していればOK

ビジネスサイドなど他チームと話し合う必要性のある項目が多数あります。

例えば、 運用上の優秀性 の『OPS 8: ワークロードの正常性をどのように把握しますか?』には、KPIの異常検知の話が出てきます。
異常検知するとしても、ビジネスサイドと正常を定義しないといけませんよね。

2. チェックリストすべて満たすことがゴール

一番大きな誤解でした。
AWS Well-Architectedの活用方法(2019) では以下の通りに言及されております。

Q:全項目ベストプラクティスに則っていないとダメなのか?
A:ベストプラクティスを理解した上で、皆様が「(ビジネス的な)判断をする」ことが重要

リスクや改善点の"顕在化"が重要となり、ビジネス判断でどこまで対応するかを話し合うことが大切とのことでした。

例えば、『Multi-AZの方が良いらしい』という理由で、Multi-AZにするのはNG。
ビジネスサイドにリスクを噛み砕いて説明した上で、判断できるといいのかなーと個人的には思っております。

アクション

まずは、『SRE が W/A の項目を噛み砕いて説明できるようにする』ことを目標にアクションする予定です。
一読だけでは、自信を持って自分の言葉で説明することはできませんでした。

プロジェクト全体を巻き込むには、以下の説明ができるようになる必要があると考えております。
・対応状況
・対応しないことのリスク
・対応するためにする具体的なアクション

まとめ

今回は、SREでの取り組みについてご紹介でした!
W/A をコミュニケーションツールとして、活用できるよう取り組んでいきます!

トップに戻る