2022-09-06

ぶっちゃけ人生は嫌なことばかり

気がつけば人生は考えたくないことで満ちていた。思い返すのは中学時代、僕は都内の私立中学に進学したが、中高6年間を通して馴染むことはなく、継続的な友達は一人もできなかった。それが原因で明らに精神的な異常を抱えるようになった (症状は 20 代の中盤まで継続した)。その後、逃げるように地方大学に進学したが学科内に友達はできなかった。苦痛な運動部を何故か辞めずに4年間を忙殺されたおかげで、こちらでは幸い3人だけ友人ができた。

卒業後、人と関わりたくない一心でITエンジニアとなり、6年間で2回転職をして今に至る。仕事も楽しいと感じたことはない。IT技術自体は嫌いではないが、資本主義の権化のようなこの仕事にいつも虚しさを感じる。しかも2回目の転職の末、今はITエンジニアというより雑用になってしまった。一応ITエンジニアとして多少のスキルを身に着けてきたつもりだったが、今はもう何をしているのかよくわからない。

プライベートで考えたくないのが結婚式だ。繰り返しとなるが、僕には友達がほとんどいない。対して奥さんは20人以上の友達を呼ぶ予定だ。幸い、同じ会社にいた頃の共通の友人(僕とはただの顔見知り)を6人ほど呼ぶので、彼らは僕のサイドに座ることになるだろう。僕は根本的に人望がないし、人から好感を持たれる人間でもないから、家族以外の誰かが心から祝ってくれるとはあまり思っていない。奥さんにだけは明るく誠実に接し続けたいと思っているが、周りから見れば僕は彼女に至極もったいなく見えるだろう。

根本的に、僕は社会で生きていくということが向いていない。だからきっと、普通に社会人として生きていく限り、この苦しみは続くのだろう。いつか心の平穏を過ごせたら良いのになと思う。

2022-09-03

BIOSコールでLBA方式を使う方法

ハードディスクを読み取る方法にはCHS方式とLBA方式がある。CHSはC(シリンダ)、H(ヘッド)、S(セクタ)の略で、ハードディスクの具体的な位置を指定するもの (xyz座標で指定する感じ)。対してLBA方式は、ディスクの最小単位であるセクタに0から通し番号をつけ、その番号で操作対象セクタを指定する方式。後者の穂が主流。確かにそのほうが楽だよね。

LBAの場合はINT13Hを使うとのこと。以下に書いてある。 https://blog.hatena.ne.jp/tsurezurejapan/tsurezurejapan.hatenablog.com/edit?openedFrom=globalheader-new-entry

CHSの場合はINT13なので、以下に従えばよい。 https://stanislavs.org/helppc/int_13.html

2022-09-03

BIOSコールの一覧

システムプログラミング

メーカ等によって違うかもしれないが、以下が参考になる https://stanislavs.org/helppc/int_10.html

2022-05-28

MQTT 5.0 で追加された Shared Subscription とは何か

このサイトを見ればわかる。下の方に書いてあるgif を参照。

2022-05-13

StatsDとは何か。具体的な中身について。

この記事では、監視などの分野で出てくる StatsD についてまとめておく。

StatsD とは、様々なメトリクス(数値データ)を送信するためのプロトコルとサーバアプリケーションのことを指す。言い換えると、障害やパフォーマンスの監視などを目的として、マシンの様々なメトリクス(CPU 使用率、メモリ使用率など)を集めるためのものである。基本的な構成としては以下のようになる。

クライアント
   |
(随時データ送信)
   |
   v
サーバ (StatsD など)
   |
(蓄積し、定期的にデータ送信*)
   |
   v
モニタリング用のサーバ (グラフなどを表示する)

*定期的にデータを送信したり、データをクリアすることをフラッシュと呼ぶことが多い。

サーバアプリケーションの StatsD

サーバアプリケーションの StatsD はこちら。CloudWatch Agent など、他のソフトウェアに組み込まれている場合もある。

StatsD プロトコル

基本形と例は以下のとおり。このようなデータが UTF-8 で UDP パケットに乗るだけである。レートについては後述するが、タイプによって有る場合と無い場合がある。

# フォーマット
<メトリクス名>:<値>|<タイプ>|@<レート>

# 例
hoge:1|c|@0.1

以下の画像はメトリクス名: "test-client.stat1"、値: "42"、タイプ: "c" (Counter タイプ) のメトリクスを送信した例である。 "test-client.stat1:42|c" という文字列が見える通り、非常に単純な構造であることがわかる。

メトリクスのタイプ

メトリクスのタイプには厳密に定義された仕様がなく製品によって異なるので、都度ドキュメントを確認するべし。

Gauge

値の推移を計測するためのタイプ。クライアントはそのタイミングでの計測値などを送信し、サーバは受け取った値をそのまま記録する (+/- する場合もある)。サーバはフラッシュまでにデータを受け取らなかった場合、前回のデータを保持する。温度などの数値の推移を計測する場合などに使われる。

# フォーマット
<メトリクス名>:<値>|g

# サーバの動作例
tempreture:21|g| を受け取る -> tempreture = 21 を保持
フラッシュ -> 21 を送信
... (データなし)
フラッシュ -> 21 を送信
tempreture:-1|g| を受け取る -> tempreture = 21 - 1 = 20 を保持
フラッシュ -> 20 を送信

Set

任意の値を送信するためのタイプ。クライアントはそのタイミングでの計測値などを送信し、サーバは受け取った値をそのまま記録する。Gauges のように前回のデータを保持することはない。

# フォーマット
<メトリクス名>:<値>|s

# 使用例
param:21|s|

Counting (Count)

カウント数を計測するためのタイプ。クライアントは何らかのカウント数を送信し、サーバは受け取った値を +/- していく (つまり累積値)。フラッシュされると 0 に戻る。

# フォーマット
<メトリクス名>:<値>|c|@<レート>

# メトリクスの例
hoge:1|c| -> +1 カウント
hoge:2|c|@0.1 -> +2 / 0.1 = +20 カウント

# サーバの動作例
フラッシュ -> hoge = 0
hoge:1|c| を受け取る -> hoge = 0 + 1 = 1
hoge:13|c| を受け取る -> hoge = 1 + 13 = 14
hoge:-5|c| を受け取る -> hoge = 14 - 5 = 9
フラッシュ -> hoge = 0

Timer (Timing, Histogram)

ms 単位での計測時間を送信するためのタイプ。サーバ側は各データを保存し、サーバ側で統計値 (最大値, 最小値, 平均など) を計算する。製品によるが、「Timer == Timing」、「Histogram は Timer のエイリアスである」、「Timer は Histogram のサブセットである」など、まとめて扱われる場合が多い。通常、タイプを示す文字列として、Timer / Timing は ms を、ヒストグラムは h を使う。

# Timer / Timing のフォーマット
<メトリクス名>:<値>|ms|@<レート>

# ヒストグラムのフォーマット
<メトリクス名>:<値>|h|@<レート>

# サーバの動作例
フラッシュ -> load = []
load:100|ms| を受け取る -> load = [100]
load:120|ms| を受け取る -> load = [100, 130]
load:400|ms| を受け取る -> load = [100, 130, 400]
フラッシュ -> max = 400, min = 100,  avg = 210 を送信 / load = []

メトリクスのレート

クライアントでのサンプリング間隔 ÷ サーバへのデータ送信間隔を示す。例えば、1 分毎にサンプリングして 5 分毎に送信する場合、1/5 = 0.2 ということになる。クライアントからサーバへの送信回数を減らして、負荷を抑えるためにこのような仕組みが用意されている。

受け取ったサーバはこれを考慮し、例えば "hoge:1|c|@0.1" であれば、通常 1 / 0.1 = 10 カウントとして記録することになる。"load:100|ms|@0.2" の場合、おそらく load += [100, 100, 100, 100, 100] という換算になるのだと思われる。

参考資料

2022-05-09

AWSの課金/コストの詳細情報を分析する

AWSで使える手軽でグラフィカルなコスト分析機能としてCost Explorerがあるが、これだと痒いところに手が届かない感が強い。より詳細に分析したい場合はCost and Usage Report(CUR)を使うと良い。

CURの使い方

CURは簡単に言うとAWSの課金情報をS3に出力する機能である。Athena(さまざまな形式のファイルをSQLで分析できるサービス)のテンプレもあるのですぐにSQLで分析できる。手順は以下。

CURでレポートを作成する
Athenaの設定をする
AthenaでSQL実行。基本的な構文(HAVING / ORDER等を含む)は使える。

カラムの説明はこのページに書いてある。なお、SQL上での項目名はスネークケースで、ドキュメント上はキャメルケースになっているので、調べ方には注意。

補足: DBRについて

DBRというレガシーなレポート機能も存在するが、2019年7月8日以降に新規登録したユーザは使えないらしい。大人しくCURを使おう。

2022-05-06

Twitter API v2 を使ってツイートの検索結果を取得する

API からツイートの検索結果を取得する必要に迫られたのだが、比較的最近 Twitter API のバージョンは v1.1 から v2 へのマイグレーションが開始されたようで、ググった感じでは v1.1 と v2 の情報が錯綜しているような。というわけで、v2 でツイートの検索結果を取得する方法について curl を使って簡単に書き留めておくことに。

事前準備

まずこのページでデベロッパーとして登録する。
Project と App を作成する。

ここまでやると API Key / API Key Secret / Bearer Token が発行されるはず。ツイートの検索結果を取得するだけなら、使うのは Bearer Token のみ。

curl で API を叩く

以下のとおり。${} を適宜変換してください。

curl https://api.twitter.com/2/tweets/search/recent?query=${検索クエリ} \
  -H "Authorization: Bearer ${Bearer Token}" \

検索クエリについてはこのページを参照。普通に "ごはん" みたいなワードを入れて検索することもできるし、色々条件指定が可能。
API 仕様についてはこのページを参照。
上記は直近 7 日間のツイート内から検索する、Recent search という API を使用している。過去のものを含めた Full-archive search という API もあるが、こちらは Academic Research access というプラン？が必要らしい。
上記の curl だと非常に限られた情報しか取れないので、画像の URL を取得したい場合など、詳細な情報が欲しい場合には、クエリ文字として指定しなければならない。このあたりも上に挙げた API ドキュメント書いてあるので、適宜参照してください。
残念ながら、API の検索結果をうまいこと Web ページに表示してくれるようなものは今のところ無さそう。めぼしいサードパーティのライブラリなども見つからなかった。

山が見えるテラス付きログハウスでダラダラ生きていたい

農学部を出てITエンジニアをしている虚しい人の徒然日記