2020/05/01

スマートフォンのモニター用マウント

スマートフォンをウェブカメラの代用としてモニターに固定する方法を思案して工作してみたが、これが意外といい出来だったので。

モニターはDellのU2720QMで、これにキングジムのDB-200から工作したマウンタを置いて、moto g7を固定したところ。
  • DB-200の前面にある小物入れというか樋部分は、狭額縁のモニターだと表示域にかかり(サイトの説明では5mmとなっているが、実物は6.5mmあった)、かつ間に挟んで上にずらしても庇みたいになって邪魔なので、3mmぐらい残して切除。
  • スマートフォンのカメラの位置をなるべく下げたかったので、g7に合わせて現物合わせで穴を開けて嵌め込むようにした。
  • 固定はg7の軟質ケースの弾性による。
工作自体は単純だが、経験的には、DIYではどうせ精度は出せないので、工作は単純なものほどよい。

穴はg7がモニターの筐体のアールに合う位置にしてあるが、これは先に試して、このアールに合わせると角度的に丁度いいことが分かっていたので。

DB-200の足は角度を無段階に調整できるように見えるが、実際は中にラッチが仕込まれていて無段階ではなかったので、ゴムワッシャーを間に挟んで自由に調整できるようにした。これでカメラの角度を多少調整することも可能という見込み。

正面からはこんな感じになる。

カメラのモニター上端からの距離は22mm程度なので、ボールジョイント付きのウェブカメラと同程度だと思う。位置をこれ以上下げるとカメラの視界にDB-200の前端が入るので、DB-200を削る必要が出てくる。

なお、この状態でもあらかじめアイコンが上に出るよう配置しておけば基本的な操作は可能。

これでスマートフォンの固定自体は満足できる状態になったが、実際に使っているとスマートフォンを代用することによる遅延が気になってきたので(DroidCamXを720pで使用)、注文してあるウェブカメラが到着すれば使用終了の予定。

2020/01/13

Gitのcore.autocrlfの設定

改行コードはWindowsアプリでは便宜的にCrLfに揃えることにしていて、.gitattributesでは「* text=auto」はコメントアウトし、.editorconfigでは「end_of_line = crlf」と設定していますが、にもかかわらず自分が認識しないところでLfに変わっていることがあり、さらにCrLfに修正してVisual Studio上でStageしようとするとStage対象に移動しないまま消える、という問題がしばらく前から起こっていて、少々困っていました。

Git絡みの問題であろうことは想像できましたが、VSの問題か、GitHub Extension for Visual Studioの問題か、Git自体の問題かよく分からず、Gitの設定にある「core.autocrlf」が関係ありそうな気がする一方、説明を読んだ限り関係なさそうに思えたので特に触らずにいました。

それが、まとまった数のファイルをCrLfに修正してcommitした後、PowerShellのCUIからそのcommitを含めてrebaseし、VSでリロードしたら全部またLfに戻っていたという問題が発生したので、思い切って以下のコマンドを実行。
git config --global core.autocrlf false

そうしたら、変な動作が全部消えました。

この設定を意識してtrueにした記憶はないものの、Git環境の構築は何度もやり直してるので、正確なところは不明。Gitの設定への理解不足といわれればそうかもしれませんが、こういう問題が起こるとは想像し難いものがあり、謎動作されるぐらいなら切っておいた方が面倒がないと思われます。

HDDの波形の変化

HDDが性能的にSSDに置いて行かれて久しい現在、それでも3.5インチHDDにはぼちぼちと進化が見られるが、2.5インチHDDには目ぼしい進化は見られない(と思う)。それは仕方ないとして、特に変化は期待せずNAS用のHDDを更新したら、HDDの「波形」について発見があったのでメモしておく。

HDDの「波形」というのは、HDDの速度を計測すると現れる位置固定のパターンのことで、記録面の記録密度に由来するものと個人的に考えているもの。基本概念は以下参照。
購入したのは東芝の2TBのMQ04ADB200。店はいつものように秋葉原のArk。

9.5mm厚なのでプラッタは2枚で記録面は4。東芝以外も含めて4TBのモデルは存在するが、どれも厚みは15mmのようなので、プラッタは4枚と推測され、したがってプラッタ当たり容量は同じと思われる。

2台のうち1台目のDisk Gazerの結果。上に出ている水色のグラフが最外周(先頭)100GiB、下の黄色が最内周(末尾)100GiBを示す。

まず計測幅が100GiBなのは、初めは先頭10GiBで計測したら水平線だけで波形が出てこなかったので、広げたから。水色の方だけではやや迷うが、黄色の方を見れば特徴的な4つの水平面の波形が分かる。これには注目すべき点が2つあって、
  • 先頭の水平面の長さは約19GiBで、これは以前のHDDより桁違いに長い。4つの水平面を合わせると約71GiBにもなる(水平面ごとの長さは同一ではない)。末尾の4つでも約27GiBとなる。
  • 同じ記録面のものと推測される水平面でも高さが微妙に異なるので、完全に同じ波形の繰り返しではない。
次に2台目のDisk Gazerの結果。こちらも上の赤紫色が最外周100GiB、下の黄色が最内周100GiB。

こちらも同じ特徴を示しているが、赤紫色の方でも4つの水平面の波形が分かりやすい。

これらが何を意味するか。一番シンプルな解釈は、あるゾーンの記録面(この場合は4つある)中のトラックを移動するのに、以前のHDDのように1つの記録面のトラックをある程度使ったら別の記録面に次々に移っていくという、記録面を小刻みに切り替える使い方ではなく、1つの記録面のトラックは(そのゾーンに属する)全トラックを最初から最後まで使った後に次の記録面に移るという、記録面をゾーンの途中で切り替えない使い方になっていることが考えられる。
  • 4つの水平面が1つのゾーンを構成するとして、1台目のように最初のゾーンの容量を71GiB、最後のゾーンの容量を27GiBとし、この間で容量が一定幅で減っていく(正確には2次関数的に減ると思うが)と仮定すれば、1863GiBは38ぐらいのゾーンに分割できる。この数はゾーン数としてあり得なくはない。
  • 水平面ごとに同じ記録面でもゾーンが違うとすれば、高さ=速度=記録密度が違うのは普通。概ね末尾に行くにつれ同じ記録面でも微妙に高さが下がる=速度が遅くなるのは、ゾーンが変わっていると捉えれば自然な推移(同じ記録密度であっても末尾(内周)に行くにつれ線速度が遅くなるので、アクセス速度も遅くなる)。
この記録面の使い方の違いがユーザーにとって何か意味があるかといえば、別に何もないが、個人的には波形の健在を確認できた。

なお、過去には専らHGSTのHDDを見てきたので、ベンダーによる違いも考慮すべきではあるが、過去の東芝のHDDの波形は他社のHDDと基本的には変わらなかった。いずれにしても、そもそも2.5インチHDDの存在自体いつまで続くのか分からないし、ベンダーの違いにこだわる話でもない気がする。