2023-02-26

wsl2のubuntu環境でman syscallsを読むためにやったこと

「動かしながらゼロから学ぶLinux カーネルの教科書」を読んでいる時の作業内容メモ

powershellでUbuntuのインストールコマンド実行
wsl --install -d Ubuntu

一般ユーザー名とパスワードの設定という初期設定だけ実施して以下作業を実施

とりあえずアップデート、毎回sudoつけるのめんどくさいのでrootユーザーで実行
$ sudo su -
# apt update
# apt upgrade

普通に実行するとページが存在しないらしい
# man syscalls
No manual entry for syscalls

manpages-devパッケージをインストールすると読めた
# apt install manpages-dev
# man syscalls

2020-05-10

UE4 で PS4 コントローラーを使うように設定してみた

今回はWindows 上のUE4でPS4のコントローラー（DS4）を接続するためにやったこと。

使ったのは Windows Raw Input プラグインで設定は下記リンクの通りで動作は確認できた。

[Tutorial] UE4 using Dualshock4 controller (via USB, PS4 DS4 Gamepad). - Unreal Engine Forums

Raw Input プラグインの設定ではベンダーIDに 0x054C プロダクトIDに 0x05C4 と入力した。DS4の第二世代の場合はプロダクトIDに 0x09CC を入力する必要がある。

またWindows上で認識されているコントローラーはスティック中央位置の値が0ではないのでオフセット設定が必要で、入力方向と数値を揃えるためにインバーターのチェックをつける必要があるようだった。

参考リンクの内容をそのまま設定してみたところどうもスティックがニュートラル状態でも細かい値の入力があり、プレイヤーが少しずつ動いてしまうので入力値を扱うところで処理が必要そう。

今回は細かい値の調整まではしていないが利用できる状態にまではなったので一旦先に他の作業を進めることにした。

最近は気になっていたUE4でのゲーム制作を動画講座で勉強をしてる。その中で教材にない部分でやったことをブログのリハビリとして書いた。

勉強していた内容を適切に書き出してふりかえらないと記憶できないほど専門的な用語が多いので適宜ブログに書いていくようにしたい。

2018-02-01

SpreadSheet から GAS を利用して Slack API で通知してみた

はじめに

こうすればSpreadSheetからSlackに通知ができたという、個人的な備忘録です。

SlackのAPIを利用する準備などはとくに書きません。

また個人的な忘備録なので、コピペですぐに動くものではありません。

GAS側でやったこと

SpreadSheetでSlackのユーザー名一覧を作成している状態で、GASでそれを取得して、文章も組み立てて通知という流れだった。

特定の何かを利用している人に対して通知したいなどがあっても先にシートを作成しておくことでこれを利用して対応できた。

GASのコード

通知したいユーザーの情報があるスプレッドシートを引数に渡して、ユーザーを取得する

// ssはスプレッドシートの意味、引数にシートを受け取る
function getUsers(ss) {
  // getRangeの引数にSlackのユーザー名が入っているセルの範囲を指定する。例えば "A2:A"
  var r = ss.getRange("").getValues();
  // 値は2次元配列なのでmapでループを回して、popで値を取り出す
  var nr = r.map(function(x){
    return x.pop();
  });
  // 空の値を除くために最後にfilter(Boolean)を実施
  return nr.filter(Boolean);
}

ユーザー情報などを利用して通知に必要なリクエストを組み立てて通知する

function myFunction() {
  var ss = SpreadsheetApp.openByUrl("ここにユーザー情報のあるシートの共有リンクを入れる").getActiveSheet()
  var users = getUsers(ss);
  // channelはユーザー名を入れるので空にしておく
  var payload = {
    "token" : "YOUR_SLACK_API_TOKEN"
    "channel" : "",
    "text": "通知したいメッセージ"
  }
  var options = {
    "method" : "POST",
    "payload" : payload
  }
  // 通知したいユーザーの数だけループを回す
  for(i=0;i<users.length;i++){
    // ここで宛先を作る
    payload.channel = "@" + users[i];
    // メッセージの送信なので今回はchat.postMessageを利用した
    var response = UrlFetchApp.fetch("https://slack.com/api/chat.postMessage", options);
    // 誰に送ったか、送信に成功したか、わかるようにユーザー名と実行結果をログに出す
    Logger.log(users[i]);
    Logger.log(response);
  }
}

ハマったところ

Slackの個人宛の通知をしたい場合、スクリーンネームなどアプリではメンションが飛ぶ名前ではなく、username を調べて利用する必要がある
- 上記が正しくない場合、通知が失敗するので、Slackの管理者などに username がわかるユーザーの一覧を事前に出力してもらう必要がある

おわりに

簡単にGASを利用したSpreadSheetからのSlackへの通知についてまとめた。

もう少しきれいな実装などもあると思うが、自分のGAS知識では現状こういった実装になった。

2017-11-22

RDS for PostgreSQL のスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

はじめに

タイトル通りの短い内容です。また自分用の備忘メモです。

RDS for PostgreSQL でスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

RDSでPostgreSQLを利用している中で、slowqueryのログをダウンロードして処理にどれくらい時間が掛かっているか出力します。

またログの時刻がUTCなのでJSTに変換するのと、durationから終了時刻を算出するところまで行います。

利用しているのは awk と date です。

macを利用している人は GNU date をインストールして利用してください。

ワンライナー

awk '$1 ~/^[0-9]*-/ && $4 == "duration:" {a = $1" "$2; b=int($5 / 1000);"gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\""|getline var; "gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\""|getline val; print "start: "val" "$4" "$5" end: "var;close("gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\"");close("gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\"")}' postgresql_logfile_name

実行結果

start: 2017-11-12 07:58:03 duration: 3230.013 end: 2017-11-12 07:58:06
以下略

start,end,durationのcsv形式で出す場合は以下のようにする

ワンライナー

awk '$1 ~/^[0-9]*-/ && $4 == "duration:" {a = $1" "$2; b=int($5 / 1000);"gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\""|getline var; "gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\""|getline val; print val","var","$5; close("gdate --date \""a" 9hours\" \"+%Y-%m-%d %H:%M:%S\"");close("gdate --date \""var" "b"seconds ago\" \"+%Y-%m-%d %H:%M:%S\"")}' postgresql_logfile_name

実行結果

2017-11-11 19:15:00,2017-11-11 19:15:09,9322.90
以下略

出力された結果を元にdurationの値をファイルでgrepすればクエリを確認することができます。

おわりに

RDS for PostgreSQLのスロークエリログ整形に使うワンライナーでした。

単純に解析するだけならツールなどはOSSなどでもあるようなので、そちらを使った方が早いかも。

2017-07-11

エラーの原因解明にモブ調査してみた

はじめに

タイトル通りです。

最近話題になっている、モブプログラミングを取り入れて開発をしているチームのモブに混ざってエラーの原因調査を実施しました。

モブプログラミング自体についての説明はとくにしません。

今回は30分程度の作業だったので、短い感想の記録です。

背景としては開発チームがモブプログラミングで開発を進めており、インフラ絡みのエラーが発生していたのでインフラチームがそのモブに参加して原因調査を実施しました。

メンバーは全体で5名で開発3名、インフラ2名という構成でした。

やってみた感想

事前に私と開発チームの3名は下記リンクのようにモブプログラミングを体験しており、さらに開発チームは現在の作業もモブプロで進めており、経験があるという状態でしたがもう1名のインフラメンバーはモブ経験がありませんでした。

しかしながら、ペア作業の経験があったからかドライバーをしてもらいましたが問題なく作業を完了まで進めることができました。

感想を聴いたところ、最初の10分くらいは緊張したがあとはペア作業と同様で問題なく作業できたそうです。

モブ作業をしていて、良かったところとして、インフラ系の調査では一人が実際にサーバに入り、別の人が必要に応じてLBからの切り離しなどのオペを平行で進めることができるなど、検証で必要な作業がよりスムーズに進めることができたなと思いました。

またアプリの挙動に合わせて検証が必要だったので、インフラメンバーだけでは検証の前にアプリ自体の挙動を正しく把握する必要があるなど、より時間がかかることも考えられましたが、開発チームとのモブ作業ではその部分が不要でディスカッションしつつ必要な動作確認ができるのでこの点もスムーズでいいなと思いました。

今回は実作業時間が短く、大きな課題となるような点は出てきませんでしたが、今後インフラチームでもモブプログラミングのようにモブオペレーションであったりモブ設計であったりといろいろ試してみて、向き不向きの検証をしていければなと思いました。

おわりに

今回は短いですが、モブプログラミングを実施しているチームにまざり、モブ調査を実施したという内容のまとめでした。

現在はインフラチームでペア作業でタスクを進めることを試していますが、さらに次のステップとしてモブオペレーションやモブ設計などタスクをモブで進めるのも良さそうだなと感じました。

2017-06-14

インフラチームでペア作業始めてみて1ヵ月経過したので全体のふりかえりをした

はじめに

ペア作業を始めて2か月ほど経過し、ようやくチームでふりかえりの時間ができたので、その記録です。

チームのふりかえりとしてはとくにふりかえりフォーマットを利用せず、またあまり時間もとれなかったので感想ベースのふりかえりになりました。

また前提として定常業務ではなく、チームの施策として進めている作業についてペアで行っていました。

前回までのあらすじ

ふりかえり

以下は今回のチームでのふりかえりで出た感想です

チームの施策の進捗がさらに良くなった
知識の共有ができた
やらなきゃだめというモチベーションにもなった
単純に作業に関する知識だけでなく考え方にも影響があった
作業内容によってはペア作業が向かないものもあるので、そういったとこでは無理にペアで行わない

上記のように前向きな意見が多かったので、このまま継続してペア作業は続けていくつもりです。

ただし、あくまでも現在のチームにあっているだけで、今後また何か状況が変わるとペア作業もなくなるという前提で進めています。

感想

今回のペア作業中に個人的に良かった点としてはスクリプトのペアプログラミングからミドルウェアの選定、設定、ドキュメントの作成など幅広くペアで作業することができたのがとても良かったです。

とくにインフラとして行う作業はコードとして形に残るものが少ないのでドキュメント化などが重要ですが、それをペアで行うことでレビューの時間を短縮し、まとまったドキュメントを用意できたことなどが良かったです。

おわりに

全体でのふりかえり実施まで少し時間が経ってしまいましたが、実施できたのでまとめました。

現状は良い状態で続けていけそうなので、このまま継続していきますが、先述のとおり今後の状況次第ではペア作業もなくなります。

こういった実験とふりかえりができるのはとても良いことなので、今後はペア作業以外にも小さく試して、ふりかえるというのをチームの文化として定着させていけたらなと考えています。

2017-05-19

td-agent でログ全文は S3 へ保存しつつ、特定文字列がマッチした場合 slack に通知する方法

はじめに

タイトルままの個人的な忘備録です。 td-agentのインストールなどはたくさん記事があるのでてけとーに見てください。 slack通知に利用したプラグインは以下のようにインストールしました。

td-agent-gem install fluent-plugin-slack

今回の設定は特定ログファイルを長期保管用にS3へアップロードしつつ、特定文字列を含むログが出力された場合、slackに通知するものです。

td-agentの設定ファイル

さっそく利用したtd-agentのコンフィグ例をもとに解説していきます。そのままでは利用できませんので、適宜必要なところは書き換えてご利用ください。

sourceの設定

まずtd-agentを利用して保存したいファイルのソースを定義します。

今回はtailプラグインを使って読み込み続けて、変更があれば追従するようにしています。またpos_fileを利用することで、何らかの理由でファイルが読み込めなくなった場合でも続きからロードできるようにしてあります。

<source>
  @type tail
  path TAIL_TARGET_FILE_PATH
  pos_file POS_FILE_PATH
  tag log
  format none
</source>

matchの設定

次に上記sourceから、S3に保存する用と、特定文字列をフィルターするためにラベル付けをする用にsourceで得たデータを分岐させて処理しています。

まずはS3にログのメッセージをそのまま、まとめて送信する設定です。

ここでformat single_valueにしているのはsourceからmessageがkeyとなっているものだけを抜き取り、そのまま送信するためです。要はログをそのまま保存したいのでsingle_valueを使っています。

またS3への保存形式をstore_as textとすることで、text/plainでS3へ保存するようにしています。

次に2つめの処理で、sourceから渡ってきたデータにラベルを付与して、次のフィルターをするための処理に分岐させています。

<match log>
  @type copy
  <store>
    @type s3
    buffer_type file
    buffer_path BUFFER_FILE_PATH
    flush_interval FLUSH_INTERVAL_TIME
    s3_bucket TARGET_AWS_S3_BUCKET_NAME
    s3_region TARGET_BUCKET_REGION
    path "TARGET_S3_OBJECT_PATH"
    store_as text
    format single_value
    flush_at_shutdown
    time_slice_format
  </store>

  <store>
    type relabel
    @label @rewrite
  </store>
</match>

filter

さて、前のmatch処理でlabel着けをしたものに対して、実際にフィルタリングを行って、マッチしたもののみ、slackに通知するのは下記のような設定になります。

まず、filterセクションでフィルタリングをkeyがmessageのものに対して行います。

今回はfilterという文字列が含んでいるものだけ通知するようにしたいので、regexp1 message filterという設定になります。その後、フィルターした文字列をslackの特定チャンネルに通知するための設定をmatchセクションに書いています。

これでログ全文を保存しつつ、特定文字列がマッチした場合slackに通知することができます。

<label @rewrite>
  <filter>
    @type grep
    regexp1 message filter
  </filter>
  <match>
    @type slack
    webhook_url https://YUOUR_SLACK_API_URL
    channel CHANNEL_NAME
    username USERNAME
    icon_emoji :ICON_EMOJI:
    flush_interval FLUSH_INTERVAL_TIME
    flush_at_shutdown
  </match>
</label>

設定全文

ここまでの設定を一つにまとめたものを下記に記載しておきます。設定の説明の最初にも記載しましたが、このままでは利用できないので適宜書き換えて利用していただければと思います。

<source>
  @type tail
  path TAIL_TARGET_FILE_PATH
  pos_file POS_FILE_PATH
  tag log
  format none
</source>

<match log>
  @type copy
  <store>
    @type s3
    buffer_type file
    buffer_path BUFFER_FILE_PATH
    flush_interval FLUSH_INTERVAL_TIME
    s3_bucket TARGET_AWS_S3_BUCKET_NAME
    s3_region TARGET_BUCKET_REGION
    path "TARGET_S3_OBJECT_PATH"
    store_as text
    format single_value
    flush_at_shutdown
    time_slice_format
  </store>

  <store>
    type relabel
    @label @rewrite
  </store>
</match>

<label @rewrite>
  <filter>
    @type grep
    regexp1 message filter
  </filter>
  <match>
    @type slack
    webhook_url https://YUOUR_SLACK_API_URL
    channel CHANNEL_NAME
    username USERNAME
    icon_emoji :ICON_EMOJI:
    flush_interval FLUSH_INTERVAL_TIME
    flush_at_shutdown
  </match>
</label>

おわりに

簡単ですが、タイトル通りの用途の設定をまとめました。

td-agent簡単に設定できて、便利なのでこれからもどんどん使っていきたい。

akms道東

ITイベント，勉強会への参加記録や趣味のことが書いてあるブログです．

wsl2のubuntu環境でman syscallsを読むためにやったこと

UE4 で PS4 コントローラーを使うように設定してみた

SpreadSheet から GAS を利用して Slack API で通知してみた

はじめに

GAS側でやったこと

GASのコード

ハマったところ

おわりに

RDS for PostgreSQL のスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

はじめに

RDS for PostgreSQL でスロークエリログのファイルから開始時間、実行時間、終了時間を出すワンライナー

おわりに

エラーの原因解明にモブ調査してみた

はじめに

やってみた感想

おわりに

インフラチームでペア作業始めてみて1ヵ月経過したので全体のふりかえりをした

はじめに

前回までのあらすじ

ふりかえり

感想

おわりに

td-agent でログ全文は S3 へ保存しつつ、特定文字列がマッチした場合 slack に通知する方法

はじめに

td-agentの設定ファイル

sourceの設定

matchの設定

filter

設定全文

おわりに