iOS での RDP のキーボード操作の挙動

Android では RDP(遠隔で Windows を操作できるプロトコル)を使うと、キーボードがおかしくなると言う話題を書いた。これを iOS でやるとどうなるか、会社にある iPad で試す機会を得た。
上記だとただ愚痴だけが書かれているが、より詳しくレポートしようと思う。というのも上記の愚痴はなぜそうなったのかを解らないうちにツイートしてしまったからだ。あれから色々と調べた結果、おそらく以下の様な挙動ではないかと推測するに至った。

まず現象として、RDP で日本語を入力していると予測変換が働き、それを無視して入力し続けると、予測変換が勝手に確定されていってしまう。そこで予測変換が出てきたときに変換キーを押すと、スペースとなってしまい、これまた予測変換が確定してしまう。

ここで試したのは、まず Windows 側の IME を OFF にしてみること。
次に、iOS 側の日本語入力を OFF にし、 Windows 側の IME を ON にしてみること。

この二つの結果は同じであった。
つまりどういうことかというと、おそらく iOS はキーボード入力を直接アプリが触ることは出来ないのではないかと言うことだ。RDP は Windows を操作するものであって、iOS の日本語変換は関係ない。本来ならば押されたキーをそのまま素直に Windows に伝えるのが RDP の役目だ。しかし iOS だとこれがどうやら出来ないらしいのだ。つまり iOS で文字入力したその結果を Windows に渡しているようだった。
だから Windows 側にいろいろ単語登録してあっても、iOS 側で変換してしまうので何の意味も無い。それ以前にキーボードの操作は iOS のものでしかない。ボクは Windows 側の IME に Atok を使っているのだが、これらはまったく意味なし。そもそも IME は ON でも OFF でもまったく関係ない。変換キーを押してもそれはスペースにしかならないため、先ほどのように予測変換で出たものが確定されてしまい、スペースが入力されてしまうのだ。

ではどうやって文字入力をするかというと、予測変換が出てきたときに iOS と同じようにそこから変換をタップするか、候補をタップして望みの変換を選ぶしかないのだ。つまりキーボードから手を離して画面をタッチしてこれらを行うわけである。

う~む、なんだこれ?wwww

新年度が始まると道路も混むと予想していたのだが、それに反してここ数日は秋葉まで一時間を切っている。新年度で交通量が減るというのは初めての経験かも知れない。まぁ別にちゃんと観測しているわけではないのはもちろんなのだが……。

打ち合わせによる作業中断の非効率さ

ツイートの通りなんだけど、解説すると、ある作業をしていて、打ち合わせの 30 分前に終わったとする。次の作業は 30 分以上かかることがわかっている。すると、打ち合わせを済ませたあとやろうって気になっちゃうっていう話ね。

でね、労働時間は 8 時間と決まっているので、打ち合わせが終わってやる次の作業が今日の作業時間 8 時間を越えた場合、やっぱりやりたくなくなる(笑

それだけ打ち合わせというものは、打ち合わせの時間だけ邪魔しているわけではなく、その影響はもっと広範に及ぶのである。

何を言ってるんだと思うかも知れないが、打ち合わせってほんと大変。そもそも参加者全員の時間を合わせなくちゃいけない。それをするだけでも労力がいる。そこで報告や決める「事」が当然あるとは思うんだけど、全員が顔をつきあわせてやらなきゃいけない「事」は少ないはずだ。報告ならネットでイイし(メールや掲示板など)、決めることは予め決めて欲しいことを送って、実際の打ち合わせは投票して終わりでいいことのほうが多いと思う。
プレゼンとか話さないとわからないことってのもあるとは思うけどね。

ちなみに上の話では切りのよいことを前提に話してしまったが、仕事というものは時間が来たら途中で切り上げた方がいいときもあるらしい。と言うのも、次に再開するときに、再開する気になるらしい。すでにある区切りまで仕事を終えてしまうと、その次の段階に進むのにエネルギーがいるが、中断されている作業の場合は「途中だからやっとかなきゃ」という心理が働き、すぐに仕事を始められるらしい。
人間、面白いものである。

マンコが決まっているお仕事をお願いします!

ボクは Docomo なんだけど、au や Softbank と契約している人に SMS を送ろうとするとぜんぜん文字数が足りない。なんだあれ? 21 世紀になってもう 18 年も経とうというのに、だ!

Android と Windows のキーボード問題

ボクは今ノート PC の代わりに Android タブレットを自宅のサーバに接続し、サーバの仮想 Windows マシンにアクセスして使っている。つまり Android を表示マシンとして使い、PC としての機能は仮想 Windows マシンが担っているわけだ。
ここで不思議な現象が起きている。Android では日本語キーボードという設定なのだが、Windows では英語キーボードとして認識されてしまうのだ。

日本語キーボードと英語キーボードは実はけっこうキーの配列が違う。もちろんアルファベットはどちらもおなじ QWERTY なのだが、記号が全く違うのだ。ボクは日本語キーボードで憶えてしまったので英語キーボードが使えない。ログオンするたびに日本語に直さないといけないという面倒な作業が発生している。

HEIF と BMW の読み方と、職人の朝

Twitter から拾った雑多なネタ。

ボクの携帯は iPhone 7 なんだけど、HEIF に対応している。HEIF の利点はなんといっても JPEG より小さいサイズで高画質が維持できることだ。しかし Windows と Windows 版 Photoshop が HEIF に対応してないおかげで、iPhone の画像は JPEG で保存してきた。

そして、ついに Windows 10 が HEIF に正式対応することになった。
ありがたい! あとは Photoshop が HEIF に対応してくれれば!
どうでもいいけど HEIF ってなんて読むの?w

ふと思ったこと。ボクが小学生の頃、BMW のことをベームべーと読んでいた。いわゆるドイツ語読みだ。でもいつの間にか英語読みするようになったなーって。英語に切り替わったのはいつ頃からだろうねぇ?

超くだらないけど、好きなのであげました(何
そしてコレを思い出したので張っておく(ぇー

最後にメモ程度に撮った写真とか。Big メロンパン、一個で 626kcal とかスゲーんですけどって思って写真に撮ったんだけど……一個で 1000kcal 越えるやつとか結構あるので、わりとどうでもよかった(汗)。桜は浅草橋の 27 日の開花状況(ぉ
最後のは給油に寄ったガソリンスタンドの隣りにある西友の駐車場に止めてあったちっちゃい車。
なんだろう??

スタイラスのせいじゃない、Android のせい

経緯から説明すると長くなるんだけど、ボクは外出先でのメモ取りや成果物のデモンストレーションやプレゼンなどに Windows タブレットを用いてきた。ASUS の VivoTab Note 8 という機械だ。とてもお世話になった。
が、あるときからタッチパネルが全く効かなくなってしまった。
ネットで調べると、まぁいろいろと苦労しているユーザさんは多かった。結果的には購入時に戻すと直るというのもあり、そんなバカなととも思っていた。ただ、確かに Windows 10 の大型アップデートが来るたびに数日間だけタッチパネルが復活するという現象は起きていた(大型アップデートは OS をクリーンインストールしたくらい設定が初期化されたり、ファイルが書き換わってクリーンな状態になるため)。これを 3 回経験しているので 1.5 年前からこの不具合は起きていることになる(Windows 10 の大型アップデートは半年に一回ある)。
復活しても数日でタッチパネルが効かなくなってしまうので、結局使うのはあきらめていた。

次に登場したのが、3000 円で買ってきた Android タブレットだ(笑)。コイツは本来は自宅開発機のセカンド ディスプレイ用に買ってきたのだが、Windows タブレットが上記のようにポンコツなのでコイツを代わりに使うようになった。
と言ってもこの Android タブレットは動作がクソ重く、ネットサーフィンをするのもつらいぐらい。で、どうしたかというと自宅サーバに仮想 Windows マシンを作ってそこに RDP で接続して Windows マシンとして使っていた。
これがなかなか悪くないというか、液晶画面が 1920×1200 ドットもあるものだから、Windows のデスクトップをそのまま持ち出しても何の問題もなかった。ただ画面が 7 インチしかないので操作がちょっと難有りだ。タップしたいところをうまくタップできないこともままあるみたいな感じで。
なので、スタイラス ペンを使えばもっとストレスなく使えるのではないかと思い立った。

思い立ってから三日後、ようやく買った(笑)。車はヨドバシ AKIBA の駐車場に止めているので、毎日ヨドバシカメラに行っているのに、すっかり買うの忘れてたwww

で、結論は、ボクのタッチが悪いんじゃなくて Android タブレットが遅いだけったっていう。
スタイラスで的確にタップしても、反応が遅くてぜんぜん動かない→タップ連打→他のところがタップされてしまう。という感じで、ストレスは指で操作しているのとまったく変わらなかった。
やっぱりこの Android タブレットじゃダメかぁ……。RDP 自体はイイ感じなんだけどなぁ。

ところで今日は雪が降った。三月も下旬だというのに、めずらしいなぁ……。

WB-BT300 とか PHP とか VPN とか

Twitter から拾った、コンピュータ関係の話。

iPhone の音を PC の音とミックスして出したくて、使っていなかった Bluetooth レシーバを引っ張り出してきた。Onkyo の WB-BT300 という機械だ。コイツはなにをする機械かというと、iPhone など Bluetooth 対応機からは音響装置に見え、WB-BT300 に対して音声を飛ばしてくれる。WB-BT300 は iPhone からきた音声を、デジタル信号かアナログ音声信号に変換して出力してくれるのだ。

で、会社の開発機には TEAC の US-366 というミキサー兼 USB 音源があるのでそいつと接続すると、PC からの音と iPhone からの音をミキシング(混ぜて)出せるようになるのですな。ちなみに US-366 と WB-BT300 は光デジタルケーブルで接続。

ところが、iPhone からの音しか出ない!! なんだこれ??

原因は WB-BT300 のデジタル フォーマットがサンプリング周波数 192kHz、量子化ビット数が 24bit のせい。このフォーマットは統一しておかなければならないのだが、たかが Bluetooth の音声受信装置でなんでこんな高い設定なんだwww
ちなみに CD はサンプリング周波数が 44.1kHz、量子化ビット数が 16 ビットだ。CD よりも音が悪いクセにデータ量は CD の 6.5 倍もあるwww

仕方がないので PC 側の出力も 192kHz の 24bit に設定した。こうすることによって無事 PC と iPhone の音が同時に出るようになった。

某絵描きから、イベントの福引きみたいなクジをデジタル化できないかという依頼があり、ごりごりと PHP と HTML と Javascript で作った。今流行の HTML5 というヤツだ(ぁ
中身はすぐに出来た。そりゃまぁ、そうか。クジ振るだけだから、出た乱数が何等賞なのかに変換して表示するだけである。

問題は管理画面である。単純にクジ、と言っても誰でも彼でもアクセスしてクジが引けるというワケにはいかない。以下の様な機能が入っている。

  • ユーザ登録して、ユーザ登録した人がクジを作れる
  • クジはいくつでも作れる
  • それぞれのクジには 1 ~ 10 等賞まで設定でき、さらに残念賞、参加賞が設定できる。そしてそれぞれの賞及びはずれがいくつあるのか設定するようになっている。
  • QR コードの表示
  • クジを引く画面を Javascript でアニメーションさせる。
  • 何等賞が出て、残り何の賞がどれくらい残っているかリアルタイムで監視する、モニター

使い方はユーザ(主催者)がクジを作ったら、そのクジを iPad などの端末で表示し、お客さんがそれをタップしてクジを引くというものだ。
さらに QR コードを吐いて、それをお客さんが撮影してクジを引くという機能もつけた。この場合、ちゃんと一回しかクジは引けないようになってるのだが、残念ながら Javascript では機種固有の識別番号を取得できないので、cookie になってしまった。そのため、cookie を消去すれば何度でもクジは引けてしまう。

ツイートでの愚痴は、HTML というかサーバのプログラムは一回一回が初めてのアクセスになるというか、仕組み上、同じ人が何度アクセスしようが、サーバ側は初めての人が初めてアクセスしたことにしかならない。
今アクセスしに来た人が前の○○という場所にアクセスしに来て、今のアクセスはそれの続きであるということは実は認識できないのだ。それを実現するために、cookie やらセッションやらっていう仕組みがあるのだが、とにかく一回一回のアクセスがすべて関連を持たせられないので、渡す数値だのなんだのも全部もらい直さないといけないので、プログラミングがすげーめんどくさいっていう話。

これが普通のプログラムだったら、さっききたアクセスは変数に残ってるし、その変数を参照して関数を呼び出せば済むんだけど、PHP だとアクセスが来るたびにプログラムは先頭から実行されてしまうのだ。

あと処理は PHP なんだけど、それを表示するのは HTML なのね。組み方としては PHP が処理の結果に応じて HTML を吐き出してるワケなんだけど、そうなるとプログラム ソースの中に PHP と HTML が混在してけっこう美しくない結果に……。今回は仕様書も何もないままテキトーに作り始めてしまったので分離されてないのだけど、予定してたより大きなプログラム(PHP 部分で 2000 行程度、Javascript が 500 行程度)になってしまったので、今後は気をつけたい(汗


(MP4 / 750×1334 / 25fps / 1’05” / 126MB / iPhone)

amatsukami.jp サーバの様々なサービスは、色々がんばって外に出してるんだけど、それでもやっぱり一部の機能は VPN を張らないと使えない。そのたびに端末(iPhone など)から VPN を張ってるんだけど、けっこうめんどくさい。
モバイル WiFi ルータに VPN を張る機能があれば、端末でいちいち張らなくても済むのになぁ……。

高架下のひさごと iPhone 用マイク iQ7

浅草橋駅の高架下にある蕎麦屋さんが、前々から気になっていた。
名前は『ひさご』。
中はカウンターしかなく、6 ~ 7 席ぐらいしかないんじゃなかろうか?
勇気を出して入ってみる。

すると、中で店を切り盛りしていたのはおばちゃんだった。

オーソドックスに天ぷらそばを注文する。ちなみにご飯類は一切無い。
ストイックな立ち食いソバ屋だ。

味は東京のおそば屋さん。関西の人からすると色々文句は言われそうだが、ストレートな出汁醤油に東京そば。見た目の通りの味としょっぱさ。そして出てくるのが早い。また来よう。

ちなみに常連客が多いらしく、入ってくるお客さんみんな気軽に店主に話しかけていた。
愛されているんだなぁ。

さらに追加情報として最近仲良くなったスーパーがあるんだけど、ひさごさんはそこで食材などを入手しているらしく、顔見知りとのことだった。そしてひさごは入り口に飴を配っているというかご自由にお取りくださいって感じでおいてあるんだけど、それを無料だからということでごっそり盗んでいくお客さんとかいるんだそうな。という井戸端会議的な話を聞いた。
世知辛いのう。

話変わって、iPhone でもそこそこちゃんとした録音が出来るマイクを買った。
実は 4/26 にちょっとした撮影をすることになり、ちゃんと録音する必要もあったのでこれを機会に買ってみたのだ。
生録の機械は実はずっと知人のものを頼ってきた。常に持ってないので、いろいろ録り逃したりしていたのだけど、専用の録音機はでかいし常に持ち歩くのもなぁと思って何となく買わずにズルズルときてしまっていた。
iPhone につなげられるプロ用のマイクの存在も知っていたんだけど、こちらを買わなかった理由は Lightning だ。USB の Tpye-C が普及しつつある昨今、Mac も Type-C しかインターフェースがないマシンも投入したりしているので、iPhone もいずれ Type-C になるんじゃないかと思っているのだ。なので Lightning のマイクを買ったら使えなくなるんじゃないかと。

まぁでも、変換コネクタとか出るかもしれないし、とりあえず明日収録だしとか勝手に自分に言い訳して買った(笑い

ZOOM の iQ7 というマイク。Lightning インターフェースに挿して使う。
マイクの感度を角度で調節でき、指向性マイクから環境音の収録まで可能になる。
ただし 48kHz / 16bit までしか録音できないけど(汗)。
まぁでも音は iPhone 本体で撮るよりも格段によい。音質はちょっと堅めでカチッとした音。人の声はすこしシャープすぎるかもしれない。

なんか録音したデータをここに上げようとしたんだけど、出してもよいデータが一つもなかったので、レビューだけで(汗)。