がとらぼ

エレコムトラックボール HUGE (大玉) ラスト

疲れるということで気に入らなくて悩んでいたエレコムのトラックボールHUGEだが、TwitterでKensingtonのセンターボールタイプのトラックボールに触れられている書き込みを見て何も考えずに返信書いて、その後に突然悟って1ヶ月もモヤモヤしてたのが一気に晴れた気分。

「がとらぼ」の中の人は元々MicrosoftのTrackball Explorer 1.0 (絶版)を愛用。
で、それのボタンの調子が悪くなったのでTrackball Explorerの後継として人差し指タイプの似た感じのHUGEを店で触らずにテキトーに購入。これが始まり。
HUGEの何がどう疲れて気に入らなかったのか。

Trackball Explorer。18年の月日を経て恐ろしくキチャナイ。元々筐体(ボタンとホイールとボール以外)の上面は表面がシルバーの塗装だったのだが、主に手が触れる部分が塗装が取れてなんとも表現の難しい変な色になっている。つまり上の画像の右下から中央上部にかけて変色している部分にベッタリと手を乗せていた。

このように持っていた。手は力を抜ききって掌から人差し指の第3関節までトラックボールの上に乗っけていた。ボールを転がす指は転がす時に多少曲げるとはいえ、上の画像のように指が伸びた状態が多い。ボタンを押したりホイールを転がす親指も上の写真のような状態が基本状態。上の画像ではわかりにくいが腕から手首は机の天板に乗った状態で、ほぼ人差し指から手首までが1直線に近い状態。これがとても楽。

これがエレコムのトラックボールHUGE。大きさの割に背が低い。さらに右側(手首側)はパームレストの厚みが2cmほどあるので掌から指にかけての盛り上がりというのは相対的にとても低い。ボールも水平に近い感じで配置されている。

一番盛り上がっているべき人差し指の第3関節部分が低くパームレストが高いので掌が水平に近い状態。そのせいで手首が2cmほど不自然に浮いた状態になる。人差し指は変に反った状態が続くし小指側が高くて人差し指側が殆ど殆ど高くないので掌を内側にねじった状態。当然だけど酷く疲れる。

並べて比べてみた。赤い線はボールの傾斜。これは見ための参考。
オレンジの線。パームレスト部分が低いTrackball Explorerよりもパームレストの高いHUGEの方が実は背が低い。つまりTrackball Explorerは人差し指側が盛り上がっている。
人差し指と小指のそれぞれ第3関節あたりを結んだ傾斜。HUGEの方がかなり傾斜が緩やかなのでこれは手を内側に捻ることを示す。

HUGEはこんなのを長時間使い続けると疲れるよね。
だから酷く不満に思った。

しかし、センタータイプのトラックボールの使い方を思い出したときにようやく悟った。

センタータイプのトラックボールに似せた手の状態。1〜2cmほど手を前に寄せる。これによりほぼ手首までがパームレストの上に乗る。掌をトラックボールの上面にベッタリ載せるのではなく第三関節も浮かせた状態。ボールは上から操作する感じ。こうすると掌をベッタリ乗せてた時とは違ってボールの左横にあるFn1,Fn2ボタンもある程度人差し指で押しやすくなる。人差し指の第二関節から腕までがほぼ直線になるので変に反ることもなくかなり楽になる。こう使う場合は人差し指側は自ら浮かせることで十分に高くなっているわけで、トラックボールの上面は小指側にかけての傾斜がきついよりも緩いくらいの方が丁度よい傾斜になる。

つまり、HUGEはセンターボールタイプのトラックボールのように使えばちょうど良いトラックボールだといえる。
ただ、Trackball Explorerとは似てるようで全く違う。これは写真ではわからない。使ってようやく気付くのだが、気付いた時には(おそらく買ってるので)もう手遅れ。

パッケージに書かれた手の状態はトラックボールの上面にベッタリな感じ。(エレコムのウェブサイトの製品紹介ページにも同じ絵がある)
きっとこの絵が間違って描かれているから「がとらぼ」の中の人も皆も誤解したんじゃないかしら？

勝手な解釈かもしれないけど、これで何かスッキリしたのでHUGEは卒業しようと思う。欲しかったのはセンターボールタイプのトラックボールではなく、Trackball Explorerの代わりだからね。

最先端なWebPメインなウェブサイトを作る with Nginx

ウェブサイトの転送量の低減化のためにも閲覧者の為にも写真や絵の画像は次世代フォーマットに対応させた方が良さげ。で、次世代フォーマットは幾つかあるけど、現在はどれも「これだ」という状況ではない。おそらくGoogleが推すWebPが有力なんだろうなという程度。そのWebPはJPEG 2000推しのAppleがSafariブラウザでなかなか採用してくれないので「もうそろそろ世界中皆でWebPに切り替えた方が良くね？」という風に簡単にはいかない。世紀の糞ブラウザのIEももちろん非対応だし。

でも、「がとらぼ」の中の人的にはもうWebPに切り替えたくて我慢できなかった。やっぱりWebPファイルサイズの小ささを見ちゃうとね。何でSafariとIEの為に採用を待たなきゃならないのかという感じ。
と、いうことでWebP対応をしてみた。どうせWebPにするのなら「Jpeg/PNGメインだけどWebP対応ブラウザ対応なら特別にWebPで表示しちゃうよ」を飛び越えて「WebPメインだけどWebP非対応だったらお情けでJpeg/PNGで表示してあげる」という最先端なウェブサイトにしてみたい。今回はNginxを使って「がとらぼ」を最先端なWebPメインなウェブサイトにした方法のメモ。(Jpeg/PNGメインも一応途中に入れておく)

Jpeg/PNG形式の画像をWebP形式に変換

PNGやJpeg画像をWebPに変換するのはとても簡単。
FreeBSDならportsやpkgでgraphics/webpをインストールする。WebPへの変換用のコマンドはcwebpとなる。

いちばん手っ取り早く変換するならこれ。(普通はこれで十分)

% cwebp hoge.png -o hoge.webp

画質を指定するなら -q ＋ 0〜100 をオプション指定する。0が最低画質。初期値は75
70〜80が実用的。

% cwebp -q 80 hoge.png -o hoge.webp

ファイルサイズが大して減少しなくてもどうしても画質を下げたくない(ロスレスにしたい)なら -lossless をオプション指定する。

% cwebp -lossless hoge.png -o hoge.webp

コマンドで画像を1つ1つ指定して変換するのは面倒で堪らないしウェブサイトによっては事実上不可能かもしれないのでスクリプトで纏めて変換するのが良い。

スクリプトのファイル名は任意。保存したら実行権限を与える (chmod +x ファイル名)

#! /usr/local/bin/bash

if [ $# -ne 1 ]; then
  echo "利用方法: $0 path" 1>&2
  echo "実行するには引数としてpathが必要です。" 1>&2
  exit 1
fi

find ${1}/ -type f -name "*.png" -exec cwebp {} -o {}.webp \;
find ${1}/ -type f -name "*.jpg" -exec cwebp {} -o {}.webp \;

コマンドには引数として変換したいファイルのあるpathを指定する。指定したpathの下層ディレクトリは再帰的に辿って変換する。

% スクリプト名 /dir/path

この場合はhoge.pngはhoge.png.webp、hage.jpgはhage.jpg.webpになる。この形式の名前は後で使う。元のJpeg/PNGファイルはそのまま残る。

関連サイト: WebP変換 (悪いインターネット) コマンドじゃなくてインターネットのオンラインツールで変換。

手動でコンテンツ書き換え

WebPを表示するにあたり真面目にコツコツとウェブサイトのコンテンツを変更するつもりなら以下。

<img src="/path/hoge.png" alt="Hoge" />

もともとこういうタグで書いていたのなら

<picture>
    <source type="image/webp" srcset="/path/hoge.webp" />
    <img src="/path/hoge.png" alt="Hoge" />
</picture>

こんな感じで書く。

しかし、これは対応が面倒だし、将来的に全てのブラウザがWebP対応になったら再び書き換えることになると思われる。それも大変。

Jpeg/PNGなコンテンツのまま「特別」にWebP画像を出力

ウェブのコンテンツの側は一切書き換えずに、Jpeg/PNGアクセスがあったらウェブサーバの側でWebP対応のブラウザに「特別に」WebP画像ファイルを渡すという方法もある。ウェブサーバがNginxの場合はとても簡単。

Nginxの設定

map $http_accept $webp_suffix {
    default   "";
    "~*webp"  ".webp";
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name  www.example.com;

中略

    location ~* ^.+\.(jpe?g|png) {
        add_header Vary "Accept-Encoding";
        try_files $uri$webp_suffix $uri =404;
        expires max;
    }
}

ググったら判をついたようにこればっかり出てくる。誰が何処に書いたのがオリジナルなのか判らないくらい。
mapの側で$http_acceptを見て、webp対応のエージェントなら変数$webp_suffixに".webp"をセット。
locationの側で、リクエストされたURIがJpegやPNGのものであればそのファイル名に.webpを付けたファイル名(のファイル)を送信する。リクエストと違うファイルを返すのでVaryヘッダを付ける。ブラウザの側に保存期間をmaxで指定する。expiresは別で指定してるよという場合もここで再指定。

これで、WebP対応のブラウザで hoge.jpgやhoge.pngにアクセスがあったらhoge.jpg.webpやhoge.png.webpを送信してくれる。

ところで、これはコンテンツを書き換えないということで <img src="/path/hoge.jpg" alt="Hoge" />のままになる。
せっかくWebP対応を行うならコンテンツの画像ファイルの名前をWebpにしたい。かといってpictureタグに書き換えるのもイヤ。
つまり、<img src="/path/hoge.webp" alt="Hoge" /> こうしたい。

WebPメインなコンテンツで「お情けで」Jpeg/PNGを出力

このために必要な処理は、「WebP対応のブラウザでWebPファイルへのアクセスがあったら当然WebP画像ファイルを送信するが、WebP非対応のブラウザでWebPファイルへのアクセスがあったらJpegを送信しようとする。Jpegが無ければPNGを送信する。」というもの。

コンテンツ側の対応。PNGやJpeg画像のURLの拡張子をwebpに書き換える。
今度はhoge.jpg.webpとかhoge.png.webpではなく、hoge.jpgでもhoge.pngでもhoge.webpとする。
WordPressだったらSearch Regexプラグインを使う。

関連記事: WordPressの一括変換用Search Regexプラグイン

画像ファイル側の対応

先程WebP用の画像のファイル名をhoge.jpg.webpやhoge.png.webpにした。なのに今度はhoge.webp。ｽﾝﾏｾﾝ

お詫びに再帰的にファイル名を書き換えるスクリプト。
スクリプトのファイル名は任意。保存したら実行権限を与える (chmod +x ファイル名)

#! /usr/local/bin/bash

#引数にpathを指定して実行のこと。
if [ $# -ne 1 ]; then
  echo "利用方法: $0 path" 1>&2
  echo "実行するには引数としてpathが必要です。" 1>&2
  exit 1
fi

find ${1}/ -name "*.png.webp" -type f -print0 | xargs -0 -I {} sh -c 'mv "{}" "$(dirname "{}")/`echo $(basename "{}") | sed 's/\.png\.webp$/\.webp/g'`"'
find ${1}/ -name "*.jpg.webp" -type f -print0 | xargs -0 -I {} sh -c 'mv "{}" "$(dirname "{}")/`echo $(basename "{}") | sed 's/\.jpg\.webp$/\.webp/g'`"'

これでhoge.jpg.webpやhoge.png.webpをhoge.pngにリネームする。
注意: xBSDとLinuxなどの両方でいけるように作ったつもりだけどFreeBSDで使っただけなのでLinuxでこのまま動くかは未確認。

Nginx側の設定

map $http_accept $webp {
    default   "";
    "~*webp"  $uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name  www.example.com;

中略

    location ~ (.+)\.webp$ {
        set $wo_ext $1;
        set $jpg "${wo_ext}.jpg";
        set $png "${wo_ext}.png";
        add_header Vary "Accept-Encoding";
        try_files $webp $jpg $png $uri =404;
        expires max;
    }
}

mapの方は先の場合とほぼ一緒。変数名を$webp_suffixではなく$webpにしたのと、セットする内容がリクエストのあったURI(のパラメータ無し)というところが違う。これで、WebP対応ブラウザでアクセスがあれば$webp変数にURIが入る。WebP非対応ブラウザでアクセスがあれば$webp変数は空がセットされる。
locationの側はWebP画像へのリクエストがあったらURIの拡張子を除いた部分を$wo_ext変数にセット。
$jpg変数に$wo_ext ＋ ".jpg"をセット。これでJpeg用のURIが出来る。
$png変数に$wo_ext ＋ ".png"をセット。これでPNG用のURIが出来る。
if文を使ってよければwebp対応ブラウザの場合はVaryヘッダを付けないという書き方もできるが、Nginxではif文は忌み嫌われていて余程のことでなければ使わないということになっているようなので、それに倣ってif文は使わず、WebP対応時にもVaryヘッダを付ける。実害は無い筈。
try_filesで$webp $jpg $pngを並べた。WebP対応ブラウザであれば$webp変数にWebP画像のURIがセットされていてそれが先頭に指定されているのでそれが表示されることになる。(もしもWebPが無ければJpegが、それもなければPNGが表示される)
WebP非対応ブラウザでは$webp変数は空なので実質的にtry_filesは$jpgと$pngが並んだ状態となる。先に$jpgで挑戦してJpegファイルが存在するならそれが表示される。Jpegが存在しないならPNGファイルが表示される。それも無ければError 404になるが、それは元々表示できる画像が無いということ。
このやり方と設定はググっても無かったので「がとらぼ」の中の人が無い知恵を絞って作った一応オリジナル。これで「がとらぼ」は表示できているようなので問題無しと判断している。WebP非対応ブラウザはIEで確認。何かとんでもなく間違っていたらご指摘いただければと。

問題はAMP。上でやったことにより、実質的にWebP専用コンテンツになっている。救済としてWebP非対応だったらJpegやPNGが表示できる状態だが、その処理が入っているのは自前のウェブサーバだけ。AMPはGoogleのAMPキャッシュであればGoogleのサーバなのでこの処理は通用しない。つまりAMPのコンテンツに書かれた画像のURIがWebPで、Googleのクローラーが拾っていった画像がWebPということになるとそのAMPキャッシュはiPhoneのSafariでアクセスしたらどうなるのだろう。Googleが気を利かせてSafariには自動的にJpegやPNGで出力してくれるならそれでOKだが、そうでなければSafariには画像は表示されないことになる。iPhoneは個人的には持ってないし周りの人も偶然にも誰も持っていないので確認のしようがない。
個人的にはもうAppleの端末はどうでもいいと思い始めてるけど、iPhoneの日本のモバイルでの比率を考えたら普通は無視できないよね。

新しいIP電話機を安く買いたい Grandstream

「新しいIP電話機を買いたい」の続きで3つめ。

前回は中国のFanvilだったが、今回は米国の Grandstream NetworksのIP電話機。この会社の電話機は中国の通販ではあまり扱っていないようだが、日本のアマゾンで入手できるよう。まぁ価格は決して安いと言えないけど。送料を考えると(安い機種は)アマゾンで売られている価格がバカ高いという程でもない。

GXP1620/1625

価格: $US35〜40, 日本のアマゾン8000〜9000円程度
SIP Lines: 2
表示: モノクロ液晶 132x48px 3行程度
電源: 1625はPoE, 1620はPoE非対応 5V/0.6A
Network: 10/100Mbps
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: 2
Programmable buttons: 3
BLF: 無し

最近タイで日本人の特殊詐欺グループが15人ほど捕まったが、そのグループが使っていたIP電話機はGXP162xの筈。それが不名誉なことではない。犯罪グループの技術担当者は大抵とても合理的なのでそういう人のお眼鏡に適った製品というのは彼らの目的には必要十分で「良い製品」。(絶対じゃないけど)
でも、個人で1つ2つ買う程度なら性能面でもう少し色付きのモデルにしたいかも。

GXP1628/1630

価格: $US50〜60, 日本のアマゾン12000円程度
SIP Lines: GXP1628は2、GXP1630は3
表示: モノクロ液晶 132x64px 4行程度
電源: PoE対応 5V/0.6A
Network: 10/100/1000Mbps
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: GXP1628は2、GXP1630は3
Programmable buttons: 3
BLF: 8

GXP161xが1SIP、GXP162xが2SIP、GXP163xが3SIPということのようなので1628と1630は別クラスということらしいが筐体が同型でBLFを備えるモデルなのでこの記事では一緒に扱った。

GXP1760/GXP1760W/GXP1780/GXP1782

価格: US$60〜90, 日本のアマゾン14000〜22000円程度
SIP Lines: GXP176xは3 (6回線), GXP178xは4 (8回線)
表示: モノクロ液晶 200x80px
電源: PoE対応 5V/1A
Network: 10/100Mbps, GXP1782は1000MHz対応
1760WはWi-Fi対応 802.11 a/b/g/n/ac 2.4/5GHz
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: GXP176xは6, GXP178xは8
Programmable buttons: 4
BLF: 無し

この筐体のモデルで飛び抜けて高額なのはWi-Fi付きのGXP1760Wだけど、日本で扱ってるのは並行輸入品しか見かけない。日本の技適が通ってなさげなので日本では使ったらダメかも。

GXP2130 v2

価格: US$65程度, 日本のアマゾン13000円程度
SIP Lines: 3
表示: 2.8インチカラー液晶 320x240px
電源: PoE対応 12V/0.5A
Network: 10/100/1000Mbps x2
コーデック: G.711u/a, G.722, G.726, G.729A/B, iLBC, Opus
Line Keys: 3 + アカウント3ボタン
Programmable buttons: 4
BLF: 8

GXP2135

価格: US$70程度, 日本のアマゾン14000円程度
SIP Lines: 4 (回線8)
表示: 2.8インチカラー液晶 320x240px
電源: PoE対応 12V/0.5A
Network: 10/100/1000Mbps x2
Bluetooth: 2.1対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: 8
Programmable buttons: 4
BLF: 無し

GXP2140

価格: US$80程度, 日本のアマゾン17000円程度
SIP Lines: 4
表示: 4.3インチカラー液晶 480x272px
電源: PoE対応 12V/1A
Network: 10/100/1000Mbps x2
Bluetooth: 2.1対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: 4 + アカウント4
Programmable buttons: 5
BLF: 無し

GXP2160

価格: US$95程度, 日本のアマゾン18000円程度
SIP Lines: 6
表示: 4.3インチカラー液晶 480x272px
電源: PoE対応 12V/1A
Network: 10/100/1000Mbps x2
Bluetooth: 2.1対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: 6 + アカウント6
Programmable buttons: 5
BLF: 24

GXP2170

価格: US$95程度, 日本のアマゾン24000円程度
SIP Lines: 6 (回線12)
表示: 4.3インチカラー液晶 480x272px
電源: PoE対応 12V/1A
Network: 10/100/1000Mbps x2
Bluetooth: 2.1対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: 6 + アカウント6
Programmable buttons: 5
BLF: 24

以下3機種はGXVシリーズのAndroidビデオ電話

GXV3240

価格: US$160程度, 日本のアマゾン34000円程度
SIP Lines: 6
表示: 4.3インチカラー液晶 480x272px, mini-HDMI出力
電源: PoE対応 12V/1.5A
Network: 10/100/1000Mbps x2
Bluetooth: 4.0 + EDR対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus, H.264
Line Keys: -
Programmable buttons: -
BLF: 無し
Camera: CMOS 100万画素
Android: 4.2

GXV3275

価格: US$220程度, 日本のアマゾン37000円程度
SIP Lines: 6
表示: 7インチカラー液晶 1024x600px タッチスクリーン, HDMI出力
電源: PoE対応 12V/1.5A
Network: 10/100/1000Mbps x2, Wi-Fi 802.11b/g/n
Bluetooth: 4.0 + EDR対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus
Line Keys: -
Programmable buttons: -
BLF: 無し
Camera: CMOS 100万画素
Android: 4.2

GXV3370

価格: US$220程度, 日本のアマゾン扱い無し
SIP Lines: 16
表示: 7インチカラー液晶 1024x600px タッチスクリーン, HDMI出力
電源: PoE対応 12V/1.5A
Network: 10/100/1000Mbps x2 Wi-Fi 802.11b/g/n 2.4/5GHz
Bluetooth: 4.0 + EDR対応
コーデック: G.711u/a, G.722, G.723, G.726-32, G.729A/B, iLBC, Opus, H.264
Line Keys: -
Programmable buttons: -
BLF: 無し
Camera: CMOS 100万画素
Android: 7.0

2018年秋の新製品。日本語カタログがあるので日本でも販売すると思うが日本のアマゾンでは4月12現在は取扱いなしだった。技適待ちかしら。Android7.0対応ということで、普通は3275よりはこの3370を選ぶかなと思う。ハードウエアは3275と同じ？米国アマゾンでは価格変わらず。

BLFは回線の状態によって光るやつ。例えばアイドル中は緑で通話中は赤く点灯で保留中とか着信Ring中は赤く点滅とか。で、そのボタンを押したら直接その呼を取れるって機能だったり。コールセンターではBLFの(アイドル状態を示す)緑が全部無くなったら次はもう呼が溢れるよ「ヤベー」ってやつ。
DSSは似たようでもう少し多用途多機能。そういう認識。違ったらｽﾝﾏｾﾝ。

個人なら通話のスペック的にはGXP162xあたりで十分。だけど画面を使って遊びたいと思っているので、それで考えると電話機のGXPシリーズは全部候補から外れるかも。ビデオ電話のGXVシリーズのどれか辺りでしょうか。そうすると電話機としては過剰なスペックで価格もお高めになる。
一昔前はIP電話機はかなり高額で、小さくてしょぼいカラー液晶が付いただけで10万円超えとかが当たり前だったので大きなタッチパネルの付いたAndroidビデオ電話が3万円以下というのは安い気もするが、現在は小さなカラー液晶のついた電話機が5千円以下で入手できるので、それを思うと高いような気もしないではない。そしてAndroid電話は安定性が気になるところ。これは他社製品も同じ。Androidビデオ電話機は他社も含めだいたい似たようなスペックで200ドルちょっとくらいが現在の相場なのかしら。