「日本語OS」をやめた日

OSで使用する言語を英語に変更しました。

英語、というよりはASCIIです。一つにはソフトウェアを開発する際にファイル名やら日付やらメッセージやらにASCII以外が混じっていると、扱いにくい、邪魔臭いためでした。

特に不愉快だったGoogleDrive の「マイドライブ」が「My Drive」になって非常に気分が良いです(笑)

また一般ユーザの立場からみても、Windowsなどが「日本語化」されていることがそれほどのメリットとは感じていませんでした。もともとが英語の概念で作られた機能の名前を、不自然に日本語化してわかりにくかったり、不統一だったりして、使いにくいことも多いです。特にWindows と Mac での日本語の違い。Operaの日本語も少し独自です。

もともとコンピュータのコマンドやメッセージやマニュアルが英語でしかなかった時代に育ったせいかも知れません。

昔、コンピュータやネットワークは非日常的でちょっとシャレた世界でしたから、お仕事臭い日本語が入ってくるのに違和感を覚えたという面もあります。メールの Subject が「件名」と称されるようになった時には、不快感に近い違和感を持ったものです。

もちろん、長い文章だと日本語のほうが良いですが、短くて定型的なコマンド、メニュー、メッセージ、(生成される)ファイル名、その他カタカナで表現される容れ物に入れるのは、やはり英語のほうが良いと思います。

いったん英語のサラ地に戻ってから、本当に必要な部分を日本語にすれば良いかなと思っています。まあ、GUIのカレンダーだけは日本語表示のほうが良いと思いますけど。

2020-0516 SatoxITS

ブランド名

社長:社名を変えようと思います。

全員:ええーっ!

社長:新しい会社名は「ライトクリック」です。

広報:わかりやすいですね。イメージが湧いてきました。

基盤:right click ですか?lightじゃないですよね?

経理:今朝もまたドメイン名取ってましたね。

営業:なぜですか?

社長:創立以来いろいろやって来るうちに、我が社ができること、やるべきことは、そこにこそあると思うようになったからです。そこは未開ではありませんが広い余地が残されており、今後大きく広げられる可能性を秘めていると思うのです。フロントエンドにおけるフロンティアであり、我が社のバックエンドへの最適な入り口と言えます。これは、ニッチではありません。

開発:コンテクストメニューという意味ですね。文脈に適して生成されるプログラマブルでカスタマイズ可能なメニュー。

社長:そういう事です。ウィキではこう要約していますね。

コンテクストメニュー コンテキストメニューとは、グラフィカルユーザインタフェース内のアイテムをクリックすることでポップアップするメニューのことであり、操作や実行中アプリケーション、選択したアイテムのコンテキストによって変化するオプションの一覧を提供する。ショートカットメニューや、右クリックメニューともいう。 [Wikipedia]

社長:これをより一般化して捉えると、コンセプト的にも技術的にも、我が社の方向性にぴったりだと思うわけです。

基盤:Wikiの人はクじゃなくてキ派ですね。プログラマじゃないな。

営業:現社名「ITS more / いつも」は文脈に応じて硬軟使い分けられて使い良いと思っているのですが。社名ではなくブランド名ということではどうでしょう?

社長:たしかに。いつもには思い入れもありますしね。じゃあそうしましょう。

経理:請求書によりますと、.cc, .click, .site, .tech, .tokyo, .work 6ドメイン合わせて 1,428(税込み)。リーズナブルと思います。

社長:1円ドメイン(right-click.work)というのを初めて買いましたよ。6件同時というのも初めてです。例によってXSOnamaeから気が狂ったように**完了通知のメールが来ました(笑)1秒のうちに37件です。いつもうるさいのでようやく、自動振り分けルールをつけました。
で、その確認も兼ねて「light-click」シリーズも取っておきました(笑)こっちのほうが洒落ててよいですね。


商標登録

社長:我が社も商標登録というものをしてみたいですね。いくらくらいかかるんでしょうか?

経理:ちょっと待って下さい … えーと、1件単独で出す場合ですけど、出願時に12,000円、で審査を通ったら、登録料28,200円ですね。つまり4万円。

社長:登録料28,000円かぁ。ちょっと重いかな。

経理:ただし、10年間有効です。

社長:ええーっ!年間2,800円相当ですか。ドメイン名維持料より安いですね。しかし、10年間必要かな?(笑)

経理:少し割高になりますが5年にすることもできるようです。ところで、今週もまたなんかいろいろドメイン名を取ってましたね。

社長:いやあ、駄洒落を思いつくとつい、ドメイン名ポチっちゃうんだよね。千円くらいだし。投資投資。で、手続きは?

経理:基本電子申請ですね。電子証明書と専用アプリでやります。ですが、出願してから通常だと1年以上かかるとか。

社長:マジ?

経理:権利を抑えるのが目的ならそれで良いのでしょう。早く使いたい場合には早期審査という道もあって、それだと3ヶ月くらいで通るようです。ここを通れる条件は「その商標を既に使用している事」です。会社名については、登記もしているしドメイン名としても使っているから問題ないんでしょうね。

社長:そうですか。特許も出してみたいし、特許庁、なんか面白そうですね。てか、まずロゴを決めないとなー。

2020-0513 SatoxITS


ヒゲはクチほどにものを言い

社長:社長になったのでヒゲをのばしてみました。

基盤:いわゆる無精髭との違いは?

経理:経費節減への一歩。

社長:それで今日ウェブ会議した時に自分の顔の画像を見て思ったのは、口髭の形状でいろんな気分を伝えられるな、ということです。似たものにマユ毛がありますが、あれはなかなか操作するのがむずかしい。歳をとると表情筋も衰えますしね。くらべてヒゲは口の周りの筋肉で操るのが簡単です。

社長:それにそもそも、ヒトの表情を形作る可変で最大の要因は、顎モジュール、とりわけ口の形です。たとえば 🙂 :-p 😀 😐 😮 とか。今日は当社にとって重要な契約関係の会議だったので基本 😐 という表情を作っていましたが、途中からヒゲ形状が作りだす表現にハマってしまい。巨泉x前武ゲバゲバ90分みたいで自分でもおかしかったです。おかげ様か会議も和やかに終了しました。

基盤:これですね。

社長:おお、これこれ。このベロからして A. アインシュタインがモチーフだったんでしょうかね?これほどの表情を作るには、よほどの人生修行が必要と思います(笑)あと私は Skype の ROFL が大好きでした。

Skype の ROFL (Rolling on the Floor Laughing)

社長:たくさん積んで遊んだりしてました。



社長:我が社のシンボルマークもこういうにこやかでダイナミックなのがよいですね。

基盤:どちらもマユが無いのは剃ってるんでしょうかね?

2020-0512 SatoxITS


優しいウェブページの「詳しく」

社長:我が社のウェブページもなんかイマドキな技術を取り入れたいですね。ヒトに易しく処理系にも優しいという感じ。

基盤:たとえば?

社長:そうですね、最近見たなかでとても良いなと思ったのは、ページ内で折りたたんだり開いたりするあれです。いちいちポップアップされたりするのすごく嫌ですし。あと、その場でその部分だけ文字拡大できるとか。

基盤:私の育った時代ですとそういうのは SSI とか iframe でした。

社長:(笑)ブラウザだけでできないとね。サーバにもネットワークにも負担をかけない、結果的にユーザの懐にも負担をかけない。応答は最速でユーザは気持ちが良い。ページを書く側も簡単。ブラウザにもサーバにも依存しない実現方法。将来表示できなくなったりすると困るからシンプルで安定した仕様。HTML だけでできるとベストですね。

基盤:最近はHTMLも5とからしいですからね。WordPressでサポートしてくれていると手軽で良いのですが… ちょっとぐぐってみます… どうやらこの、details というタグを使うみたいですね。

詳しくはここをご覧ください これは details というタグを使って折りたたんだ情報です。デフォルトでは折りたたまれていますが、クリックすると開きます。

社長:おお、これこれ。なるほど、タグだけでやれるのか。まあ、当然そうあるべきものだよね。ちょっと洒落た表示をしようとするとすぐにほにゃららスクリプトだーって、嫌な間に合わせの時代が終わりを告げたと。

社長:ところでこれって、脚注的なものに使うのも良さそうね。脚注とかって、紙印刷の時代の異物感があるしね。インタラクティブじゃない紙。んーでも、文書全体を公式に残すのには必要な表現方法ではあるのかな脚注。

基盤:埋め込みついでに、data URI を使うとこんな感じになりますね。残念ながら、どのブラウザでも画像として表示されません。↓

deta URIによる画像埋め込み例 ここには data URI scheme で表現された画像が表示されるはずなんですが → ”Larry”

社長:detailed の中に書ける要素って制限があるんですかね。そもそもいつのHTMLからなんだろう。

基盤:HTML5.1から、とありますね。つまり、3年くらい前からです。2020年3月の時点で主要全ブラウザとモバイル系で対応済だそうです。

社長:そうですか、それで最近目にするようになったのか。ついに我が社も時代に追いついて来ましたね。てか、手書きでHTMLを書ける時代が戻って来たようにも思えてうれぴー。

社長:あれ?でも、選択した details を開いた状態で印刷って、できるのかな??

2020-0512 SatoxITS


YouTubeデビュー

社長:YouTubeを活用しようと思うんですが。

基盤:具体的には?

社長:開発したソフトの広告とか無料でできるんじゃないかと。実際の画面上の操作例は製品を説明するのに有効だと思う。うまくすれば視聴料までもらえるとか?

基盤:利用規定とかどうなってるんでしょうね。まあ、とりあえず技術的にどうやるのかを調べてみます。

基盤:やってみました。コンテンツには Opera のウィンドウのリストアを使いまして、こんな感じです↓

https://www.youtube.com/watch?v=dvfOjrde9tw

社長:おお、できましたね。それで、どうでした。

基盤:投稿自体はめちゃめちゃ簡単ですね。タイトル書いて、動画ドラッグして、ポチッと押す。それだけです。ただ、YouTube側での動画の受入れ処理にはかなりかかりますね。でその待ち時間に説明文を書きはじめたんですが、これに30分くらいかかりまして(笑)

基盤:それよりもアカウント名を何にするか迷ったのですが、まあお試しだし、u-tube (Tube You)にしときました(笑)。あと、macOSのスクリーンの動画はどうやって作るんだろうって30分くらい時間を食いましたが、なんのことはなく、OSに備え付けのキャプチャ機能をポチッとするだけでできました。YouTube への投稿よりこれに感動しましたね。最近のmacOS になるまでは、このQuickTime Playerが公式な静止画のキャプチャ機能も兼ねてたようです。それと、この元の動画は47秒で38MBで、もちろん画質はピクセル単位で完璧です。YouTube が配信するのは圧縮してかなり劣化してますね。

社長:そうでしたか。やっぱりMacOS最高ですね。サイコーでーっす!

2020-0511 SatoxITS

Operaと暮らす事になりました

こんなにステキなブラウザがいつもそこにあったのに。これからはもうずっとOperaですね。さようならChrome!

Opera というブラウザは昔から知っていて時々使ってもいました。楚々とした上品な赤いブラウザだと思っていました。品は良いが機能と馬力が足りない、そんな風に認識していたので、何か他のブラウザでうまく行かなかった時のリリーフとか、逆に「Opera でもできるなら大丈夫」的な試験用でした。

ところが、私が目を離していた10年の間に、実用機能的に macOS+アプリが Windows に追いついていたのと同様に、いつからなのか Opera が他のブラウザに機能的に劣る事もなくなっていたようです。

こうなるともう使いやすさ、気持ちよさの勝負です。今日初めてまともに使ってみたのですが、私が10年間 Chrome や Firefox で不便・不快に耐えてきたことが、Opera ではほとんど解決済みなのです。使い勝手がよく考えられていることに唸ります。根本的に設計思想が素晴らしい、というか、実にマトモ。形容はもう楚々ではなく凶暴を秘めた凛ですね。

Chrome のブックマークも Opera にインポートしたので、あと Chrome に残す思いはパスワードだけです。どうせ今でも生きているのは半分くらいしかないし、本当にヤバイのはさらにその半分くらいですから、この際に見直しながら Opera に移そうと思います。同期したがるパスワードのヤバさがクラス分けされてなくて、モバイルの Chrome からですら全てベタに見えてしまうのはどうなんだ?と思っていたところでもあります。バイバイ Chrome。

明日からは(というか既に今現在から) Opera です。きっといつまでも。

2020-0511 sato@izmoh


というわけでさっそくOperaに浸ってまして、デスクトップがこんな風になりました↓

4 x 4 でミニュチュアオペラをタイル状に並べて動かしておいて、開きたいウィンドウのタブを見つけたらそれを Fullscreen にすると別室(別の仮想デスクトップ)に移動、閉じると元の位置に収まる、という形です。いろいろ使い勝手状の問題はありますが気持ち良いです。自分の経験では、同時に開いていて混乱しないウィンドウの数は20くらいまでだし、負荷的にもこんなところかなと思われます。

Operaの実装はたぶん1タブ/1プロセスになってますが、一プロセスはとても小さいです。Chrome時代に比べてメモリプレッシャーが低い。CPUは見た目常時100%近く食ってます(ユーザ70%、システム25%)が、プルセスの優先度が低いのでしょうか、マルチコアだし、インタラクティブな作業を邪魔する感じはほとんどありません。他にCPUバウンドなプログラムを走らせても、time コマンドは、70%程度はCPUを使えた、と報告します。

ウィンドウがすごく多くなったら、各プロセスの優先度をすごく落とすとか、明示的に一時停止させるとか、最近アクセスした順に並べるとか、色々な工夫が必要そうです。ミニチュア化したときに自動的に表示の倍率を小さくするとか、全体を統括するOperaとか必要です。なにより「Fullscreen」じゃない、「Normal」サイズのウィンドウの段階が必要です。昔のウィンドウシステムはそうなってたと思うんですが…Xとか、CEとか…

なんにしても、デスクトップスクリーンが広大になった今日、しかも仮想デスクトップもできるわけなので、もうオーバラップじゃなくてタイルだよなー、と思います。

Operaは終了しても、再起動すると、終了前のウィンドウを完全に復元してくれるので、この設定は継続的・永続的に使えます。もうアップデートのための再起動は苦じゃない (^-^)/。ただ、その復元作業のため、起動時にロードアベレージ120超えとか普通にしますが、それで他の作業に大きな支障が出る感じはありません。変に自前のスレッドとかしないで、OSが管理できる単位であるプロセスにしているのが勝因なのでしょうか?

2020-0511 SatoxITS

モバイル対応

社長:我が社がこれから対外サービスを行うにあたってですね、モバイル端末対応というのは必須だと思うわけです。

基盤:具体的には?

社長:さしあたっては、スマホの画面サイズにページの表示をフィットさせられることと、スマホのユーザにページのURLを簡単に伝えられることですね。

基盤:調べてみます。

基盤:調べました。テスト用のページを作って試したんですが。まずパソコンのブラウザで見るとこんな感じ。

同じページをスマホで見るとこんなふうに表示されます。

社長:ぱっと見よさそうですね。中身を詳しく。

基盤:まず画面サイズですが、ググったところ、HTMLに一行おまじないのメタを貼ると良いということでした。

For starters, use this viewport tag:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
– APAD1 May 20 '15 at 19:56
[ HTML body not filling complete width on mobile devices ]
https://stackoverflow.com/questions/30358630

社長:それだけですか…まあ出だしの一歩だしね。この Satackoverflow のコメントは2015年のだから、もうみんなこのメタをサポートしてるかな。URLをヒトに伝えるのはやはりQRコードですか。

基盤:そうですね。世界に誇る日本生まれの技術ですし。それと、QRを産んだDENSO関連のアララがクルクルのアクセス解析サービス付きQRコードを生成してくれるので、それを貼ってみました。こんなふうにアクセス状況が見れます。↓

社長:なるほど、QR の URLをクルクルのサーバに向けてリダイレクションしてるわけか。これ、いっそページのカウンターがわりに使わせてもらえないかな …(利用規定読む気力がない)…
なるほど、わかりました。お疲れでした。

社長:話はかわるけど、レンタルサーバの運用費の削減のほうはカタが付きましたか?

基盤:そうですね、月2千円でイケそうな感じです。社長は毎月1万円を7年間払ってきましたらから、まあ最初から安い仮想マシンがあったとしたらですが、67万円ほどロスしてますね。

社長:あ、そう。(しょんぼり…)

2020-0510 SatoxITS


CI

広報:当社広告用の看板案ができました。イチオシはこれです。じゃじゃーん。

社長:おおっ!目が覚めるようですね。というか、吐き気すら覚える。

広報:では、この線で進めてよろしいでしょうか?

社長:いや、だめでしょう。一体どいういうコンセプトですか。

広報:不快感は無感覚に勝る、です。

社長:当社の倫理に反するので却下。

広報:代替案も用意しております。これでいかがでしょう?

社長:改善。配色重要ですね。使うとしても赤はワンポイントにしましょう。何か困っていることはありますか?

広報:手持ちの日本語フォントのバリエーションが少なくて。フォントを買うとか、デザイナーさんを頼めると良いのですが。

社長:必要なお金は出します。3千円くらいまでなら。

広報:らじゃー。調査します。


rsync 最高っす!

開発しているプログラムを別のプラットフォーム上でコンパイルして実行してテストしたい。少し変えてはテストしたいので、コンパイル結果は10秒程度で得られると良い。手持ちのツールだけでやりたい。

そう考えたのでとりあえず、変更したらプログラムをリモートのマシンにscpして、sshでコンパイルやテストのコマンドを送るという安直な方法にしました。今日びのOSはデフォでsshを装備しているので、追加でインストールするものはありません。

この手順を行う簡単なシェルスクリプトを書いただけで実現。変更分だけの再コンパイルであれば、差分が小さければ、コマンド打って10秒程度で結果が得られるのでほぼ満足しています。

気になったのは、プログラムをリモートに送り込むための時間です。ソースコード類のサイズはナマだと約10MB、tar して gzip して 2.5MB。scp だと状況によっては転送に数秒かかります。それだけでなく、これを何百回もやってると、サーバ側の従量ネットワーク課金が気になってしまいます。

それで思い出すのが昔懐かしい rsync です。ググってみると最近は通信に ssh を使うようになっていて、すごく健在のようでした。やはり原理的に良いものは生き残るのだな。よし、これで行こう。手元のマシンでも、リモートでも rsync とコマンドを打つと何か動くので、インストールされているようです。

どう使うのか?rsync -h とかするとどどっと出てくるので読む気にならない((実は man rsyncの先頭だけ見ればサクッとわかることに後で気づく))。scp と同じノリで使えるとラッキーと思い、

% rsync ファイル リモートホスト:

としたら、そのまま動きました。 素晴らしいです。

性能的にはどうなんでしょう?超簡単なベンチマークをやってみました。

% openssl rand 10000000 > 10MB
% time rsync 10MB remote:
rsync 10MB remote:  0.46s user 0.37s system 6% cpu 12.435 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.08s system 7% cpu 1.833 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.07s system 7% cpu 1.804 total

リモートのファイルの cksum を確認しましたが、もちろん同一です。そしてこの例では、2回目以降は何もデータ内容に変更が無いので、何も送られていないようです。macOSの(とてもステキな)アクティビティモニターには、一発目の転送しか出てきません。

rsyncでのデータ転送(差分のみ)

一方 scp では毎回データを転送してますので、毎回ニョキニョキと送信データグラフが伸びます。

scpでのデータ転送(毎回全転送)

% openssl rand 10000000 > 10MB
% time scp 10MB remote:
10MB     100% 9766KB 796.4KB/s   00:12    
scp 10MB remote:  0.18s user 0.20s system 2% cpu 13.473 total
% time scp 10MB remote:
10MB    100% 9766KB 893.0KB/s   00:10    
scp 10MB remote:  0.19s user 0.20s system 3% cpu 12.118 total
% time scp 10MB remote:
10MB       100% 9766KB 497.7KB/s   00:19    
scp 10MB remote:  0.19s user 0.19s system 1% cpu 20.791 total

このホスト関係、ネット環境だと、ssh 接続の確立に1.2秒かかる(この遅延、ログインする時に結構気になるんですが)ようなので、それよりは短縮できないですね。常設のトンネルw開通させておくしか無い。rsync自体の空作業は0.1秒未満の模様。

% echo a > a
% time scp a remote:
a                   100%    2     0.0KB/s   00:00
scp a remote:  0.01s user 0.01s system 2% cpu 1.217 total

% echo b > b    
% time rsync b remote:
rsync b remote:  0.01s user 0.02s system 2% cpu 1.283 total

考え所は、クラウド上のサーバのデータ(主に差分はログだけ)のバックアップも rsync でやるかどうかです。ファイル数が70万くらいあるので、変更されたファイルを効率的に知る方法が無いと、それを探索し回るのに結構な負荷がかかりそうです。まあ、変更した本人のサーバかOSが教えてやれればよいのでしょうけど。

とりあえずは、サーバ仮想マシンのディスクのスナップショットをとるほうが簡単だし全面的ですし、スナップショット保管料金は1日4円程度です。なので、あれはあれで良いかなという感じ。

クラウド上のドライブサービスも、rsync的な仕組みが入っていると良いですね。入ってるのかな?

2020-0509 sato@izmoh