EExでタグをエスケープする場合には%を重ねる

koseki.hatenablog.com

こちらを見てピンときたので、Elixirの EEx でも確認した所同様にできるのでメモ。

foo <%= bar %>

例えば、これをそのまま出力したい場合。

iex(1)> EEx.eval_string("foo <%%= bar %>")
"foo <%= bar %>"
iex(2)> EEx.eval_string("foo <%%= bar %>", [bar: "piyo"])
"foo <%= bar %>"

エスケープした場合第二引数の bindings に bar をアサインしようとしてもそのまま出力される。

<% %> についてもそのまま出力したい場合は前方の % を2つ重ねればよい。

foo <% bar %>

iex(3)> EEx.eval_string("foo <%% bar %>")
"foo <% bar %>"

後方の % だけ2つ重ねるとエラーが出るので要注意。

iex(3)> EEx.eval_string("foo <% bar %%>")
** (TokenMissingError) nofile:1: syntax error: expression is incomplete
    lib/eex/compiler.ex:45: EEx.Compiler.generate_buffer/4
    lib/eex.ex:196: EEx.eval_string/3
    (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6
    (iex) lib/iex/evaluator.ex:245: IEx.Evaluator.handle_eval/5
    (iex) lib/iex/evaluator.ex:225: IEx.Evaluator.do_eval/3
    (iex) lib/iex/evaluator.ex:203: IEx.Evaluator.eval/3

両方の % を重ねると、後半だけ重ねた状態でそのまま出力される。これを利用することはないとは思うが、挙動だけ覚えておいたほうが良さそう。

iex(4)> EEx.eval_string("foo <%% bar %%>")
"foo <% bar %%>"

プログラミングElixir

github flowで便利なgitコマンドまとめ

業務中に便利ツールを作った際に、git commandを駆使していろいろな情報を取る機会があったのでまとめておく。

git diff

$ git diff master development --name-only

masterブランチとdevelopmentブランチで差分のあるファイルをファイル名だけ表示できる。

git log

$ git log --reverse --merges --oneline --ancestry-path ${commit_hash}...development

developmentブランチがfeatureブランチになっていたケースで、developmentブランチに向けてpull requestが送られていた場合のmerge commitを表示できる。

When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), only display commits that exist directly on the ancestry chain between the commit1 and commit2, i.e. commits that are both descendants of commit1, and ancestors of commit2.

gitの 公式ドキュメント にもあるように、--ancestry-path で、${commit_hash} からdevelopmentブランチの間で、developmentの祖先になっていて、かつ ${commit_hash} の子孫になっているコミットを取得できる。 --merges でmerge commitに絞り込んでいるので、下記のようなリストが取得できる。

abcdef Merge pull request #XXXX from work/hoge_branch
123456 Merge remote-tracking branch 'origin/development' into huga_branch

Githubのpull requestからマージされた場合は、上記のように Merge pull request #XXXX from というcommit messageが表示されるので、ここに grep をかけるとGithubのmerge commitだけを絞り込める。

git log --reverse --no-merges --pretty=format:%h master...development

developmentブランチにあって、masterブランチにないcommitのうち、merge commitでない( = --no-merges )ものだけをcommitの古い順に表示できる。これの先頭を取得することで、「masterブランチからdevelopmentブランチが切られた後、最初にdevelopmentブランチに入った開発中のcommit」を取得することができる。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

統計検定2級に受かったのでやったことを全部書く

1ヶ月ほど前の6月17日に、 統計検定2級 を受けてきた。

自己採点で34問中31問正解だったので、マークミスさえなけりゃ大丈夫と踏んでいたが、昨日試験結果の通知が書面で届き、無事合格確定となった。

ありがたいことに、最優秀成績賞なるものも合わせて頂いた。賞状をもらうのも学生時代以来で、承認欲求を満たせて良い。たまに資格試験を受けるのもよいのかもしれない笑

極めて優秀な成績を修めた受験者にＳ、特に優秀な成績を修めた受験者にＡの評価を与えました。

とあり、受験番号と照らし合わせて確認したところ今回頂いた表彰状はS評価らしい。

受験データ を見る限りだと、1532人の受験者の中669人が合格で、自分と同様にS評価を受けたのは31人(Web合格発表希望者のみ)とのことだった。 S評価を受けた総数(Web合格発表希望者以外も含めた)を50人と見積もると、統計検定は100点満点で採点されているとの情報をチラッと見かけたので、概ね90点ないし80点後半を獲得した受験者が対象になりそうという推測ができる。

ロードバイク遠征中にスクーターとぶつかってリアディレイラーが壊れた話

毎年この時期はロードバイクで長距離を泊りがけで走ることにしている。去年国道4号経由で仙台まで 走破した ので、その続きとして今年の遠征旅行は仙台〜青森の青い森公園(国道4号起点)まで約370km程度を走ることにしていた。日程としては4/30から4日間を予定していた。

しかしながら、合計320km前後を走ったあたりの交差点で事件発生。 国道4号沿いを直進していたのだが、交差点に差し掛かったあたりで、スクーターに乗った高齢の女性が横からそのまま直進してきたのだ。こちら側はスクーターが右折してくるだろうという憶測で走行していたという確認不足と、スクーター側もこちらが停車するであろうという確認不足が重なり、そのまま衝突。

左側にロードバイク、右側にスクーターという構図での接触となり避けきれずお互いに左側に倒れ込むという事故になってしまった。幸いお互いに20km/h程度のスピードしか出していなかったので大事故には至らず、特段怪我もなかったが、ロードバイクの後輪のあたりにスクーターが折り重なるようにして倒れたため、後輪のホイールや変速周りにダメージを受けた。

転倒後に相手側から「あんたが悪いんじゃ」という言葉をかけられ頭が真っ白になってしまったこともあり、転倒直後に目視で確認した範囲ではロードバイクに大きな損傷が見られなかったことからその場で警察を呼ぶという考えにも至らず、そうこうしているうちに相手側のスクーターはそのまま走り去ってしまった。

その後一人になってから改めて後輪のあたりを確認すると、ホイールの回転にブレがあったこと以外に損傷は見られなかったため、ブレーキシューを緩めつつそのまま走行を続行しようとサドルにまたがり変速を変えようとした瞬間、「バキッガリガリガリ！」という音とともに前進できなくなった。

恐る恐る確認すると、リアディレイラーごとポッキリと折れてしまい完全に見たことのない愛車の姿がそこにあった。その瞬間自分の心も折れてしまい走行を続行する気にはならず、あえなく断念となった。後々調べてみると、リアディレイラーを使わずシングルギア化し、無理やり走行を続行するという選択も出来たといえば出来たが、そこまでは頭が回らなかった。

そこからは自転車をたたみ、最寄りの駅が2kmほどの距離にあったのでそこから電車で青森駅まで向かった。青森駅の駅前に交番があったので一応事故について申告をし聞き取り調査を受けた後、そのまま何も観光する気も起きず新青森駅から新幹線で帰途に着いたのであった。

車内でぼーっと考えてみると、計画段階での準備不足とトラブル対応力の不足が事故に繋がったなぁという感想しかなかった。考えられる要因が3つあるので改めて振り返ってみる。

要因(1): 直前での行程変更

計画段階での行程は、下記のように4日間で370km程度を走りきるつもりだった。

• 1日目(4/30): 宮城県仙台市〜岩手県一関市(約90km)
• 2日目(5/1): 岩手県一関市〜岩手県盛岡市(約90km)
• 3日目(5/2): 岩手県盛岡市〜青森県十和田市(約120km)
• 4日目(5/3): 青森県十和田市〜青森県青森市(約70km)

しかしながら、3日目の夜から4日目にかけていわゆるメイストームによる荒天が予想されていた。直前まで天気が微妙に変わり続けていたので、1日目を走り終えた段階で2日目以降の行程を決めるという状況に陥っていた。

一関の宿で1時間ほど必死にこの後走行する地点の天気予報を確認したところ、どうやら5/1までは天候がもちこたえ、5/2の夕方までに青森市に着けばそこまで荒れた天気の中走行せずに済むということがわかった。

このため、急遽下記のような行程に変更した。

• 1日目(4/30): 宮城県仙台市〜岩手県一関市(約90km)
• 2日目(5/1): 岩手県一関市〜青森県十和田市(約210km)
• 3日目(5/2): 青森県十和田市〜青森県青森市(約70km)
• 4日目(5/3): 青森市で観光してから帰る

2日目に2日に分けて走ろうと思っていた距離を一気に詰めるというものである。長時間の走行が必要になったため、2日目は朝の4時に起床、4時半にチェックアウトし5時に開始し20時半まで走り続けるという過酷な旅になってしまった。

また日没後の走行区間が山道に入っており、街灯がほぼなかったため、自身のフロントライトと並走する車のヘッドライトだけが路面の状況を確認する手段という非常に厳しいライドを強いられた。

これにより、3日目は出発直後からかなりの疲労が蓄積された状況で、瞬発的な判断力が落ちていたというのが実情だった。

こうならないためにも、旅行の日程をある程度前後にスライド出来るように宿を予約しておいて、天気の状況を見つつ最善の日程を選択するというのも一つの改善方法だったのかと思う。

要因(2): 予想以上に路面が悪路だった

去年の東京〜仙台間の国道4号とは対照的に、仙台〜青森間の国道4号はロードバイクにとって非常に走りづらい環境であった。それは路肩のひび割れが大変多く、また歩道も砂利や落下物が散乱していたため、「どっちを走っても辛い」「どちらかというと酷くない道を選ぶしかない」という状況が続いた。

いろいろ調べていくと、降雪後の道路上での雪解けが影響するとのことだった。

tenki.jp

時期的な問題なのかもしれないが、道路の補修が終わる頃を狙って走ったほうが良かった可能性がある。

要因(3): 2日目にもトラブルが起きていた

要因(2) で書いた悪路の影響で、実は2日目の盛岡付近を走行中に後輪が釘を踏みつけパンクしてしまった。自宅でのチューブの交換作業は経験があったものの、出先で限られた機材を使ってのパンク修理の経験がなかったため、復旧作業に非常に手間取った。

まず自身での復旧作業をその場で試みた。予備のチューブは2本持っており、そのうちの1本は保管方法が悪く既に穴が空いた状態になっていたが、気づくのがかなり遅くなってしまった。それを使って最初復旧を試みようとCO2ボンベで空気を入れていたが当然空気は入り切らず。

残りの1本は穴が空いていないことを確認してから空気を入れていると、今度は力の入れ方を誤り、携帯用空気入れを破損するという自体に陥ってしまった。このため自身での復旧作業は完全に詰みの状態となり、あえなく近場のサイクルショップに駆け込む羽目になった。

その場でチューブのみ交換をお願いし無事に走行を再開できたものの、釘で穴が空いた状態のタイヤに砂利かなにかが入りこんだのか、再びパンクが発生してしまい更に2軒目のサイクルショップでのタイヤごとの交換作業を余儀なくされてしまった。

このためパンクの発生〜完全復旧まで諸々合わせて3, 4時間も要してしまい（移動時間含む）、大変なタイムロスとなってしまった。要因(1) での行程変更も相まってこの後の走行は常に精神的にピリピリしたものになってしまい、楽しく走ることができなかった。

---

振り返ってみると、楽しいはずの遠征旅行が準備不足や経験不足によりただただ辛い移動をしただけに終わってしまった。

しかしながら、東北地方を移動中は多くの見知らぬ現地の方に励まされ、助けられてきたのでそれはすごく良かった。暗い話で終わるのも嫌なので、幾つかエピソードを上げてこのエントリを締めたいと思う。

• 急な訪問にも関わらず、スピーディーにパンク修理をしてくださったサイクルタテさん
• 2度目のパンク修理をしてくださったサイクルベースあさひさん
• いわて沼宮内でロングライドについて気さくに話してくれたおじいちゃん
• 岩手県岩手郡岩手町で背中を押してくださったおばあちゃん
• 接触事故を起こした後、駅まで送ってくださった近くにいた工事現場のおっちゃん

皆さん、本当にありがとうございました&助かりました。力不足で無事完走することはできませんでしたが、貴重な経験にはなりました。

---

追記 (2018/05/06 14:00加筆)

帰宅後にロードバイクを購入したサイクルショップに修理に出していて、先程見積もりの連絡が来て修理費用はざっと5万円弱とのこと。ちょっと高い勉強代と考えれば、必要経費かなと思う。

修理箇所は事前に自分で見ておいた部分で大体あっていて、フレームの損傷までは到達していなかったので良かった。

依存先のnode moduleの脆弱性がGithubから通知された

今朝方、github.comからメールでこんな通知が来た。

よく見ると、「あんたのrepositoryの依存moduleに脆弱性があったから、このバージョンに上げると良いよ」という旨の内容。

実際にリポジトリを見に行くとこのような注意を促すポップアップが出ていた。

hoek というnode moduleに対し、 CVE-2018-3728 の脆弱性が発生していたらしい。

hoek node module before 5.0.3 suffers from a Modification of Assumed-Immutable Data (MAID) vulnerability via 'merge' and 'applyToDefaults' functions, which allows a malicious user to modify the prototype of "Object" via proto, causing the addition or modification of an existing property that will exist on all objects.

merge と applyToDefaults の関数で、悪意のあるユーザーが任意のObjectを __proto__ 経由で操作できるようになってしまうというものだった。

github.com

ライブラリのcommitを辿ると今年の2/7には解消していたらしい。脆弱性情報データベース(NVD)を元に通知しているため、厳密には修正からNVDへの反映までの時間と、github.comのNVDのクロールまでの時間でタイムラグが発生してしまう。しかしながら、このように気づかなかった脆弱性にもきめ細かく対応できるので個人的にはありがたい機能だなと思った。

解消するとこのようにリポジトリから警告が消えたので一安心。