日々の破片

_ マイナポータルで特別定額給付金の申請（と思ったら違ってぴったりサービス）

マイナンバーカードを持っていると特別低額ではなく定額給付金の申請がオンラインでできるというので、マイナポータルからわかりやすい導線に従って進んでいったら、PCにカードリーダライタが必要とわかってしょんぼりしていたところ、塚本さんが『特別定額給付金の申請をオンラインで済ませた』というノートを書いていたので、ならばスマホでやってみるかと再チャレンジしてみた。塚本さんはiPhoneだがおれはAndroidだ。でもおそらくMIFAREだろうからどちらにしても使えるはずだ（と思ったら、Type BでMIFARE（Type A）でもFelicaでもなかった。富士通の『マイナンバーカードの技術仕様と利活用方式』は良い資料だ）。

最初、普段使いのGalaxy A30（マイナポータルで、サポート対象なのは確認済み）にマイナポータルAPをダウンロードしたのだが、いきなりPINを入れろと出て来てびびる。読み込んでからPINなら間違い回数がわかるけど、間違えて入力して読み取りに自動再試行で失敗しまくればあっという間にリトライオーバーでロックされちゃうんじゃないか？ と不安を抱えたままのスタートとなる。

まあ、実際間違えていたのだけど。

あと、一瞬Chromeが開いてぱっと消えるのも不安要素ではある（自動的に閉じない場合はクリックとやっと読めたが、自動で閉じるので一瞬フロントに出て来てあっという間にバックに回るので怪しいことこの上ない。というか最初からChrome専用のWebサイトにしたほうが良いんじゃないか？ QUICPayとかそうだし）。

でPINを入れて、次へをクリックすると、設置しろと出て来てこれまた疑問がたくさん。しかしいろいろ試したら、ある位置に置くと動作が開始して、そして「動かすな（エラーコード）」と表示されておしまい。動かしてないのにおかしいな？ と何度も試したが、1回だけ「暗証番号が違います」が表示されたので、あわてて、マイナンバーカード受領時の紙を探すことにした（少なくともあと2回はチャンスがあるのがこれでわかったからそれはOKでもあるけど）。探したら、区役所の妙な色（蕎麦の実色に緑の字）の封筒が出て来て、中にウサギ（マイナちゃんというらしい）の顔が見えたので一安心。

だが、正しいPINを入れても読み取りエラーになることは変わらない。メッセージは常に「動かすな」なのだが、動かしていないから、SYN-ACKまでは進むが（TCP/IPではなくても、通信は最初のエスタブリッシュフェーズは短いコマンドでやるものだ）、その後が続かないような状態なのかな？ ということは伝送長によって不安定になるということだろうと考える。データ転送中にパケットが消えるので「動かすな」というのは悪くないメッセージかも知れないが、この場合は当てはまらない。

そういえばBluetoothも繋がりが悪いのだった。そういうマシンなんだろう（個体問題かも知れないし、もしかすると、附属していた薄いカバーのせいかもしれない）。カバーを外してリトライする気にはならないのであきらめてアンインストールした。

ついでにエラーコードをマイナポータルのお問い合わせに投げ込んだ。A30はサポート対象なのだし、途中まで進むのだから一応、原因は聞いておきたいし。ちなみに、ここの導線は最悪だった。お問い合わせフォームに最短時間で到達するのを競うゲームが作れそうだ。

が、ふと気づくと、Pixel 3aが予備機として手元にあるのだった。しかもこいつは普段使いではないので剥き身のままだ。

で、再度、マイナポータルAPをダウンロード・インストールして再試行。

するとするする進む。読み取り位置は上半分にカードを横向きが安定している。2020年7月に証明書が切れるから役所で更新しろと注意がポップアップされるが、オンライン更新できないのかな？ この場合はEMV接触型ICチップのほうを利用するのだろうか（前述の富士通のPDFにも更新については記述されていない）？

最初にPINを入れて読み取ってログイン、特別低額給付金の申請に進み、郵便番号を入力してサポート対象の地区かどうかを判定、いよいよ申請となると再度PIN入力、読み取って名前や住所を自動入力、振込先のエビデンスを求められるので最近よく利用するようになったソニー銀行のホームページを開いて写真を撮ってアップロード（どうでも良いけど、こういう場合、URLに銀行名ではなくMONEYKITとかいうわけのわからないドメイン名を表示するのはエビデンスとしては使いにくいし、どこにもソニー銀行という文字がなくて閉口する。良くみたらタイトルバーにはソニー銀行と出ているので、そこも撮影範囲にした。

最後に、暗号化して送るので署名用暗証番号（番号ではないが）を入力して再度読み取りなんだが、書き込みとかやるせいかえらく時間がかかって相当不安感を覚えたが無事完了。

というわけで、申請は完了。

A30でもたついたことと、問い合わせフォームダンジョン探索を除けば、なかなかうまくできていると思う。楠さんがいろいろ呟いている通り、相当良いものだ。

ところが、メーラを見たらPDFが添付されたメールやらメール送信確認のお知らせなど計3通が、【ぴったりサービス】というわけのわからない件名で来ていて、なんのフィッシング詐欺か？ と驚いた。

ヘッダを確認すると送信元がsendgrid.netだから怪しいといえば怪しいが、return-pathなどはちゃんとmyna.go.jpになっているのだから、件名にもマイナポータルと書けばいいじゃんと思わざるを得ない。

が、スマホのほうを見るとマイナポータルAP(に起動されたChrome)の画面に「ぴったりサービス」って書いてあった。怪しい名前だけど、そういうものなのか。

何がぴったりサービスかわからんが、マイナポータルAPが制御するまま、そんな名前のサイトで作業していたのかと気づかずに入力していたことに愕然とした。（多分、ここからは「ぴったりサービス」のサイトで行いますのようなメッセージがあったのかも知れないが、まったく意識していなかったわけで、フィッシングに引っかかる典型的な行動だったのだな）

国内版SIMフリー Google Pixel 3a 64GB Clearly White(-)

_ ラストマンと縦横

kdmsnrさんがFBでくっそおもしろいラストマンの続きはどうなるんだ？ とか書いていておもしろそうなので4月18日に買って、さっき1～6巻まで読み終わって、くっそおもしろいラストマンの続きはどうなるんだ？ となっている。

70年代に日本アニメで育って、最近はナルトあたりを読んでいるらしきフランス人3人組のマンガ（いちおうバンド・デシネに分類して良いのだと思う）だが、20世紀マンガの文脈総ざらいの側面があってどうにもすさまじい。

日本のマンガの影響を後書きマンガなどで公言しているが、絵柄は日本のマンガではない。でも細部にいろいろそれっぽいところはある。

とにかく様々な要素を惜しげもなくばんばん投入してきて、それにほとんど破綻がない（読んでいて、あれ？ なんでこうなると最初は思わなくもなかった。特に、王国から谷を抜けてマッドマックスになった時にはそう思った。思い返すと相棒が出てくるところもえ？ となったな）。

最初は、主人公の少年が木の精霊の力を使う格闘技学校で訓練しているところから始まる。トーナメントへの出場が目的らしくて、同級生（嫌な奴もいればどうも恋心がなくもない女生徒とかも出てくる）間の話かと読んでいると、いきなりマッチョな好漢登場。主人公のやたらとセクシーな母親がからみ、なんでこうなるのとどんどん話が展開していくのだが、展開が唐突ではあるが、ちゃんと筋道が立っているので滅法おもしろい。魔法の国の武道大会に始まり、マッドマックス風暴力の世界での裁判、一転、ギャングの麻薬戦争、そしてベルセルク風なダークファンタジーに変わり、さてこのあとどうなるんだろうというところで7巻に続く。

特に謎の仮面戦士が良い味を出している。

4巻あたりのあとがきインタビューで作者の一人が、なぜセックスシーン（まったく露骨ではない）が日本の読者から拒否反応を受けたのか不思議だ、だってキャッツアイでもっこりとかバシバシ出てくるじゃんというようなことを書いているのが、すごくおもしろかった。というのは、おれも拒否反応はまったくないものの、そのシーンではん？となったからだ。おそらく日本のマンガ文脈では、交接そのものを示す描写は書かないからだろう。というか、画がその部分が妙に自然にセクシャルだからだと思う。どうもコンテキストの中に埋没しているのが、逆にマンガとしては不自然な感覚を受けるのだろう。というか、フランスだからかも知れないがあまりにいきなりそこまで進んでしまうからかも。ここが、文化的に一番の相違点になっていそうだ。

ラストマン (1)(バラック)

アマゾンでKindle版を購入したが1～4巻は右綴じ、5～6巻は左綴じで別の書籍コードになっているらしくライブラリが2つに分かれる。

右綴じは日本のマンガと同じページ繰りなのでその点は自然なのだが、コマ割りは左から右で、最初の2ページで話が続かなくて不思議だった（で、コマ割りが左から右へ進行と気づく）。さらにセリフが左揃えになっているので、縦書きではなく横書きだと頭ではわかるのだが、縦読みしそうになったりもする。特に字数が揃っているところはそうだ。

試し読みできる範囲だと

負けた
者だけ
交代だ

は、「たけだけだ……」とつい読みそうになる自分に気づいておもしろい。

慣れたところで、5巻以降は左綴じなので自然と左から右へのコマ割りでOKとなる。

日本語は、現在は横書きの場合、左から右なので左綴じであれば自然と読めるが、これが日本のマンガを欧米に持ち込む場合のネックというのは相当前に何かで読んだ。

要は右から左へコマが進むので、左綴じだと不自然（セリフは横書きになるわけだが）、右綴じであっても当然不自然、そのため、読者の便を考えて反転させて出版するので、日本マンガの登場人物は全員左利きで不自然ということだった。さすがに現在はページを反転させて出版したりはしないだろうとは思うが、読みにくそうだな（と思う反面、1～4巻もこちらはすぐに慣れたのだから、わざわざ日本のマンガを読もうという人達には屁でもないのだろう。でも、マスで売るものは、現在でも反転させていたりするのかな？）

同じく、縦書き2行の吹き出しに、横書きにするとえらくハイフネーションされまくって読みにくそうだが、そのあたりはどう処理しているんだろうか？

# このマンガの今気づいたすごく良い点は、どの登場人物も次々変化する文化状況に対して不思議がることはあるのだが（精霊の国から出て来てテレビを目にすればそりゃ不思議だろう）、すぐさま状況を受け入れるところだ。だから政治目的や欲望遂行のための暴力や敵対はがんがんあっても、文化的対立がまったくない（解放戦士はいるけど文脈が異なる）のはとても教育的だ。

_ CoffeeScriptに地雷を埋め込んでしまって、踏み抜いた

Rails5で標準装備（特に設定とかしなくても勝手にトランスパイラが動いて処理できる）だったので、時代遅れ感はわかっていたがCoffeeScriptを使っていたのだが、とんでもない地雷を埋め込んでそれが爆発したので記録。

CoffeeScriptは書式が多少Rubyっぽいので、ときどき終端endを書いてしまうことがある。

if foo 
  console.log('foo!')
end

実際はCoffeeScriptはPythonのようなインデントベースなので上記のコードのendは不要だし、そもそも予約語ですらないのでエラーとなる。

ここで重要なのはendは予約語ではないという点で、そのためstrictモードで動作させるCoffeeScriptではReferenceErrorがスローされるということだ。

というわけで通常は上記のようなコードを書くと例外を食らうのですぐに気づくのだが、以下のようなコードを記述していたため、まったく気づかずに半年以上稼働させていた。

ready = ->
  displayStartEndPeriod = ->
    start = $('#foo-start-date').val()
    end = $('#foo-end-date').val()   # 予約語ではないので変数名として利用できる
    $('#date-disaply-div').text(formatBlaBla(start, end))
    ...
 
  fooBar = (foo) ->
    if someCondition(foo)
      console.log('foo!')
    end
 
  displayStartEndPeriod()
  fooBar($('#baz').val($('#baz').text()))
 
$(document).ready(ready)

このコードに対して、期間表示をサーバー側処理へ移動したので、displayStartEndPeriod関数を削除した。その結果、特定条件で（上のコードだとfooBar関数のパラメータfooがsomeConditionを満たす場合）例外が発生するようになった。

もちろん例外がスローされた場所はわかるので見た瞬間にfooBarのendが悪いということはわかる。

わからないのは、なぜこれが半年も稼働していたかだ。

mergeのタイミングか？ とか調べても半年間上記のfooBarで動いていたことは間違いない。

でしばらく考えてやっとわかった。

CoffeeScriptが生成するJavaScriptでは、すべての変数はトップレベルの関数内に定義される。

したがって上の例からは以下のようなJavaScriptが生成される。

(function() {
  var ready;  # トップレベル関数用の変数
  ready = function() {
    var start;
    var end;
    var displayStartEndPeriod;
    var fooBar;
 
    displayStartEndPeriod = function() {
      start = $('#foo-start-date').val();
      end = $('#foo-end-date').val();
      $('#date-disaply-div').text(formatBlaBla(start, end));
    }
    ...
 
    fooBar = function(foo) {
      if (someCondition(foo)) {
        console.log('foo!')
      }
      retun end;
    }
 
    displayStartEndPeriod();
    fooBar($('#baz').val($('#baz').text()));
  }
  $(document).ready(ready);
}).call(this);

displayStartEndPeriod関数でend変数を利用しているのに対して、ready関数のスコープでend変数を宣言しているため、fooBar関数内でのendという記述が既存変数に対する参照となるために動作していたのだった。

この状態でdispalyStartEndPeriod関数を削除すれば、start,end両変数の宣言も削除される。しかしfooBar関数の中身はそのままとなる（endに対して代入が行われていないので宣言は作られない）。結果としてundefinedなendに対する参照が行われてReferenceErrorがスローされる。

なぜ、end付きifで動作していたのか実に不思議だった。