代案

徴用工判決での仲裁委、韓国また開催拒否 第三国選定期限
https://www.sankei.com/world/news/190718/wor1907180016-n1.html

日本が一方的、恣意(しい)的に設定した日程だ。縛られる必要があるのかという考えだ

いずれ開催する意志があるなら、通常は「いつまでなら回答できる」という代案の提示があると思う。
代案の提示がない、ということは、実質的に開催拒否だと理解できる、と自分は考える。

開催拒否、ということは、日韓請求権協定を遵守する気がない、ということであって、破棄するつもりだと思う。

破棄するならば、遵守しないのならば、ここまできたら、やはり「金返せ」ということになるような気がする。返してくれたら、そこから元徴用工に日本の責任で賠償できる。

たったこれだけの論理。どこかに論理破綻がありますかね?

一般的に、「また、今度ね。」とか「いつか、またね。」なんて別れ方をした場合、「また」とか「いつか」が来るなんてことは滅多にないような気がする。この歳になると、握手しながらの「また、いつか」で、その後二度と会っていない、今ではどうしているかもわからない人は、数え切れないほどいるような気がする。ましてや交渉ごとで、相手と都合が合わなければ、自分の側から日程案を提示するのが普通で、それを指定しないってことは、破棄しか考えていないんじゃなかろうか。

よほど親しければ別だけれど。だけど、まさか韓国は、自分たちが親日国だとか、日本の友好国だと思っているんだろうか?

韓国が国際社会に訴えるなら、日本も、世界中の新聞に「意見広告」を出したら?何よりもまず、韓国の新聞に日本の立場の意見広告を出したら?って、拒絶されそうだけど。

日韓請求権協定破棄

こういう、ネトウヨが書きそうなページはあまり書きたくないけれども。

韓国の世論で、あまりにもひどいと思うのは、日本は韓国に全く賠償していない、というものだと思う。
韓国では誰もそれを訂正しない。訂正しようものなら、殺されても文句言えないくらいの状況になるんじゃなかろうか。
明らかに事実に反しているのに。

それだったら、いっそのこと、その状況にしたらどうかと思う。そもそも、日韓請求権協定の、協定内容なんて韓国では大して重視していない、ということだろうし、だったら破棄して、支払い済みの金を返せと、一回チャラにしてリセットしたらどうか、それを誰か(辞職覚悟で)政府関係者が、支払い済みの金を返せと発言してみたらどうか、なんてことを思う。それに対する韓国国内の世論が、「そんな協定、日本のでっち上げだ」ということになるのなら、もはや、どうしようもない。粛々と、協定内容を履行するか、支払い済みの金を返してリセットするか、相手に迫り、どちらにも応じないなら国際司法に訴えるだけじゃなかろうか。
日本の政府関係者の誰かが「日韓請求権協定破棄」に言及したら、「妄言」だという反応もあるだろうけれども、日本がいくら韓国に支払ったか、その事実だけは韓国内に周知できる。韓国メディアが無視するなら、実際に破棄を申し出て、「返還」を要求したらいいと思う。

いくら「協定に基づいて」と主張しても「応じる気はない」の一点張りなんだから、その協定そのものを元に戻すべきじゃないか。慰安婦合意は韓国側が一方的に「見直し」した。だったら、日韓請求権協定は、日本側が一方的に「見直し」するだけじゃなかろうか。日本が包括的に支払った金を、国民への補償に当てなかったのは韓国政府の都合だし、と、日本人の私は思う。
結構、我慢の限界に近づいている気がする。私だけだろうか。

なんて、日本側が主張する前に、韓国側で徴用工問題で資産売却に踏み切るだろうから、まずはそれに対抗する措置を日本側がとるだろうし、日韓請求権協定の「見直し」は、その事実に基づいて、ということになるんだろうな。資産売却に至ったら、国際司法を説得するのに十分だと思う。協定違反の事実が積み上がる。

こういう、ネトウヨまがいのことは書きたくなかった。むしろ、「ヘイトスピーチ反対」の話題を書きたいくらいだったけれども、約束とか事実とかがあまりにも軽い現状には、「我慢していい」とは思えない。我慢すべきじゃない、と思う。ここで我慢していたら、日本人の嫌韓感情は現在の韓国の嫌日感情をはるかに上回るレベルに達して、相当に修復不能なレベルで長引く気がする。何十年でも、文政権の政策が蒸し返されると思う。韓国がいまだに「戦犯」という単語を持ち出す。つまり、協定に基づく賠償金は意味がなかったということなんだろう。それならば、日本人は「賠償金には意味がなかった」という事実、「協定も合意も、一切履行されず、一方的に破棄される」という事実を、次の世代に語り継ぐだけ、だと思う。

一歩前進

何やってるんだろう、なんて思いながら、やっと治具が動いた。(ってか、一年半前に作り上げたエミュレータを、新しい環境で動かし直しただけ。)某社の某マシンのエミュレータ。仕様書なしで通信データだけを読んで、マシンの動作を完コピした。
復活!でも、バテバテ。

仕様書や文書が調っていないプログラムのメンテナンス、通信プロトコルをプログラムから読まなきゃならないような通信ソフトのメンテナンス、設計者が会社を辞めてしまって、どうにも修正できないプログラムの延命パッチ、などは得意といえば得意ですが・・・窓口会社を通していただく、ということで・・・(直接お金の話はしたくないので)。

良かったぁ、って違うでしょ?これからやっと仕事が始まるってのに、もうこの時間。

「製品」の動作確認するための「治具」が、こんなんでいいの?(トラップの作りが雑)、とは思うが、プロトコル上は完全に某社の某システムと同じ動作する。
よくある話で、フィッシングサイトなんかと同じ。

例えていえば、可愛い女の子とチャットしているつもりが、実は無精髭生やしたオッサンだった、なんて感じでしょうか。
「今度会いたいなぁ。でも上京するのにお金がないからぁ、・・・」なんて言われてつい、鼻の下をのばして・・・

論理のトレース

バグを潰しにかかって、一番厄介なのは表面的に起きている現象と原因との乖離、なんだろうな。
一つ前のページ、原因は自作関数の戻り値の検証不足。接続できることを試したかったから、つい先を急いだ。エラー処理系は手抜き。その結果エラー・リターンと、正常動作のカウント0の戻り値が同じになってしまい、原因を見つけるのが遅れた。
開いたファイルは必ず閉じる。(COBOL系の人はこれをやらない。言語処理系が自動的に閉じてくれるから、閉じない習慣があるらしい。自動ドアに慣れていると、自分でドアを閉じないのと同じか。)C++なのに、閉じていなかった。これも、先を急いでいたから。ここで、やっちまった。なおかつ、自分の意識の中でWrapperの戻り値をシステムの戻り値だと勝手に決め付けてしまっていた。

丁寧に、ステップごとに辿れば、この類のバグは必ず潰せるんだけれども、思い込みで注目点がズレていると、原因部分へのアプローチが遅れる。ものすごく時間がかかった。

基本的に、私はモノグサだから、面倒なことはやりたくない。そうすると、一番厄介なところ、自分で「完成品」と思っている箇所を無意識に避けて、勝手に論理をすり替えて、「この現象の原因は、ここにあるはずだ」と思い込んでしまう。こうなると、ドツボ。まさかとは思ったけれども、ps(プロセス状態取得)が誤動作していると、勝手に決めつけて、そこばかりを調べようとしていた。分かる訳がない。これで数時間ロスした。

一番怖いのは、論理のすり替え。すぐに論理をすり替える人に論理的な説明をしても、全く意味がない。だって、すり替えた先にはなんの問題もないんだもの。それと全く同じ。

相手がコンピュータで良かったと、つくづく思う。相手が人で、こちらは論理的に説明しているつもりが、寄り切られると、最後は自分自身を捻じ曲げるしかなくなる。
まず拒絶、次に思い込みと決め付け、そしてマウンティング。
それが続くと、自分の側が原型を留めなくなる。

どこぞの国との交渉も、「交渉」はできても「議論」にはならないだろうなぁ。ニュースを聞いていて、体から力が抜けた。こちらの主張を理解してもらう、なんて無理じゃないかなぁ。だって、全く聞く耳を持たずに一方的な主張しかして来ていないと思う。

そもそも、戦略管理物資が不正に流れていることの指摘は、アメリカ側から来たんじゃないのかなぁ。そのアメリカに、某国がどういう説明をしたのか、とても興味がある。きちんとアメリカが把握していた事実に合致する説明を、したんだろうか、それとも、何か都合のいい「作文」で説明したんだろうか。一度作文しちゃうとそれが一人歩きするから、もはや「事実」など霞んでしまう。あれは作文でした、なんていう撤回は、これまで一度もないと思う。その作文に基づい国民が大騒ぎする。直近ではレーダー照射がいい例で。
覆水盆に返らず。関係改善なんて、もう無理じゃない?

コンピュータ相手の仕事で良かったと、つくづく思う。純粋なロジック以外のことは、一切合切考えないようにしようとは思うんだけれども、脳ミソは一つしかないから、難しいです。

気を取り直して・・・

ps と grepでツボった話 <-- 初心者並 orz

反省箇所多し:自分への戒めで、晒しておこう。

発端は、なんか知らんけど、nohupとrbenvの相性が悪い、かな、と思った。最初はきちんと動いているのに、十数分後から

sh: 1: 1: Too many open files
nohup: 出力を ‘nohup.out’ に追記します

このメッセージが画面に溢れる。nohup.outを見ると

rbenv: cannot find readlink – are you missing GNU coreutils?
/usr/local/bin/rbenv/libexec/rbenv: line 22: /dev/null: Too many open files
/usr/local/bin/rbenv/libexec/rbenv: cannot make pipe for command substitution: Too many open files

この繰り返し。1秒間に10回はシェルを起動、実質的なマシンフリーズ。わからん。ツボった。

元を辿ったら、理由がわからないけれども、

ps -ef | grep puma | sed ‘/grep/d’ | grep -c puma

でpumaの起動を確認。別窓でrailsサーバは起動済み。それなのに、プロセス数が0で返ってきて、サーバが落ちてると勘違いして、nohupの起動コマンドが起き出す、で、同じポートを指定するから、多重起動をブロックされ、その後プロセス起動の無限リトライが始まる、とここまでは追い詰めた。

pumaは間違いなく動いている。クライアント窓からアクセス可能。grep puma自身のプロセスをブロックするために、sed ‘/grep/d’でその行を削除。正常動作では1が返ってくるのに、突然0が返り出す、この原因がわからない・・・psが走ってるプロセスを拾ってくれない、みたい。

半日潰した。やり方変えようかなぁ。何が起きているんだろうか。プロセスのrun状態を見るのに、何かキャッシュが入ってる?kernel読まないとダメ?

ってか、これ、ダミーホストで完全な治具だから「私には解決できません!」と諦めるのがも正解かも。

こういうの、悔しいんだよなぁ。負けるが勝ちか?
問題を解決できないこと自体が悔しい。

意味もなく、自転車でぶらつくことにする。


いた。虫がいた。
if(++ret == count){
pclose(fp);
return ret;
}

としないと、パイプを開きっぱなしになるのに、

if(++ret == count) return ret;

なんて書いていた。初心者みたいなバグ。

cannot make pipe のメッセージを見落としていました。

バグに煮詰まったら、そばにいるプログラマを捕まえて、状況説明すると、だいたい自分で気づくってのがよくある話で・・・。私の場合にはそれがネットだった、ってことね。

反省箇所は、まだある。一年半前に書いた治具用のコード。自分専用だから、ちょっとテストランしてそのまま使っていた。よくよく読んでみると、popenのエラーを返すのに0を使っていて、カウント数0はサーバダウンの時に戻る「処理正常」の値。これが被っていた。ど素人か、みたいなミス。
賄い飯みたいなものだけれど、だからって適当に書いていると、こういうことになる。粗忽だ。
orz

ボーッと生きてます・・・

ベビースターの「チコちゃんバージョン」が出たみたい。
あの「ボーッと生きてんじゃねぇよ(炎)」のパッケージ。
近所のファミマに、売れ残ったみたいで値引きで置いてあった。最近リバウンドがついに7kgに達したんで、買わなかったけど。

この時間帯、日によって落差が激しい。
多少捗った日は、「俺って、天才じゃねぇか」的な、ルンルン気分
捗らない日は、「もうダメだ、使えねぇ」的な、泥沼モード。メンタルトレーニングが必要かも。

平滑回路が欲しい。歩くチョークコイル、歩くキャパシタが欲しい。

キョエちゃんバージョンは出ないんだ。
生ゴミ大好きな、カラスのキョエちゃん。
時々ドツボる。「俺って、燃えない粗大生ゴミじゃねぇか」って。
キョエちゃんロボット、どこかで作って、売り出しませんか?「生ゴミ大好き、生ゴミ大好き」って、連呼して!

暗号資産

去年のG7で「仮想通貨」から呼び名が変わったんだ。知らなかった。
ユーザとしても業務受注としても縁がないもんで・・・不勉強です。
どちらかと言えば、今必死で仕入れている知識は「ポーラス加工」とか、そんなあたりで・・・必要に迫られたら、何だって勉強します。出来ることならば、システム設計する前に関連するJISなんかの基準を全部頭に入れたいんだけれども、9割5分は無駄知識。

昔大学生協の本屋で「ラーメン構造の力学」という背見出しの本を見つけて、ラーメンの麺の腰の強さとか、そんなのが本になってるのかな、と、勝手に決めつけてその本を手に取ることもなく、機械工学科のサークルの同期生とラーメン屋に入った時に、さも得意げに・・・(以下省略)
色々あるよなぁ。昔だったら図書館。今はインターネットで、あれこれと首を突っ込み始めたらもう止まらない。ゲームにハマるのとは別の面白さがある。でも、仕事に結びつかない知識は、全部無駄知識。ですよねぇ。

話を戻して、余りにも無防備なシステムが多くないか?と思った。ついこの間のセブンペイ。2段階認証はそこそこ有効なのに、やってなかった?

あれかな?携帯電話に、余りにもスパムが多いから、PCから携帯電話へのメールはブロック設定する人が多い。それだと認証登録用のメールが送れないから、やらなかった?これって、携帯キャリヤが、通貨価値を扱う会社(そんなに多くないと思う、キャッシュレス決済に、仮想通貨に、銀行のオンライン決済?などなど)のために、専用のゲートウェイを用意してくれたなら、二段階認証をシステムで組むプログラマの負担も減るし、低コストでセキュリティのレベルを上げられるし、通信キャリアにも考えてもらうことがあるような気がする。ガラパゴスと言われようとも、セキュリティに関してはガラパゴス化の方が海外からのハッキングを防ぎ易いとも思う。

昔の全銀協手順なんて、ほとんどが専用線だったと聞いている。ルパン3世じゃあるまいし、ハッキングなんかやりようがなかった。それに近い「実装」ができるように、携帯キャリヤとか、光を含めた固定回線の事業者が、協力すべきだとも思う。

暗号化について、思うことがある。同じ暗号鍵を使って暗号化すると、毎回同じ符号になる。これは当たり前の結論。東京都なんかはフリーのWi-Fiが多いけれども、偽装のフリーWi-Fiもあるらしい。実を言えば、僕の知識は、Telnet/FFTの頃のプロトコルまで。SSH接続とか、SSLでどこで符号化し、どこでデコードしているかとか、細かいところの勉強が追いついていない。SCPのプロトコルも、聞かれて内部動作を説明できるような知識を持ち合わせていない。だから、「可能性」しか言及できないんだけれど、バックドアを仕掛けらえた通信機器(が、出回っているという噂が絶えないけれど、それ)を使ってパケットを全部盗んだとする。あるいは、観光客や日本人が、都内のフリーWi-Fiを偽装したLANに接続したとする。プロトコル上、IDやパスワードそのものを盗めなくても、その部分だけ別プログラムに処理させて、盗んだ「暗号化済み」のIDやパスワードを流し、決済会社などに接続してから、通常の公開鍵を使って暗号化するプログラムに切り替えたなら、通信媒体が信頼のおけないメーカーのものであったり、フリーWi-Fiであったりした場合には、やはり「暗号化されたまま」のIDとパスワードを盗まれるリスクがあるような気がする。試したことはないけれども、こんなもん、試してから「盗めます」なんてネットに書き込んだら、とんでもないことになる。(いや、実際僕はそれで人生を棒に振った気がしている。まだ何もしていないのに。)とにかく、HTTPSはHTTPと違って暗号化されているから安心、というのは、「本当なの」というのが僕の疑問。もし僕が攻める側なら、(読む人が読めば、これだけの書き込みで、どういうプログラムを書けばいいかわかると思うので、以下省略)
簡単にこれを回避する方法が一つはある。ホスト側とパスワード認証を行う際に、暗号化前のデータで、必ずIDやパスワードに、タイムスタンプなどの「その都度変わる」情報を組み合わせて暗号化し、無論、マシンごとのタイムスタンプなどクライアントとサーバとで一致しているはずはないから、プラスマイナス2分などのフィルターを通して、余りにもタイムスタンプが違いすぎている認証パケットは拒絶する、という方法があると思う。毎回生成される認証のためのパケットのビット列が変わり、かつ時間が経てば使えなくなるから、これだけでフリーWi-fiなどの問題は回避できる気がする。(試してはいない。)AndroidもiOSも、「時刻」が秒レベルで正確なことは、保証されて・・・いたか、いなかったか、調べていないけれども・・・
他にも方法はあると思うけれども、盗まれる前に考えてみたらいいと思う。

今回ニュースで言っていた「暗号資産」の会社のサーバも、インターネットに繋がっていたらしい。
インターネットに接続している時点でアウトだと思う。管理情報は、特定の場所(ビルのこの部屋とか)に居なければ使えないようにすべきだと思う。普通はそうする、と思う。
実は、VPNの信頼性についても僕はまだ、十分な知識がない。調べてもいないし、使うだけ。仮に、メンテナンスなどの必要性から外部アクセスが可能なように、インターネットに接続する、にしたって、せいぜいVPN経由にするとか、VPN上の認証を二重に被せるとか、防御策はあるような気がする。

財務省とか、経済産業省とか、キャッシュレス決済のシステムだの、暗号資産を扱うシステムだのの「設計要件」に関する認可とか、許可とか、基準は作らないんだろうか?住宅みたいな目に見えるものだと、耐震構造がなんちゃら、柱のどの場所に補強がなければダメだの、やたらと細かいみたいなのに、目に見えないものだと、チェック基準すら作らないの?

うちのあたり、僕が子供の頃は玄関の鍵をかけない家がほとんどだった。それでなんの問題もなかった。そもそも、我が家なんて、盗まれるものがなかったし。これが日本人の発想のルーツ。世間に悪い人はいない。でも、インターネットは違う気がする。

自動運転の電車が、「配線の断線が原因でした」って、お粗末すぎないかと思った。一度書いてから「非公開」にしたページ、医療機器だったらそんな設計はしないという話題を書いた。フィードバックを必ずチェックし、制御信号が被制御側の機器に届いていることを確認できるメカニズムを持たない限り、危なくて乗れないでしょう?と思うんだけれども、国はこういう部分の設計には「認可」とか「基準」とか、設けないの?自動運転車両って、例えば「ゆりかもめ」って、何年前からありましたっけ?

なんてことを思った。

Wikipedia

Wikipediaから以下のようなメールが届いていた。
何かとお世話になっているんで、(その都度本を買ったり、図書館に行ったりして調べる手間を考えたら、比べ物にならないくらい「時間」をもらっている。)HELP!の掲示が出た時には多少の「区切りのいい金額」は寄付した。
だから、また来たのかなと思うけれども、年に一度くらいならば辟易するほどのしつこさでもないし、やはりWikipediaにはお世話になっていると思う。

残念ながら、今の自分にできることは限られているけれど、そして、自分なんかに大した影響力があるとも思えないけれど、無断転載します。(無断って・・・)やっぱり、拡散したい内容だとも思うし・・・

インターネットには「良質な情報」が不可欠だと思う。良質な情報の発信量が悪質な情報を凌駕すれば、何かが変わるような気がする。

私たちは、自分たちの価値観を妥協するよう度重なる圧力をかけられてきました。でも、もうたくさんです。例えば、広告を掲載すること(仮にコンテンツの中立性がおびやかされるとしても)。または最高額を提示する入札者にユーザーのデータを売却すること(仮にユーザーの安全性を脅かしたとしても)。 あるいは、ペイウォール導入への圧力もありました(仮にそれが何10億もの人びとの学ぶ機会を奪うことになったとしても)。 これらの圧力に20年間「ノー」と言い続け、目の前にちらつかされたお金に手を出さなかったことを誇りに思います。

私たちは非営利団体です。寄付してくださる読者は全体の1%未満ですが、毎月何億人もの読者のアクセスをかろうじて支えています。もし、すべての読者が寄付してくださったら、何が起こるでしょうか。インターネットにおける知識共有の方法そのものを変革できるかもしれません。

毎年、寄付者の皆さまから届く反響は、私を良い意味で驚かせてくれます。でもまだ、目標の募金額には達していません。残された時間はわずかです。私たちは営業マンではありません。私たちは図書館員であり、情報の保管人であり、また情報マニアです。この18年間、ウィキペディアは読者の皆さまから集まる寄付金で成り立ってきました。

また一年ウィキペディアを守り維持していくために、再び寄付してくださいませんか。

ちなみに、日本語表示、日本円での寄付リンクは、下記です。
https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&country=JP&uselang=ja&utm_medium=sidebar&utm_source=donate&utm_campaign=C13_ja.wikipedia.org

僕のこのページも、敢えて広告は貼り付けていない。滅多にないけれども、何としても中立性を守りたい内容を書きたいと思うことがあるから。
コメントを受け付けるのは吝かではないけれども、コメント受付にはバイアグラだの何だのの書き込みなどが大量に入ってくる。(Captcha認証を加えればいいんだろうけれど、その手間が・・・)

こんなことを書いていて、一体何の意味があるんだろうとも思う。ただ、自分の直感を信じて、出来ることならば続けるだけ。Wikipediaも、閉鎖に追い込まれて欲しくはないから、ここでも、ささやかながら出来ることは続けたいと思う。
たぶんね、力尽きて、気力が萎えて、もうどうにもならなくなるまでは、しぶとく続けるんだろうな。Wikipediaにも、しぶとく生き抜いて欲しい。

移転作業中

SSLの設定で、現在トラブっています。

PHPのバージョン、ZendFrameworkのバージョンの問題などもあり、現在PHPで書かれているアプリを、Ruby on Railsにするか、または Python/Djangoにするか、何れにせよ移植検討中です。

サーバの言語設定を自由にできないため、SSL設定や、サーバ設定などを自由に行うことができるサーバの移転を検討中です。

お見苦しいメッセージが出続けていて、「紺屋の白袴」のような状況ですが、自社のWEB設定に時間をかけられない状況のため、しばらくお待ち願えればと存じます。