年賀状の宛名書き 2023

年賀状の宛名印刷の宛名データ生成は自作のPerlスクリプトでやってます.元になる住所はLDAP (OpenLDAP) に登録してあります.

何でそんな面倒くさいことをしているかというと,住所の二重登録が嫌だからです.かつてはMicrosoft Accessに年賀状を出す人の宛名を登録してありました.そこでよくあったトラブルは,自分用の汎用のアドレス帳とその年賀状専用のAccessのデータに齟齬が生じたのだけれどもどちらか正しいか解らないという事態でした.

それなら,自分の汎用アドレス帳から年賀状宛名を生成するか,少なくとも自分の汎用アドレス帳と年賀状のアドレス帳を同じツールで見比べることができるようにしよう,と考えました.たぶん2000年頃だと思います.

アドレス帳のデータベースと言えば,LDAPしかないようでした.もちろん,MySQLを使う手もないことはないですが,「同じツールで見比べる」という条件はクリアできそうにないです.

そこで適当にネットのドキュメントを斜め読みしたり,試行錯誤してデータベースを築き上げてたぶん20年間くらい使ってます.

「個人用の汎用のアドレス帳」も,そんなにこれが良いと言うこともなかったのですが,長年Macintoshを使い続け,1000件以上の登録があります1大半は現役時代の仕事がらみの登録で,現在はそのほとんどが無効と思われますが,消す作業はあえてしていません..2011年から運用開始されたiCloudでアドレス帳がMacintosh, iPhone, iPod touch, iPadで同期されるようになってからは,何の迷いもなくiCloudのアドレス帳を使い続けて,メンテもよくしています.

iPhoneやMacintoshのアドレス帳でかつてはOpenLDAPのサーバーに接続できていたのですが,もうずいぶん前のiOSのupgrade時につながらなくなり,以降iOSやmacOSのupgradeのあとなどときどき試していますが利用できていません.

今一番優秀なLDAPのクライアントはMozilla Thunderbirdです.ThunderbirdとmacOSのアドレス帳を立ち上げて比較ができます.

そんなわけでLDAPに登録したアドレスと,今年年賀状を出すか出さないかを記したCSVファイルを照らし合わせて,年賀状を出す人のアドレス帳を吐き出し(CSV),それをLibreOfficeのDataベースに読み込ませて,宛名の差し込み印刷をしています.

いつの頃からかLDAPのslapdを

/path/to/slapd/slapd -h "ldaps:///"

という形で起動して,TLSのポートのみ聞くようにしていました.今回困ったのは,PerlのNet::LDAPがslapdに接続できないことです.TLSのみでもThunderbirdのLDAPクライアントはちゃんと接続できます.

この問題について,ベタな方法としては一旦slapdをkillallなどで止めてから,

/path/to/slapd/slapd -h "ldaps:/// ldap:///"

で起動し直せば解決します.

その後,得意なネットの斜め読み調査で,Net::LDAPの代わりにNet::LDAPSを使えば良いと言うことが解り,よりスマートな形で解決しました.

ただ,現在LDAPサーバーのメンテ方法で困っていて,phpLDAPadminというWeb UIがありますが,一旦開発者が見捨て,PHPのupdateで何年も前に使えなくなりました.その後GitHubでボランティアたちがPHPの仕様変更にだけ対応しているようです.また,上記のLDAPSのみのクライアントにはつなげられないようで,平文接続できるようにしてもエラーが出てデータベースのメンテ作業ができません.

いずれにしても元々のアドレスデータベースの一本化はかなり早い段階であきらめてしまったので,その後の経緯は妥当だったのかどうか考えると微妙ではありますがトラブルなくできているのでよしとします. 一番重要な,汎用アドレス帳とLDAPの年賀状用アドレスリストの齟齬を生じさせないということについては,修正は必ず両方のデータベースに対して行う,メモ欄に修正日を記す,でなんとかなっています.

LDAPという訳の分からないデータベース・デーモンを動かして利用することがむしろ目的化しています.

その後のデータ通信量(2)

B-MobileにMNPしてからのiPhone 14のモバイル通信量についての話の続きです.

適当に感じたところを書いてもしょうがないので,その後のその後は毎朝データを記録しています.

記録しているのは,B-Mobileのサイトに表示される総使用量,iPhoneの設定>モバイル通信に表示される「システムサービス」および,前回怪しいと思ったシステムサービスの中の「書類と同期」です.

日々の総使用量は3〜6MBです.個別では「システムサービス」が一番多いですが,その使用量は総使用量を上回る日もあってあんまりあてになりません.しかし,モバイル通信量のほとんどがこの「システムサービス」であると推測されます.

さらにシステムサービスの内訳ですが,「書類と同期」はその後わずかに0.1MB増えただけです.DNSサービスが地道に増えているように思いますが,記録を取っていないのでなんともいえません😓

その後のデータ通信量

初日に426MBほどデータ通信がありましたが,その翌日,翌々日(一昨日)は,一日3〜4MBでした.たぶんこれが外出は食料品の買い出しとPokémon GOのジム・ポケストップ巡り兼散歩に出かける普通の日の使用量だと思います(Pokémon GOは,別のAndroidスマホでやってます).

昨日は,医療機関の受診に出かけました.ネットの利用的には,処方箋を撮影してLINEで薬局に送ったことくらいですが40MBも食ってました.送った処方箋の写真のファイルサイズはわずか2.1MBです.

先日統計データをリセットしておいたデータ通信量を見てみると, “システムサービス” が40.6MB,そのうち “書類と同期” が34.4MBくってます.

システムのうちの書類の同期っていうとiCloudだと思いますが,全く心当たりがありません.

しばらく様子を見てみます.

初日のデータ通信量

昨日,楽天モバイルからB-Mobile(日本通信)の合理的シンプルプランにMNPしました.その初日にいきなり,400MBもの通信量が発生しています.ほとんどの時間Wi-Fi接続していたにもかかわらずです.

そういえば楽天モバイルの初日もそんな感じでいきなり消費して,1か月では軽く1GBを超えるんじゃないかと不安に思ったのを覚えています.

接続した直後に端末と通信会社の間で大量にデータをやりとりするんでしょうか.

知らんけど.

結局2回線ともB-Mobileに

一時期メインとサブの両回線とも楽天モバイルにしていましたが,2回線目はどっちみち無料にはならないので,今年の春(2022年3月)に日本通信(B-Mobile)の合理的シンプルにMNP移転しました.

楽天モバイルのままにしていた1回線目のほうも,9月から無料枠がなくなり,3GBまで税込み千円強になりました.

楽天モバイルのメリットは,楽天リンクで通話すれば通話料無料になることと,IPv6に対応していることです.しかし,1か月のモバイルデータ通信量は1GBを超えることはないので,3GBまで千円というのはあんまり得ではありません1もし1GBまで500円という料金設定があれば,楽天モバイルにとどまったと思います.

日本通信の合理的シンプルプランのデメリットは,移転の事務手数料3300円がかかる,IPv6が通らないの2点です.

特に後者については,IPv6が通る楽天モバイルは大きなメリットではありましたが,IPv6は光熱水料や食品の値上がりを補えるものではありません😓

また事務手数料も月額料金と比較すると10か月分以上になりますから,馬鹿になりません.楽天モバイルと合理的シンプルの月々の差額700円で,事務手数料を取り返すためには5か月かかります.

それでも,先延ばしにしても得はないので,この際MNPしました.

少しでも安く済ませようとスターターパックを買いました.これで,楽天モバイルとの差額の半月分取り返せます.

楽天モバイルのMNP転出も,日本通信のMNP転入もほぼスムーズに行きました.

日本通信のスターターパックによるMNP転入は,日本通信の “マイページ” からではなく,スターターパックに書かれたURLに書かれた専用URLから行います.最初の手続きの段階でeSIMを選ぶことはできません(当社調べ).

どうしてもeSIMを使いたい場合は開通してから日本通信のサイトで切り替えを申し込むことになりますが,スマホを替えるのに手数料がかかるeSIMを使うつもりはないです.