code-lab.net

新入社員と退職と労働契約

稲葉食品の一件以来、退職RTAが流行っているらしい。変化の早い現代において、決断が早いことは良い事でもある。「情報収集して勤務初日を迎える前に判断しなよ。」と思わなくもないけど。

一連の記事で何が一番不味いかって、今の中高年には採用活動において不法行為に及んでいると可能性に対する認識が薄いようだ。そしてそこには気がつかないまま、「若者は我慢が足りない」とか平気で発言している。

労働契約を結ぶときにあらためて説明していない限り、募集要項や面接時に示した労働条件が契約として有効になる。

例えば有りそうな話しとして、採用面接で「配属は希望を考慮して決定します」と言っておきながら、労働契約時点では希望に添えなかった事を説明せず、勤務初日に希望と異なる配属を明かした場合、法定で争ったら企業側が負ける可能性が高い。稲葉食品で問題となった話しも、採用募集時には総合職の初任給を提示しておきながら、入社してみたら一般職採用で報酬も少なくなっていたと言う。採用面接時の約束事を反故にしても刑事上の罰則なんかは無いが、民事の損害賠償ぐらいは取られる可能性があるのだ。

今の若者は、企業が不法行為をおこなっていることを認識しているし、不幸行為を我慢して受け入れる必要のない社会環境にある。

高校入試と不登校と内申点

Yahoo! News:高校不合格のゆたぼん　父らは内申点「時代遅れ」指摘に「よいことは1つもない」「否定するのはおかしい」と賛否

ゆたぽんの高校入試の件で話題に上がっていたので、県立高校の入試時の内申点の取扱について確認してみた。

沖縄県立高校の場合には試験成績と内申点の比重は5:5。特に音楽、美術、保健体育、技術・家庭が重視され、所謂5教科よりも配点が5割増しになる。つまるところ不登校で内申点が低くなっている場合には、公立高校の受験は著しく不利になる。試験で50点程度とれば合格できる高校でも、内申点が最低レベルに低い場合には、試験で100点を取らないと合格できないという扱いになるようだ。

なるほど、公立高校に受かるわけが無い。流石に沖縄県の選考方法には問題があるように思う。不登校児の公的扱いに対する問題提起のために、敢えて公立高校を受けて見せたのかとまで考えてしまう。

この問題は県によって大きく異なる。例えば東京都の場合には試験成績と内申点の比重は7:3。特に音楽、美術、保健体育、技術・家庭が重視され、所謂5教科よりも配点が二倍になる。試験で50点程度とれば合格できる高校でも、内申点が最低レベルに低い場合には、試験で80点を取れば合格出来る事になる。沖縄よりはマシだが、内申点の低さが大きく影響することに変わりは無い。

私の住む茨城県の場合にはちょっと分かりにくい。概ね次の様になる。募集定員が100名の場合には、試験成績が80位以上で、内申点が100位以上をA群として合格にする。残りをB群枠とし、B群の7割程度を試験成績重視で内申点によらず合格、B群の3割を試験成績によらず内申点重視で合格とする。B群枠のうち成績重視と内申点重視の比率は高校の裁量となる。結果的に試験成績と内申点の比重は7:3程度になるが、仮に内申点が最低レベルでも、試験成績が上位に入れば合格を狙えるような制度になっている。

ちなみに学校に一切行かなければ内申書上は評価不能で斜線となる。内申書が評価不能となっている場合には、不利な扱いをしないように通達がなされているので、多くの高校では試験成績を重視して評価してもらえる。中途半端に通学してしまうと評定に1がついてしまい、まったく通学しなかった場合よりも不利になる。公立高校入試を考えるなら、中学校には中途半端に通学してはならないのは常識であるらしい。

ゆたぽんは中学校に中途半端に通学してしまっており、この点でも不利だったことになる。

TV用の同軸ケーブルを使用してネットワークを接続する

築15年程度の一戸建てに暮らしていますが、LANの配線はおろか、電源関係も配管を通してあるわけではないので、後からLANを引くことが困難。1Fと2FにあるTVでひかりTVを視聴するためWiFiで接続を試みたのですが、一応は写るが時折ブロックノイズが走る。そこで有線接続する方法を検討した。どうやらTV用の同軸ケーブルを使って接続する方法があるらしい。

国内ではTLCモデムという名称で販売されており、殆どの製品は最大でも100Mbps、実効速度は数十Mbps。4K映像を視聴するための必要な帯域幅が30Mbpsと考えると心許ない。DXアンテナがリンク速度1Gbpsまで対応する製品を販売しているが、それでも実効速度は300Mbpsに過ぎない。せっかく数万円をかけるなら、他の機器も有線にして安定化したいじゃないか。

海外だとPLCモデムはリンク速度2Gbps、実効速度は1Gpbs近い製品もあるのだが、いかんせん日本では動作しない（アース線も使って通信をするため）ので、結局のところ600Mbps程度にしかならない。しかも違法だ。

検索する事、数十分。MoCa(Multimedia over Coax Alliance)規格のTV用の同軸ケーブルを使ったLANにたどり着く。現在売られているMoCa 2.5対応の機器を使えばリンク速度2.5Gbps以上、実効速度は1Gbpsで接続する事が出来るという。国内メーカーはない。同軸ケーブルを使うので、PLCのように漏洩電波が問題になることもなく、法的な制約に引っかかる心配も無い。

というわけで早速個人輸入。国内にも販売する業者が居るが、国内サポートがあるわけでもない。米Amazonで買ってきた方が送料込みでも安い。

届いたのはこんなの。

電源、アンテナ線を接続する端子、LANを接続する端子、LED（電源、アンテナ線、LAN線）があるだけのシンプルな代物。図の通りに繋いでしばらく待つと、アンテナ線のLEDが点灯してリンクした。シンプルだ。

だが一応は暗号キーの設定ぐらいはした方が良いらしい。設定はWEBブラウザから行う。出荷時に固定のIPアドレスが振られているので、パソコンのローカルアドレスを固定で設定し、工場出荷時の初期パスワードでログインする。

二台とも同じ初期IPアドレスが振られている。アンテナ線でリンクアップしているとIPが重複してまともに設定出来ないので、1台づつ電源を入れて設定を行う。

暗号鍵は三箇所に設定する。適当に12～17桁の数値を入れる。ついでにIPアドレスもDHCPに変えてやる。これで全ての設定は完了。

検案だったひかりTVの状態もバッチリである。ついでに1Fの無線APにも有線で繋げてやると、1FでWiFiを使ったときの速度も大幅にアップした。

ステータス画面を見ると3.2Gbpsでリンクアップしている。なるほど、そういえばカタログには2.5Gbps以上と書いてあったなぁと。LAN端子が1Gbpsだから実行速度が1Gbpsを超える事は無いが、だいぶ余裕があるようである。速度が2Gbpsに落ちる分、ちょっとだけ安くなるMoCa 2.0機器でも十分だったかもしれない。

MoCa2.5の子機は最大で16台まで増やすことが出来る。私が住んでいる家は、各部屋にアンテナ線が来ているので、書斎にも子機を増やすと良さそうである。

ひとつだけ注意事項がある。使用している周波数がBS/CS放送と被っているのだ。同じ同軸ケーブルにBS/CS放送の信号も流している場合にはMoCa2.5を使えない。その場合は国内のTLCモデム製品を選択するしかない。

・・・と言う訳でアンテナ線は来ているが、LANを引くのは難しいというお宅には、MoCa 2.5がおすすめである。

バックグラウンドジョブをcronで実行する。（NextCloud+Docker）

ある日を境に、NextCloudにログインすると「ストレージ容量がいっぱいです～」と言うエラーメッセージが表示されるようになった。どうも原因はバックグラウンドジョブが正常に起動されていなかった為のようで、この機会にcronから起動するようにシステム構成を変更することにした。

NextCloudは公式のDockerイメージを使用しているので単純にcronから実行する事はできない。dockerコマンドを使ってcron.phpを実行する命令をcronに登録することにする。

以下のコマンドを実行して編集画面を表示。

sudo crontab -e

以下のコマンドを登録して5分おきに実行。

*/5 * * * * sudo docker exec --user www-data [docker container name] php /var/www/html/cron.php

TP-Link Deco X50 + ひかりＴＶ

結論から言うと動作しない。Deco X50をブリッジモードにするか、Deco X50でIPv6をパススルーに設定すれば動作するような気がするが、実際には動作しないません。

ひかりTVはTV放送データを効率よく配信するためにIPv6 multicastを使用しています。つまり「ひかりTVに対応出来る」＝「IPv6 multicastを適切に扱える」に限りなく近いわけです。

TP-LinkのDeco X50は、ルーターモードでもブリッジモードでも、IPv6のファイアウォールがデフォルトで有効になっており、このファイアウォールを無効にする事ができないようです。このファイアウォールによってIPv6 multicastの通信がドロップされているように推測されます。ファイアウォールのルールを設定する画面もあるのですが、設定の制約が厳しく、マルチキャスト通信を許可するような設定を入力する事ができません。マルチキャスト通信は宛先IPv6アドレスがFF00::/8となりますが、このようなIPアドレスの入力を受け付けないのです。

設定に使用するスマホを英語モードにすれば入力できる可能性はあります。ただTP-Linkの英語版掲示板を見る限り、IPv6 ｍulticastが通らないといった相談は度々あがっており、公式アカウントからのログ提出依頼もついていますが解決には至っていません。本質的にIPv6 ｍulticastはMesh WiFiと相性が悪いのかもしれません。

・・・というわけで、あえてメッシュWiFiは使わずに、WiFiルーター＋WiFiエクステンダーで構成するのが良さそうです。

寒波でEVの充電できずに立ち往生した話とか

米国の寒波でTESLAの急速充電器が動作しなくなり、充電待ちのEVが電欠で動作できなくなり行列を作っているとニュースになっていました。そういえば日本でも夏に充電できなくなった急速充電器とかありましたね。この手の話し、たまたまEVがニュースソースとして注目されやすいからニュースになっているだけで、－30℃なんていう寒波の中では、EVの急速充電器に限らず色々な機械が止まっているはずなのです。

というのも、世の中の機械は－30℃～40℃でしか動作保証をしていないことが多いのです。例えば「やはりハイブリッドカーが最適」という発言をちらほら見かけるけど、プリウスのマニュアルには－30℃以下だとハイブリッドシステムが起動出来ない場合があると明記されています。なんならガソリンエンジンも通常で-15℃、寒冷地仕様で-30℃を下回ると起動できない場合があるそうです。そもそも内燃機関は急速充電器が止まってしまうような低温下では、ヒーターで温めてからで無いと始動できないのです。

ガソリンスタンドの給油機もやっぱり－30℃～40℃だったりします。ディーゼルだともっと深刻で、－10℃～－30℃ぐらいで軽油に含まれる高分子量の成分が分離して固形化してしまうそうな。灯油の凝固点も－20℃～－46℃なので、燃料が固まっているから石油ストーブも動きません。じゃ北極圏に近いような場所ではどうやって暮らしているのかと言えば、24時間暖房を耐えさせないようにしているわけです。

同様の事は高温時にも起こります。日本でも夏の気温が上がり35℃を超える猛暑日が度々おこるようになりました。直射日光が当たるような場所なら40℃を超えても不思議ではありません。気象条件が変わって寒波が襲来したり、猛暑が到来したり、度々おこるようになっている以上、インフラ関係の機器だけでも－40℃～50℃ぐらいまで動作するように考えなければならないのかもしれません。

某高校の入試申請で話題になってたメールサーバーのこととか

神奈川県の高校入試出願システムで障害、志願者のGmailにメール届かず – 現在は解消

神奈川県下の中学三年生は約7万3千人。予備のメールアカウントも登録しているから、全員に一度にメールを送信しようとすると、約15万通のメールを一度に送信しうるメールサーバーという話になる。

件のメールサーバーではMXテーブルにIPアドレスを指定していたことが原因で、SPFやDKIMが機能していない。その状態で大量のメールを送信したためレピュテーション（評価）が低下、不正中継サーバーと判断されて、メールを拒否されるようになった。Googleが制限しているためメールを受信出来ないという表現は確かにその通りだが、不正メール対策として正しく設定していないメールサーバーからのメールを受信しないのはGoogleに限らず多くのベンダーで行っている基本的な対策だ。正しく設定出来ていなかったメールサーバー側が全面的に悪い。

では正しく設定出来ていたら問題無くメールを送れたかというと、実は送信出来なくなった可能性が高い。新規にドメインを取得して間もなかったり、普段より極端に多くのメールを送信した場合にも、レピュテーション（評価）が低下する。これはSPFやDKIMによる認証が行われるようになる以前から行われていた不正中継対策だ。

もし独自にメールサーバーを立てるなら、ユーザーの利用が集中しないように利用開始時期を分散させつつ、レピュテーション（評価）の状態を確認しながらメールの送信数を調整、時間当たりに送信するメールを少しづつ増やしていく必要がある。運用に常に人を張り付けて微調整が必要になる。そもそも1～2月だけ大量のメールを配信するというのはレピュテーション（評価）を下げやすいので、年間通してメールを送り続けるような仕組みまで考えておく事を求められる。

実際には上記のような運用は手間がかかるし、バッドノウハウの塊なので経験がないものが実施するのは難しい。そこで通常は大量のメール送信を代行する、メール配信事業者に頼むことになる。

1月～3月だけ数十万通のメールを送信するシステムで、自前のメールサーバーから配信しようとしている時点で、発注者側にも受注者側にも適切に設計を出来るIT知識が無かったことがうかがわれる話だったりする。

参考：Google メール送信者のガイドライン

Nintendo SwitchのSDカードを容量の大きなものに交換する

Nintendo Switchに使っているSDカードの空き容量が不足してきたので、サイズの大きなSDカードに交換したいと思う。Nintendo SwitchのSDカードはFAT32フォーマットを採用していて、2TBのSDカードまで対応している。パソコンで単純にコピーできれば早いのだが、Windowsでは32GBを越えるFAT32パーティションを作成することが出来ない。そこで使用するのは以下の二種類のツール。作業を始める前にダウンロードしてインストールしておく。
・HDD Raw Copy Tool
・MiniTool Partition Wizard 無料版

SDカードリーダーが2台有ればMiniTool Partition Wizardで元となる容量の小さなSDカード、新しい容量の大きいSDカードに直接コピーできる。だがその為だけにSDカードリーダーを追加で用意するのも勿体ない。ここではHDD Raw Copy Toolを使ってSDカードを複製した後に、MiniTool Partition Wizardでパーティションサイズを変更する手順で作っていく。

コピー元SDカード⇒ディスクイメージファイル

最初にHDD Raw Copy Toolを使用してSDカードからディスクイメージフィルを作成する。HDD Raw Copy Toolは日本語化されていないので日本語のフォルダ名やファイル名は文字化けする。保存先などには日本語名が混じらないようにする。

SDカードをリーダーに挿した後にHDD Raw Copy Toolを起動すると認識しているディスクの一覧が表示されるので、コピー元となるSDカードを選択して、Continueをクリックする。

次にコピー先となるディスクイメージファイルを選択する。認識されているディスクの一覧の最後にFILEと言う項目があるので、それをダブルクリックする。保存先の選択ダイアログが表示されるので、保存先のファイル名を入力する。

コピー先となるディスクイメージファイルを指定したら、Continueをクリックする。

以下のような確認画面が表示されるので、Startをクリックして、ディスクイメージファイルの作成が終わるのを待つ。コピーが終わったら100% completeと表示されるので、HDD Raw Copy Toolを終了する。

ディスクイメージファイル⇒コピー先SDカード

コピー先SDカードに差し替えて、再びHDD Raw Copy Toolを起動する。最初にコピー元を選択するが、今度はディスク一覧の最後にあるFILEを選択する。FILEをダブルクリックして、先ほど作成したディスクイメージファイルを指定して、Continueをクリックする。

次にコピー先を選択するので、ディスクの一覧からコピー先となるSDカードを選択して、Continueをクリックする。

コピー確認画面でStartをクリックする。コピー先のパーティションを上書きして良いか警告が表示される。ここでは警告を無視して「はい」をクリックして先に進める。

パーティションサイズの変更

この時点では、コピー先SDカードのパーティションサイズは、コピー元SDカードと同じになっています。この後に、MiniTool Partition Wizardを使用して、コピー先SDカードのパーティション拡張を行います。

MiniTool Partition Wizardを起動してドライブの一覧から対象のSSDにあるFAT32パーティションを選択したあと、右側のパーティション変更からパーティション拡張をクリックします。

パーティション拡張のバーを一番右側までスライドさせ、パーティションサイズを最大まで拡張します。

最後に右下の「適用」をクリックしてパーティションの拡張を実行します。

この手順で、キャプチャした画像はコピー元のSDカードが32GB、コピー先のSDカードが64GBになっていますが、最大2TBまで制限無く拡張できるはずです。

緊急地震速報の誤報報道の滑稽さ

緊急地震速報（警報）で震度7の警報が出たにもかかわらず、有感地震が無かったことが誤報として問題視されている。同様の誤報は数年おきに発生しており、今回が初めてと言う訳でもありません。

緊急地震速報の仕組み自体は気象上の緊急地震速報（予報）発表状況にかなり詳しく記載してあり、なぜ誤報が起こるのかまで記載されています。

緊急地震速報は次の様な仕組みになっています。

２箇所以上の地震計で、地震のP波と思われる振動を捉えると、震源地や最大震度を予測して、その結果を緊急地震速報（予報）として関係諸施設に送信します。一回計算して終わりでは無く、新たな地震計のデータを加えて何度も予測計算を繰り返し、そのたびにより正確な緊急地震速報（予報）を送信します。予測される最大震度が4.5超える場合には緊急地震速報（警報）を送り、スマホからおなじみの警報音が鳴り響くことになります。

ここでお気づきと思いますが、2箇所の地震計の観測データから震源を計算したとしても、その震源は帯状の範囲としてしか予測できません。正確に震源を特定するなら最低でも3箇所、出来れば4箇所以上の地震計のデータが必要になります。それにも関わらず2箇所の地震計のデータで震源を計算しているのだから、誤報が発生して当たり前のシステムなんです。

緊急地震速報は全国に約1700箇所ある地震計を使用しています。日本の陸地面積は378000平方Km。仮に地震計が一様に設置されているとしたら、約222平方Kmに1箇所、およそ15Km間隔で地震計が設置されています。Ｐ波が地中を伝わる速度は約7Km/sだから、３箇所目の地震計からのデータを待つなら最大で２秒程度遅れることになります。現状でも緊急地震速報警報が伝わってから、S波到達までの時間的余裕は数秒～数十秒でしかありません。３箇所目のデータをまつために２秒遅らせたら、緊急地震速報は本震に間に合わず、存在意義を失います。そのため不正確なのを承知の上で、２箇所に地震計のデータで処理を行っているわけです。

緊急地震速報の予測震度が大きくずれる原因はある程度わかっています。
・震源が陸から（地震計から）大きく離れている場合
・地震発生と同時に、周辺の地震計が地震以外の震動や電気的雑音を拾った場合。
・たまたま複数の地震が同時に発生した場合。
・地震計の故障などにより、使える地震計が少ない場合。

今回は大きな地震発生から間もないため頻繁に地震が起きており、また地震計も被害を受けているため使える地震計が少なく、誤報が発生しやすい条件下にあります。

緊急地震速報は、ある程度の誤報を許容する事で、より早く警報を出せるようにしたシステムです。誤報の発生を許容する警報システムそのものを問題視する議論ならわかります。そこを無視して、緊急地震速報に誤報の再発防止だの、誤報を出したことの管理責任を求めたりというのは、エンジニア目線だとわりと滑稽な話です。

2024年1月1日16時移行、13回の緊急地震速報の警報を発表している。震度5を越えても警報が出なかったのが3回になっている。人命や減災を意識するなら、実際の震度が低いにもかかわらず発報してしまった場合よりも、実際には震度5を越えているのに発報できなかった事を問題視するべきはずだ。だが、逆の事をしているあたりが、リテラシーの低さを物語っています。

NextCloudで”一部のファイルは整合性チェックに合格していません。～”

dockerでNextCloudを動作させて居るのですが、バージョン28.0.1への更新移行、以下のエラーが発生する状態になってしまった。監理者設定の画面を開くと、以下の通りに表示されている。

“無効なファイルのリスト”のリンクを開くと、整合性チェックでエラーとなったファイルのリストを確認出来る。

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
	- INVALID_HASH
		- core/js/mimetypelist.js
	- EXTRA_FILE
		- core/img/filetypes/dwb.svg
		- core/img/filetypes/drawio.svg
Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [core/js/mimetypelist.js] => Array
                        (
                            [expected] => 550ab566d30693bfa24ec4b15d9df87731ae8a3be8f79dabf94757e5b8b20eec6e4b678f17af1718297f2872f6b04519eeb024d1dff11947f29da431c7f11201
                            [current] => 301654cbbe168b8723530db88fd2e40ad688f4e6b0bdaeade5b4fe34bd94d9d3cfe760821e97dc792e585d4b6ccff838597bfd46466bb07d30ff84df4cb79518
                        )
                )
            [EXTRA_FILE] => Array
                (
                    [core/img/filetypes/dwb.svg] => Array
                        (
                            [expected] => 
                            [current] => 43731dd5f17a048112ea5109b40b02ec019b3ee2324385a0f448e3bd2264cb13dc160ab018d893f92f8e2f168fd09009b51578c8c6b97a02a1617c67ac087701
                        )
                    [core/img/filetypes/drawio.svg] => Array
                        (
                            [expected] => 
                            [current] => 92e0974cf869bf8ab969c3442dc2b80d55fde36441d22924db74916a06b407520aa2a9dc39336f9157195ebede697ffac0e639360879255ab91932d406e1897d
                        )
                )
        )
)

core/js/mimetypelist.jsがバージョン不整合を起こしていることが分かるので、NextCloud（https://nextcloud.com/changelog/）から28.0.1のbzip2ファイルをダウンロードし、nextcloud-28.0.1\nextcloud\core\js\mimetypelist.jsをhtml\core/js/mimetypelist.jsに上書きする。

html\core/img/filetypes/dwb.svg、html\core/img/filetypes/drawio.svgはexpected（必要なファイル）のハッシュ値が空欄である事から、そのまま削除する。

監理者設定の画面を開き”再スキャン”をクリックすると、再度整合性チェックが行われる。これで”一部のファイルは整合性チェックに合格していません。～”の表示が消えた。

“468 error in the logs issu”の方も気になるのでログを確認すると、”Temporary directory /var/www/html/temp is not present or writable”との表示が並んでいた。

以下のコマンドを実行してtempフォルダを作成する。

sudo mkdir .\html\temp
sudo chown www-data:www-data .\html\temp