転職しました

今年の2月に約2年ほどアルバイトとして働いていた IT 企業を退職しました。
その後、3月から別な IT ベンチャーの会社でアルバイトのサーバサイドエンジニアとして働いています。
今しがた気づいたのですが、今日はちょうど入社して3ヶ月でした。

辞めた理由としては、

• サーバサイドエンジニアとして働きたかった
• 会社自体に不満があった

おもにこの2つです。

以前の会社では、主に Web フロントエンドの開発をしていました。フロントエンドも嫌いではないのですが、個々最近はフロントエンドよりバックエンドに興味が動いてきていて、そちらにメインに携わりたいと思っていました。

もう一つの理由に関しては、そのままです。
もう少し詳細に言うと、会社の体制や、技術に関する考え方などが自分の考え方に合わないと感じてきていたためです。
とはいえ、会社に不満を持つというのは (ある程度) 普通のことだと思うのでここでは特に言及するつもりはありません。(一応その理由についての記事は書いているけど、多分投稿することはないはず…)
不満について聞きたかったら直接お願いします。

現在の会社では100% Go を使って開発していて、自分の好きな言語も Go なのでとても良いです。
先輩や後輩もみんな優秀な方ばかりで、コードレビュー、リポジトリのソースコードを読んだりして、毎日とても勉強になっています 🙇‍♂️

現在の会社は、今が一番重要な時期に入っていて、そこに関われるのは光栄な事だなと思っています。
すべてのプロジェクトにメインで参加しているので、技術のハードルや要求が以前の会社より高く、結構ついていくのが大変な時もありますが、楽しく仕事ができているので転職してよかったと思っています。

これからもよろしくお願いします…！

任意のコマンドのサブコマンドにエイリアスを設定できる 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 眼中。

使った本

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

2017 データベーススペシャリスト「専門知識+午後問題」の重点対策 (午後試験対策シリーズ)

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

試験

午前 I

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

午前 II

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

午後 I

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

午後 II

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

まとめ

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

おまけ

友人です

敗因はスマートウォッチを選択しなかったこと

— さわ (@ywkw1717) 2017年4月16日