SVX日記

　翌日の水曜日の朝、痛みが出ていない隙に泌尿器科に行くと、やはり結石とのこと。レントゲンから直径3mmくらいとわかる。前回の倍の大きさだ。ここまでくると、体験版のレベルでなく、キッチリと製品版といったところか。しかし、位置はまだ上流の方とのこと。結石を排出しやすくする薬と、鎮痛剤のロキソニンをもらって帰宅。しかし、夕方からまた激痛。鎮痛剤なんて効きやしねぇ。

　翌日の木曜日は、終日なんでもなかったものの、その次の日からは、日に数回の激痛。ガキの運動会と法事というイベントを棒に振り、結局、悶絶の一週間を過ごした。

　寝ている時にも痛みを感じているためか、妙な夢を見る。車で自宅に帰る段になって、カーナビで帰宅ルートを検索すると、狭い道を山の向こうへ抜けるルートしかないと出るが、その途中、居酒屋の中を通り抜けるので注意とある。実際に向かってみると「居酒屋 TURU HALL」という暖簾を掛けた店が道を塞いでおり、そこを車に乗ったまま通り抜けることに。慎重に進むが、あまりの狭さに客の足を踏んでしまい「イテェ！」と怒られる……これ、どう考えても尿路結石のイメージそのままではないか。しかも「THRU HALL」て、我ながらシャレがキツい……。

　痛みは月曜まで続いたが、その後は違和感のみで、激痛はなし。水を飲むと良いというので、がんばって飲むが、そもそも、ガブガブ飲むのは小便が近くなるので好きじゃないんだよな。

　一応、石が出たら確保しようと、トイレではちょっと気をつけていたのだが、一向に出る気配がない。いつの間にか出てしまったのではないかと、ほぼ、あきらめていた金曜の夕方……ポロッと。おぉ！

　運良く小便器の上に乗ったが、ちょうど隣に人が居て、拾うのがためらわれる状況。こういう時に限って、隣の小便が長いのだ……終わった！サッと拾って、ジャっと洗って確保成功。なるほど、結構、デカい。コイツのためにエラい目にあったぞ、まったく。真ん中のデカいのが今回の。左の2つは前回、前々回の。

　しかし、製品版の結石は、クリアに優に一週間以上もかかるのかよ……いろいろと予防する方法を調べたが、どれもあまり有効そうじゃないんだよなぁ。とほほほ……。

[ツッコミを入れる]

2017-06-10(Sat) 高機動高火力スピーカユニット「デンドロビウム」ロールアウト

　先日、既成のブックシェルフスピーカをモバイル仕様に改造したのだが、目指す完成形は、ほぼスピーカ単機での楽曲再生能力、および、Bluetoothスピーカとしての任務をも果たすことなのであった。

　というわけで、かなり前にアリエクに発注し、既に届いていたmp3/flac/Bluetoothオーディオアンプモジュールを、アレコレと当てがい、最適な実装の形を模索しつつ、最終的には秋月から購入した透明なプラスチックケースの中に、aitendoの3.7V/850mAhリチウムポリマ充電池と共にパッケージングしたのであった。

　実は、アリエク以前に、同じ用途のためにコレも入手していたのだが、IRのパターンにセンサをつないでも、既存の赤外線リモコンに反応しないようなので、赤外線リモコン付属で安価なアイテム2点(もう1点)を手配していたのであった。

　結果、リモコンの信号は、いずれも既存のものと同じで、手元に同じリモコンが3つ存在することになってしまった。まぁ、別にいいんだけど。

　動作のテスト中、microSDカード関係でひと悶着あったが、特に問題なく動作した。このモジュールは、ちゃんとflac形式も再生でき、曲の再生中に電源を切ると、次に電源を投入した場合には、その曲の頭から再生する仕様である。残念なことに音量は記憶してくれないが、とんでもなくデカい音で起動するわけではないので、まぁ、問題ない。動作モードの読み上げも、中国語でなく、英語音声だ。

　動作が確認できたので、モジュールを装着する。場所は、左スピーカの側面だ。つまり、見た目、線のつながっていないピュアスピーカなのにガンガンと音が鳴っている、というアイテムのできあがりなのである。リモコン一発でBluetoothスピーカにも変化。右スピーカの付け外しもサクッとできる。これは使い勝手がいい。

　まさに、システムの中核をなす極小のユニットと、それに比較して巨大なスピーカとで構成されるスタイルは、某「サウンドフォース」というレベルを超越し、もはや某「デンドロビウム」なのであった。

　ちなみに、電源を切った状態にすると、上部のピンフレームがイネーブルになり、そこからリチウムポリマ充電池に充電することができる。充電器は以前に作ったもので、充電風景はこんな感じ。コンセントの近くにスピーカごと移動する必要があるが、ハンドル付きなので機動力抜群であり、何の問題もないのであった。

　うむ、ほぼ思い描いた通りのオーディオ機器に仕上がったといえよう。バージョン2、完成！

[ツッコミを入れる]

2017-06-14(Wed) 世にも奇妙なmicroSD

　先日、某サイトから、安価な16GBのmicroSDカードを購入した。さほど、厳格に用途を決めていたわけではないし、とりあえず工作中のmp3プレイヤにでも使ってみようと、Windows10マシンでFAT32フォーマットし、Linuxマシンからmp3ファイル、flacファイルを書き込み、mp3プレイヤに挿し込んだ。

　 ……あれ？いきなり1曲目の途中から再生された……ような……早送りすると、2曲目以降は普通だが……あれ？十数曲目以降が、1曲目の途中からの再生ばかりになってしまう。……なんだこれ？

　 mp3プレイヤの側も工作中なこともあり、どっちが異常なのかわからない。とりあえず、microSDを抜いて、Linuxマシンに挿し込むと……スーパーブロックが壊れているって？ ……なんだこれ？

　 LinuxマシンでFATを扱ったことがマズいのかしらん？と、思い、ファイルの書き込みまでWindows10マシンで完結させても、やっぱりおかしな症状が出る。いろいろと試してみると、microSDカードを挿して、書いて、抜いて、挿すと、もう、書いた内容がおかしくなっている。これ、microSDカードがおかしいんやないか？

　以前に「抜くと元に戻るSDカード」を経験して以来「ここ一番にはSanDisk」を励行してきたのだが、それを外した途端にトラブるもんかねぇ。

　購入元に連絡したところ、即座に代品を送ってくれ、翌日には代品が手元に届くという素晴らしい対応だった。んが、不良品を返送する前に、再テストしてみたところ、なんと、代品にも同じ現象が出てしまった。どうも、ある程度の容量を書き込むと、microSDを抜き差しせずとも、先頭部分がブッ壊れるっぽい。

　と、ここでピンときた。以前に、見た目はxxGBなのに、実際にはxxGBの容量を持たない詐欺的なSDカードがあると聞いたことがある。改めて考えれば、一定の場所でループ構造にしている、つまり、上位ビットを捨てることで実現している、と考えるのが妥当なわけで、そうであれば今回の事象に合致する。

　というわけで、こんなプログラムを書いてみた。デバイスの先頭からシーケンシャル番号で領域を書きツブしながら、先頭部分の変化を監視する、というものだ。

 #!/usr/bin/env ruby
 
 # SD カードチェッカ
 
 class Integer
     def to_h
         sprintf('%d', self).to_s.reverse.scan(/.{1,3}/).join(',').reverse
     end
 end
 
 dev = ARGV[0]
 check_max = 8 * 1024 * 1024 * 1024                              # 8Gbytes
 puts('device = %s, check_max = %16s' % [dev, check_max.to_h])
 
 adr = 0; open(dev, 'w') {|fh|
 
     last_md5 = nil; while(adr < check_max)
         puts('%16s .. ' % adr.to_h)
 
         chunk = ''; (1024 * 1024 / 8).times {                   # 1Mbytes
             chunk << [adr >> 32, adr & 0xFFFFFFFF].pack('N*'); adr += 8
         }
         fh.write(chunk)
         fh.fsync
 
         system('dd if=%s of=/tmp/_sdcard_checker_ bs=4096 count=1 iflag=direct >/dev/null 2>&1' % dev)
         md5 = `md5sum /tmp/_sdcard_checker_`.split(/\s/)[0]
         puts('  %s %s' % [md5, last_md5])
         last_md5 and last_md5 != md5 and raise('Unmatch!')
         last_md5 = md5
     end
 }
 
 puts('%16s finished.' % adr.to_h)
 
 __END__

　イザ、実行ッ！

# sdcard_checker /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
  fa9971f35ad33faaaf100800b4b85b8c 
       1,048,576 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
   1,609,564,160 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
   1,610,612,736 .. 
  fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :

　 ……んが、1.5GBくらい書いても先頭部分に異常が出ない。そんなバカな。もしかして、よく読まれる部分を避けるとか、そんな高度な詐欺行為を働いている？

　それならばと、プログラムを変更してみた。今度は、同じようにデバイスの先頭からシーケンシャル番号で領域を書きツブしながらも、先頭部分だけでなく、書きツブした部分をトビトビに監視する、というものだ。イザ、実行ッ！

 #!/usr/bin/env ruby
 
 # SD カードチェッカ 2
 
 class Integer
     def to_h
         sprintf('%d', self).to_s.reverse.scan(/.{1,3}/).join(',').reverse
     end
 end
 
 dev = ARGV[0]
 check_max = 8 * 1024 * 1024 * 1024                              # 8Gbytes
 #check_step = 128 * 1024 * 1024                                 # 128Mbytes
 check_step = 63 * 1024 * 1024                                   # 63Mbytes
 puts('device = %s, check_max = %16s' % [dev, check_max.to_h])
 
 adr = 0; open(dev, 'w') {|fh|
 
     check_md5s = {}; while(adr < check_max)
         puts('%16s .. ' % adr.to_h)
 
         chunk = ''; (1024 * 1024 / 8).times {                   # 1Mbytes
             chunk << [adr >> 32, adr & 0xFFFFFFFF].pack('N*'); adr += 8
         }
         fh.write(chunk)
         fh.fsync
 
         check_adr = 0; while(check_adr < adr)
             system('dd if=%s of=/tmp/_sdcard_checker_ bs=4096 count=1 skip=%d iflag=direct >/dev/null 2>&1' % [dev, check_adr >> 12])
             md5 = `md5sum /tmp/_sdcard_checker_`.split(/\s/)[0]
             check_md5s[check_adr] ||= md5
             puts('%16s %16s %s %s' % [check_adr.to_h, check_adr >> 12, md5, check_md5s[check_adr]])
             check_md5s[check_adr] != md5 and raise('Unmatch!')
             check_adr += check_step
         end
     end
 }
 
 puts('%16s finished.' % adr.to_h)
 
 __END__

　出た。128MBトビトビに監視していたら、256MBを書いた直後、書いたばかりの部分がブッ壊れる症状が出た。

# sdcard_checker2 /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       1,048,576 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
     267,386,880 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456            65536 ba2930882b4da3d3ddd5b8697fc127d5 ba2930882b4da3d3ddd5b8697fc127d5
     269,484,032 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
     134,217,728            32768 01517d88da540a8eb5d44af02f122649 01517d88da540a8eb5d44af02f122649
     268,435,456            65536 5aa7b9d34285ac27f76b54f5ff4560fc ba2930882b4da3d3ddd5b8697fc127d5
/home/mitsu/develop/petit_tools/sdcard_checker:33:in `block in <main>': Unmatch! (RuntimeError)
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `open'
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `<main>'

　試しに。中途半端に63MBトビトビに監視してみても、256MBチョイを書いた直後、書いたばかりの部分がブッ壊れる症状が出た。

# sdcard_checker2 /dev/sdb
device = /dev/sdb, check_max =    8,589,934,592
               0 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       1,048,576 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       2,097,152 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       3,145,728 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
       4,194,304 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
    :
    :
    :
     329,252,864 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440            80640 f005f81d5ee41aa397fc39db563060fe f005f81d5ee41aa397fc39db563060fe
     331,350,016 .. 
               0                0 fa9971f35ad33faaaf100800b4b85b8c fa9971f35ad33faaaf100800b4b85b8c
      66,060,288            16128 2ed7a89c5a42bb4040bff4894be82bdb 2ed7a89c5a42bb4040bff4894be82bdb
     132,120,576            32256 919cfe23e7079f9077e4360ad127f628 919cfe23e7079f9077e4360ad127f628
     198,180,864            48384 c5d3ae3f1ac1b256bb20b044cc491719 c5d3ae3f1ac1b256bb20b044cc491719
     264,241,152            64512 dc83f09e6ee934dcc90677af587a629d dc83f09e6ee934dcc90677af587a629d
     330,301,440            80640 d207d5474108dac6a8961a17d6f73fa2 f005f81d5ee41aa397fc39db563060fe
/home/mitsu/develop/petit_tools/sdcard_checker:33:in `block in <main>': Unmatch! (RuntimeError)
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `open'
	from /home/mitsu/develop/petit_tools/sdcard_checker:17:in `<main>'

　この症状は、代品もまったく同じで、これはもう仕組まれたものと考えて間違いないだろう。要するに「容量偽装」というわけだ。まぁ、ウェアレベリングの仕組みに意図しない不具合があった、という見方もできなくはないけれど。無理に、先頭部分のみパーティションを確保して使う方法もあろうが、さすがに256MBじゃ、いまどき使い物にならんわな。

　しかし、悪意だと仮定して、ここまでしてクソ製品を売ることにどれほどの意義があるんだろう。これをカメラに挿して旅行に出かけた人がどれほど悲しいことになるか、考えたことはあるんだろうか。販売店にも迷惑がかかるし、そもそも貴重な資源をクソの山にすることに罪悪感はないのだろうか。いったい誰が得をするっていうんだ。

　ったく、時間の無駄だったぜッ!! などと悪態をつきながらも、ここ数日、心のどこかで、やや楽しみながらこういう試行をして記事にしてしまったオイラは、やや得をしたのかもしれんけど……。

[ツッコミを入れる]

2017-06-22(Thu) ようやくS+昇格

　本格的にスプラトゥーンを初めて、1年半弱。ようやくウデマエS+に到達した。ウデマエSになったのが昨年の5月。1年以上もかかった。

　得物はほぼ一貫してハイドラントカスタム。当初はヒト速特化型から、途中、攻撃力、インク回復、ヒト速バランス型に変更した。

　ずっと、毎晩2時間くらいプレイしていたのだが、ここ1ヶ月くらい、ちょっとテンションが下がってきて、ややあきらめかけていたところなので、昇格できたのが不思議なくらいだった。

　今晩のステージは、ショッツルとモンガラのエリア。ショッツルはかなり得意なステージ。S78からスタートして、5k3d勝で82、4k2d勝で86、10k5d負で80ときた。味方全員ひどいキルレで、10k5dなのに負けかよ、と、初めて食らった-6を苦く受け止め……このパターンは、ヘボ味方を押し付けられる流れかも……と思ってヤメようかと思いつつも、もう少し続けたところ、9k3d勝で84、4k4d勝で88ときた。おぉ？

　 3連勝したら昇格だが、そうそうウマくいくわけがないしな、と引き気味の気持ちで、9k4d勝で92、3k3d勝で96ときた。え？マジ？しかし、昇格戦には鬼が潜むというし……えぇい、やってまえ!!

　今晩はモンガラは1度だけで、昇格戦もショッツル。あ、あれ？味方ムチャ強い。後ろから牽制するくらいしか、仕事がない……これ、何もしなくてもイケるのでは？ ……時間を余らせてノックアウト……あ、上がってしまった……1k1d勝で……こんなにあっけなく？

　今晩は終了。総プレイ時間は800時間弱。といっても、3回くらいサブアカ作って少し遊んでいたこともあり、実質的には800時間は超えているかも。800時間か。間違いなく、これまでのゲームの中でダントツのプレイ時間だが、この時間は、有意義だったのか、無駄だったのか？

　まぁ、有意義ではないだろうが、いろいろな「気付き」が得られたことに違いはない。

　まず、自分が決して上手いプレイヤではないということ。マルチプレイヤのゲームは、ひとりで遊ぶゲームとは違い、容易に酔わせてくれない。ネットを見ていると、S+昇格に800時間もかかっている人は、あまり見ない。歳を取って、反射神経が落ちているのも多分にあるだろうけど。

　確率は偏るのが普通ということ。意図的な要素がゼロではないだろうが、苦手なステージばかり続いたり、ヘボ味方ばかり続いたり、チャージャーばかり集まったり。んが、考えれば、8人でマッチングしているのだから、自分だけマークされているワケもなく、偶然の要素が強いのだろうと思う。そして、これは、実際の人生にも起きうると気付けたことは、有意義だった。

　 4人の場合、1人がヘボだと、ほぼ勝てない。5000試合以上していて、4対3で勝ったことは、数回しかなかった。これも、実際の人生にも起きうることで、1人のヘボをフォローするには、3人ではぜんぜん足りないということだ。これも有意義な気付きといえよう。

　そして、似たような作業でも、ひたすら繰り返せば、徐々にでも腕前は上がっていくということ。明らかなことは言えないし、その自覚もないが、間違いなく、今回の結果はそれを示しているのだと思える。これもかなり有意義な気付きといえよう。

　さて、800時間もかけて得た気付きとしては、有意義だったとは言えないかもしれないが、他に何をして得られる気付きということを事前に知ることもできないわけなので、それでなんとなく納得しておこう。

　スプラトゥーン2発売まで1ヶ月を切っての昇格で、喜ばしくもあるが、S+の道のりはまだ続いている。しかし、何となく、甲子園出場を果たして、夢を叶えてしまった球児のような気分になってしまったのも確かだ。

　うーむ、感慨深い……。

[ツッコミを入れる]