プログラミングする上で致命的な欠点が iPad にはあった(解決)

実は旅行に行っている間、ずっと PHP の開発をしていた(笑い
ツールは iPad +リモートデスクトップである。amatsukami.jp サーバ上にある仮想マシンが実質の開発マシンであり、iPad はそれを遠隔で操作するためのものである。なので、Windows で開発していると言っても良い。
エディタは秀丸だ。

PHP 程度では上記の装備で、そんなに問題ない。デバッグも別に専用のデバッガを起動してブレークポイントを設定したり、メモリやスタックの中をダンプしたりなんて必要もない。PHP なんていうものは、プログラムと言ってしまってもいいものかと恥ずかしくなるくらい簡単な言語である。まぁだからプログラマを引退したボクでもある程度は組めるわけだが。

開発のストレスというのは主にキーボードにある。前にも説明したが、キー入力情報だけを送って Windows の IME を使うと言うことが現時点では iOS ではできない。実際入力した文字情報が Windows には送られる。

  • CTRL や SHIFT などの情報が限られる
  • 日本語の辞書が iOS のものを利用することになってしまう
  • スペースで変換出来ない

まぁ、主にこんな感じだ。何のキーを押したかという情報が送られていれば、処理をするのは Windows の方になるのでかなりストレスが減るのだが、なにをするにも iOS 側で変換された文字情報が行くので、どうしてもこうなってしまう。

今回の旅先の仕事は、新しく組む部分はほとんどなく、出発する前にだーっと組んでおいたプログラムが正常に動くか確認し、動かなかったら修正するというのがメインだった。だから基本的にはデバッグ作業みたいなものだ。だから入力する部分もとても限られている。
だから最初はあまりストレスを感じなかった。

結局、作ってきたプログラムがそのままではなぜか動かす、何か根本的に間違っているのかと思い、いろいろと組むことになった。そこで iOS の新たなクソ仕様が判明してしまうのである。

シングル&ダブル クォーテーションが勝手に全角になって補完されてしまう! しかもそれを OFF にする方法がない!!

どういうことか、プログラマじゃないと解らないことなので順を追って説明しよう。
シングル クォーテーション、ダブル クォーテーションというのは、’ や ” というものだ。日本語で言うと「」みたいなもんだ。これは日本語と同じく、前と後ろで種類が違う。

‘シングル クォーテーションで囲んだよ。’
“ダブル クォーテーションで囲んだよ。”

とまぁ、こんな感じだ。しかしプログラミングではいちいち書き分けはしない。すべて右閉じのものを利用する。

'シングル クォーテーションで囲んだよ。'
"ダブル クォーテーションで囲んだよ。"

そもそも全角の文字を使うこと自体、NG だ。ところが iOS ではこれらの文字を入力すると、始まりは ‘ に、終わりは ’ に勝手にされてしまうのだ。設定にある自動補完機能を OFF にしてもダメ。プログラムではシングル クォーテーションやダブル クォーテーションでコンピュータに与える値を囲むことが多いため、この二つの記号は使いまくるのだ。

結局どうしたかというと、シングル クォーテーションを入力したいときはすでに入力されているシングル クォーテーションをクリップボードにコピーして貼り付けるという方法で回避するしかないのだ。ダブル クォーテーションを入力したくなったら今度はダブル クォーテーションをクリップボードに。
なんだそりゃ???
ウンコ過ぎるだろ。

一応、もう一つ回避方法がある。それは「変換」だ。クォーテーションを入力したあと変換キーを押すと候補に半角のクォーテーションも出てくる。ただこれがよく解らないのが、出てこないこともあるのだ。良く解らん。ただこれに関してはこちらの問題もありそうな気はするが……。

そんなわけで、これは超致命的。プログラミングに全く使えないと断言しても良い。
買い換えを考えるレベルだ。
う~ん、今まで気づかなかったなぁwww
買う前にいろいろ試してはいたんだが……記号の入力ってのはぜんぜん試してなかった……orz
iOS のクソがまた一つ、明らかになってしまったなぁ。

下のスクリーンショットは実際に開発している様子。赤文字になっているのがクォーテーションで囲まれた文字列で、その使用頻度が多いのが解ると思う。

と、さんざん iOS のことをこき下ろしておいて本当にこの自動補完は OFF に出来ないのかもう一度設定画面を眺め見た。そこで気になったのが「スマート句読点」という設定項目だ。あ、ひょっとしてクォーテーションも句読点の一種と扱われているのでは? と思って OFF にしてみたら、クォーテーションの補完も OFF になった! なんだ、やればできるじゃん!
ただし今度は変換を押してしまうと NG。変換すると補完されてしまうのだw ので入力したらすぐに確定しないとダメ。まぁでも今までよりはずいぶんマシだ。これでプログラミングのストレスもだいぶ減るかも??

うどんの写真は、酔壱やさんの讃岐うどんだよ~。透明なだし汁が嬉しい。出汁濃いめ~。

  

iOS12 にしたら画面が明るくなって、村井

iOS12 が来てたので何も考えずにアップグレードした。そしたら画面が妙に明るくて、「うおっ、まぶし!」ってなった。iOS11 と見比べてみると、確かに白飛びしているように見える。こういう変更って何か意味があるんだろうか? 別に前のままでもいい気がするんだけどなぁ……???

過去のスクリーンショットをあさったらもっとわかりやすい画像が出てきたので、下にはっておく。当然だが暗い方が iOS11 で明るい方が iOS12 である。

ただそれだけ(ぁ

今日は浅草橋でもまだ行ったことがないトンカツ屋さんに行った。名前は『村井』。
ウチの会社の人の中には、ボクが大好きな串竹よりもこの村井の方が美味しいという人もいるくらいの店だという。
奥まった場所にあるので、なんとなーくイカなかったのよね。

店の雰囲気は昭和な感じ。まぁ、浅草橋にはそういう店が多い。とは言え、「汚い」昭和系とは皆無で店内はキレイ。ただテーブルや椅子の大きさの規格が昭和。風景も。そしてメニューも。
ただ種類は豊富。ミルフィーユカツもある。
でもまずはオーソドックスにロースカツ定食を頼む。ハムカツがついてきた。
味はと言うと、肉がかなり柔らかい。少し驚いた。この柔らかさの秘密は肉そのものではなく、充分に筋を落とした下ごしらえの柔らかさの感じ。なるほど、串竹よりうまいというのも解るが、肉そのものは串竹の方が良い肉を使っているんじゃないかと思えた。

面白いのが、ウスターソースしかないこと。とんかつソースではないのだ。
そしてウスターが合う。カツそのものが割と淡泊でそこにウスターのストレートな味がマッチする。中濃だとだれてしまうだろう。なるほど。

あとおそらくこの食べ方は名古屋方面にあるものと推測された。というのもメニューの中に名古屋風の物が多かったからだ(味噌カツとか魚雷のエビフライとか)。他のメニューもたべたくなったので、また来てみよう。

iOS はクソだなぁ……

 

事の発端は 3/6 に作った福引きシステムを Bluetooth のシャッターボタンでも引けるようにするという要望だった。夏コミが近くなり、この福引きシステムを夏コミにも使うのだが、前回、お客さんがなかなか引けないという場面があり、列が伸びてしまったらしいのだ。

お客さんがひけなかった原因は、単純に「タッチ」しなければならないのに、画面にタッチした時、指を画面から離す前に指で画面をこすってしまい、タッチとして判定されなかったためだ(スワイプとして判定されてしまう)。緊張したのかなんなのか解らないが、そういうお客さんが多かったらしい。なかなか引けなくて後ろの列が伸びてしまった。列が伸びると次のサークルを回りたい人はさっさと諦めて引かずに行ってしまうらしい。
そこで対策としてリモコンのシャッターボタンを押して貰えば、失敗が少ないのではないかというわけだ。

リモコンのシャッターボタンはキーとしては【Volume Up】の信号が送られてくる。
確かにスマートフォンを横向きに構えると音量ボタンがちょうどシャッターボタンぽい位置に来る。
なので Javascript でシャッターボタンを拾うように組んでみた。とりあえず Windows の Edge で実験。ちゃんと動いた。
ところが iPhone ではウンともスンとも言わない。んー? なんだ?
シャッターボタンは拾えないのかな?

そこで、どんなキーを押しても動くように組み直してみる。
それでも iPhone だと何も起きない。おいおい、どういうことだよ。
そこで気づいたのが、iPad だ。ボクの iPad にはキーボードが着いている。これなら絶対に動くはずだ!!

ところが、iPad + キーボードでも動かなかった!!

ここに来て初めてボクはググった。そしたらなんと、画面にキーボードが表示されていないと、iOS ではキー割り込みが発生しないのだった!!! なんだこのクソ仕様は!!! つまり Javascript では何をしようがどうしようが Form の上か画面にキーボードが表示されていないと、キー情報をとることができないのだ(ちなみに Android はできる)。

というわけで、リモコンのシャッターボタンでは iOS ではクジは引けない。回避方法はないのだ。この一連の変更はすべて無駄となった。

で、結局どうしたかというと、スワイプでも引けるようにとりあえずした。
ただこれでお客さんの失敗が減るかどうかは、夏コミに実際に引いてもらわないと解らない。それはまたその日の日記に。

いきなり!セックス

まー、ツイートの通り。格安風俗で、「いきなり!セックス」っていう「いきなり!ステーキ」のパクリとかあってもよさそうって思っただけ。

iOS にはどんなときでも最低限の設定が変えられるように、コントロール センターという機能が用意されているんだけど、そこで WiFi を ON / OFF できるのね? なんで WiFi を ON / OFF する必要があるかというと、公衆無線 LAN を勝手に拾ってくれるのはいいんだけど、移動中だったりするとすぐにその範囲から出てしまう。その公衆無線 LAN の電波が届かなくなる辺りは非常に通信速度が低下し、さらには携帯回線に切り替わった瞬間にネットワークがダウンしてしまうこともしばしば。
それがすごく煩わしいので、移動中はよく WiFi を OFF にする。

ところが、WiFi を OFF にしたのを忘れて、OFF のまま大容量の通信をしてしまうことを防ぐために、コントロール センターから OFF にした場合は、すぐに ON になってしまうのよ。

そのおかげで、家にたどり着く前に何度も WiFi を OFF にしなくちゃいけなくて、めんどくせー!! っていう話。ちなみに設定(いわゆるコントロール パネル)から OFF にするとずっと OFF のままなんだけど、これだと家に着いたり会社に着いたりして安定した WiFi 環境に入ったとき、ON にし忘れて動画見たりアプリのダウンロードとかしちゃって痛い目をみることも(汗

運転免許証の一部の表記が西暦になる。ボクはよいことだと思っているのだがどうだろうか?
官公庁は元号を使っているのは解るのだが、アレ、内部処理は西暦だったりしないのかね(笑い
正直、元号は使いづらい。まだ皇紀の方がいいかもしれない<ヲイ

ところで絢子さまだったかが西暦を使ったことに右翼が落胆していたっていう記事をどこかで読んだのだが、見つけられなかった(汗)。

下の写真は浅草橋で一位二位を争ううまいイタリア料理屋『Dark Horse』のカルボナーラ
なんかいろいろ味が混ざっていて複雑なカルボナーラが出てくるのかなと思ったら、かなりストイックでストレートなカルボナーラだった。ほんとに卵と黒胡椒が前面に来ている真面目なカルボナーラだった。

真夏日に+メッセージと出会ったタイのカラムーチョ

いやー、まだ 6 月だというのに真夏の気温だ。これ、7 月・8 月はどうなってしまうんだろうか……。ボク自身は暑いのは平気だが、サーバが心配だ。すでに 7 年目に突入しているからなぁ……。

+メッセージiOS 版がようやくリリースされた。RCS という SMS に代わるサービスでやりとりしている。ボクがコレを待ち望んでいたのは、ボクの周りは Android ユーザが多いこととボクが車で色んな人を迎えに行くことが多いからだった。
iOS 同士なら自分の位置をすぐに相手に知らせることが出来る。これが Android 相手だとそうもいかない。いちおう SMS でできないこともないんだけど……。

あと iOS 同士でもなぜか iOS のメッセージング機能ではなく SMS でつながってしまう場合がある。こうなってしまうと異なるキャリアの場合、文字数制限がかかってきて全然送れないこともあるのだ。

そんなわけで今、周囲の人たちに「+メッセージいれろ~、+メッセージ入れろ~」と呪文のようにお願いしているwww

下の写真は左上から順番に酔壱やの肉ぶっかけ、おそらく浅草橋界隈最安値であろうコインパーキング、うまい棒の萌えキャラ(?)x 2、タイで発売されているカラムーチョ、ワールドカップ日本代表バージョン カラムーチョである。なぜ熊本が「かぼちゃコーンポタージュ味」で東京が「シナモンアップルパイ」なのかは謎のままである。
タイで発売されているカラムーチョ、いいね! やっぱ本気の辛さじゃないとなぁ。

HDD の収納とか WiFi とか

amatsukami.jp サーバはバックアップ サーバがあるわけではなく、時々ボクが手動でバックアップしている(汗)。次、サーバを入れ替えるときにバックアップ サーバも用意しようかなとは思っているんだけど……今の所、現在の運用で事足りている。

バックアップ サーバは普段電源が切れていて、バックアップ時間になると Wake on Lan によって起動し、バックアップを取ったらまた電源が落ちるようにしたいなと思っている。ただバックアップサーバの導入をためらう理由は、バックアップに使われる HDD は amatsukami.jp サーバが使っていた HDD のお古なわけだけど、一台辺りの容量が現行サーバよりも少ないため、どうしても HDD の台数がかさむ。そのためより大きなケースが必要となってしまい、バックアップとるためだけの PC なのにケースがそこそこ巨大になってしまうからだったりする(汗)。

まぁそれはさておき、ボクのデスクの上にバックアップ用の HDD が裸のまま無造作に積まれていたりする(汗)。こいつを裸族に挿してバックアップをとっているのだが、どうにも裸のまま HDD を置いてあるのが精神衛生上よくない……ってその状態でもう何年もおいてあるんだけどさ。
というわけでこういうモノを買ってみた。

HDD を収納しておくケース(?)。この 6 台の HDD が amatsukami.jp サーバのバックアップに使われている HDD だ。ただし正確には 5 台で、1 台はシステム バックアップ用だ。PC のサポートで、システム ドライブをまるごとバックアップを取らなければならないみたいな状況がよくあるので、そのために 1 台確保してある。

コレでとりあえず HDD をほったらかしにすると言うことはなくなった。

ところで、iPhone の WiFi を ON にして外出すると野良 WiFi に接続することがよくある。しかしこちらが移動していると WiFi は範囲が狭いのですぐに通信不能となってしまったり、アクセス数が多すぎて激重になったりする。
そのためボクは外では WiFi 自体に接続して欲しくはないのだが、外出するたびに WiFi を OFF にするのもめんどくさい。
でも聞いていた曲が途切れたり、ネットサーフィンしていてネットが切れたりすると手動で WiFi を OFF にしてるんだけど、この時、コントロールセンターから WiFi を OFF にするといつの間にか復活していて、またネットが切れたりどしたりする(設定から OFF にすると、ずっと OFF のまま)。
っと OFF のままでいいのに……。

下の写真はボクのお気に入りの揚げ物屋さん、串竹のトンカツ。
もう何度も断面を載せている気がするが、写真がある限り載せるよ!

 

Android と iOS、そしてチキンプレイス!

隣の芝は青く見えますよ的な。ボクは Android のプログラムはやったことがないので解らないが、Android って 100% ネイティブで動くわけではないっぽい?? ところどころ Java が介入する場所があるように見える。その辺が iOS よりもスムーズに動かなかったりする原因なのかしら??

エロ方面は具体的なエッチシーンは Android も iOS も NG だから、ボク的にはどっちでもイイかも……。

下の写真はチキンプレイスのチキンカレー。鶏肉がゴロゴロ。浅草橋お勧めグルメの一つである。

あと、那須塩原旅行で買ったチーズのレビューをすっかり忘れていた!
というわけで、まずは山羊のチーズから。モツァレラよりもクセがない。臭いもそんなにしないし、食べてもうすーいヨーグルトって感じ?(汗
その代わり何にぬっても問題ない。

ゴーダチーズはそのまま食べても、パンに載せても、そしてサラダに入れてもよい。
サラダに入れた場合は、ドレッシングなくてもゴーダチーズの味で野菜がサクサク食べられる。パンに載せた場合、スライスチーズみたいに溶けるわけではないので、薄く切ったものを何枚も載せるとイイ感じ。こちらもクセは弱いように思った。チーズ苦手な人でもいけるんじゃなかろうか?