有痛性外脛骨の除去手術を受けた
先日、有痛性外脛骨の除去手術を受けました。 手術前いろいろ調べたのですが、あまり情報がなくて不安になったりしたので、出来るだけ残しておこうと思います。
このブログは手術して退院直後に書いてます。
前提
僕は、冬の間はほぼ毎週スキーに行っています。今回の手術はほぼそのために行いました
経緯
1月にいったスキーの帰りで、スキーブーツを脱ぐときに右足首に違和感と痛みがあったのが始まりです。(冬の間はスキーにほぼ毎週行ってます 最初はブーツのシェルに出っ張りが出来たのかと思ったのですが、よくよく見ると、右足の内くるぶし前方に骨の出っ張りが出来ていました。
気にせずスキーに通い続けていたのですが、症状はどんどん悪化し、ブーツを脱ぐのが激痛。スキー中も痛みがすごくて半日が限界。という状況になってしまいました。特にリフトに乗ってるときの、足が浮いている状態が痛みが激しかったです。 せっかくお金をかけてスキー場に行ってるのにこれではもったいないと思い、整形外科に行ってみることにしました。
初回の通院にて、外脛骨障害という診断。CTをとったところ、僕の場合は大きく剥離(?)してしまっているので、自然治癒の可能性はほぼなし、手術で摘出がおすすめ、という話になりました。外脛骨とは、足にある余剰骨のことで、偏平足や色々な要因で内くるぶしに前方に飛び出してしまうことがあり、それに痛みが出ると有痛性外脛骨障害、ということらしいです。
ただ手術してしまうと、数か月はリハビリが必要ということで、手術がシーズンが終わったあとに行うことにしました。
手術を受けるために病院へ
4月後半に病院に向かい、手術を受ける意向を伝えたところ、さくっと2週間後に決定しました。 入院は2泊3日で、全身麻酔を使った手術を受けることがここで決まりました。
1日目: 手術前の検査
2日目: 手術
3日目: 退院
というスケジュールです。
全身麻酔を行う場合は、前日夜から絶食を行う必要があるため、これが最短スケジュールになります。
入院・手術
入院当日は手術前に必要な検査をしただけで、半日ほぼやることなし。入院するときは、時間つぶせる本を持ち込むのがおすすめです。翌日の手術の開始時間もこの日に教えてもらえました。
翌日朝起きると、手術の開始時間を伝えられます。手術の開始時間が近づくと、自分のベッドで手術着に着替えて待ちます。時間になると、手術室までは自分で歩いて行きます。ベッドで運ばれるイメージだったので意外でした。
手術室に入ると、担当の看護師や麻酔医の方から挨拶されます。手術室の奥に、手術台があり、自分で手術台に横になります。いくつか確認があったあと、全身麻酔が始まります。全身麻酔は初めてだったのですが、麻酔が始まった瞬間に頭が重くなる感じがあり、次に目が覚めると手術はもう終わっていました。時計を見ると1時間半ほどかかっていたのですが、体感は数秒でした。ただ、目覚めた直後は少し息苦しい感じと、悪寒、震えはありました。しばらくすると正常になりました。
手術した箇所は鎮痛剤を点滴されているのであまり痛みは感じないものの、じんわり痛みがあり、それを見て初めて手術した実感がわきました。 手術した当日は、右足に体重をかけてはいけない(そもそも痛くてかけられないけど)ので、移動は車いす、ベッドからの移動はナースコールで看護師さんを呼んで移動することになります。自分の意思で移動できないのはかなりストレスありました。
リハビリ・退院
翌日朝、リハビリとして、松葉杖の使い方を教えてもらい、問題なく移動できるようになれば、退院です。
余談ですが、松葉杖を使った階段昇降はかなり恐怖ありました。(上る場合は、松葉杖で全体重ささえて、片足ジャンプすることになる) 出来なくて入院延長もよくある話だそうです。
家の中を松葉杖で移動するのも、結構を気を使います。少なくとも松葉杖で移動できる導線を確保してもらうところまでは、家族などに協力してもらわないとなかなか厳しいです。移動中常に両手がふさがるので、何かを持って移動する、ということが基本的に出来ません。
仕事については、コロナの影響もあり、自宅で仕事できるので影響はありませんでしたが、外に出る仕事はかなり難しいと思います。
手術前にしばらく松葉杖ということは聞いていたのですが、思ってたより大変でした。
費用について
病院や、手術内容によって大きく変わると思うのであまり参考にならないとは思うのですが、入院は2泊3日、全身麻酔で手術時間2時間ほどで、6万5千円ぐらいでした。 限度額適用認定証を一応取り寄せていたのですが、結果的には不要でした。
スキー旅行一回我慢するぐらいの金額で出来るので、もし同じように痛みに我慢してスキーしてる方がいたら手術してしまうのがよいかもしれません。
その後
一週間後に抜糸、その後リハビリです。元のように動ける日が待ち遠しいです。スキーブーツの痛みもなくなってるといいな。(痛みの原因である骨がなくなったのでたぶん大丈夫だとは思うんですが
Nginx Ingress ControllerはAnnotationに不正な値をセットすると503を返す
起きたこと
Nginx Ingress Controllerが突然503しか返さなくなり、原因を調べるのにめちゃくちゃ時間がかかってしまった。
前提
Nginx Ingress Controllerは、ユーザーの記述したManifestを元にNginxのconfを生成します。これは、Nginx Ingress ControllerのPodにログインして、 /etc/nginx/nginx.conf を参照すると確認できます。
原因
Nginx Ingress Controllerのソースコードを確認すると、confを生成しているテンプレートがあり、503を返す箇所を確認することができます。なぜエラーなのかもコメントとして出力されます。
巨大なif文なので、ちょっと読みづらいですが、
{{ else }} # Location denied. Reason: {{ $location.Denied | quote }} return 503; {{ end }}
に対応するif文は、1069行目の
{{ if isLocationAllowed $location }}
です。
たとえば、White List SourceRange のようにCIDRを期待しているannotationに、CIDRではない値をセットすること、 isLocationAllowdがFalseになり、503を返します。
Annotationの一覧はこちら
学び
Nginx Ingress Controllerをある種ブラックボックスとして扱っていたのですが、Nginx Ingress Controllerはnginxのconfを生成しているということを知っていれば、もっと早く解決できたので、利用しているミドルウェアが何をしているのかはだいたいでいいので把握するようにしておきたいと思いました。とはいえ、まさかNginxのconfにエラーメッセージがあるとは思い至らないのでなかなか難しいところですが。
Nginx Ingress Controller + oauth2-proxyでSSOしてるときに、特定のIPアドレスからのリクエストのみ認証をスキップさせる
タイトルに書いてある通りのことがやりたかったのだけど、結構はまったので残しておきます。 脆弱性テストのためのクローラを通すとか、必要なシチュエーションはあるのではないでしょうか。
色々試行錯誤したのですが、下記の手順でいけました。
Nginx Ingress Controllerのfowarded-forオプションを設定する
k8sクラスタの前段にCDNなどを配置している場合はまずこれが必要です。
use-forwarded-headersにTrueを設定することで、Nginx Ingress Controllerからプロキシされる先にX-Forwaded系のヘッダーがセットされます。
ConfigMap - NGINX Ingress Controller
oauth2-proxyの設定を追加する
oauth2-proxyでX-Forwaded-ForヘッダにセットされたIPを受け取るには、reverse-proxyオプションと、real-client-ip-headerオプションを指定する必要があります。(oauth2-proxyのデフォルトはX-Real-IPのため、real-client-ip-headerオプションで設定する必要があります) その上で、trusted-ipオプションを指定します。
また、気付きづらいのですが、 trusted-ipを指定し、認証がスキップされると、oauth2-proxyはそのままupstreamにリクエストをプロキシします。そのため、upstreamが指定されていないと、404を返却し、Nginx Ingress Controllerが行う認証が失敗してしまいます。この場合、Nginx Ingress Controllerは500を返します。これを回避するためには、 20xを返す upstreamを設定してあげればよいです。 (static://202 など)
ここまでのオプションをまとめるとこうなります。
--real-client-ip-header=X-Forwarded-For --reverse-proxy=true --upstream=static://202 --trusted-ip=xxx.xxx.xxx.xxx --trusted-ip=yyy.yyy.yyy.yyy --trusted-ip=zzz.zzz.zzz.zzz
参考
Nginx Ingress Controller とoauth2-proxyを利用したSSOについて blog.1q77.com
trusted_ipの挙動について github.com
2020年まとめ
仕事の区切りが悪く、年末年始感があまりなかった。今やってるプロジェクトが一区切りついたらまとめたい。(特に忙しいわけではない)
最近は仕事以外の趣味に使う時間を増やしていきたい気持ち。特に体動かす系は、今のうちにどのくらい技術習得できるかが今後の楽しみに影響しそう。 仕事、というかソフトウェア開発は体力関係なくずっと出来そうなので、気長にやっていく。
Nginx Ingress Controllerには2つの実装があるので注意
はじめに
Nginx Ingress Controllerには2つの実装があります。
Kubernetesチーム管理のkubernetes/ingress-nginx(以下ingress-nginx) github.com
Nginxチーム管理のnginx/kubernetes-ingress(以下nginx-ingress)
ingress-nginx, nginx-ingressと呼び分けているのは、両者のドキュメントで Helmを利用したインストール方法でnameとして採用されているからです。
2つの違い
Nginx側のレポジトリ にドキュメントがあります。
kubernetes-ingress/nginx-ingress-controllers.md at master · nginxinc/kubernetes-ingress · GitHub
基本的な設定は似ていますが、マニフェストの書き方が異なる箇所が多く互換性はありません。Nginxの商用製品を使う場合はnginx-ingressが必須です。
ingress-nginxに関するドキュメントは、 kubernetes.github.ioでホストされています。 kubernetes.github.io
nginx-ingressは、docs.nginx.com でホストされています。 docs.nginx.com
annotationなど設定値で検索すると両者がヒットするとこがあるので、間違えないように気を付ける必要があります。
stable/nginx-ingress について
古い記事では、下記のように stable/nginx-ingressを利用する記述がありますが、stable/nginx-ingress はDeprecatedになっており、新規で利用してはいけません
helm install stable/nginx-ingress
stable/nginx-ingress はKubernetesコミュニティの Ingress Controller なので、移行先は ingress-nginx です。
https://github.com/helm/charts/tree/master/stable/nginx-ingress
BigQueryで日付の欠損を補完したレポートを作成する
BigQueryで日付の欠損を補完したレポートを作成するときの方法です。過去何度かやったのだけどその度に調べたり思い出して対応してたのでここに残しておきます。
たとえば
テーブル1
日付 | 属性1 | 金額A |
---|---|---|
2020-07-01 | A | 500 |
2020-07-03 | B | 500 |
テーブル2
日付 | 属性1 | 金額B |
---|---|---|
2020-07-01 | B | 100 |
2020-07-02 | B | 500 |
という2つのテーブルから下記のような結果を出したいとします。(例としてはめちゃくちゃなんですが、やりたいことは察してください)
日付 | 属性1 | 金額A | 金額B |
---|---|---|---|
2020-07-01 | A | 500 | 100 |
2020-07-01 | B | ||
2020-07-02 | A | ||
2020-07-02 | B | 500 | |
2020-07-03 | A | ||
2020-07-03 | B | 500 |
日付を作成する
GENERATE_DATE_ARRAY関数で日付の配列を作成することができます。UNNEST関数で展開することでテーブルとして利用することができます。
SELECT base_date FROM UNNEST(GENERATE_DATE_ARRAY( DATE("2020-07-01"), DATE("2020-07-03"))) AS base_date
属性のパターンを作成し、クロスジョイン
属性の取り得るパターンを事前に作成し、日付とクロスジョインします。(属性のパターンは、SELECTで作成するのではなく、マスターテーブルから取得するのが正しいです)
WITH date_series AS ( SELECT base_date FROM UNNEST(GENERATE_DATE_ARRAY( DATE("2020-07-01"), DATE("2020-07-03"))) AS base_date ), dimensions AS ( SELECT "A" as attr1 UNION ALL SELECT "B" ),base AS ( SELECT base_date, attr1 FROM date_series, dimensions ) SELECT * FROM base
このSQLで下記のようなテーブルを作成することができます
date | attr1 |
---|---|
2020-07-01 | A |
2020-07-01 | B |
2020-07-02 | A |
2020-07-02 | B |
2020-07-03 | A |
2020-07-03 | B |
データテーブルとjoinする
あとは、データが入っているテーブルとJOINすれば完了です。WITH句は先ほどと同じです。
WITH date_series AS ( SELECT base_date FROM UNNEST(GENERATE_DATE_ARRAY( DATE("2020-07-01"), DATE("2020-07-03"))) AS base_date ), dimensions AS ( SELECT "A" as attr1 UNION ALL SELECT "B" ),base AS ( SELECT base_date, attr1 FROM date_series, dimensions ) SELECT base.base_date, base.attr1, テーブル1.金額A テーブル2.金額B FROM base LEFT OUTER JOIN テーブル1 ON base.base_date = テーブル1.base_date AND base.attr1 = テーブル1.attr1 LEFT OUTER JOIN テーブル2 ON base.base_date = テーブル2.base_date AND base.attr1 = テーブル2.attr1
VALORANTをインストールするとキーボードが効かなくなる場合がある
はじめに
VALORANTをインストールすると、VALORANTと一緒にインストールされるアンチチートツールVanguardによってCtrl2Capがチートツール扱いされ、ドライバエラーになり、なんとキーボードが無効化されるのでその注意喚起です。 この事象はRedditでも報告されていました。
対応方法
キーボードが無効化されるのでソフトウェアキーボードでWindowsを操作する必要があります。 ログイン画面では右下からソフトウェアキーボードを表示することができ、ログイン後はタスクバー右クリックで「タッチキーボードボタンを表示」を有効化することでソフトウェアキーボードを有効化することができます。 タスクバーからVanguardを右クリックしてUninstallを選択してアンインストール、その後OS再起動でキーボードが有効になります。
VALORANTをPlayするには
おそらく、ctrl2capをアンインストールするしか方法はありません。僕はctrl2cap無しでWindowsは扱えないのでVALORANTはしばらく見送りました。
ちなみに
キーボード故障かと思って新しいキーボード買ってしまったのですが、結果的には買い替えるよい口実になりました。
追記
アンチチートツールについてはすでに話題になってました maruhoi.com