lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【テキスト処理系コマンド編】
前回の続き。
lpic試験では基本的なunixコマンドについても学べるのだけど、今回は普段あまり使ってなかったけど使ってみると非常に便利そうなテキスト処理系のコマンド(join
,cut
,grep
,sed
….etc)を集めてみた。*1
テキスト処理系コマンドって便利
ちょっと前に達人プログラマーという本を読んだのだけど、第3章基本的なツールの19節に「テキスト操作」というのがあって、
正しく使えばこういったツール(テキスト操作言語やシェルなど)は驚くほど手際よく巧妙な成果物を生み出せます。しかし、マスターするのにはそれなりの時間がかかるのです。
と書かれている。まあ、覚えておかなくてもいいけど、ちょっと痒いところに手を伸ばしたい時に、今回のコマンドは非常に役に立つなと感じている。
grep, egrep, fgrep
grep
は有名だけど、egrep
とfgrep
というのもある。(この2つはどちらもgrep
で出来ることなので、なぜあるのかよくわからないけど、トリビア要素としては面白かった)
- egrep:拡張正規表現と呼ばれる普通の正規表現とは少し異なったパターンの正規表現を使う場合に使う。
grep -E
と同じ。 - fgrep:正規表現を使わないgrep。
*
や?
などを正規表現の特定文字ではなく普通の検索文字列として識別したい場合に利用する。例えば、fgrep ‘*’ hoge.txt
とgrep ‘\*’ hoge.txt
は同じ。
最近良く使った手法
# -vで指定の文字列を除外 grep -v ‘hoge’ sample.txt # 複数文字列をOR検索(-eをつなげても出来るけど見づらくなる) grep ‘hoge|fuga|hugo’ sample.txt # 一致した行の前後の行も出力 grep ‘hoge’ sample.txt -A 10 -B 10 # 上の-vと組み合わせて、余計なログは省いてtail -fする tail -f xxx.log | grep -iv 'hoge' | grep -Ev [poke|fuga]
…etc *2
正直自分のローカルマシン上だと、ptコマンド(Platinum Searcher)などを使って検索することが殆どだし、標準出力をパイプで渡して検索したいときなども、grep
よりもpecoを使ってしまう(最近だとfzfがいいのかな)ことが多いから、ほぼgrep
を使う機会はないのだけど、sshした先のlinuxサーバーにはそれらのツールはインストールしていない事が多いので、grep
の使い方を覚えておくと便利だったりする。
sort
行単位でテキストファイルをソートしてくれる。デフォルトでは昇順になっている。csvとかリストファイルとかログファイルで、ちょっとしたソートをして表示したい時にたまに使える。
個人的には-b
オプションで行頭の空白を無視してくれるのが便利で、行頭に空白があるテキストファイルでも特に気にせずにソートしてくれる。
あと-n
をつけないと数値をテキストとして処理してソートしてしまうので、数値でソートしたいときは覚えておくと便利。
sort -b hoge.csv | pbcopy
uniq
入力されたテキストの中で重複している行を調べてくれる。
デフォルトなら重複を排除して表示してくれるのだけど、-d
をつけると重複している行のみを出力する。-u
なら重複していない行のみを出力する。
-u
の方を使う機会が多くて、最近だと、とあるcsvファイルに重複した情報がないかどうかを確認する時に
uniq -d hoge.csv
ってやって、特に出力がなければ重複なしと判断したりした。便利。*3
wc
テキストの行数、単語数、バイト数を表示してくれる。 最近でかいcsvを扱う時に行数を確かめるために使いまくった。
xargs
標準入力で受け取ったテキストを引数にして、与えられたコマンドを実行する
# findでhogeという名前のファイルを見つけて、それらをrmする。 find . -type f -name ‘hoge’ | xargs rm
これだけではあまりは利点はなさそうに見えるけど、findするファイルが非常に多かったとき、rm *
とかだとシェルの制限で削除するファイルが多すぎてエラーになってしまうことがある。でも、xargs
経由で渡すとxargs
がうまい具合にシェルの制限を超えないように処理してくれる。*4
split
指定した行数でファイルを分割してくれる。
これもでかいcsvを扱ったときの話なのだけど、そのcsvを分割したいとなって、その時はviエディタでシュッと分割したい行に移動して別ファイルに残りをコピペして分割するということをしたのだけど、split
を使えば一瞬だったな〜と反省した。ちょっとしたテキスト分割には重宝するはず。
tee
標準出力とファイル書き出しを両方を行ってくれる。文字通りT字に処理結果を分岐してくれることから、tee
という名前らしい。
正直、勉強したときは「いつ使うんだ?」と思ったけど、以下の記事を見て「なんか覚えておいたら、かっこよそう!と思ってしまった。
(番外)便利そうだけど使い道に困ってしまった子達
- tr
- join
- nl
- od
- expand
- unexpand
- fmt
- pr
join
とtr
は工夫すれば使えそうな気はしているのだけど、まだ真価がわかっていない。どういったコマンドなのか、他も調べてもらえればわかるけど、正直「いつ使うの?」と感じてしまった。
*1:あくまでlpic 101 level1の試験範囲のコマンドに今回は限定している。
*2:全然簡単な使い方かも知れないけど、これくらいのことを新しく覚えておくだけでも出来ることが増えた実感がある
*3:ぐぐるとsortコマンドとの組み合わせが多く見られる感じがあるけど、他にも色々使い道はありそう
*4:ちょっと用法は違うけど、xargsで並列処理を実験してるqiita記事があって、面白かった。ref:
lpic 101 - level 1に合格したけど、実務で使えそうな知識をまとめてみる【systemd編】
先日lpic level 1 101試験を合格したのだけど、非常に勉強になったし、いままで触れていたlinuxの周辺技術の理解を更に深めることができた。
その中には実務で役立ちそうだなと思ったものもあれば、そうでないものもあったのだけど、せっかく役立つ方をまとめておけば、今後のためにもなりそうだったのでブログに書いておこうかと思った。
今回は、システムアーキテクチャの章で出てくる systemd
辺りの話をまとめておこうと思う。
systemdとは?
ググれば幾らでも出てくる。自分なりにまとめてみると、linuxシステムで起動処理や起動時の設定などを行ってくれるシステムの一つ。SysVinit
やUpstart
などもあるがsystemd
はそれらを更に改良したシステムで、自分が勉強した限りでは現在界隈で一番主流になっているシステム。
systemd
のおかげで今まで直列型のようにシステムを起動していたのが、並列型のように起動できるようになったのでシステム起動が早くなったりした。また、いろいろなシステムの処理の設定・管理をUnit
という単位で管理してくれたり、Service UnitをCLIから管理するためにsystemctl
というコマンドも用意されていて、サービスの起動・停止・再起動などを行える。
webサービスを触っていて「nginxを再起動したいけど、どうするのかな」と思い、ググった結果「systemctl restart nginx
でできるよ」と書いてる記事があったり、そうでない記事があったりで、自分はよく混乱したけど、systemctl
を利用しているのは「systemdで管理しているnginx serviceをsystemctl
で再起動する」ということ。linuxの知識が薄い自分にとっては、systemctl
の正体を知るキッカケになった。
Unit
systemdはUnit
と呼ばれる単位で処理を分けているといったが、このUnit
もいくつか種類がある。service
, swap
, target
’, device
, mount
が主な種類。特にwebサービスを触っているエンジニアなら、Service Unitを触る機会が多いはずで、linuxシステム上で管理している各種サービスはだいたいここに属するはず。
Unit
の実態になる設定ファイル(Unitファイルと呼んだりする)は、/etc/systemd/system
以下、もしくは/usr/lib/systemd/system
以下にxxxx.service
という拡張子で置かれている。ちなみにシステム起動時には、前者から後者の順で適用される。*1
実際にxxxx.service
ファイルの中身を見てみるとわかるのだが、そのサービスがインストールされたときの挙動や、systemctl restart
,systemctl reload
などのコマンドを送ったときの挙動が定義されていたりする。つまり、「systemctl hogefuga service
を叩くと、どういった挙動になるのか?」は、Unitファイルを参照すると色々なことがわかるというわけ。
Unitという概念で各種サービスを管理してて、どこに設定ファイルがあるのか?これを知れただけでも、個人的に非常に勉強になった。
最近、Consulを通してどういったserviceが動いていて、それらserviceはどういった設定になっているのかをxxxx.service
を見に行ったりする機会があり、ちょうど勉強した内容について触れられたのも良かった。多分、今後も役立ちそうな知識だ。
systemctlコマンド
man systemctl
すると色んなオプションやサブコマンドがあるけど、まあ自分レベルが実務で今すぐ使えそうなのはこのくらいかなと思う。
- systemctl start
- systemctl stop
- systemctl restart
- systemctl reload
- systemctl status
- systemctl is-active
- systemctl enable
- systemctl disable
- systemctl list-unit-files
is-active
はstatus
があるので、ほとんど使う機会がないかも知れない。
enable
,diable
は実際に叩いてみるとわかるのだけど、起動しているTarget
配下にシンボリックリンクを作る or 削除することで、次回のシステム起動時に指定したserviceを自動起動するのかどうかを設定できる。
Target
は、Unitの種類の一つで、複数Unitをグループ化してくれる。主にmulti-user.target
やrescue.target
などのターゲットに分けられ、これをsystemdの起動時に最初に読み込む/etc/systemd/system/default.target
へシンボリックリンクを貼れば、linux起動時に指定のtarget
(ランレベル)を指定して、グルーピングされたUnitも順次起動するという仕組み。つまり、システム起動時にどんなサービスが自動起動するのだろう?というのを知りたければ、目当てのtarget
の設定ファイルとディレクトリを見に行けば良い。
list-unit-files
は知らなかったのだけど、unitを一覧で見れて、覚えておくと使い所はありそうな感じ。
systemd-journald
systemdのプロセスには主に
- メインプロセスである`systemd``
- ログを管理するプロセス
systemd-journald
- ログイン処理プロセス
systemd-logind
- デバイスの検知プロセス
systemd-udevd
などが存在する。
この中で特に実務で使いそうなのが、ログを管理するsystemd-journald
だと思う。サービスが予期せぬ事で停止してしまった時や不具合が起きた時にログを確認して、原因究明に役立てる。実際、このプロセスに対して指示を出すのは、systemctl
と同じようにjournalctl
というのがあり、それを使う。lpic101 level1ではよく出る題目ではないが、journalctl -xe
とか、journalctl -u xxxx.service
などを叩く機会は多いかと思う。
自分も実務で「start叩いてるのに、なんかミドルウェアが起動しない!!」という場面があったりした時にお世話になった。各種サービスのログは、主にjournald
プロセスで管理していて、journalctl
で見たりできることを覚えていれば、システム不具合等の時の調査で役立てられるはずだ。
———————
systemdは結構前からあるシステムで、ググったりすると私、systemd嫌いみたいなタイトルの記事も出てきたりで、良きところもあれば悪いところもあるらしい。でも、linux初学者の自分にとってLinuxシステムがどういった仕組みで動いているのかの基本的な内容を知れたのは、めちゃくちゃ良かった。
次はunixコマンドを辺りで、実務で役立ちそうな内容をまとめたいと思う。
LPIC Level1 101に合格しました
先月下旬頃にLPIC Level 1 101試験*1を受けて、無事合格できました!!
LPIC 101受かった!!ほっ…(*´-`) pic.twitter.com/slepWCDBbX
— kamelo151515 (@kamelo151515) May 26, 2019
なんで試験を受けたのか?
web系のサーバーサイドエンジニアだったら、サービスが動くLinuxサーバーを触る機会は結構あるかなと思う。実際、自分も業務でLinuxサーバーにsshしたりして、コマンドを叩いたり、メモリやプロセスを見たりしている。
ただこの辺りの知識に関して、いままではhistory
コマンドを見たり、詳しい人に教えてもらったりして、矢継ぎ早に知識をインプットしてたので、土台がしっかりしていない感があっていまいち自信を持てない感じであった。また、Linuxサーバーはどういう風に動作するとか、各ディレクトリはどういう役割があるとか、普段触る機会が少ないコマンドはどうやって使うのか、、、、疑問は多く、知識不足感を感じていた。
で、もう少し知識を深めて、業務に活かせないかなぁと思ったのがきっかけ。
試験を受けるまで
2〜3月頃から参考書籍(巷では小豆本とか呼ばれてるらしい)を買って、合間を縫ってちょこちょこ読んだ。また、いろいろ合格体験記などを見てみると、「参考書を読むだけでは合格は難しい。ping-tで過去問も解くといいよ!」とあったので、書籍を一通り読み終えた後はpint-gに登録して過去問・コマ問と呼ばれる問題集をひたすら解いて、知識の定着化を図った。
確かに、参考書を読むだけでは全然駄目で、参考書の内容を応用したりした問題が多く、最初は過去問を解いてもひどい正答率だった。でも、何度も解いていくうちに当たり前だけど正答率も上がっていき、試験前には正答率が常時8割になるくらいになる。
(ping-tは問題を2回連続正解すれば金、直前に1回なら銀、一度も解いたことないor間違えていたら銅のメダルが付く。以下のような感じで金メダルが増えれば、そろそろ試験の受け時かなと思う。)
実際、試験を受けてみて...
- 選択問題以外に、コマンドを入力する問題が出題されるのだけど、これが自分が思ったよりも出題された。多分全体の6/1くらい。
- 問題の日本語訳が怪しいときがあると聞いていたが、これはホントで訳が分かりづらい問題が出たりした。英原文も見れるのでそちらを確認が必須で英語力も少し必要だな〜と感じた。
- まあ、試験問題なので当たり前なのだけど、めちゃくちゃ似ているコマンドを選択する問題など、ちょっと厭らしい問題な〜と感じる多い印象だった。いや、試験だから当たり前なんだけど。騙されないように丁寧に問題文や選択肢を読んだ。
結果は600/800点。大体7割ちょい。できれば8割行きたかったな〜と。
あと、反省点としては選択問題以外に、コマンドを実際に入力する問題をもっと解いておけば、より知識が定着してたし、問題も自信を持って解けたな〜と感じている。
久しぶりに大学の試験みたいな勉強をしたので疲れたけど、資格という目に見える形で結果が残ったので、合格したときは普通に嬉しかった。
ただ自分の会社の等級だと受験金の補助が出ないという悲しい事があった。自分が補助を受けられるのはLevel2から。さっさと、次の102試験も受けてLevel1をシュッと取り、Level2もシュシュッと取っていきたいな〜と思う。
がんばります。
*1:LPICから独立して最近LinuCと言われる別の試験ができたらしい。LPICの試験問題の情報漏えい問題や各国で利用されるLinuxディストリビューションにも差異があるため日本市場に合わせることを考慮したのがLinuCらしいが、世界的にも利用されているLinuxの知識から、わざわざ独立して国内でよく利用している知識に閉じるような動きがよくわからないし、スポンサーとかを見てももどうも自分が関わっているweb業界とは離れた市場を標準にしていて違和感があった。まあ、Linuxの関する基礎知識をつけるのが目的なので、両者でそこまで内容に差異はないだろうし、上記の懸念もあったので、LPICを受けることにした。
rubykaigi 3日目 感想
下書き状態で、公開するのを忘れていた。。。いまさらopend。
Reducing ActiveRecord memory consumption using Apache Arrow
- apache arrowというデータ処理系のツールや機能を多言語で共有して使えるする取り組みに期待
- ARをapache arrowに最適化するために、ARのオブジェクトの中身(
ActiveRecord::result
)をapache arrowを扱えるオブジェクトに置き換えれる。 - 行志向ではなく列志向のオブジェクトになれば、データ操作が早くなる。(
raw-majoar
vscolumn-majoar
)。縦方向の検索に早くなるということ。
The future of the Bundled Bundler with RubyGems
- まず、言語を入れたセットアップ完了ということで、bundlerを辞めたいという話
- 改めて2FAなどの推奨
- rubygem3は古いrubyのサポートを切って、色々と新機能が追加された。bundler2も同じ感じ。また古いrubyのサポートを切ったのでrubybuildの時間もすごく短縮された(いずれにしても長いけど)
- bundlerのテスト ⇛ make test-bundler
- Rspecの本体もruby本体に入れられる????!!!!革命。今まではmini-testとかであったけど、Rspecも入れられるのはすごすぎる
- rdoc-6.0.4のエラー、、、見たことある気がする。
- bundlerがないよ!って言ってたのが、
Update BundlerVerionFinder
が機能として追加されたので、その機構がエラーを吐いていた - dependencyリゾルバといsてmonillio???みたいなのがある。bundler,rubygemでも使われている。
- rubygem3(鋭意パッチを募集中)
- gelうまく親和性を保っていければ...。
The challenges behind Ruby type checking
gem install steep
- duck typingについて、どういったインターフェイスを呼び出すとプログラムが暗黙的に想定され、どういったオブジェクトを呼び出すのかも暗黙的に想定されるといってもいいかも
- eval, define_method, ARのhas_manyとかもメタプロといえる。色々メタプロが活用されている物がある。
- Rubyへの型定義
rbi
について聞いた感じ、いままでのRubyのコードと全く同じような書き方としては捉えないほうがいいかも知れない。 ruby <--> signature。- sorbetのセッション聞いてないから、その辺りとの兼ね合いを聞きたいな。
- rubyのprivateMethodってmixinでアクセス出来てしまうので、その辺りも型シグネチャで確認することができるようになっている。privateMethodの型定義をするかどうかは開発者に委ねられる。
Cleaning up a huge ruby application
巨大なRailsアプリケーション Cookpadのコアコードが肥大化しているので、いらないコードは削除しようというプロジェクトとそれに伴って作ったツールのお話。
KitchenCleaner
というセンスありまくりのツールで、定期的に未使用のコードが無いかどうかを検知して、疑わしいコードがあればtachikomaみたいにissueを立ててくれる。
実際に使われていないコード検知については、iseqlogger
を使いRubyVMがRubyコードを解釈したときに出力されるiseq(instruction sequence)
を見て、その結果をログインしているらしい。ログ情報はfluentd
に送って、最終的にredshift
に溜め込んでいる模様。
ただ、このiseq
を見る方法だと良くない部分はあるので、より綿密に見れるoneshot coverage
といった方法でも実行されたコードを見たりする。
- コード削除では既知と既知でないものもあり、今回は既知でないコード削除を対象。やはり、コストが高い作業で、本当に消して良いコードなのかを調査しなければいけない。これがなかなか不要なコードを削除できない理由の一つとも言える。
- またどうしても優先順位が低いというのも、なかなか取り組めない理由の一つと言える。まあ、優先度を上げる提案をしないといけない。耳が痛い。priorityを他のタスクとも兼ね合って考える。
- 未使用のテンプレートなどを探すのは向いていそうだけど、if文などの細かいところは検知がちょっと曖昧感があって、そういったところは実際にコードを見に行って判断しないと行けなそう
- 今度はoneshot coverageという方法で、一度でも実行されたコード行を見てくれる。
ケースバイケースでコードカバレッジの精度が変わるので、うまく使い分けてる
alias_method?
rubykaigi 2日目 感想
昨日のAfterPartyの疲れもあったのか、正直眠かったけど、なんとか最初のセッションからこれ
All bugfixes are incompatibilities
これまでのBugfixの経験談を主に語ってもらい、普段Rubyコミッターやメンテナーがどうやってお仕事してるのか知れて楽しかった)これを聞いて思ったけど、redmineの動向とか追っておけば、来年のRubyKaigiとかで同じようなセッションあったときに「あ〜あの話ね〜」ってなって面白そう)。
初日にMatzも言っていたが、既存のRubyコードが壊れないことを考慮して互換性や名前を非常に考えながら取り組んでいて、感謝の気持ちしか起きなかった。こういったメンテナンスポリシーとは逆に破壊的な変更を許容してどんどんアップデートしていくと、進化は早くなるかもしれないが、こういったポリシーのほうが僕ら利用させてもらう立場的に本当に感謝しか無い(IO.read
、File.read
でブロック変数の最初にパイプ渡したらそれ以降に記述したコマンドを実行してしまう話を禁止するか、互換性を保つためにwarningを喚起するだけにとどまるかの議論も、聞いてて楽しかった)。
parse.y
は魔境
better csv processing with ruby 2.6
終始、漫才感のある発表で、内容ともに楽しかった!
csvのパース、エクスポートを高速化した話が主。
「CSV,generate_line
vs CSV#<<
」の話では、複数行書き出す時は<<
を使うと、10倍も早くなっちゃうのよ〜〜すご〜〜〜い(each_line
が最速のパース方法らしいけど、クオートがあるとうまく出来ないという制約があるらしい)。
どうやって、これらの高速化出来たのかという話についても、Rubyのコア部分の話になるのかなと思って身構えたが、そんなことはなくて、普段僕レベルでも知っているメソッドのたちが登場した。
例えば、複雑なクオートを利用しているcsvだとsplit
を使うと遅くなってしまうらしいので、StringScanner(.scan)
を利用したらしく、split
使うと遅くなるし、コードも汚くなるけど、scan
ならコードきれいになりやすくて、メンテナンスしやすいし、性能が劣化がないというメリットを説明してくれて、なるほど〜となった。
ただ逆に、複雑なクオートではなく、単純なクオートを使ったcsvだと、StringScanner
では遅くなってしまうらしく、そっちはsplit
を利用していた。ケースバイケースで使い分けてる。
他にも、CSVオブジェクトを作成するタイミングを遅延化(lazy
)して、毎回オブジェクトを初期化する無駄を省いて高速化したという話もあった。これも、僕らが普段使うような@a ||= object
みたいなコードが出てきて、ふむふむってなれた。
今後もこれらの高速化に取り組むらしくが、まだutf-8
などへの文字エンコーディングの速度が問題らしく、これが今後の主な課題らしい。
お手頃なKEN.CSV
みたいなcsvを、どっかから取ってきてcsvいじってみたくなった。
メモ
quate_char:
オプションparse_column_value
liberal_parsing
オプションbackslash
オプションstrip
オプションgem install csv
でとりあえず早い方の使えるぜ!RedDataTools
の取組の一環
Ovto: Frontend web framework for Rubyists
「自給自足プログラミング」これ好き。
OvtoというHyperApp
というJS製のFWに強く影響してて、更にOpal
によってRubyでフロントエンドもかけちゃうフロントエンドフレームワークを紹介してもらった。単純に楽しそう。
普段、VueとかReactは趣味で触っていたので、VirtualDOMやReduxは知っていたが、その辺りの基礎的な説明から入ってくれて、それらを機能が使えるHyperapp
について紹介から始まった。その後、Rubyからjsコードを生成してくれるOpal
も紹介してもらい、その後それらを使った表題のFWの説明とデモを見せてくれた。
jsは嫌いじゃないけど、普段使っているrubyでフロントも書きたい...無いから、作った...まさに自給自足プログラミングを体現していた。本当楽しそう。
早速触ってみました。東京帰ったら、もっと弄ってみようっと。
#rubykaigi さっそくovtoで遊んでみる 🐙 pic.twitter.com/WD4DyWxYHK
— kamelo151515 (@kamelo151515) April 19, 2019
メモ
runtime.rb
: OvtoApp -> ovtoが変換 -> JS(VirtualDOM -> hyperappcoreに送る。アプリ側の処理が重くない限り、ある程度の速度は担保できる?wired_actions.rb
???You might not need redux
- SSR, routeも欲しいという話がでたら、作る予定。
The fastest way to bootstrap Ruby on Rails
uzuraさんのセッション。
CRIU
は初めて聞いたし興味津々だった。linuxのプロセス情報をimageでdumpしてくれるらしく、dumpしたimageは別ホストでrestoreすれば、同じコンテナを簡単にマイグレーションできる優れものらしい。
また、CRIU
を利用することで、例えばモノリシックで大きなRailsアプリケーションとかでも、linuxのプロセス初期化をうまいことスキップしてくれるので、その初期化分の時間をreduceできて、結果的にbootstrap処理時間が早くなるというものだった。また、一つのホスト上のコンテナが死んでも、自動で別ホストでリスタートしてアクセスもそっちに流すようこともしてくれる。コンテナスケールアウトのコストも削減。
ほえ〜と思いながらここまで聞いていたが、ここからが本題で。
これらはコンテナ環境で利用できるが、VM環境をサポートしたものが無いので、同じようにmigration,checkpoint,restore
を実現するGrenadine
を紹介していただいた。
英語もわかりやすかったし、Grenadine
触ってみたい!ってなったけど、正直コンテナとか園周辺の知識というが個人的に乏しかったので、こういった機能とかワードがあるんだな〜というのも知れてよかった。dockerにも既にcheckpointの機能は既にあるらしいのだが、まだまだ出たばかりということもあり、Grenadine
を作るきっかけにももなったらしい。作ってしまうのですごい。。。
CloudNativeバンザイ!!!!
Benchmarking your code, inside and out
いままで聞いたセッションとは毛色が違う内容だった。。。と思う、、、英語リスニング力が弱くてわからなかった...。
多分、Micro benchmarking
に関する取り組みとか、rally
などを利用した計測のベストプラクティスとか話してくれたのかな...。くっ...、英語リスニング力付けたい
最後のLT大会も楽しかった〜〜〜。。。。明日は最終日....あっという間だ。
rubykaigi 1日目 感想
「鉄は暑いうちに打て」ってよく言うし、忘れないうちに今日受けたセッションの感想とか思ったことを自分なりに書き残しておく。 (間違ってる!とか補足情報とかあればコメント欲しい :pray:)
Matz session
内容は大別するとパフォーマンス、Static Typing、Concurrency、あとちょっとだけ2.7や3.0の新機能の話をしてくれた。
世の中の言語進化のトレンドはStatic Typing
あまり多言語は詳しくないが、PHPだったらtype hinting
、pythonだったらtype annotation
、jsだったらtypescript
といった元々は動的型付けなプログラミング言語にも静的型付け
と同様の機能を後付で付与するリリースが頻発していて、Rubyでもそれらの導入が検討されているらしいという話。
個人的には多いに賛成だし、開発していて型を指定できる安心感を得られるな〜という気持ちになるのだけど、Matz自身は「型を指定するというのは、機会に余計な指示をしているようで、DRYではないので、正直あまり導入はしたくない」と嘆いてた。この考え方について「なるほどな〜」と思いつつ、でも実際のRubyを使う開発者サイドとしては「うーむ、それでもサポートしてくれないかな〜」という気持ちが正直なところではある。今後の動向に注目したい。
この機能をサポートする技術は色々検討はされているらしく、なんかeslint
のlineチェックを明示的に外すコメントアウトみたいに、rubyコードの右に型の指定を記述したコメントアウトみたいなのを追加するとか、rbi
ファイルみたいな別の型情報を持ったファイルを用意するとか、はたまた真新しいことをしなくてもサポートしようとしていたりとか、sorbet
or steep
とかをつかってtype checkするとか、、、、色々紹介してくれた。
(余談だけど、Matzの「テスト角の嫌いなんですよ。僕らはプログラムを書きたいわけで、テストを書きたいわけではない。でも人類は正常なプログラムを書けないので仕方なくテストを書いている。」って説明がなんか良かったし、ほっこりした。)
後は、よくテーマになるPerformanceの話
RubyコンパイラとしてJITとかMJITという言葉は聞いたことあるけど、Rubyって2.6は昔の2.0よりも実行速度が2.8倍も早くなったいたらしい。ただ、Railsなどのフレームワークをかますと何故か処理速度が遅くなってしまうらしい。。。この辺り、正直「なんで?」ってなってよくわからないのだけど、この辺りの疑問をもう少し自分たちなりに深掘りして調査してみると、実務でRailsサービスの速度を早く出来たりするのかな〜と逆に興味が湧いた。
あと、そういったコンパイラの実行速度改善以外に、パフォーマンス改善の手段として並列性(Concurrecy
)の話も出てきた(どうでもいいけど、Falcon
使ったことも触ったこともない)。
話によると、RubyはElixir
などの並列処理してもそれぞれのプロセスがデータを共有しない(Shared Nothing
)ような設計になっていないので、その問題を解決しないといけないらしかった。で、この問題を解決してくれるのがGuild
というものらしく、Goのgorouting
、Elixirのprocesss
のようにShared Nothing
を実現してくれるらしい。この辺りも今後の動向に注目したい(この話を聞いた後、スポンサーブースの同人誌コーナーにあった並列処理大全
って書籍がめっちゃ気になって買いたくなってしまった)。あと、Guild
って名前がゲーム業界から予約語として指摘されたのおもろかった。
あと、諸々気になったワードをメモ
- Deep Fronzen Object
?
Literal wwwwww- メソッドオブジェクトを取り出す???
Proc.curry
::
でメソッド呼び出しができるの知らんかった- Ruby Pattern Matching
keyword extension
あと、とにかく、RubyGemsアカウントは乗っ取られないように、2段階認証やパスワード共有禁止などして、みんなで安全な世界をRuby世界を作りましょう!って気持ちになった。
How to use OpenAPI3 for API development
実務で使えそうなお話かな〜と思い聞きに行った。そもそも知らなかったのが、Swagger
とかOpenAPI
とか名前が自分の中で混在してたのだけど、「あ、一緒なんだ」、、、という感じの僕みたいな知識レベルでもわかりやすかった。
OpenAPIなどのこういったJSONスキーマを定義しておくツール?は、あくまでjson
やyml
でリクエスト・レスポンスのルール書いて、それに基づいてフロント・バックエンド・アプリなどの多方面のプラットフォームがそれを念頭に開発するというメリット持ったルールになる。なので、これ自体が実装するプログラミング処理に直接関わるというのはちょっと違う(あんまりJSONスキーマを定義してから、開発するという経験が薄いので、改めてメリットを知れてよかった。ちなみこういったschema first development
と言ったりする)。
そして、更にそれらルールをmachine readable
にすることで、色々とメリットはある模様。そのmachine readble
なメリットを持っているのでOpenAPI3
らしい(json hyper schema
, graphq
、gRPC
なども類似としてあるけど、それぞれ違いやメリデリはある。)
OpenAPI3
は幾つかStructureがあって、紹介してたSecurity Object schema
は、Oauth2とかベーシック認証などもぱっとymlに書くだけでいいのが良かった。(別に定義したからと言って、それがすぐ使えるようになるわけではないです。)
あと、リクエスト・レスポンスの両方をRack層でvalidationしてくれるcommittee gemも紹介してもらい、スキーマ通りの実装が出来ているかどうかを担保することができるんだな〜スゲ〜、ってなった。
~あと、openapi-parserみたいなどを使えば、ymlのネストをRubyで読み込むとオブジェクトが入れ子になってて見づらい問題を解決してくれるらしい。~
あと、諸々気になったワードなどをメモ
- openapi-parser
- json schema not equal json hyper schema
- openapi-generator
- https://openapi.tools/
Pragmatic Monadic Programing in Ruby
日本語だったのに、1日目で一番「僕の知識では追いつけない...うまく咀嚼して理解できない...」と思ってしまった。有名なjokerさんのセッションだったのと、モナド
という未だによく理解していない概念を知れるきっかけになればいいと思って聞いたが、僕にはまだ早かった...。
話の流れ的には、AST実装を例に、関数型言語にある概念?の一つにあるモナド
的な動きをする処理をRubyで黒魔術を使って書いてみたという話...と解釈したけど、あってるかな...。
https://rubykaigi.org/2019/presentations/joker1007.html#apr18
とにかく、覚えて帰ったのが、「monad はある法則に基づいて動く flatMap
」
あと、諸々気になったワードなどをメモ
- Fanctor
- Applicative fanctor
- bind operator
>>=
- moand 計算チェーン??
RubyVM::AST.of
Ruby for NLP
自然言語処理でよく出るMeCabもあるけど、RubyでもNLP(Natural Language Processing
)できるやで!っていうのを形態素解析の基礎から説明してくれたセッション。大学生の時ニューラルネットワークやら自然言語処理やらをちんぷんかんぷん状態で聞いていて、まったく知識がない状態だったけど、めっちゃわかりやすい説明で良かった。最後のDemoをもっと見たかった...。
資料が挙がったら、発表の最後の方に紹介してもらった、RubyでNLPを実現するためのツール群を調べて、色々遊んでみたい!
A Bundle of Joy: Rewriting for Performance
bundle install
,bundle exec xxx
、、、bundler遅いから新しく書き直して、gel
というgem manager作ったよ!というお話だった。
実行速度を紹介してもらったが、installやらrmやら諸々のbundlerの実行コマンドがgelに置き換わっただけで、半分以上も短縮されてて、「とにかく、やばそう!!!!1」ってなった。
この辺り、どうやって実現していたのか、英語力が足りなくて悔しかった。bundler
からRubyGems
に完全移行する話も最初のセッションで柴田さんが言っていたけど、それらの動きと、このgem managerがどういった感じで関連してくるのかな〜というのも気になった。
気になるワードやらURLやら
Pattern matching - New feature in Ruby 2.7
Ruby2.7から導入されるPattern Maching
機能について。
実用面ではjsonなどを受け取って、そのjsonパターンと一致した場合に何か処理をしたり、そのjsonの一部を変数に代入したりといった使い道が紹介されていて、早く使ってみたい!という気持ちになった。
Array,Hash,Value,String,...(後なんだっけ)などの、色々なパターンがあって、リリース時に是非ドキュメントを熟読して実務で活かせたらいいな。特に、Array patternのパターンマッチが色々説明があって、より複雑なパターンのマッチを処理したいときに有効そう。ネストした配列、マッチしたパターンの一部を取得?...etcなど、すげー!ってなったけど、ドキュメントを見て改めて整理した。
ref: https://speakerdeck.com/k_tsj/pattern-matching-new-feature-in-ruby-2-dot-7
After Party 最高でした!!!!1明日も楽しみ!!!!1
Nuxt.jsを初めて触った
3連休最後は公式のドキュメントを見ながらNuxt.jsで遊んだ。
yarnもしくはnpxを使ってちゃちゃっとプロジェクトの土台を作れて、始めるのはとても楽だった。 ちょい概念として予習したほうが良さそうなのが、Flux。Actionとかdispatcherとか、データをstoreに置いてviewに反映さえるとか、Fluxアーキテクチャのフローは先に知っておくと良さそう。
ちゃっと作って。。。
わーーい。すぐに画面ができた。
使ってみて
最初に触ってみて思ったのが、ファイル構造がわかりやすいということ。それぞれが何の役割を持っていて、何をするのか?をパッとディレクトリ構造を見ればわかるし、細かい設定はだいたいnuxt.config.js
を見ればわかる。
Vueを勉強し始めた時は、以下のVue.js入門を読みながら進めたのだけど、Nuxt.jsを触りながらのほうがより実践的にVue.jsの知識を習得しやすかったかな〜とか思ったりもした。
先程、ファイル構造がわかりやすいと言ったように、ルーティングごとにpages
配下にvueファイルを置けばnuxtがファイルを読んでいって対応したルーティングを作ってくれる。基本的にRailsみたいにconfig/route.rb
とか作らなくて良い。動的にルーティングも_show.vue
みたいにアンスコを頭に入れれば出来る。
pages
以外にも、layouts
, middlewares
, plugins
, modules
, components
, static
, store
といったディレクトリがある。
layouts
は想像の通りデフォルトのレイアウトテンプレートを置くところ。エラーのレイアウトのテンプレートも用意しておけば、エラー時にNuxtが良しなにエラーの方のテンプレートを呼び出してくれる。
statics
はその名の通り静的ファイルを置いておくディレクトリなんだけど、webpackで扱うパターンと、単に置いておいて管理するパターンの両方が出来る。
middlewares
はルーティング前に制御したい処理を書いておく。
外部プラグインなどはplugins
に置いていき、VueのインスタンスやVueストアにInjection(注入)して使うことが可能。
modules
はNuxt.jsのコアをどんどん拡張していくことが出来る。多分、もっとサービスの機能を増やしていくとなると、このあたりのディレクトリをいじっていくことになるのかなと思う。
store
(VuexStore)についてはクラシックモードとモジュールモードの2つがある。サーバサイドから初期値などを取得したい時はnuxtServerInit
とかに処理を書くと良さそう。
nuxt.config.jsが肥大化していきそうな予感
初めて触ってみて、middlewareやpluginを読み込んだり、ヘッダー情報を書き込んだり、グローバルなcssを読み込んだり、環境ごとのビルドを設定したりと、いろんなことを設定できるコアのファイルとしてnuxt.config.js
ってのがあって、これがプロジェクトルートに置いてある。
結構これの設定が重要で、アプリーケーションが大きなるに連れて、このconfigファイルを大きくなりそう。。。