最近ミーティングやレビューや調査の依頼などの仕事を優先してしまって、やりたいことができないことで心理的に疲労が溜まってる気がする。どれもやらなくてはいけないことではあるが、他のやらなくてはいけないことが常に頭にあって、それだけでそれが焦りになって負担を感じている気がする。スタックの上に積まれたタスクは捌けているけど、下にあるタスクがずっとその場所に居座っている感じ。優先順位をつけて優先順位の低いタスクを取らないようにしようというのは解決策ではあるが、それが実行可能なのかは正直わからない。タスクの心理的な負担を減らすには頭の中にタスクを積むのではなくメモ帳やツールに書き出して、一つ一つのタスクをやっている時には思い出さないようにするというのはあると思う。
gh コマンド(GitHub CLI) でよく使う操作
terminal から Pull Request 作れたりするので便利。
history | grep "\bgh\b" | tail
でよく使ってるコマンドを見てみた
PRをwebで見る
gh pr view {pr-number} --web
gh pr view {branch-name} --web
現在のブランチのPRをwebでみる
gh pr view --web
自分のPRの一覧
gh pr list -a {my-user-name}
現在のブランチのPRを作る
gh pr create
確認すると Pull Request 扱うのにしか使ってない。
OAuth 2.0 と OpenID Connect の本を読んで概要を掴んだ
仕事でなんとなくOpenID Connectを触っていたところ、『雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本』というちょうどいいタイトルの電子書籍があるとはてなブックマークで知ったので買って読んでみた。その後同じ著者の書いている『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』も読んだ。
OAuth 2.0とOpenID Connectの基本的な登場人物と流れが丁寧に説明されていたので、https://accounts.google.com/.well-known/openid-configuration で見れる hoge_endpoint などの意味がわかるようになった。混乱しやすいOAuth 2.0 とOpenID Connectのそれぞれの目的と関係が説明されてて、同じものを違う呼び名で呼ぶような混乱しやすい用語も整理されているのも役に立った。
詳しく知りたかったのはOpen ID ConnectのIDトークンについての情報だったけど、その前提としてOAuth 2.0 と OpenID Connectの仕組みを掴めたのはよかった。認可と認証の仕組み、役に立つのはもちろん、純粋にそれ自体が面白いので個人的にちゃんと知りたいという気持ちが高まった。
『入門 監視』で監視に入門
業務でモバイルアプリの開発をしていたのから、サーバーサイドのアプリケーションの開発をするように変わって1年。アプリケーションエンジニアといえども監視に対する知識が足りないときついと感じ始めていた。読みたい本が多くて手を付けられていなかったが、とりあえず『入門 監視』を今週買うだけ買って、今日最初の1章だけ読んだ。
幸い自分の開発しているサービスでは監視の設定がなされているので、
- 既存の監視について、サービスが正常に動いているとはどういうことだと定義されているのかを考える
- 通知をうけとったときに、どんな対応・修正が必要なのか考える
ぐらいを意識して来週からの仕事をやっていこうと思う。
それにしても本を買う数に対して、読む量が追いついていない。
すごいHaskellたのしく学ぼう!
数週間前から引き続き、少しずつHaskellの勉強を続けている。
『プログラミングHaskell』が教科書だとしたら、『すごいHaskellたのしく学ぼう!』のほうが副読本のような感じで、補完しながら読んでいる。
『すごいHaskell』のほうはKindleだとリフロー型で読みにくいけど、達人出版会だとPDFで販売しているので電子書籍だとそちらがオススメ。
https://tatsu-zine.com/books/sugoi-haskell-ja
基本概念やシンタックスは理解できてきた。プログラミングHaskellでいうと1〜10章と15章の遅延評価ぐらい。今はFunctorとかApplicativeとかMonadとかHaskell以外ではあまり聞かない概念のところを読んでいる。Applicativeあたりから難しくてよくわからんとなってきた。去年圏論少し勉強してたからFunctor(関手)といわれても全く新しい概念ではない。ただ本の中では圏論についてほとんど触れずに進むから、困惑した。圏が何かはっきりしないまま、関手について考えている気がしてもやもやする。そこは自分で矢印書いて理解していくべきなのだろうか。
あと、Hackerrankというサイトで関数型プログラミングの練習問題があったから解いたりしていた。
プログラミングの問題じゃなくて、ラムダ計算の簡約や適用やチャーチ数についての問題もあったからそこも調べながらやってみた。
プログラミングHaskell 第2版
最近は趣味でHaskellを触っている。
プログラミングHaskell 第2版www.lambdanote.com
前に本買ったままほとんど読み進めてなかったので、読んで練習問題で練習してる。各章の末に練習問題がついているのがいい。解答例もあるのでわからなくても安心。
仕事でもコードを書いているけど、仕事で書いているプログラミング言語とはぜんぜん違うので面白い。Webやアプリの開発で新しいことを勉強する機会は多いけど、すぐに役立つ実用的なことはそんなにわくわくしない。特に最近はそう感じる。何に役立つのかわからないもののほうがわくわくする。
SOAP
注: 通信プロトコルについての記事ではない
病院で診察中に医師の記入している電子カルテを除くと、S,O,A,Pという各項目に記入していっているのをみかけた。どこの業界も謎の頭文字好きだよなと思いつつ、なんとなく気になって調べてみた。
SOAP(そーぷ)とは、問題指向型診療録(POMR)の一つである。POS(Problem Oriented System:問題志向型医療)の考え方によって得られたデータを内容ごとに分類・整理した上で、下記のようにS、O、A、Pの4つの項目に分けて考える分析手法でもある。
- S(Subject):主観的データ。患者の話や病歴など。
- O(Object):客観的データ。身体診察・検査から得られた情報。
- A(Assessment):上記、SとOの情報の評価。
- P(Plan):上3者をもとにした治療方針。
これを見て医療とITで業界は違えど、同じような思考でやっている仕事もあるなと思った。
ユーザーや運営が困ったときに技術的なサポートをするという仕事をすることがある。たいてい突発的にやってきて、開発をしているエンジニアが交代で対応している。専任のサポートエンジニアがいるわけではなく、対処方法も色々なので、各エンジニアが臨機応変に対応している。
サポートの仕事もユーザーの主観的な情報を聞いたあと、客観的な情報を集めるという作業を行う。例えばユーザーからデータが消えたという情報を得たなら、本当に消えたのかDBを見て確認するというような作業だ。そしてその主観的情報と客観的情報を突き合わせて状況を評価する。そしてその評価をもとに何らかの対応をする。
ユーザーサポートにおける例:
- S: データが消えた
- O: DBにはデータがある
- A: データは消えていない
- P: ログインしているアカウントをユーザーに確認してもらう
書いてみて思ったが、このSOAPというフレームワークは患者の症状のような主観的にしかわかり得ないが重要な情報を扱うときに有用だ。すべて客観的に情報を把握できるのならば主観的情報は排除できる。重要だが主観的な情報を客観的な情報で補って評価をするというのがこのフレームワークの要点だ。
システムのサポートも、主観的な困っている状況を客観的情報で固めていく手順は似ているので転用できるフレームワークである。サポートの仕事が苦手で困っているエンジニアがいたらこういう思考と手順でやっているんだよと教えてもいいかもしれない。