42 SILICON VALLEY Piscine 2017 match/nmatchを考える（番外編） 再帰の説明

このブログの読者は会社員と大学生が多く、どちらもいわゆるビジネス・アワーに訪れる人たちが多い。何かしらの問題に遭遇し、検索の結果、目的の投稿へ辿り着き、答えを見つけて帰っていくのだろう。
特定の記事は、ブックマークされることがあるかもしれない。繰り返し参照される記事だけはBounce rateが緩やかに上昇していく。

週末に投稿したmatch/nmatchが、このブログでは特異なアクセス傾向を示していることに気付いた。Avg. Time on Pageは当初4～5分前後だったものが、今日は後編が10分を超えた。
同時にBounce rateはどちらも9割近かったものが、昨日を境に後編だけ復帰した。


42関連の投稿は、これまでにない傾向を示している。おそらく勉強している人達が繰り返し訪れ、日、月曜日を境に前編を卒業して、後編へと前進したのではないかと解釈している。

私は読者に迎合するつもりはないのだが、熱意には応えたいと思う。要はお節介だ。
match/nmatchで詰まっている人の原因は再帰の理解にあるのではないかと考えている。今回はmatch/nmatchの話題に関連し、再帰を説明してみようと思う。
今回の問題はPiscineの問題ではなく、独自のものだ。あくまでも再帰の説明に焦点を絞っている。

光回線が不通になったとき 確認、そしてバックアップ回線としてのプリペイドSIM

実質2日間、光回線の不通を経験した。その間のインターネットも断たれてしまった。原因はマンション共用部結線の経年劣化。対応作業そのものは迅速であったものの、NTT職員の訪問までには2日間を要した。経緯はこのような感じだった。

Day 0 障害発生日	午後に障害発生、NTTへ連絡。 点検訪問は明後日になると告げられる。 半日以上のインターネット不通
Day 1 障害発生翌日	終日インターネット不通
Day 2 障害発生明後日	午前中一杯、インターネット不通 正午に点検開始。障害回復。

今回は経年劣化によるもので、平時での対応だったため、回復までに数日間で済んだ。居住地によっては、さらに日数を要するところもあるだろうし、台風などの災害時であれば不通期間はさらに伸びるリスクもある。

障害確認から連絡までの流れ、必要な場合に個人でできる事前対策の一案として、プリペイドSIMの活用をまとめた。

42 SILICON VALLEY Piscine 2017 match/nmatchを考える（後編） 最後は力業

42 SILICON VALLEY Piscineの個人プロジェクト、2つ目はmatch/nmatch。2つの課題で構成されるプロジェクトだ。問題文には明記されていないが、再帰構造の理解と実装が求められている。

再帰はややこしく、理解し難いと言われる。実際その通りだと思う。しかし再帰を用いずにロジックを組むと、さらに複雑になるだろう。再帰の流れを理解するのは難しくとも、ロジックの「見た目」は、それを用いない場合に比べて、非常にシンプルになる。

今回の投稿では二つ目の課題、nmatchを採り上げる。一つ目の課題であるmatchについては、前回の投稿を参照してほしい。

題材は文字列比較だがmatchとは求められていることが異なる。単純な比較結果を出力するのではなく、合致するパターン数を出力しなければならない。前回同様、これまで考えもしなかったロジックで、かなり手間取った。

前回同様、サンプル・コードはPythonで記述したが、Piscine受講生に配慮して、C言語的な記述になるよう配慮した。