「Linux標準教科書」読書会レポート vol.4

株式会社リゾーム 技術部 システム開発 第3グループの藤岡です。 「Linux標準教科書」読書会の第4回レポートです。第3回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

4回目レポート

今回は5章「基本的なコマンド2」で、参加者は6名でした。

それぞれの感想・意見交換

ファイルのタイムスタンプの変更(touch)

  • 空のファイルを作成する用途でしか使った事がない
  • タイムスタンプをいじるよりは空のファイル作成に使いそう
  • 更新時間を任意の時間に指定できるの知らなかったけど、あまりいい使い方はなさそう

ファイルの一部の取得(head, tail)

  • 使ったことがない。どういう場面で使うのか
  • shellでファイルの先頭の数行を取得して何か操作するときに使ったかな
  • 行頭にそのコードの説明を入れる運用にするといった使い方が載っていてなるほどと思った
  • 最初のメタデータを抽出して加工したり、CSVのヘッダーを抽出したい時に使うかな
tail
  • -fと組み合わせて使う以外使ってないかもしれない
    • ログファイルを見るときによく使う
    • ログファイルを監視できるのは便利そう
  • よく less +F が tail -f の上位互換として紹介されている
    • less +F だとそのまま検索とかもできる

ファイルのソート(sort)

  • uniqと合わせる以外であまり使ったことない
  • ソートしてさっきのheadとかと組み合わせて情報取ってきたりするのだろうか
  • 列を指定してソートできるのは知らなかった
  • 数字をソートに使う場合は要注意
    • -nオプションで数字と文字を区別することは忘れそうだから覚えておく
  • -tで区切り文字を指定できるのでcsvファイルのソートも出来そう

行の重複の消去(uniq)

  • 前回の正規表現と合わせて知っていると、できることが広がるコマンドだと思う
  • 重複する行を連続にしておかないと重複を除去できない点に注意が必要
  • 「重複している行だけ出力(-d)」や「重複しなかった行だけ出力(-u)」できるオプションがあるのが地味に便利
  • 特定の条件に合致しないものを抽出したりできる
    • 特定の条件に合致するデータを持ってきて意図的に重複させる使い方も

文字列の置き換え(tr)

  • 文字の置き換え以外にも文字を削除するオプションもあったりして汎用性高そう
  • 大文字を一括で小文字に変換するみたいなことをしたい時に使える
  • 文字列の置き換えが出来ないので、似たコマンドのsedをよく使う

ファイルの比較(diff)

  • 普段の業務で使うとすると-rをつけてディレクトリごとの差分をとることが多そう
  • -yオプションは横並びで差分が表示されるため見やすいと思った
  • Railsのバージョンアップでよく見る
    • アップデートタスクを実行した際に新しいファイルや既存のファイルの変更を確認する時に表示される
  • 研究で過去のプログラムの変更箇所の確認に使用した
  • 設定ファイルの書き換え前後の比較とかで使う
  • 変更のあったファイルを取得できるのでCIやCDで使うことがあるかも

まとめ

テキストファイルを処理するコマンドはtailを使う程度で他はあまり使ってませんでした。 今回の意見交換を通じて、どのようなシーンで使うかが分かりました。
学んだ事を活かして、業務を効率良く出来るようにしたいと思います。
次回は第6章「viエディタ」です。

「Linux標準教科書」読書会レポート vol.3

株式会社リゾーム 技術部 システム開発 第1グループの岩﨑です。 「Linux標準教科書」読書会の第3回レポートです。第2回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

3回目レポート

今回は4章「正規表現とパイプ」で、参加者は6名でした。

それぞれの感想・意見交換

リダイレクト

  • 使う機会がなかったから忘れてた
  • こういうのがあるくらいの認識で、実際に使ったことはなかった
  • catコマンドとリダイレクトで内容を直接書き込んでファイルを作成できることは知らなかった
  • catで自由なファイル作成を出来る事は初めて知ったが、viエディタでいいかなー
  • catでファイル指定せずにいきなりリダイレクトすると、自由な内容でファイルを作れるのは知らなかった
    • shellで適当なファイルを丸ごと書き換えたいときに便利かもしれない
  • 適当な文字列を入れたファイルを作りたい時とかに使う
    • $ echo test > test.txt
  • zshrcにパスを追加する時によく使う
  • viエディタが使えない環境だとcatコマンドとリダイレクトでファイルの編集をしたりする
  • DBにデータを流すときに使う

標準エラー出力

  • 標準出力と標準エラー出力をリダイレクトできることをそもそも知らなかった
  • エラー内容をファイルに出力はやった事がなかった
  • リダイレクトで標準出力か標準エラー出力どちらをファイルに出力させるか指定できるのは知らなかった
  • 標準出力と標準エラー出力を同じリダイレクト先を指定したりするのはまあまあややこしい気がする
  • 標準出力を捨てる場合、/dev/null にリダイレクトしたりする
  • シェルスクリプトでログ取る時とかに便利そう

パイプ

  • 初めて知った
  • あまり使ってない
  • 実行中のプロセスを表示してkillする時によく使う
    • $ ps aux | grep プロセス名
  • パイプ前のコマンドをパイプ後の標準入力とする
  • grepコマンドと組み合わせて使うことが一番多いかな
  • 複数行に渡るコマンドの実行結果やgrepで絞り込んだ結果をパイプでつなげて、lessで表示させたりする
  • ワンライナーで書きたい時に使ったりする
  • Docker, Github Action, CIを触ってると使うと思う
  • 本番環境で調査したりする時に使う

grepコマンド

  • パイプと同じく初めて知った
    • 確かにデスクトップ環境が無い場合にはこういったコマンドがあると助かりそうなイメージが浮かぶ…
  • grepはパイプとの組み合わせの代表的なコマンド
  • 卒業研究で使った

正規表現

  • 業務でもたまに使うことがあるが、毎回忘れていてそのたび調べている
  • 正規表現あたりの記法は覚えづらく使うたびに調べている
  • そこまで使う機会がないから使うときに軽く調べたりする
    • &や?などの記号を変換する処理で使ったりする
    • URLで使えない文字、記号の変換など
  • [^abc] は abc 以外の文字を持っていればマッチ
    • "defg" => match
    • "abcd" => match ←これがマッチしないと勘違いしがち
    • "abc" => unmach
  • 否定先読みができないっぽいので「~を含まない行」みたいなのを探すときに苦労しそうだなと思った
  • 一括で置換したい時とか、なにかとよく使うので、覚えておくといろいろ便利
  • ログから抽出する際に使う
  • Userエージェントからブラウザを確認する際に使う

まとめ

本章では実務でどういった使い方をするかを中心に意見交換ができたかと思います。 私自身Linuxを触った経験がほぼないため、本章で学んだパイプやgrepコマンドについてぼんやりとしたイメージしか持っていませんでしたが、意見交換を通じて具体的な使用方法などを理解することができました。 また正規表現はプログラムを記述するときにも活用できるため、気を付けるべきところ等をしっかりと整理して次の章に進みたいと思います。

次回は第5章「基本的なコマンド 2」です。

「Linux標準教科書」読書会レポート vol.2

株式会社リゾーム 技術部 システム開発 第2グループの土井です。 「Linux標準教科書」読書会の第2回レポートです。第1回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

2回目レポート

今回は2章「Linuxのインストール」と3章「基本的なコマンド」で、参加者は7名でした。

それぞれの感想・意見交換

Linux のインストール
  • WSL2でUbuntu(20.04 LTS)の環境を構築した
    • Ubuntu.exe起動時に「システムコールに渡されるデータ領域が小さすぎます」とエラーメッセージが表示された
    • FILESTREAMが有効なMSSQLサービスが実行されているときにこのエラーメッセージが表示されて起動できない模様
    • 無効にしPCを再起動すると無事起動することが出来た
  • Hyper-V+CentOSで環境作成した
    • 仮想スイッチが難しかったがDefault Switchで事足りそうだったので、Default Switchを使用した
  • VirtualBox+CentOSで環境構築した
    • VirtualBoxCentOSのバージョンが合致するものとしないものがあるらしい
  • VirtualBoxCentOSGUI環境を作った
    • Audioを無効にしないとエラーで強制終了する
ファイル操作
  • 大学の頃に使用していたコマンドが登場して懐かしい気持ちになった
  • sshで入った際に使うことが多い
  • クライアントで使うことは少ない
    • GUI操作で済むから
  • 権限に関するコマンドは使うことが多い印象
  • ファイル絞り込みで文字数が分かっている場合は?を使って絞り込める事を知ったが、 *で十分な気がする
    • cpやmvとかにもワイルドカードが使えるので、txt拡張子全てを操作したいときとかは便利
lsコマンド
  • lsオプションで -lや-aはよく使う
    • よくll(ls -l)とかla(ls -a)とか使う
    • ls -laSr でファイルサイズでソートしたりもする
    • -tで最終更新時間でソートできる事を知った
cpコマンド
  • マウス操作でファイル複製するからあまりcpは使ったことがなかった
  • cpとmvは-iオプションで上書きミスを防げるので使うときは-iを付けることを基本としたらいいかもしれない
  • cp のオプションを使う機会はあまりなかったので学び
rmコマンド
  • ディレクトリ削除(rm -rf)は万が一があるので注意して扱う必要がある
ディレクトリの操作
pwdコマンド
  • pwdコマンドは知っていたが正式名称Print Working Directoryは初めて聞いた
  • pwdの略は昔教えてもらったことがあったことを読んでて思い出した
  • 字面的にパスワードに見える、このコマンドはいつも心の中でパスワードって呼んでる
  • pwdは使ったことなかった
    • RailsだとRails.rootがあるから使ってないな...
  • pwdは特にCUIに慣れない頃によく使っていた覚えがある
    • cdしまくると自分がどこにいるのかわからなくなった…
  • いきなり自分の知らない地点に行くことってないのであんまり使うことないけど、DockerとかだとImageから作ったコンテナに入ったときに今どこにいるか知りたくて実行することはある
cdコマンド
  • cdなどはWindowsでも常連のコマンドのため、業務でも使うことが多い
  • cdは、よく使ってるコマンド
  • 一番使ってるコマンドかなー
mkdirコマンド
  • mkdirはあまり使ったことがない
  • mkdirの-pオプションは初めて知った
  • mkdirとtouchをまとめてできるコマンド欲しいなってよく思う
rmdirコマンド
  • rmdirは実は知らなかったコマンド
  • 中身があるない関係なく消したいことの方が多いのでいつも rm -r で消してる
  • ディレクトリの作成ミスで使うぐらい
パス指定
  • ディレクトリ(..)やルートはcdで使うことがよくある
  • 絶対パスは現在位置に左右されずに使える
  • あるパッケージ内のみでファイルの参照関係が完結する場合、例えばアプリケーション開発の場面とかでは基本的に相対パスを使う
  • 必ずrootパスから追いたい時は絶対パスを使う、パッケージじゃなくてサーバ自体に依存する時とか
ファイルの内容を表示
cat,more,lessコマンド
  • catはドットファイルを確認するときに使うことが多い、moreやlessは知らなかった
  • catとlessはよく使うがmoreは使ったことが無い
  • moreとlessとmanは初めて知った、今後使えそう
  • ログファイルの閲覧でless +Fをとてもよく使う
    • less +Fはファイルが更新されると、リアルタイムで表示も更新される
  • lessで事足りるので、moreはあまり使わないかなあ
  • catはファイルの中身を丸ごと別のファイルに挿入したい時とかでよく使うかな...
    • ファイルの中身を参照したいだけだったらlessとかtailの方をよく使う
  • ページングとページャの名前は初めて聞いたことと、機能としては意識していなかった
  • moreはファイル末尾まで行くと終了するらしい
  • catで標準出力→grepで絞り込み→lessで表示みたいな感じで、パイプで繋いで使ったりもする
  • ファイル開いた後のコマンドモードで使うコマンド類は覚えておくと作業がだいぶ捗る
  • catコマンドは複数ファイルを指定して結合してくれる
ファイルの検索
findコマンド
  • findもあまり使ったことがない
  • findは使い方をあまりおぼえていないので、あまり使っていない...
  • shellの世界で頑張る必要がある時に結構使う
    • 普段だとFinderとかGUIでファイル探す方がわかりやすいしあんまり使わない気がする
  • findコマンドは卒業研究で前年度までのプログラムを探す際に助けられた
  • 指定ディレクトリ以下のファイルを対象とする場合に使う
コマンドのパス
whichコマンド
  • whichはほぼ使ってない
  • whichは使うことはほぼなさそうだけれど覚えておこうと思った
  • whichもトラブルシューティングでよく使う
    • どこのコマンドを参照しているのかとか
      • yumでインストールしたコマンド、ソースからビルドしたコマンドが同居していて、意図していないコマンドを利用していたり
  • ツール類をいろんなところからインストールしてる程よく使うかな...
    • 例えばRubyとかも公式からインストールしたやつじゃなくてrbenvでインストールしたやつになってるか確認する時とか
  • ライブラリのバージョンが変わらない時に使ったりもする
ヘルプの使い方、マニュアルの使い方
  • man, helpはこのコマンドのオプション何だったか調べるときに良く使っている
helpオプション
  • helpオプションを使うのはオプションの確認する時ぐらい?
manコマンド
  • manもほぼ使ってない
  • コマンド名知ってれば使うことってあまりないよな...コマンド名がうろ覚えの時とかに使うのかな?Linuxコマンド以外のマニュアルを見たい時に使うんだろうなーって感じはする
  • manコマンドがセクションで分かれていることは知らなかった
  • ゲームのコマンド(セクション6)もあるみたい

まとめ

基本的なコマンドでも担当業務が異なると使うもの、使わないものがあることが分かりました。実際にどのような場面で使ったり、どういった使い方をすることで便利に扱えるかといった部分で意見の交換を行えてとても参考になりました。

今後の業務などで、ここは読書会で触れたところだなと思いだし活かしていければと思います。

次回は第4章「正規表現とパイプ」です。

「Linux標準教科書」読書会レポート vol.1

株式会社リゾーム 技術部 システム開発 第4グループの平松です。「入門 監視」読書会が終わりましたので社内の有志で新たに読書会を始めました。それをレポートしていきたいと思います。

読書会の題材

題材として選んだのはLinux標準教科書です。

linuc.org

読書会の本を決める際に賛同する声が多かったので、こちらになりました。
また、標準教科書は今回選んだ本以外にもサーバー構築やセキュリティについて書かれたシリーズもあり情報技術を包括的に学べる教材となっています。

読書会の進め方

進め方は、「入門 監視」読書会の時と同じです。

  1. 当日までに事前に章を読んでおく
  2. 感想や疑問点をまとめる
  3. Yammer(Viva エンゲージ)にアウトプットする
  4. 読書会当日、感想をそれぞれ発表する
  5. 意見交換を行う

1回目レポート

初回は、「Linuxとは」で、参加者は6名でした。

それぞれの感想・意見交換

基本ソフトウェアと応用ソフトウェア

  • 大学の頃にLinux環境でのプログラミングを少し学習したが、今はほとんど覚えていない
  • 例を挙げて説明されている部分が分かりやすく、知識を定着させやすいと感じた
  • 基本ソフトウェアの役割について、分かりやすく明文化されていて理解が深まった
  • 基本ソフトウェアと応用ソフトウェアは自分の中で明確に区別をつけていなかったため勉強になった
  • 普段の業務に活かせる部分は活かしていきたい
  • 卒業研究でRaspbianには触れていたのでその時の経験とすり合わせながら学習を進めていきたい

UNIX

  • Linus TorvaldsさんがLinuxを作ったということ自体は知っていたが、Linuxの特徴(特にライセンス形式)は知らなかったため新たな知識になった
  • 多機能・高機能のOSを目指した結果、広まったのはコンパクトで小回りが利くUNIXなのは面白い
  • 歴史を辿るのは結構大事
  • 大学で一通り学習したはずだが、誕生の歴史はほとんど覚えていなかった
  • UNIXが派生し、BSDやSystem V・Linuxがある
    • あまりそれぞれがどういった経緯でできていったのかは覚えていなかった

Linuxの特徴

  • ユーザランドでコマンドが動作する事は初めて知った
  • シェルはzshを使っている
  • ハードウェアに直接アクセスする部分がカーネルで、それ以外のPCを利用する側が認識できる部分がユーザーランド?
    • なのでユーザーが実行するコマンドとかファイルシステムとかの動作領域もユーザーランド?

ディストリビューション

まとめ

今回は誕生の経緯や特徴など前提知識がほとんどでしたので経験知の共有がしづらい章ではありましたが開発環境に関する共有は多少できたかと思います。 次章以降コマンドの実習等もあるのでより業務や過去の経験と絡めた感想を共有していきたいと思います。

RubyKaigi2022レポート

技術部第3グループの廣江(@buta_botti)です。会社のサポートを受けてRubyKaigi2022に参加させていただきましたので、自分の見聞きした範囲で簡単に紹介させていただきます。内部の難しい話はわからないので、その辺りに興味のある方には他の方の参考になるレポートや、発表者の方のスライドやブログを参考にしていただくとして、今回は利用する側の目線で色々書ければなと思っています。

タイトルはこちらのスケジュールに記載のものを流用しています。

rubykaigi.org

Ruby meets WebAssembly

speakerdeck.com

ざっくりと言うとRubyがブラウザ上で動くようになりました。多少の課題は残っているものの、多くのRubyスクリプトには影響がないので、どんどん利用してフィードバックしていくことが私のような一般Rubyistが貢献できる方法となります。

利用方法は至って簡単です。

<script src="https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@0.3.0-2022-09-06-f/dist/browser.script.iife.js"></script>
<script type="text/ruby">
  # Ruby code
</script>

<script type="text/ruby">内に書いたRubyコードが実行され、pメソッドやputsメソッドを使うとコンソールに出力されます。

少し凝ったことをしようとすると、JavaScriptで多少ゴニョゴニョする必要があります。

<script src="https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@latest/dist/browser.umd.js"></script>
<script>
  const { DefaultRubyVM } = window["ruby-wasm-wasi"];
  const main = async () => {
    const response = await fetch("https://cdn.jsdelivr.net/npm/ruby-head-wasm-wasi@latest/dist/ruby.wasm");
    const buffer = await response.arrayBuffer();
    const _module = await WebAssembly.compile(buffer);
    const { vm } = await DefaultRubyVM(_module);

    vm.eval("# Ruby code");
  }
</script>

凝ったことをするにあたって、RubyからJavaScriptを実行したいこともあるでしょう。その場合はrequire 'js'でJSライブラリを使えるようにします。

<script>
  // ...省略
  vm.eval(`
    require 'js'
    text = "Hello Ruby!"
    JS.eval("document.body.innerText = '#{text}'")
  `)
</script>

HTML上のbodyに「Hello Ruby!」を表示できます。

ここで紹介したようなサンプルは、全てruby.wasmで詳しく書かれています。とても親切。

github.com

また、require 'js'したJSライブラリの実体は以下のファイルのようです。

github.com

C言語が読めなくても、親切なコメントが書かれているため、使い方を理解することができます。

Types teaches success, what will we do?

speakerdeck.com

こちらは gem_rbs_collection の紹介になります。

github.com

実際にプルリクを出して取り込まれるまでの過程を丁寧に解説してくださっており、自分もやってみようという気にさせていただけました。内容としては docs/CONTRIBUTING.md の内容を日本語で詳しく解説していただきました(スライドは英語)。

github.com

自分のプロダクトで使っているケースで型を書けばよいということらしく、そのライブラリが想定しているすべてのパターンを考慮しなくても気軽にPRを出せるのということなので、すごく取り組みやすいのではないでしょうか?個人的にはOSS活動の中でも(ライブラリの理解は使っている以上前提として)typo探しの次くらいに取り組みやすい領域だと思います。早速手元のRailsプロダクトでsteep checkして、不足している型をgem_rbs_collectionに提出しましょう!

Tools for Providing rich user experience in debugger

www.slideshare.net

(VS Codeを利用していない方でも)ChromeのDevToolsでめちゃくちゃ好体験のデバッグができるようになったという話でした。

利用しているRubyにdebug.gemがインストールされていることが前提です。

$ rdbg --open=chrome sample.rb

もしくはプログラム内のdebuggerで開くrdbgコンソール上で

open chrome

デバッグ用のChromeDevToolsを開くことができます。

Sourcesタブでデバッグ対象のRubyプログラムが確認でき、ConsoleタブでRubyスクリプトを実行できるみたいです。これだけでもテンションが上がりますね。Consoleタブで実行したRubyプログラムはSourcesタブのプログラムの状態に影響するようです。

↑変数aの値が書き変わっている様子

Make RuboCop super fast

speakerdeck.com

RuboCopはrequire 'rubocop'の処理が重いという課題があったそうなのですが、この度サーバーモードというのが追加されたことによって、RuboCopサーバーをローカルに立て、そこにRuboCopモジュールをロードしておき、RuboCopの実行をこのサーバー上で行うことで重いrequire処理をスキップ(正確にはrubocop/serverという軽量なものだけで済む)でき、高速化します。

RuboCopサーバーが起動していない状態でのデフォルトのrubocopコマンドは従来通りの動きで、オプションを明記したrubocop --no-serverと同等です。rubocop --serverでRuboCopサーバーが起動していない場合に起動し、サーバーモードでRuboCopを実行し、サーバーの停止、再起動はそれぞれ--server-stop--server-restartが対応しています。起動しているサーバーのステータスは--server-statusで確認できます。

ちなみに、RuboCopサーバーが起動している状態でオプションなしの rubocop コマンドを実行すると、サーバーモードになるそうです。

error_highlight: user-friendly error diagnostics

(スライド見当たらず...)

エラー表示がとても親切になりました。実際どう便利なの?今でもファイル名と行数出てるから場所わかるし十分では?みたいな意見に対しては明確に便利になるケースを提示してくださっていました。

例えばerror.rbの2行目に次のコードがあります。

hash[:foo][:bar][:baz]

ここでNoMethodErrorが起きた場合のエラー表示は以下のようになります。

error.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)

何番目の[]が原因か分かりにくいですね。これがerror_highlightによって

error.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)

hash[:foo][:bar][:baz]
          ^^^^^^

のようになります。原因箇所が一発でわかって便利です。

また、実際のコードがチラッと見えることによって、見覚えのあるコードであればおおよそのあたりをつけてデバッグを開始できたりと、デバッグにおいてかなり便利になるのではないかなと思います。

Real World Applications with the Ruby Fiber Scheduler

Falconやasync.gemが出てきてPumaよりFalconの方がパフォーマンスが出ていたというのはスライドを見ていて分かったのですが、なにぶん英語が聞き取れなくて後でスライド見ようと諦めて聞き入っていたのに、いざまとめようとするとスライドも見つけられなくてめちゃくちゃ悲しい思いをしています。他力本願すぎたことを戒めに英語を勉強しなければなという気持ちにさせられました。スライドを眺めていただけのイメージで話をすると、今のアプリケーションは大量のリクエストを捌ききれないことがあり、それがノンブロッキングなFiberを使うことで捌けるようになってパフォーマンスも上がるみたいな感じなのかなと思っています...。FalconをRailsで使うとActiveRecordのリクエストをFiberで捌けるようになるとかそんな内容もあったとか。実際はそんなサラッとした内容ではなくて実現するための苦労話がたくさんあったと思います。

github.com github.com github.com

Rack3でストリーミングに対応するという話も出てたみたいですが、この辺りのことのなのかな...?

There is one new feature in Rack 3 which is not directly backwards compatible:

・Response body can now respond to #call (streaming body) instead of #each (enumerable body), for the equivalent of response hijacking in previous versions.

github.com

ここのリポジトリに情報が詰まってそうなので、読んだり動かしたりした後にまたブログを書ければなと思っています。 github.com

History of Japanese Ruby reference manual, and future

slide.rabbit-shocker.org

るりまの話を聞きました。個人的にはるりまをRDocからMarkdownで書けるように...や、サンプルコードをwasmで動かせるように...と計画しているのが一番インパクトがありました。Markdownなら普段から使っているので、ちょっとドキュメントの修正をしたい時に簡単に提案ができていいなと思いますし、サンプルコードをブラウザ上で実行できるのもすごく手軽に動作を確認できていいですね!るりまは新しく追加された機能とかについては割と大丈夫だけど、昔からある機能については更新されてなかったりとかするみたいなので、その辺りにコントリビュートチャンスがありそうな気配がします。ひっそりとissueを出しても埋もれてしまうので、ruby-jpのslackなどで相談しながら進めていくのがいいのかなと思います。

多言語対応もロングスパンで進めていくそうで、日本語以外を母国語に持ち、翻訳をしてくれる方を募集しているそうです。

あとはissueが山盛り溜まっているっぽくて、現在のステータス管理とかしてくれる人を募集中だそうです。Ruby本体の方でも似たような話を聞いたような...?

github.com

るりまには長年お世話になっているので、何らかの形で恩返しをしていきます。

全体の感想

TwitterやSlack、Discordで普段話している人とオフラインで会うことができてとても楽しい3日間を過ごすことができました。発表に関してはやや難しくて理解しきれない部分も多くありましたが、そこは実際に触ってみて、体で覚える方向でカバーしていきます。実際にデモを用意して動かしてみる記事も別で書いていますのでお楽しみに!RubyKaigiは美味しいご飯とお酒を飲みながら、知り合いと好きなプログラミング言語についてわいわいと語らうことができるので最高ですね。今回、現地参加は弊社からは私一人でしたが、私と一緒にRubyKaigiに行きたい!という方が社内に増えてくれるととても嬉しいなと思っています。

「入門 監視」読書会レポート vol.12

株式会社リゾーム 技術部 システム開発 第4グループの平松です。
読書会の第12回目のレポートです。 第11回目のレポートは、こちらになります。 tech.rhizome-e.com

12回目レポート

今回は、「付録C 実践 監視 SaaS C.6~C.8」で、参加者は5名でした。

それぞれの感想・意見交換

テスト駆動開発と監視

  • ソフトウェア開発とテストがセットであるように、システム運用と監視はセットで語られるべき
    • システム運用側の視点が薄かったかなと思った
  • 監視とテストを同じ枠で考えたことがなく、頭の中で何か別のものとして切り離していた
    • 確かに毎回テストしているようなものだ
  • 燃料警告灯を付け忘れないのはそれが既に完成されているからであって、新しい何かを作るときは監視まで意識していないとできない気がする
  • 今後はより本質的な捉え方をしていこうと思う
  • 監視しやすいシステムを作っていくにはシステム運用と監視の両方の視点が必要になってくる
    • そのシステムをどれだけ理解しているかが重要になってきそう
  • システムの監視に自覚的にならないといけない
  • ヘルスエンドポイントのように、開発していく中で、そういった観点は必要になる

自分で監視を作る

  • テストは不安なところを書くべきとは自分もよく言っているのだけれども、監視も同じなのか
    • 何を監視するべきかを知っているのは開発者自身…なのかもしれないが、だったらなんで開発者は何を監視すればいいのかこんなに悩んでいるのか
    • ちゃんと自分たちの運用の不安と向き合う時間がいるんだよなと思う
  • アラートが上がってるけれど、なにをすればいいのか?となったら、放置してしまいそう
  • 監視はビジネスロジックを理解していないと作れない
  • 「後で修正するときにテストがないと漏れる可能性ある」「テストなかったら常に改修で壊れていないかどうか心配しないといけないじゃない?」
    • この考え方を監視にも当てはめて考えればいいのか
  • SQLでデータベースの状態をメトリクスとして引っ張れるなら、色々計測できそうな気がしてくるが、具体的に何を取得したらいいのか悩むところ
  • 締め処理など非同期Jobの結果が格納されるレコードのステータスなんかは見たほう良さそうだが、SC BASE*1は基本的にデータを蓄積していくアプリなので
  • テストと同様に、開発しているアプリケーションの心配事を監視するべき
    • でも何を監視するべきか悩んでいる...
  • 「テスト」という観点だと、「仕様どおりに」「バグを起こさないように」といったことが考えられるが、監視という観点だと、どのような不安があるか...

監視を育てる

  • ヘルスエンドポイントパターンに変更する…。監視も育てる思考
    • たしかにヘルスエンドポイントパターンに移行すれば、テストが可能になるので良い
    • 標準化の視点を持てる
  • アプリを作成しているとバージョンアップや改修など、作りきりでないことは一般的になってきていると思うが
  • 育てると聞くと、育てない場合の罪悪感が半端ない
  • より良い監視の方法を模索し続けないと現状より悪くなることはあっても良くなることはないのでコードのリファクタリングなど同じで定期的な見直しは必要
  • 今一度何が監視できていて、何が監視できていないのか整理したい

自動復旧のためのアイデア

  • アラートのWebhookを使って自動復旧用のリクエストを行うわけか
    • そういう発想自体がなかった
  • 何らかの復旧が必要な異常を検知し、これを契機として作動させるということか
  • 教科書に書かれている仕組みではなくて、応用みたいな話になってくるのかも

監視パラダイムの変遷

  • 便利な反面に複雑化している昨今のシステム構成。
  • 監視SaaSならば分散トレーシングにも対応しやすいというのは、確かにそうかも…
  • 「Observability」、最近よく聞くワード

機械学習と異常検知

  • 監視に対する機械学習の適用。たしかに膨大なデータがあるので、何かしら兆候を察知させるのに使えるのかも
    • データが膨大にある監視SaaSならではのサービス
  • こんなところにも機械学習の波が
  • 機械学習の場合はデータセットの質や量にかなり影響されるかもしれないが、サーバー監視ならある程度揃っているだろうし使えそう
  • 考慮漏れの可能性があるからレビューなどがあるわけでその部分を機械学習で補填してくれるのはとても便利
  • 監視SasSは膨大なデータ量を扱うので、確かに機械学習を利用出来るな
  • 標準的なメトリクスを監視することは有効ではないが、兆候を検知して通知するのは、長期的に保守していくBOND GATE*2で非常に助かりそう

監視SaaSのまとめ

  • 昔に比べると監視のハードルはずいぶん下がっているんだから、自分たちの手で監視したいものを決めていけたらいいなと思った
  • 監視の民主化は、今後取り組んでいくべき箇所
  • 監視SaaS(New Relic/Mackerel)を利用して、みんなが見れる状態を整備したい所存

まとめ

今回は監視SaaSの活用や今後について各々、疑問や課題などを上げてそれについて話し合うことができました。 特に監視する上での考え方は今後、監視に取り組む際に必要な基礎の部分になるため、それを今回の読書会で学ぶことができてとても良かったです。 「入門 監視」を読む前は、監視についての理解も浅く、監視SaaSを導入してもあまり活用できてない状況でした。 ですが、この本から監視についての様々な知見を得ることができました。 すでに取り組んでいるものもありますが、今後、本から学んだことを実践してより充実した監視が行えるように環境を整えていきたいと思います。

「入門 監視」読書会はこれで終わりですが今後も、読書会を行いたいと思います。

*1:売上報告・賃料計算も一体化​したDX対応の業務支援システム(ホームページ商品説明引用)

*2:情報共有と業務効率化、遠隔でもデベロッパー・ショップの充実したコミュニケーションを実現するグループウェア(ホームページ商品説明引用)

「入門 監視」読書会レポート vol.11

株式会社リゾーム システム企画・開発部 第3グループの藤岡です。
入門監視 読書会の第11回目のレポートです。 10回目のレポートは、こちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン | Mike Julian, 松浦 隼人 |本 | 通販 | Amazon を題材としています。

11回目レポート

今回は、「11章 監視アセスメントの実行」と「付録C 実践 監視 SaaS C.1~C.5」で、参加者は5名でした。

感想・意見交換

ビジネスKPI

  • 製品毎に何のメトリクスが取れるか
    • 施設数(テナント数)、月次経常収益、顧客あたりの収益
    • 顧客あたりのコスト、導入・サポートコスト
    • 各種機能の活用率(検索・登録・閲覧)、オプション機能導入率
    • 顧客生涯価値
    • 項目毎の検索実行数
    • ユーザー毎、契約会社毎のログイン回数
    • システムの利用状況
  • 営業やお客様からユーザーのログイン回数やシステムの利用状況を求められることがあるので、真面目に検討していきたい

フロントエンド監視・セキュリティ監視・アラート

  • 本書に挙げられている、ほとんどの項目は流用できそう
  • 締め処理など非同期処理が反映されるまでの時間を計測したい
  • NewRelicで監視できそう。この辺りをダッシュボード化したい
  • ミドルウェア周りの監視(メトリクス取得)ができていない
  • 何ができて、何ができてないのかを見直す時がきたのかも

実践 監視 SaaS

  • PaaS, SaaS, laaS は確かに料金コストがかかるが運用コストはもっとかかるし、知識・技術の不足やセキュリティのことを考えると利用した方が安心だよな...
    • 個人開発だとどうしてもコスパ的にVPSに詰め込む形になりがちだけど
  • 導入自体は、エージェントをインストールするだけで簡単だが、監視・アラートやダッシュボード設計とかの学習コストはかかる
  • 今は外形監視をしているだけなので活用できてないな...

監視SaaSの利点

  • チーム全員が監視システムにアクセス出来て、属人化が排除できる
    • ただ現状はSaaSを利用しても属人化してしまっているので、使い方の勉強会や手順書の整備は必須
  • Mackerelはサーバー監視・New RelicはAPMとして組み合わせて使うとか出来ればいいが、ツールが増えると面倒だったり、お金の問題がある

監視SaaSは信用できるのか

  • 疑って手をださなかったらいよいよ何もしないだろうな
    • だったら手軽にでも始めるのがきっと正解なんだと思う
  • 料金改定・障害発生率・セキュリティインシデント、最近は特に目立つ気がしている
  • 運用をサービスに合わせる姿勢は大事だと強く思う
    • サービスを運用に合わせることが基本スタンスになっていると、改善も見込めず非常に使いづらい
  • GitHub, GitLab, Bitbucket etc... のように類似サービスのコア機能にはほとんど違いがなくなり、差別化された機能や料金、サービス停止や買収なんかの心配をするようになる日が、既に来ているのかも

まとめ

現状、SaaSを利用しても属人化してしまっている、活かすことが出来ていないと思います。 今回の章で課題や検討事項を整理出来たので、その内容を他のメンバーにも共有して改善していければと思います。