blog.syfm

徒然なるままに考えていることなどを書いていくブログ

任意のコマンドのサブコマンドにエイリアスを設定できる salias をつくった

動機

最近のコマンドは大抵サブコマンド形式になっています。

$ docker pull hello-world

このように、コマンド名 + サブコマンド + 対象 みたいな形式。
サブコマンドには大きく2種類あって、サブコマンドに動詞を指定するタイプと、リソースを指定するタイプがあります。
感覚的に、コマンドのパターンが多くなってくるとリソースを指定するタイプが主流になっている気がします。
最近だと Docker が以下のように動詞タイプからリソースタイプに移行しつつあるようです (現在はどちらのコマンドも利用できる)

$ docker run hello-world
# 動詞タイプ

$ docker container run hello-world
# リソースタイプ

動詞タイプのほうがタイプ数は少ないが、リソースタイプのほうが階層化されているので秩序がある。
とはいえ、割りと頻繁に利用するコマンドなのに、毎回 container とタイプするのはかなり面倒。
alias を使って、

$ alias dc='docker container'

みたいなこともできるけど、なんとなく気持ち悪いし、既存のコマンドと衝突する可能性も十分にあります。特にすべてのエイリアスがフラットになっているので管理が煩雑になるのも厳しいところです。

つくったもの

このため、サブコマンドにエイリアスを設定できるツールをつくりました。

github.com

これを利用すると、TOML の設定ファイルにサブコマンドに対するエイリアスをコマンドごとに設定できます。

[go]
i = "install"
b = "build"

[docker]
l = "logs"
i = "image"
c = "container"
cl = "container ls"

[kubectl]
c = "create"

利用するには、以下のコマンドを実行する必要があります。

$ source <(salias __init__)

毎回実行するのは面倒なので、.zshrc.bashrc などに含めておくことをおすすめします。
こうすると、以下のように実行できるようになります。

$ docker c ls
# docker container ls

コマンド自体にエイリアスを設定することももちろんできるので、以下のようにもできます。

$ alias d='docker'
$ d c ls
# docker container ls

仕組み

仕組みは単純で、source <(salias __init__) で alias を列挙したテキストをプロセス置換でカレントシェルに読み込ませています。
例えば上の例だと、salias __init__ は以下のような結果を返します。

alias go='salias go'
alias docker='salias docker'
alias kubectl='salias kubectl'

これをプロセス置換で source することで、各コマンドが salias を通して実行されるようになっています。

salias は、引数に渡されたコマンドを展開し、実行しています。

まとめ

目標としていたのは、サブコマンドのタイプ量を極力減らす・エイリアスが大量に増えることを防ぐことだったので、サブコマンドのみエイリアスを設定できるようにしています。
また、Zsh の alias でできるようなグローバルエイリアスも機能に加えたかったのですが、すべてのコマンドを salias に通さないといけなく色々大変そうだったため、今回はひとまず見送りました。
salias を利用して一文字でもタイプ数が少なくできれば幸いです。

その他

土曜にこれを実装していて、PlaidCTF があることを完全に忘れていた。
ちゃんとやっていた友人の Writeup は以下。

ywkw1717.hatenablog.com

データベーススペシャリスト試験を受けた

動機

先週の日曜日に情報処理技術者試験があって、データベーススペシャリスト試験を受けた。
受けた理由としては、データベースの基礎とかが所々欠けていて、今はそこまでデータベースをがっつり使ってはいないけどいずれ使うときに苦労しそうだなと思っていたため。
なので、基礎を補完するつもりで勉強を初めた。
あとは、高度区分で春に受けられる技術分野の試験がデータベーススペシャリスト試験だけだったため。情報処理安全確保支援士は out of 眼中。

使った本

テキストには以下の本だけ使った。

SC を受けた時もこのシリーズの本を使っていた。
午前Iは免除していることが前提(or 自力で解ける)っぽくて、そこに関しての解説等はない。あくまでデスペの本質である範囲を扱っている。
午後の過去問の解説が詳しいので、午後対策したい人にはオススメかもしれない。

試験

午前 I

AP と SC を持っているので免除。

午前 II

ほとんど解けたと思ってたけど、意外と間違えてて割と危なかった。自己採点で7割くらいだったので合格。
CSIRT 間違えたのでセキュリティスペシャリスト失格です。

午後 I

特に問題を見ずに大問1・2を選択。
SC の時もそうだったけど、問題が面白いので解いてて楽しい。
過去問解いてた時もそうだったけど、時間が足りない。ほとんど長考してないにも関わらず時間ギリギリだった。
とはいえ、適当にネットでさらっと他の人の解答と照合して見たらだいたいあってるので受かってると思う。(正式な答えは今週木曜に公開される)

午後 II

これは完全に失敗だった。
SC の時は午後 II はノー勉だったので、今回もいけるだろ〜みたいな感じでいたら、思ったよりできなかった。
午後 II は試験時間が2時間とかいう頭おかしい構成なので、めちゃくちゃ問題が長い。問題だけで10ページくらいあるので、読むだけでも大変。
しかもエンティティとか属性も紛らわしい・長い・分かりづらい名前のものばっかりで、開始10分でゲシュタルト崩壊した。
例えば、補充* という属性が11個あり、 補充* というエンティティも6個ある。分かりづらい…。
こんな感じのこともあって、何度か過去問を解いて、解法をある程度身につけておかないと解けなさそうだった。
一応解答欄はだいたい埋めたけど、正直微妙…。受かってるかは五分五分な感じがする。

まとめ

勉強はちゃんとやったほうがいいと再認識した。

おまけ

友人です

ホームページを移行した・続

今日のお昼ごろに以下のようなエントリを書いたら、id:upamune さんから Netlify なるサービスを教えていただいた!

syfm.hatenablog.com

www.netlify.com

パッと見めちゃくちゃ良さそうなので早速試してみた。
以下のように、GitHub や Bitbucket と連携してリポジトリを選択し、ビルドコマンドと成果物が生成されるディレクトリを指定してやると、GitHub に push されたタイミングで pull してビルド、公開までを自動で行ってくれる。

f:id:ktr_0731:20170312230641p:plain

元々ページを Gulp + EJS で生成していたため、登録して5分くらいで公開まで行けた。

前の記事では、ホームページの公開に GitHub Pages を、デプロイに CircleCI を使っていたけど、デプロイのためだけに CircleCI を使ったり、リポジトリを2つ作らないといけなくて微妙だったのが、Netlify でまるまる置き換えられた。
Cloudflare で SSL 対応していた部分も、Netlify で Cloudflare 同様にワンクリックで対応できた。その関係で DNS サーバを お名前.com のほうに戻した。

f:id:ktr_0731:20170312231200p:plain

他にも CLI が用意されてたり、リダイレクト・リライト、Webhook、カスタムヘッダなど様々な設定ができる。SPA などのためにプリレンダリングもできるらしく凄まじい…。

ここまでメリットしか挙げてこなかったけど、以前の環境と比べてレイテンシが少し大きくなっている気がする。
でも本当にちょっとだし、個人的には全然問題ないと感じる。

まったく変更する予定のないページであれば GitHub Pages で十分だけど、静的サイトジェネレータとかを使ってるならば間違いなく便利に使える。