共有するEXCELファイルは「ZIPファイル」にする

部内で使うような簡単なツールをEXCELで作成した場合や、テンプレートファイルを作成した場合、配布方法には注意しなければならない。ファイルサーバに置いたり、Sharepointに置いたりするわけだけれど、置いたが最後、誰に壊されるかわからないのだ。

EXCELで作成するようなツールは、大体の場合、「計算式」や「リストの参照先」を持っている。リテラシーが低いユーザはそんなことを考えもしないので、計算式を値で上書きしてくるし、「リストの参照先」を削除したりする。そしてそのまま、サーバ上、Sharepoint上で上書きをするのだ。なので、一般的には「ファイルを上書きできない権限」だけ与える、EXCELで上書き警告設定を行う等、上書きをできないような対策を行う。
EXCELファイル側では、計算式セルを保護したり、参照先シートを非表示にしたりするような対策を行う。
なんだけれど、ツール作るときや配布するときに、いちいち毎回このような対策を行うのは非常に面倒なのだ。
オリジナルツールをどこかほかのところに保存しておくのもよいけれど、それは2重管理になってしまうのでやりたくない。履歴管理するのもよさそうだけれど、ファイルサーバの履歴管理は「壊れたことにすぐ気づけた」場合には役立つけれど、数か月後に気づいてしまったら、履歴自体が消えてしまうし、そもそもやり方を教えるのもめんどくさい。
そんなもろもろの対策より簡単なのが「ZIP」で提供することだ。

ZIP化することによって、
①オリジナルは保護される。
②コピーは（解凍することで）各自が保有する。
③コピーが破壊されてもオリジナルには影響がない。
という状態を保つことができるのだ。

なので、「EXCELでテンプレートやツール作ったときは、できるだけZIP化して提供するとよいですよ」という話でした。
たいていの場合「壊れた？知らんがな、元ファイルがここにあるから、解凍して使いな」で対応完了する。

まあ、こんな感じでいいんじゃないかと思う。

とあるネカフェの最適化行動

数年ぶりに池袋のジュンク堂に行ったのだけれど、書店は時間を忘れる場所なのでつい長居してしまい、池袋駅に戻ってきたらヘトヘトになっていることに気づいた。

カフェで休憩してから帰ろうと思ったのだけれど、この暑さと、インバウンドだかなんだかで、やたらと混んでいる。まあしょうがないので、諦めて帰ろうと思ったが、ふとネカフェってあまり行ったことないなと思い、何事も経験なのでネカフェに寄ってみた。

個室入場料金1時間550円とのことだったので、下手すると一般的なカフェより高くつくなあと思ったのだけれど、入場してからネカフェは本気出してきた。店舗によって異なるのだろうけれど、このネカフェはドリンク飲み放題タダ、カレー食い放題タダだったのだ。

部屋は死ぬほど狭いので、気持ちはリフレッシュされないのだけれど、食事と飲み物と足を休める場所とで体力は回復した。

しかも、滞在時間が30分のプランまであり、個室でなければ最低価格200円。このプランでもフリードリンク、カレー食べ放題。ここまで来ると意味がわからない。

 

多分ネカフェって、短時間で低コストに体力回復するという目的であれば、最適な場所なのだと思う。いやとにかくすごいね。設備がお金を産まない時間を、極限まで減らすための採算設計なんだろうけれど、原価割れサービスの最たるものじゃないだろうか。

 

逆に言えば、正直長時間いる場所じゃない。ホテルやアパートがわりなんてもってのほかだ（個人の感想です）。なんというか、超高齢化社会になったディストピア*1感がすごいのだ。

*1:科学の発達で人が死ななくなった時代の人管理方法っぽい

SSDってHDDよりファームの問題多いよね

最近見た障害情報の中で、興味深かったのが「SSDが同時に3本壊れてシステム障害になった」というケースだ。
HDD*1でも無いのに3台同時破壊なんてあり得るのかね？まあ、RAID崩壊*2を3台同時破壊と表現するのであればそんなことも起こるかもしれないが、いまどきバッテリーを積んでいないRAIDコントローラなんて採用しないだろうし、SSDが壊れたといっている以上、RAID崩壊が原因ではなく、少なくともSSDの物理破壊か論理破壊が原因だろう。*3

同時に発生する物理破壊といえば、地震か過剰な電力だろうけれど、データセンターに入れておけば大体問題ないと思われるし、そもそもSSDは地震の影響は少ない部品なので、物理破壊はあまり考えられないのではないだろうか。つまりは、論理破壊が同時に発生したということだ。

同時に発生する論理破壊って何だろうと考えるとき、思いついたのは「n日問題」だ。「n日問題」は私が勝手に名付けた問題で、定義は「稼働後n日経過すると、必ず障害が発生するという問題」のことだ。497日問題の亜種が大量に存在するので、それをひっくるめて表現するために、でっち上げた。そういえばSSDにもn日問題が存在したはず、、、と思って調べたところ、
32768時間問題と40000時間問題と70000時間問題が見つかった。発生年から考えると、おそらく40000時間問題が原因だろう*4。

推測に推測を重ねてしまうが、SSDでRAID6を構築していたが、40000時間問題によってSSD3本の同時論理破壊が発生したことによって、RAID6では対応できず、システムが停止してしまったということではないだろうか。

重要なのは、「おなじ構成だったら、全サーバでおなじような障害が発生するよ」ってことだ。国内メーカーはすでに中規模以下のIAサーバ(Intel互換サーバ)を作っていない。実は現在の中規模以下のIAサーバは、ほとんどがHPE社などのOEM製品なのだ*5。だからNECのサーバだろうが日立のサーバだろうが、HPE社のサーバで起こる問題は、ほかの国内のメーカサーバで発生する可能性がある。

なので、
①ここ3年前から5年前くらいに構築した
②Intel互換の物理サーバで
③SSDを使用している
を満たしたサーバについては、おなじようなことが起こる可能性があるので、一応しらべておいたほうがいいんじゃないの？と思った次第である。まあ、NECも富士通も日立も、多分自分が販売した顧客については、情報を通知しているだろうから*6、多分問題があるとしたら、通知情報を無視した顧客側になってしまうのだろうけどね。

*1:HDDは衝撃に弱いので、地震などで同時破壊はありうるし、縮退（1台破損または2台破損）を放置して、3台目も破壊はありうる

*2:瞬停などに起因してRAID内部のつじつまが合わなくなる現象

*3:RAID崩壊は原因でなく結果

*4:2023年10月10日 - 40000時間 = 2019年3月18日で、導入年が平成31年であることに一致する。違っていたらごめんなさい

*5:日本のサーバメーカーは、現在フロントベゼル（サーバー前面の「社名が入ったガード」）メーカーになっている（笑）

*6:さすがにこの事例見て通知しないメーカーはないだろう

イベントの翌日 無線LANがつながらなくなる

昔、社内のイベントフロア*1で無線LANがつながりにくくなることがあった。特に頻繁に発生するわけではなく、数か月に1回程度だけれども。情報システム部に訴えても何もしやがらねえので、個人的に調査を行ったところ以下のことが分かった。

・この現象が発生すると、9割近くの端末がつながらなくなる。
・アクセスポイントが死んでいるわけではない。そもそもアクセスポイントは大量にあるので、9割もつながらなくなるわけがない。
・PCを見てみると、実は無線LANはつながっているが、IPアドレスが払い出されていないことがわかった*2。
・DHCPサーバの問題を疑ったが、情報システム部でもないのでDHCPサーバを調査することができない。
・しつこく無線LAN接続をリトライすると、IPアドレスが払い出されることがある。

以上のことから、アドレスプールの枯渇が原因であることが考えられたが、前述した様にDHCPサーバの調査する権限を持っていないので、調査は行き詰った。フロアごとに異なるアドレス帯が設定されているので、そもそもアドレスプールの枯渇なんて、そのフロア内の同時接続が圧倒的に多くなければ*3発生しないはずだ。

しかし、現象が発生しているフロアに行っても、人が多くいるわけではない。とくに大きなイベントも開催されていないのだ。そこで気がついたのが、「昨日は大きなイベントがあった」ということだ。ということは昨日のIPアドレスが、まだ解放されていないのではないか。

そこで、無線LANがつながっているPCを調べたところ、驚いた。IPアドレスのリース時間が48時間になっているではないか。どこのバカが設定したDHCPサーバなのか。このDHCP設定見直せよと情報システム部*4に訴えても何もしやがらねえので、放置するしかなかった*5のだが。その後何年か経過し、DHCPサーバのIPアドレスリース期間は1時間程度に短縮されたようだ*6。

一般的に、通常業務を行うフロアでは、DHCPのIPアドレスのリース時間が長く設定されていても、大きな問題は起こらないことが多い。無線LANを使用するユーザは限られており、そのフロアに大量の新規ユーザがなだれ込んでくることはそうないので、IPアドレスの使用数はあまり変わらないからだ。しかし、イベントフロアは別だ。イベントフロアは「昨日のユーザと今日のユーザが全く異なる」「午前のユーザと午後のユーザが全く異なる」ということが頻発する。ということは、長くとも1時間程度でIPアドレスを解放しないと、IPアドレス不足が簡単に発生してしまう。

結局何が言いたいのかといえば、DHCPサーバのIPアドレスリース期間は、デフォルトを使用せず、短くしとけよハゲということだ。

*1:小中大のイベント開催可能、基本小イベント実施するが、中規模や大規模イベントを実施する場合は会場のしきりを移動させて任意の広さに変更

*2:APIPAを取得していた

*3:一般的には250以上の端末が同時接続していなければ

*4:当社の情報システム部は親会社の情報システム部で、親会社は超縦割りなのであまりいうことを聞かない

*5:厳密には有線LANで凌いだ。有線LANは固定IPアドレスなので、イベントごとに固定IPアドレスを割り当てて、そのIPアドレスを使用させた。

*6:多少話が分かる情報システム部のメンバー（やる気はあるが権限がない）に確認してみたところズバリだった

70巻以上の漫画

年に２回くらい巻数が多い（超長期連載の）マンガを数えて、まとめ記事にエア引用されるシリーズ。

尚、シリーズの集計は「外伝」と思われるものを除外します。
○が単独。△が単独でも70越え。☆がシリーズ。

識別子 タイトル 巻数 継続 備考
○ ゴルゴ13 212
☆ ドカベン 205 完 「ドカベン(48)」、「大甲子園(26)」、「プロ野球編(52)」、「スーパースターズ編(45)」、「ドリームトーナメント編(34)」
○ こち亀 201 完
○ ミナミの帝王 177 ただし、「ヤング編(6)」、「ヤング編 利権空港(3)」を含まない
○ クッキングパパ 169
☆ 刃牙 150 「グラップラー刃牙(42)」「バキ(31)」「範馬刃牙(37)」「刃牙道(22)」「バキ道(17)」、「刃牙らへん(1-)」」で外伝を含まない
☆ 銀牙 148 「流れ星 銀(18)」、「WEED(60)」、「WEEDオリオン(30)」、「LAST WARS(22)」、「ノア(17)」、「レクイエム(1-)」を含み、「赤目(3)」「少年伝説(3)」を含まない
☆△ キン肉マン 142 「キン肉マン(85-)」、「キン肉マン2世(29)」、「キン肉マン2世 究極の超人タッグ編(28)」
○ はじめの一歩 140
☆ ジョジョ 133 「ジョジョの奇妙な冒険(63)」「ストーンオーシャン(17)」「スティール・ボール・ラン (24)」「ジョジョリオン(27)」「ジョジョランズ(3-)」
○ 江戸前の旬 124 ただし「旬と大吾(3)」を含まない
○ 鬼平犯科帳 121
☆ 超人ロック 120 完 巻数は推定
○ 天牌 116 完? ただし天牌外伝(37)を含まない）
☆ コボちゃん 115 「コボちゃん(60)」、「新コボちゃん(55-)」
☆ キャプテン翼 114 完 「キャプテン翼(37)」「ワールドユース編(18)」「ROAD TO 2002(15)」「GOLDEN-23(12)」「EN LA LIGA(6)」「ライジングサン（20）」あと短期連載が3冊。岬太郎を含まない
○ 釣りバカ日誌 113
○ 浮浪雲 112 完
○☆ 静かなるドン 111 「静かなるドン(108)」、「もう一つの最終章(3)」
○ 美味しんぼ 111
○ 弐十手物語 110 完
☆ 島耕作 109 「課長(17)」、「部長(13)」、「取締役(8)」、「常務(6)」、「専務(5)」、「社長(16)」、「ヤング(8)」、「係長(4)」、「会長(13)」、「相談役(6)」、「学生(6)」、「就活(3)」、「社外取締役(4-)」
○ ONE PIECE 108
☆ 白竜 107 「白竜(21)、「LEGEND(46)」、「原子力マフィア(2)」、「HADOU(38-)」
○ あぶさん 107 完
☆ 千里の道も 106 完 「千里の道も(45)」、「新(16)」、「第三章(39)」、「修羅の道(6)」
△☆ MAJOR 106 「MAJOR(78)」、「2nd(28-)」
○ 名探偵コナン 105
○ パタリロ 104 ただし、右に記載する外伝４シリーズを含まない「西遊記(8+1)」「源氏物語(5)」「家政夫シリーズ(5)」「パパ(1)」
☆ 浦安鉄筋家族 102 浦安鉄筋家族(31)」、「元祖(28)」、「毎度(24)」、「あっぱれ(19-)」
☆ ドクターK 101 「スーパー(44)」、「Doctor K(10)」、K2(47-)
○☆ あさりちゃん 101 「あさりちゃん(100)」、「5年2組」
☆ コータローまかりとおる 94 「コータローまかりとおる(59)」「新コータローまかりとおる 柔道編(27)」「コータローまかりとおる L(8-?)」
○ いのちの器 93
☆ カイジ 91 「黙示(13)」、「破戒(13)」、「堕天(13)」、「和也(10)」、「ワンポーカー(16)」、「24億(26-)」
○ ふたりエッチ 91
○ 弱虫ペダル 90
☆ 金田一事件簿 90 「少年シリーズ(70)」、「37歳(16-)」、「30th(4)」
☆ 怨み屋本舗シリーズ 87 「怨み屋本舗(20)」、「巣来間風介(6)」、「REBOOT(13)」、「REVENGE(11)」、「EVIL HEART(9)」、「WORST(21)」、「DIABLO(7-)」
☆ テニスの王子様 84 「王子様(42)」、「新(42-)」
○ 土竜の唄 84
○ 風の大地 84 完
☆ 味いちもんめ 83 「味いちもんめ(33)」、「新(21)」、「独立編(10)」、「にっぽん食紀行(6)」、「世界の中の和食(2)」、「継ぎ味(11-)」
☆ 鉄拳チンミ 83 「鉄拳チンミ(35)」、「新鉄拳チンミ(20)」、「Legends(28-)」を含み、外伝(4)を含まない
☆ タフ 81 完 「高校鉄拳伝タフ(42)」、「TOUGH(39)」を含み、「龍を継ぐ男(31-)」を含まない)
○ なんと孫六 81 完
○ 山口六平太 81 完
○ G・DEFEND 78
○ ゼロ 78 完
○ 銀魂 77 完
☆ 釣りキチ三平 77 完 「釣りキチ三平(65)」、「平成版(12)」
☆ DEAR BOYS 76 「DEAR BOYS(23)」、「ACT2(30)」、「ACT3(23)」、を含み「OVER TIME(3)」「ACT4(12-)」を含まない
○ まるごし刑事 75 完
○ BLEACH 74 完
○ キングダム 72
☆ かっとび一斗 72 完 「かっとび一斗(46)」、「風飛び一斗(26)」
○ NARUTO 72 完
☆ 男塾 72 「魁(34)」、「暁(25)」、「極(7)」、「真(6)」
☆ センゴク 72 完 「センゴク(15)」、「天正記(15)」、「一統記(15)」、「権兵衛(27)」
☆ 神の雫 72 完 「神の雫(44)」、「マリアージュ(26)」、「deuxieme(2)」
○ 黄昏流星群 71
○ 夕焼けの詩 71
○ DREAMS 71 完
○ 王家の紋章 70

次回用メモ


電子書籍のみ

識別子 タイトル 巻数 継続 備考
○ 解体屋ゲン 106
○ なみだ坂診療所 102 完
○ ハートのしっぽ 75 完

一部電子書籍のみ

識別子 タイトル 巻数 継続 備考
☆ 特命係長只野仁 94? 「特命係長(9)」、「新(20)」、「ファイナル(52)」、「ルーキー(12)」、「大人味(1?)」


※超人ロックはこちらのid:soorceさんによりカウントされた93巻以降、風の抱擁が(3)+4、ホリーサークルが(1)+2、刻の子供達が+3、ラフラールが+4、ドラゴンズブラッドが+4、鏡の檻が+5、ガイアの牙が+3、カオスブリンガーが+1。または、こちら参照
※シティハンターシリーズはシーケンシャルな物語でないので、集計から除外。
※金田一シリーズはこちら
https://ja.wikipedia.org/wiki/%E9%87%91%E7%94%B0%E4%B8%80%E5%B0%91%E5%B9%B4%E3%81%AE%E4%BA%8B%E4%BB%B6%E7%B0%BF

警報が鳴れば電源を切る

夏の風物詩といえば、「教師によるプールの水出しっぱなしと高額請求」ではないだろうか。
IT業界の人々は「警告だせばいい」とか「満タンになったら自動で止めればいい」とかいうのだけれど、ことはそう単純でもなかったりする。特に昨年川崎で発生した事例は、そんな手法では解決できなかったのだ。

川崎市の報告書

2023年の8月に川崎市で発生した「プール水止め忘れ」問題は非常に興味深い事例だった。
資料はこちら
https://www.city.kawasaki.jp/templates/press/cmsfiles/contents/0000153/153608/houdouhappyou.pdf

簡単に言えば、
①プールの水入れ操作（電動）を実行した
②（別要因で）警報が鳴った
③警報止めるためにブレーカー落とした
④プールの水止め操作（電動）を行ったが、ブレーカー落としていたため、水止め操作が実行されなかった

この事例の結論はこうだ。
「どんなに頑張ってエラー防ごうとしたって、電源切られたらお手上げ」

コンパイルエラー、ランタイムエラー

プログラミングを行っている時、よほどの天才でない限りはエラーを経験する。この時に、エラーメッセージが発生するのだけれど、プログラミングの初学者によくみられる傾向として、「エラーメッセージが出たら、そのメッセージを真っ先に閉じる」という行動がある*1。これはエラーメッセージは警報の一種で、警報は人間にストレスを与えるため、ストレスを回避するための行動だろう。

今年の4月にtwitter上で、こんな話が合った。
｢エンジニアって一生エラーと付き合っていくの、、、、？耐えられる、、、、？｣→｢プログラミング苦手な理由として、自分が責められてるみたいだからエラーメッセージ読むのがストレスみたいなこと言ってた人が昔いたんだけど、たぶんこのタイプの人たち人間同士でも「率直に問題点を議論する」みたいな時にめちゃくちゃ配慮必要そうでめんどくさいな、と思った。｣ - Togetter [トゥギャッター]
やはり、警報はストレスを与えるし、回避できるのであれば回避したいのだ。

警報音

IT業界でまれに怪談として語られるのが、「毎日かならず17時に停止するサーバ」だ。CPU使用率が特に高くなるわけでもなく、特に温度センサーに異常も発生していないのに、毎日のようにサーバが停止してしまう。どうしても原因がわからないので、17時にサーバの前まで行って確認したら、清掃担当がサーバのコンセントを抜いて、掃除機のコンセントをさしていた。
という笑い話だ。

これに似た話として、1年ほど前に話題になったのが、以下の事例だ。
清掃員がうっかり冷凍庫の電源オフ、25年の大学研究成果が消える - ネット「えっぐ」「考えただけでおそろしい」 | マイナビニュース
冷凍庫のエラー音がうるさいので、清掃業者が電源をOFFしてしまった。

「自分の仕事の妨げになるようなことは、その人の常識内で回避されてしまう。」ということだ。

じゃあどうすりゃいいのって話

考えるべきは「電源切られないような警報の出し方」「簡単に電源切れない仕組み」になる。たとえばトラックの中にはバックの際に、「ピーピー、バックします」という警告音声を出すようになっているものがある。警告音だけでは何の警告なのかわからないから、音声になったのだろう。つまりは「警報がなんの警報なのか、ちゃんとわかるようにする」という対策が最低限必要になる。電源が切られたときの対策としては、ＵＰＳのように「電源が切られたという警告」が出力されることが必要になる。


ということまで考えたうえで思うことは、電源喪失まで考えたシステム構築するより、年1回か2回の水出しっぱなしは許容する方がトータルコストは少なくなるんじゃないだろうか。

だから、警告出したり、自動ストップみたいな対策を行うのは良いけれど
①警告は何の警告で、どう対処すればわかるような警告とすること
②損失が数億円になるとか、生命が脅かされるとかいうケースにいつては、電源喪失警告をだす
③トータルコストがかさむならリスクは許容するのも一つの手だよ

というようなことは考慮するべきなんじゃないかなと思った次第であった。

*1:ちなみにベテランになると、エラーメッセージが出ないと不安になるという傾向がみられる（笑）

Excelテキストコンバータ作成時の気配り

Excelはテキストコンバータとして非常に優秀だ。ある一定のルールに従ったテキストを別のルールに置換する。ちょっとしたルールであれば、関数でなんとかなってしまうし*1、少し複雑なルールであればVBAを使えばよい*2。場合によっては、関数とVBAの組み合わせなんてこともできる。まあ、とにかくEXCELにかなうテキストコンバータはそうあるものではない。

いろいろなVBAで作るテキストコンバータを見てきたけれど、VBAマスタはプログラマだけではなく、スーパーなユーザがなることが多いので、残念ながらちょっとした気遣いが欠けることが多い。以下に、ちょっとした気遣いを記載しようと思う。

・変換終了を表示する

変換が終了したら、ユーザに変換が終了したことを伝えよう。ループ処理終了後に「変換処理が終わりました」というメッセージボックスさえ出すだけで、ユーザの満足度は向上する。メッセージボックスが出ない場合、ユーザは「変換がうまくいかなかった」のか、「変換がうまくいって終了したのか」を認識することができない。

・処理件数を表示する

テキストコンバータは、一般的に複数行のデータをコンバートするのであるが、全行を処理したことがユーザにわかるように、処理対象の件数を変換後にユーザに伝えた方がよい。これは上記「変換終了」表示に含んでもよい。

・変換に長時間かかるのであれば、実行前に「本当に実行するか」ユーザに問う

VBAの起動トリガは、ボタンが多いと思うけれど、ボタンを押下すると問答無用に処理が始まってしまうのはよろしくない。ボタンの押し間違えなんて、簡単に発生するのだから、処理開始してよいかをユーザに問わなければならない。このときに、ボタンのフォーカスは「No」か「キャンセル」に当たっていること。

・変換に長時間かかるのであれば、ループ内にDoEventsを入れる

ループ内にDoEventsを入れておくと、ブレイクが効くのだ。処理を強制的に中断することができる。永久ループも脱出できるのだ。だから、DoEventsをループに入れておくのは極めてお勧めだ。処理を開始してしまったが最後、処理が進んでいるのか、止まっているのかわからない状態に陥ることはよくあるので、DoEventsを入れることをお勧めする。

ーー
まあ、こんなことを注意するだけで、結構使い勝手は向上したりする。ユーザからなかなか出てこない要望なので、ちゃんと対応するといいかもしれない。

*1:例えば、数千件のデータをDBのテーブルに入れたいとき、INSERT文を作成するのような関数を用意する

*2:例えば、1レコードが5行から10行あるようなデータを1行10列に変換したい等