ラベル ごおgぇ の投稿を表示しています。 すべての投稿を表示
ラベル ごおgぇ の投稿を表示しています。 すべての投稿を表示

2022年5月18日水曜日

従来型G Suite、無償のまま存続可能へ

色々呼び方があるようで、従来型G Suiteのほかにも、無償版G Suite、Legacy G Suite、はたまた"料金のかからない従来の G Suite"とGoogleさん自身は様々に和名を定義しておられるようですが、要は2012年まで申し込めた「無償で独自ドメインが使えるGmailが使えるサービス」の件です。

このサービスは今年2022年の年頭、1月に廃止されることが発表され、有償版のGoogle Workspaceに移行するか、Gmailが使えない無償版の「Google Workspace Essentials Starterエディション」に移行するか、使用をあきらめるように案内されてきました。
しかし、Google Workspace 管理者ヘルプによりますと、この度、将来的には何らかの制限が加えられるかもしれないが、手続きを踏めばGoogle Workspaceに移行せずに、現在のまま継続して使用することが可能になりました。

手続きというのは、Googleさんに「この従来型G Suiteは非営利目的で個人的に利用しています」ということを伝えることです。といっても、具体的にはボタンというかブラウザ上のリンクを踏むだけです。
早速手続きを終えた後、管理コンソールから確認すると以下のように表示が変わります。
「詳細」をクリックすると以下の画面になります。「個人での利用: 料金のかからない従来の G Suite を引き続き利用」にチェックマークがついていることが確認できます(手続き前はチェックマークの部分が手続き画面に遷移する右向き矢印になっていました)。

なお、すでにGoogle Workspaceに移行した人は、管理コンソールから手続きができません。その場合はサポートに連絡しなければならないそうです。

Google Workspaceに移行する場合も、今回発表された無償版G Suiteのまま使い続ける場合も、いずれも8月1日までに手続きが完了していない場合はアカウントが凍結されます。

まさか無償のまま継続して使用できるようになるとは思ってもみませんでした。
素直にうれしいです。Googleさん、ありがとうございます。

2022年1月22日土曜日

ついにG Suite legacy無償版 G Suite(Google Apps の従来の無償版)が2022/7/1をもって終了へ

初っ端から恐縮ですが、以下タワゴトです。

表題の件、ついに来るべきものが来てしまいました。

メールによる案内はまだ来ていないのですが、メディア各社による報道で数日前に知りました。

こちらのGoogle Workspace 管理者ヘルプによりますと、7/1終了とタイトルに記しましたが、実際には5/1で終了します。

但し、5/1までに有料の Google Workspace サブスクリプションにアップグレードし、かつ支払情報を登録した場合は7/1まで無償で利用が可能ということだそうです。

思えば2011年に発生した東日本大震災における計画停電のため、UPSではカバーしきれない停電時間を、せめてメールサーバだけでもなんとかならないかと思って知ったサービスでした。

それ以来11年もの間、無償で利用させていただいて、感謝の念に堪えません。加えて、無償利用の期限以降も、料金さえ払えばこれまで通り、という点でも感謝です。移行、できません!!とか、移行できます、ただしこれまでのデータは全部チャラ!!、とか結構平気であるので、これはありがたいことだと思っています。

実は、有料化したら震災前の体制に戻せばイイヤという目論見で、すべて機材やサーバソフトウェアなどの準備は常に整えてあり、DNSのMXレコードの振り向け先を変更するだけにはしてはあるのですが、やはり11年という年月は長かったようです。

特に、私だけの事情だけでも、独自ドメインのメールアドレスといっても、GoogleさんからするとGMailの単なる1メールアドレスに見ているようで、例えばこのBloggerさんの登録情報を確認してみると、Google Appsで作成したメールアドレスが、がっちりGMailアカウント扱いされてしまっていました。

まだすべてを調べ切れていませんが、Googleさんのサービスにおいて、この「GMailアカウント(扱い)」ってのが結構重要な意味を持っている場合があるような気がします。

更に確認してみると、その他Google Play Developer ConsoleだのGoogle Cloud Consoleだのその他アレコレで契約メールアドレスを変更することがそもそも行えるのかどうかもわからない状況となっています。多分させてくれないサービスはいくつか出るだろうなとは思っています。

Android端末も、地味に困るのかなという感じです。

こういった数ある事情が、メンバーの数だけあるので、仮に移行するならばよほど慎重に行う必要がありそうです。

それに、GoogleさんのGMailの迷惑メールへの対応能力が素晴らしすぎて、自前で管理するメールサーバに戻したとして、情熱をもって管理しきれるのか、ということも考えなくてはなりません。

ま、要するに、見事にロックインというわけです。

2004年から使っているメールアドレスを、Googleさんにゆだねたまま安易に11年もの間、甘えてきたツケを支払う時がやってきたわけです。

自業自得ですね。

このままGoogleさんにお願いした場合、最安でも一ユーザ毎に税込み年額一人当たり\8,976円。無論人数分かかります。

自前での管理に戻す場合、まさかThunderbirdを今更皆にインストールしろ、なんていえません。WebメールはRainLoopでいいとして、カレンダーツールは?、あれは?、これは?、アップデートの監視は?、セキュリティの監視は?、トラブル対応は?、SPAMの対応は?、サーバが死んだら代替は?(新サーバ導入までの一時的運用ならGoogle WorkspaceかOutlook365でいいかも)

何の利益を生み出さないのにこの価格や労力を支払うことが、果たしてどうなんだという結論もあるかもしれません。その場合は、このドメインを(メール用には)捨てるという決断もありうるかもしれません。

今のところどうなるかわかりませんが、それにしても、本当にG Suite legacy無償版 G Suiteの提供は実にありがたかったです。

選択肢は多いので、ゆっくり考えたいと思います。

ゆっくり過ぎて5/1を過ぎても、お金さえ払えばこれまで通り、という点で大変安心です。
安心しすぎて、結局居心地がよくて支払い続けることになりそうな予感・・・

このような駄文をここまでお読みいただいてありがとうございました。

2019年4月21日日曜日

空き時間に合わせて本を一冊、無作為に青空文庫の公開中の作品から提案するページ

あまりにもgoogle app engine上でphpを動かすのが私でも楽過ぎたので、調子に乗って表題のようなものを作ってしまいました。
見てくれは地味で恐縮ですが、こんな感じです(javascriptで動作します)。


今回の一冊 🔄
リクエスト中...


ご希望の読書量は:
+その他の検索条件  
児童書は?
旧字は?
旧かなは?
読みたいジャンルは?
著者名(and,or,notは正規表現でお願いします)


とりあえず何でもいいからランダムに一冊選べるといいなあ、とずっと思っていたのですが、ついでに時間をつぶしたい時間を指定できればいいかな、と思って作ってみたところ、思いのほか気に入ったので、さらに提案機能をオリジン間リソース共有可能なAPI化して公開してみました。
この上の画面は、そのAPIをajaxで呼び出して実装しています。

作品が気に入らなかったらリロード絵文字(絵文字が見えない場合は「今回の一冊」という行)をクリックしますと、読書時間に合わせた別の作品を提案します。

それにしても、こういう一発ネタも膨大なデータをそろえて公開してくれている人や組織、団体様あってこそでございます。
今回は青空文庫さんからGitHubさん経由でデータを拝借して実現できました。
ありがとうございます。

geocitiesや大学のサイトなどで公開されている作品は除外しましたが、提案候補は一万五千冊を超えてます。
すごい。

なお、この例のようなデータを取得するAPIの詳細についてはこちらをご参照ください。
お読みいただいてありがとうございました。

---
2019/07/13 選択対象元リストを表示する機能(Selection candidate listボタン)を追加しました
2019/08/27 著者名を正規表現(perl互換)を用いて絞り込む機能を追加しました。

2019年4月12日金曜日

ローカル環境にgoogle謹製SDKをインストールせずにGoogle App Engineにプロジェクトをdeployしてみる

たった数年前なのに、Google App Engine(以下GAE)というサービスがいろいろなものと統合されちゃって最近ではGoogle Cloud Platform(以下GCP)とかいうことにしたんですって奥様。

で、今も稼働中の、とあるサーバ機能を持つアプリはeclipseでdeployしてた覚えがあるんですが、もう既に安定稼働につきメンテナンス不要モードに入って何年もたっていて、GAEにアプリをdeployする方法も忘れちゃいました。

そこで、GAEの知識を更新したくなったので、一つなんかやってみるべえ、と思い立ちました。

今ではプロジェクトに選択できる言語が増えていますね。
無償枠で使える言語中から選ぶとすると、javaでのプロジェクトはdeployも運用もすでに経験済みというか運用中だからパスするとして、pythonはインデント縛りのおかげで私にとってメンテがだるい言語だし(インデントを忘れているのか意図しているのかわかりづらいケースがイヤ)、goは開発環境を整えるところから始めなくちゃいけないし、ということで、結局、残っている言語はphpとなりました。

そこで、phpで、アクセスされたら問答無用で四字熟語を送信するサーバを作って、それをGAEにdeployして運用してみようと思います。

余談ですが、以前と大きく変わった点としては、「組織」ってのが必須になっていることです。
これは私のアカウントがG Suiteのせいかもしれません(東日本大震災時に計画停電のせいで自宅サーバがぶっ飛んだ時にgoogle様に独自ドメイン用MXをお願いしたらなぜか今ではG Suiteというサービスになってしまったんですよねぇ)。
そして、めったやたらに権限が細かい。
何をするためにどんな権限が必要なのかがとってもわかりづらくて、プロジェクトを追加する権限は一体どれなんだ、と片っ端から権限を与えてはプロジェクト作成を試すという頭の悪いことをしてしまいましたが、結局どれが「組織なし」へプロジェクトの新規作成ができる権限なのかさっぱりわかりませんでした。
まあ、この辺りは本題から外れますのでいい加減にするとして、本題に戻ります。

ともかくGCP上でプロジェクトを作成してしまいましょう。
さすがにこの手順の解説は端折ります。
ブラウザ画面左上にプロジェクト名が表示が表示されていますから、そこからちゃちゃっと追加してください。

プロジェクトが無事生成出来たら、今度は画面右上の
というアイコンボタンをクリックしますと、bash(Cloud-shell)が立ち上がっちゃいます。

こうなったら、とりあえず自分のプログラムをこのコンソールが立ち上がっているところにダウンロードします。
とりあえず、まずはgitでhttps経由でcloneしてみます。
gitコマンドの使い方は、あまりに文献が豊富なのでここでは説明しませんが、オレオレサーバからhttps経由でcloneしてみます。
無論、別にhttpsでgitじゃなくてもいいんですけど、私が構築してあるgitのbareなリポジトリはgitbucketを利用させていただいている関係でhttpd経由でアクセスするお約束なんですが、そのhttpdがhttps経由でしかgitbucketにアクセスさせない定義になっているというだけの理由です。
あとで触れますがgitである必要性は全くありませんがともあれ説明手順が楽なので一通りこの前提で説明します。

1) オレオレサーバなのでhttps経由の場合は証明書が証明になってねぇよと怒られるので、gitさんに検証をしないで黙って持って来いとお願いする設定にします。
$ git config --global http.sslVerify false
2) オレオレサーバからデプロイしたいプロジェクトをcloneします。
3) cloneしたディレクトリにおります。
4) deployします。
$ gcloud app deploy

以上で終了です。
たったこんだけ。
app.yamlを書き忘れていても3)の段階で書いちゃえばOK。Cloud-shellからはemacsもvimも使えますので宗教論争も無縁です。え?edですか? それはないみたいですね。

んー。gitって何それ?という方に朗報です。
実はscpもsftpもwgetもcurlもCloud-shellから使えるんです。
ですので、開発したプロジェクト一式をzipかなんかで圧縮して、それをCloud-shell上でダウンロードして、展開するだけでいいわけです。
書庫の展開にはunzipもtarも、その他めぼしいところはそろっています。

方法はどうあれ、ソースをgetして展開してdeployしておしまい。
ちょっと前までが信じられないほど極めてシンプルです。

自分の管理下にあるサーバにSDKだのなんだの、得体のしれないものを一切インストールする必要がありません。Cloud-shell上に一式そろっています。

わしの環境じゃあSDKの実行にゃあpython2.7以上が必要じゃけえのう、OSのパッケージ管理システムから外してmake installせんならんけえのう、とか細かいことは何も考えずにデプロイできます。

一度デプロイしちゃえばこっちのものなので、あとはgit cloneしたり tar zxvfしたディレクトリをrm -frしちゃってください。まあ、記念に残しといてもいいですけど。

いやあ、httpsをしゃべれてプログラムも実行できるんですからインスタンス時間が28時間まで無料なGAEってホントにまいっちゃいますね。

で、何をdeployしたのかというと、アクセスすると約7千件あるデータベースの中から四字熟語を1つだけあなたに提案する「提案型四字熟語供給システム」です。大げさでいいでしょ。
インタフェイスはJSONです。供給されるのは四字熟語と、その読み。
どこからでも使えるようにオリジン間リソース共有に対応しています。
一日一語で覚えてゆきましょう。

以上です。
こんな記事をお読みいただいてありがとうございました。

2019年1月12日土曜日

The Guild II:Renaissance + MegaModPack 0.95用日本語化

あけましておめでとうございます。
なんでいまさらThe Guild II:Renaissance + MegaModPack 0.95なのか。
それは、以前0.8用の翻訳に手を付けてしまったからです。。。
自業自得です。
そういえば0.8用の翻訳も正月早々にやったんでした。

で、超めんどくせーと思いながらMegaModPack 0.82とMegaModPack 0.95の追加・変更されたテキストを翻訳してみることにしました。

とりあえず差分を比較してみた結果、追加607件、変更221件、削除72件、合計900件もの変更がありました・・・

結局翻訳は手動でやるしかないわけで、追加変更分を涙目になりながら翻訳シートを埋めてみたのがこちらです。ま、ほとんど機械翻訳なんですけどね。
後期中年者から初期老齢者の境目になるとコピペ900回とかかなりツラい。
Weblioさん、Google Translateさん、いつもありがとうございます。
Google Translateさん、奇妙な造語をするクセ、なんとかしてください。

しっかし、あれですな。
久しぶりにシートを眺めると、機械翻訳のままのところ、本当にひどい。
以前からわかっちゃいるけど、訳文、18,000行くらいあるしね。一人じゃ無理だし、そもそも全然需要がないからいいよね。

で、成果物はこちら0.82用との絡みでファイル名をText095.dbtに変えてあります。ダウンロードしたらText.dbtにリネームして使ってください。
ついでに、気に入らない翻訳があったら是非直すのにご協力いただければ幸甚です・・・まぁねえよな

そんなわけで本年もよろしくお願いいたします。


おまけ:
シートから直接dbtを作るスクリプト
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#!/usr/bin/env python3
 
#
# MegaModPack0.95用翻訳「元」シートから0.095用のText.dbt を生成するpython3 script.
# input:
#       1. 0.95用シートのtsv
#          tg2tsv_095.tsv
# output:
#       0.95用のText.dbt
#           Text095.dbt
#
 
import re
 
def make_dbt():
  regpattern = r"^\"*(\d+)\"*\t\"*(.*)\"*\t\"*(.*)\"*\t\"*(.*)\"*\t\"*(.*)\"*\t\"*(.*)\"*\t\"*(.*)\"*\t\"*(.*)\"*\r*\n$"
  reg = re.compile( regpattern )
   
  with open( r"tg2tsv_095.tsv", "r", encoding="utf-8" ) as fin:
    dic = dict()
    for line in fin:
      m = reg.match( line )
      if not m :
        continue
      index = m.group(1)
      id = m.group(2)
      en082 = m.group(3)
      ja082 = m.group(4)
      vanilla = m.group(5)
      en095 = m.group(6)
      ja095 = m.group(7)
      type= m.group(8)
      if ja095 == "" and en095 != "" :
        raise TypeError('Japanese translation is not completed!!')
      dic[ int(index) ]  = [ index , id, ja095 ]
 
  keys =  sorted(dic.keys())
  isfirst = True
  with open( r"Text095.dbt", "w", encoding="utf-16" ) as fout:
    for key in keys:
      if isfirst == True :
        isfirst=False
        fout.write("//Table File\n//by RUNEFORGE Game Studio\n//Translated by ttgcameback.blogspot.com\n\nTable Description:\n\"id\" INT  0   |\"label\" STRING  0   |\"english\" STRING  0   |\n\nData:")
        fout.write("\n")
      arr = dic[key]
      line = arr[0]
      line +="   \""
      line += arr[1]
      line +="\"   \""
      line += arr[2]
      line += "\"   |\n"
      fout.write(line)
 
make_dbt()

2018年10月27日土曜日

Android用のブラウザで暗い背景色で長文が読みたい

当blogは副題をネットウラシマと申しまして、浦島太郎感漂う「こんなことも知らんのか」と言われるようなハズカシイ話題を記録するblogです。

そこで、今回のお題は「Android版のブラウザでの長文読書は背景が真っ白で目につらい。」です。
対策は「背景を黒く(暗く)すればいい。」

当たり前すぎます。
が、今時のメジャーブラウザはこれがまったくできない、またはプラグインが必要とされることに衝撃を感じたので記録する次第です。

結論から先に書きますと、(Chrome以外でメジャーと言えるブラウザの存在があるとして)メジャーどころではAndroid版Firefox+アドオンでのみ実現可能でした。

Firefoxで背景色を暗くするアドオンは複数あるのですが、その中ではDark Readerが個人的には最も出来が良いと感じ、採用しました。PC版ChromeおよびSafari用にも同一アドオンがあります。

他はあまり良い評価点を与えられなかったので名を挙げませんが、速度に難あり(白いままの画面が割と長い間、といっても数秒、表示されてしまう)、色に難あり(反転しなくていい文字色や画像も単純にinverseされたり特定の文字色以外は全部白になったり等)、文字数が多くなると急に無反応、スクロールするとスクロールされた領域が白いまま、など、数は多かれど実質的にはとても使えなかったり、ザンネン感が高いものが多かった中、比較的動作が良好だったのが採用の理由です。

加えて、Android版Firefoxのプライベートタブでは、画面上部のタブ名表示部もアドレスバー表示部も暗色表示になるため、その部分を暗色表示にするためだけのアドオンを探さなくても気になりません。
この部分は「設定」->「一般」->「全画面表示でブラウジングする」オプションスイッチを有効にしたうえで、なおかつ、画面を上にある程度スクロールさせないと引っ込まないという大変鬱陶しい仕様ですので、最初からその部分が暗いプライベートタブで読むと手っ取り早いと思います。

実際にやってみた範囲内では以上です。

以下、なんでAndroid用のブラウザの画面を暗くしたいのかを含めた前置きと、なぜ結論で述べた以外のブラウザで実現できないか、などを書き連ねた戯言です。

子供のころから寝る前に本を読まないと寝付けない習慣がついてしまっていて、枕もとの照明で読んでいました。

ところが、スマートフォンが普及して高解像度で文字も美しく表示され、さらに一画面内の文字数も文庫本1ページ程度は軽く表示できてしまうに及び、枕もとに本を積んでおく必要もなくなり、照明をつけなくとも読めるし本より軽いのですぐにスマートフォン、その後はタブレットを用いるようになりました。

読書に用いるアプリ、例えばKindle、自炊jpeg化した小説などではPerfect Viewerなど当然のように白黒反転機能がついています。
Android4.2だか4.3まで標準搭載されていた「(アプリ名としての)ブラウザ」(ややこしいので以後旧標準ブラウザと表記します)にも、実は画面の反転表示機能があります。

尤もブラウザを使って本(長文)を読むことはなかったので、主に白黒反転機能があるアプリだけでこれまで読んできました。

ところが最近、中国古典に再度嵌りそうになっています。
Web上に面白い文献がたくさんあり、すぐに原文を参照出来たり、意味が分からない言葉の解説をすぐに調べることができ、これは寝る前にちょっとづつ読むのにいいな、画面が大きくて複雑な漢字でも明瞭に表示できるタブレットで読みたいなと思いました。

が、現在の主流ブラウザの背景色は白い。とても白い。
暗い中で真っ白な画面を見た瞬間、虹彩を絞って瞳孔を狭める筋肉に痛みが生じるくらい急激な動きを生じる程度に極めて白く、そして眩しいのです。

とてもではありませんが「読む」なんてできません。せいぜい「見る」程度でもすぐにギブアップです。
普段PCで使うモニタよりも段違いに近くで光る白い板を、暗い中で見つめることになるのですから当然といえば当然です。

旧標準ブラウザを搭載するスマホも手元にあるにはあるのですが、XperiaAなので画面が小さいためタブレットで読みたいということで、調べてみました。

さて、ようやく本題です。

まず普段だったら大本命のAndroid版Chrome。
PC版と違い、アドオンも入れられません。だからカスタマイズもできません。
このケースでは絶望です。

旧標準ブラウザもGoogle製にも拘らず、Chromeには旧標準ブラウザのような反転機能が搭載されていないどころか、アドレスバーも何もかも真っ白です。
但し、何の解決にもなりませんが念のために申し添えますと、シークレットタブの場合はアドレスバー表示部だけ暗灰色になりますが表示中のコンテンツの背景色には何の影響も与えません。そりゃそうです。

Android版Chromeを含めて、どうしてもブラウザ自身で表示中のコンテンツの背景色を暗くすることができないとすれば、OSの機能を使って色反転する手があるだろう、と思われるかもしれません。確かAndroid5だか6だかで搭載された機能です。
しかし、当然ながら略図や地図、石碑や鼎などの写真などの画像も反転してしまいます。さらに当然ながらブラウザ以外も反転します。
画面上部の通知領域と下部のナビゲーションバー(戻ったりするボタンがあるバー)も当然ながら色反転されてしまいます。
通常この両者の背景は黒なので、反転すると白くなります。一部だけ輝いていて眩しい上に余計目障りになってしまいます。
じゃあ両者を白くする/できるホームアプリを入れれば解決でしょ、と言われそうですが、そこまでするのは余程そのブラウザに対する忠誠心が高い人に許される特権でしょう。

そこまでして使うほど愛するブラウザなら別ですが、そもそも、単純に不便ですよね。

従って、あくまでもブラウザ内だけで表示コンテンツの背景色およびガワ(アドレスバー等)を暗色で表示できるブラウザを探しました。
以下、それを踏まえて縷々続きます。

お次はAndroid版Edge。インストールしたことがないしWindows10版でも自作javascriptを使った当blog用コンテンツの動作確認のためだけにあるストレージの肥やし感満載のMS期待の星です。
Chrome以外のブラウザが出てくること自体は大歓迎ですので、試しにインストールしてみましたところ、これも真っ白。背景色を暗色にするオプションも見当たらず、アドオンも利用不可。
PC版ではいつかIEのシェアを抜く日が来ることをお祈りいたしつつ結局アンインストール。

今度はAndroid版Opera。わかりやすいところに「ナイトモード」という切り替えスイッチがあるので一瞬「おおおっ」と一気に胸が高鳴りますが、実はガワが暗色に変わるだけでメインのコンテンツには適用外です。
他ブラウザでもシークレットだかプライベートだかのモードで開けば大抵そのあたりは暗色ですのであんまり魅力がありません。
ていうか最近ナイトモードとか流行ですねぇ。
平たく言っちゃえば、単純にブルーライト商法ってやつですかねぇ。
でしょうねぇ(自己納得)。

そしてなによりAndroid版Operaも背景色を暗色にするオプションが見当たらず、アドオン適用不可能のためカスタマイズ不可。
個人的にはPC版Opera12までは相当お世話になっていたため、過去一瞬だけAndroid版Operaを使ったことがあるのですが、その際は様々なサイトがまともに表示されずにレイアウトが盛大に崩れていたので即アンインストールした覚えがあります。
今回も、要件に合致しないためまたもお払い箱にせざるを得ませんでした。

今度はAndroid版Firefoxです。先の結論で申しました通り、Firefoxにアドオンを適用出来たおかげで要件を達成することが出来ました。

完全に個人の環境のせいだと思うのですが、本当はこれは避けたかった。
利用したいタブレットがMediaPad T2 Proで、この端末でFirefoxを使うと、Firefoxの初回のページ読み込みが何かのタイムアウト待ちに引っかかっているらしく、自宅サーバのホームページだろうがgoogleの検索ページだろうが、ともかくなんでもかんでも初回表示に必ず数十秒かかるためです。

同じAndroid版Firefoxでも他のスマートフォンでは全くそんな現象は起きませんし、当然他のブラウザでは一切そういったことは起きないのですが、起動後一度でも読み込みを完了しさえすれば速度的には問題なくなりますし、ページのレイアウト崩れもあまりないというメリットもありますので、Windows版とLinux版ではお世話になっていることもありますし、これからAndroidでもお世話になることにいたしました。

他にもAndroid版ブラウザはあまたありますし、中には反転機能を最初から備えたブラウザもあるのかもしれませんが、とりあえずはこれで運用してみたいと思います。

それにしても、PC上では背景色が黒くないと嫌なのはテキストエディタとvt100エミュレータくらいで、これはMS-DOSのころのアプリは背景色が真っ黒なのが一般的だったなど慣習的なもので、眩しさとかは全く関係がありません。現に、個人で気軽に使えるマルチウィンドウシステムが普及した後で使い始めたIDE(VisualC++とか)やらExcel,Word等の背景が真っ白でも全然違和感を感じません。当blogの背景色も真っ白ケッケです。

部屋が暗い中でPCを使うなんてこともありませんので、背景色を暗くしたいということを切実な要望として感じるのはスマートフォンやタブレットならではといえるのかなあ、と勝手に思う次第です。

以上、恥の記録と長大な駄文でした。
お読みいただき、誠にありがとうございました。

2017年7月12日水曜日

保存のためのコーデック: H.265 vs VP9 私見

先日、ふと「そういえばVP9てのもあったな」と思い出しました。
Googleが頑張ってるみたいで、H.265(HEVC)に迫る画質だそうな。
どんなもんかな、とYouTubeのVP9の4K映像サンプルを見に行ってみましたが、確かにきれいです。

そこで、現在利用しているエンコーダをVP9に単純に置き換えた場合どうなるのかを調べてみました。
端的に言えばタモリ倶楽部の飲み企画をエンコードしておいて酒のツマミにするために保存するためのエンコード形式への一管見です。

エンコーダのフロントエンドは今回はHandBrakeをgithubからクローン(63e20c1-master)してビルドしたものを使います。
ffmpegでもいいんですが、コマンドラインが煩瑣なのと(VP9でもH.265でも設定を追い込むならffmpegのほうがいいと思います)、最近Handbrake1.0.7で利用されているlibx265の2.1と最新の2.4の比較のためにビルドした環境があったHandbrakeを使用します。
CPUはIntel(R) Celeron(R) CPU G1820 @ 2.70GHzを使用します。
OSはCentOS7です。
libx264のバージョン: 2.4
libvpxのバージョン: 1.6.1

ソースファイルはMPEG2-TS(そらそうだ)30分の先週のタモリ倶楽部です。
ファイルサイズは3.06 GB (3,288,296,156 バイト)。
・・・で計測するつもりだったんですが、後述しますようにエンコード速度がぶっちぎりで遲いのがあった(VP9+Vorbis: MKV)ので900秒目からの30秒間のエンコードを行うことにしました。
(投球されたボールを追いかけるカメラワークもあって割と動きがあるあたりです)

その結果は以下となりました。

H.265+AAC: MP4VP9+Vorbis: MKVVP9+AAC: MKV
オプション--decomb=Default
--crop 0:0:0:0
-e x265
--h265-profile main
-q 28
--cfr
--aencoder copy
--format av_mp4
--start-at duration:900
--stop-at duration:30
--decomb=Default
--crop 0:0:0:0
-e VP9
--modulus 2
-q 28
--cfr
--aencoder vorbis
--start-at duration:900
--stop-at duration:30
--decomb=Default
--crop 0:0:0:0
-e VP9
--modulus 2
--vb 1691
--cfr
--aencoder copy
--start-at duration:900
--stop-at duration:30
エンコード後サイズ6.75 MB
(7,084,380 バイト)
187 MB
(196,485,180 バイト)
6.81 MB
(7,143,742 バイト)
ビットレート1689.46 kbps52195.44 kbps1708.25 kbps
平均処理速度4.947090 fps1.433700 fps4.908809 fps
Windows10での視聴
VLC media player問題なし問題なし問題なし
Windows Media Player問題なし不良※1不良※1a
映画&テレビ(ストア)問題なし不良※1不良※1a
Android(5.1.1)での視聴
VLC media player問題なし不可※2不可※2
MX Player問題なし不可※2問題なし
※1: 音声が再生されない(これはcodecがないんだろうから入れればいいので問題ないとして)、16:9で再生されなければならないのにdisplay dimension(1920 x 1080)を無視して再生時アスペクト比が4:3となる(Windows Media Player側の実装の問題でしょうね。なぜなら、H.265の場合はちゃんと1440x1080を16:9に引き伸ばして再生できているのですし、VLC media playerでは両者ともに正しく4:3で格納されたデータを16:9で再生しているわけですので)。
※1a: 音声の再生はOKだが映像は※1と同じく4:3で描画されました
※2: アスペクト比は正しいものの、最初の1フレーム目しか表示されない(ビットレートが高すぎる、またはハードウェアによる再生支援機能がないので再生できないものと思われる)。音声の再生は行われる。

ご注意VP9+Vorbis: MKVの場合ですが、ビットレートが異常に高いため、エンコード速度もファイルサイズも格段に悪くなっています。--qualityオプションではなく、H.265と同じようになるようにビットレートを直接指定したのがVP9+AAC: MKVの結果欄となります(HandBrakeのオプションを単純に置き換えたらどうなるかという趣旨でやったらビットレートが桁違いに高くなってしまったので仕切り直しました)。
また、折角仕切りなおすので、音声コーデックもOpusだとWMPではそもそも映像も含めて再生不可でしたのでAACをMPEG2-TSからコピーしてエンコードしました。

結論:
ビットレートがほぼ同じならサイズもエンコード速度もほぼ同じ。
まさしく互角です。音ズレもなく良好です。
ただし、ちょっとだけVP9のほうがビットレートが高いのですが、それでも動きのあるシーンではHEVCより少々粗さが目立ちます(大人の事情でお見せできませんので個人的官能評価です)。

HandBrakeを使ったから悪いのかも知れませんが、ffmpegもHandBrakeもライブラリはlibx265とlibvpxを使ってるわけで、ソースも全く同一なんだから大した違いはないだろうと勝手に決めてffmpegではテストしません。

なお、H.265でRF=28.0にしてあるのはテストのためではなく、私が普段のタモリ倶楽部のエンコード時に指定している値で、個人的に1920x1080での鑑賞に堪える数値と思っている点にご注意ください。
HandBrakeでVP9でエンコードする際のオプションで-q(--quality)を使うとビットレートが高くなりすぎてしまうのは前述のとおりです。

いやあ、噂には聞いてましたがH.264のパテント料を払いたくないってだけでここまでやるんだから、やっぱりgoogleスゲぇっす。
まあ、H.264では結局MPEG-LAと契約しなくちゃいけなくなったみたいですが、すごいことには変わりません。

H.264のみならず、打倒H.265を目指していたと聞いていましたが、なるほどと納得です。確かに互角、しかもパテントフリー。スバラシイ。

ただ・・・些末な点で言えば、現時点では再生するアプリやハードウェアを選んでしまうのが瑕瑾でしょうか。
もっとも、映像配信事業者としてのYouTubeの存在感が薄まらない限り、近い将来には再生できない環境はないところまで普及するものと思われます。最新のCPU/GPU/SoCではVP9をサポートしているようで、HEVCのアドバンテージは薄れてきているのかもしれません。

むしろ、特許関係でがんじがらめなHEVCは不利かもしれませんねえ。
まあ、特許関係ではAppleはライセンスホルダなのですし、MicrosoftのWindows10は標準サポートを謳っている上、最悪でもlibx265はGPLv2として公開・配布されてますので見られなくなることは考えられないし、方やライセンス的にフリーだといっても、現状だけ見るとVP9支援対応ハードウェアは最新のものに限られていたり、推進元がGoogleなのでAppleと反目しそうだし・・・と、事態は混沌を極めているようにも見えます。

だったら、同様なビットレートだとちょっとだけきれいに見えるH.265を使っとくか。という程度ですかねえ。

月並みな感想で終わって申し訳ございませんが、現時点では以上です。

2017年4月22日土曜日

Chrome 58.0.3029.81 でオレオレ証明書がエラーになった

Chrome 58.0.3029.81 になったらまたもやオレオレ証明書で証明しているサーバへ接続不能になってしまいました。
相変わらず世界の支配者google様ですから、「どうせ馬鹿にはわかるまいから簡単に言うとだな」的な抽象的なエラーメッセージしかお示しくださいませんので詳細は不明です。

*** 2017/4/27 追記***
エラーとなる根拠がわかりました。
以下に記述したようなワイルドカードが理由ではなく、subjectAltNameがないことが理由でした。
以下の記事ではSANを利用してみる気になったので偶然解決したように見えただけで、ワイルドカードかどうかに関わりなく、以後ホスト名の証明にはCNではなく必ずx509v3の別名(subjectAltName)を利用した証明書でなければChromeが警告を出すようになりました。
以下の記事は本ブログの趣旨である恥の記録として残しておきたいと思いますが、エラーとなる理由は今回追記した通りで以下の内容は間違っておりますのでご注意ください。
*** 追記ここまで***

2014年に署名アルゴリズムをsha256に、ビット長を2048へ変更して以来(あの時もchromeが文句を垂れるためでした)、またgoogle様によって作業を強いられることになりました。

優渥かつ寛大で親切なgoogle様に教えてもらったエラーメッセージでは詳細な原因が不明なので類推するしかありませんが、可能性としては証明書でCommon Nameにワイルドカードを指定していることが原因ではないかとあたりをつけました。

ワイルドカード証明書が使えたおかげで個別に作っていたものが一つになって大変便利だったのですが、また以前のようにサーバ毎に証明書を発行するのが最も確実だろうとは思いますが、大昔は対応するブラウザやメーラががほとんどなくて導入を断念した経験のあるsubjectAltName(SAN)を試してみることにしました。

結論から言うと、CNにワイルドカードを指定せずにSANにDNSを定義した証明書で無事chrome様が接続してくださるようになりました。Flash専用ブラウザとしてしか使っていないのに超生意気な奴だ世界シェアトップなブラウザともなりますと頭の悪い人万人が安全に使えるように様々な余計な世話配慮が鬱陶しい素晴らしいですね。

しかし・・・RFC2818では、ワイルドカードの使用が認められているはずなので、もしかしたら私の勘違いで他に問題があるのかもしれません。あるいは、自己認証局に対してだけ厳しくしているのかもしれません。
結局のところ、エラー表示があまりに不親切なので真相は闇の中です。

ちなみにopensslを使用したSAN対応証明書生成手順は以下の通りです。
  1. 設定ファイルにSANを定義する
    1. [req]エントリに
      req_extensions = v3_req
      を追加
    2. [v3_req]エントリに
      subjectAltName=alt_names
      を追加
    3. [alt_names]エントリを追加し、
      DNS.1=www.domain
      DNS.2=mail.domain

      のように証明したいサーバ名を追加
  2. 署名要求(CSR)の発行時のコマンドラインに -reqexts v3_req を追加
    例えば、
    署名アルゴリズム: SHA256
    設定ファイル名: $CFG
    有効期間: 1万日
    秘密鍵ファイル名: $KEY
    署名要求ファイル名: $CSR
    とした場合は以下になります。
    openssl req -sha256 -config $CFG -reqexts v3_req -new -days 10000 -key $KEY -out $CSR
  3. 認証局での署名時のコマンドラインに -extensions v3_req を追加
    例えば、
    認証局の秘密鍵ファイル: $CA_KEY
    認証局の証明書ファイル: $CA_CERT
    署名済み証明書: $CRL
    とした場合は以下になります。
    openssl ca -config $CFG -extensions v3_req -in $CSR -keyfile $CA_KEY -cert $CA_CERT -out $CRL
それにしても、この件に限りませんが、単に例外として認めてくれればいいところを、あまりに自分が何をしているのかわからない人が多すぎて、こうしてプログラム側で例外を認めず制限をかけてユーザを保護,言い換えれば自由を奪わざるを得ない風潮は加速する一方ですねえ。
ユーザの裾野が広がるほどそうせねば顧客が離れるのですから仕方がないのでしょうが、どうも過激なくらい過保護になっている気がしないでもない今日この頃です。

2017年3月10日金曜日

Google AdMob, AdSenseの導入

このような場末のマニアックなブログにまで来てくださる方たちですからadblockの導入率が高いと思いますが、実は先日、AdSenseを導入いたしました。
私自身も自宅内サーバのdnsmasqでふつーに広告URLをdropしていますのでPCでもタブレットでもスマホでも広告は見えません。(まあ、自分自身でうっかりクリックすると契約違反になるそうですのでむしろ自衛となるわけだからいいよね)

なぜ今頃こんなことを言い出したかというと、AdSenseを導入できなくて阿鼻叫喚している人が多いということを知って驚いたからです。

事前に申し上げておきますが、広告掲載開始の知らせを受けて一か月程度ですが、
¥100円
にもなってないサイトの記事ですので、そこのところはご承知おきください。

以下、すごく長い余談です。
まず、いきなり話が飛ぶようですが導入の動機はUnityです。

そもそも、Cities: SkylinesというゲームのMODを作っていて、そのCities: SkylinesはUnityがベースになっているのですが、私はまったくUnityというものを知らないながら(そしてC#にも不慣れながら)調子に乗っていくつかMODをリリースしてみたものの、そもそもUnityってなんなのよ、どういうものなのさ、と気になっていました。

で、あるパズルゲームのアイディアが浮かんだので、Unityってゲームエンジンなんだから作れないかな?と、これをUnityで実装してみようと思い立ったのがきっかけでした。
調べてみると、なんとWindows, Linux, Android, iOS, なんでもかんでも一つのコードで動かせるというじゃあありませんか。びっくりしました。
さらに個人利用は無料だっちゅうので、こりゃあいい、一つ勉強してやるべえ、と実際に作り始めてみますと、最初は独特の概念などがあって面食らったものの、Cities: SkylinesのMOD作りで見よう見まねで苦労してきた甲斐があってかほんの数日で作りたいとおもっていた以上のものができてしまいました(もともと大したものではないのですが)。
もちろん、こんなことが可能だったのはUnityだけでなく、ゲーム用の楽曲や画像などの素材を提供してくれる各サイトの皆さんのおかげということはこの場を借りて感謝を申し上げたいと思います。

で、実際にAndroidの実機がいくつかあり、実際にテストプレイをしてみると、本当にコードを書き換える必要もなく古い機種でも割合快適にプレイできるapkをUnityが吐いてくれているのに気をよくしてしまい、(かなり)過去にAndroid用アプリを公開しているためデベロッパーID取得費用の$25も支払い済みですので、個人的には結構満足な出来だったので最適化をしたうえでAndroid用のゲームとして公開してみようと思い立ちました。

そこで、さらに一工夫してみたいと思いました。広告です。
今時のアプリは何でもかんでも広告がついてます。

これまでの経験からAndroid用アプリは余程経費をかけないとダウンロード数が伸びないことはわかっているので、今回もほぼ誰も遊んでくれるどころかGoogle Playで誰にも見つけてもらえないところに落ち着くことは目に見えていますし、そもそもこれまで個人的な活動で作ってきたプログラムは数多くフリーウェアとして公開してきましたが(MS-DOS用常駐プログラムすらVectorさんでいまだにおいていただいていてたりします)、AndroidやiOSの世界は独特です。過当競争どころの騒ぎではありません。
まーどうせ誰にも見てもらえないなら技術的に面白そうだというだけでやってみてもいいだろうということで広告を入れるには何がいいかな、と調べると、GoogleがやってるAdMobというのがあることを知りました。

そこで、どうせAndroidだからGoogleさんのサービスがいいやねと思い、AdMobを導入するにはどうすればいいか、と調べてみると申し込みが必要で、それは当たり前ですが、これとAdSenseがなんか連携しているということでした。で、このAdSense、どっかで見たなー、と思ったら、このブログで何年か前だったか、割と読んでいただいた記事があって、その時にAdSenseに申し込んでくれたらうれしいなー、みたいなことをログイン時に言われてたのを思い出しました。
まあ、そんなことはほんの一瞬だけでしたので、たぶん勧誘する対象を誤判定したんでしょう。

話が回りくどくて恐縮ですが、これでAdSenseに申し込んだ理由にやっと戻ってこれました。AdMobに申し込むとAdSenseとAdWordsのアカウントを同時に取得させられるとのことでしたので、折角の機会ですしAdSenseのほうも申し込んでしまえ、という次第です。
AdWordsのほうは、これはむしろGoogleさんに広告をお願いするアカウントのようなので、そんなこたあまずないだろうと思います。

で、間借りしているこのBloggerさんだと、ボタン一発で申し込みができるようになっていましたので、さっそくそのボタンを押して見ました。すると、AdMobと違ってAdSenseのほうは広告出稿に当たりサイトの審査があるんだそうで、時間がかかるから待てと。

あらあら、思わぬ手間がかかるのね、と思いましたが、じゃあ折角もらった時間だし、ゲームのブラッシュアップでもしてみようかとおもっていると、翌日だか翌々日だかには偉そうに「おめでとうございます!広告が掲載されました!」とかメールをよこす始末です。
広告媒体が広がるんだから広告主のほうがおめでてーんじゃないの普通?と思いつつ、まあ、これで中断していたAdMobのほうも手続きを進めて、ゲームをリリースしましました。

ちょっとAdMobのほうに飛びますが、AdMobのほうは審査も一切なし、Unity用ライブラリもしっかり整っていてあっさりテスト用広告表示もできて、拍子抜けするほどでした。なるほど、ここまで簡単なら猫も杓子もアプリに搭載しますわね。
こちらは$25も払ってフリーウェアを配布しているのにわけのわからないいちゃもんつけてくるやつ、もとい、ユーザ様(なんで急に卑屈になってんだ!)とかいますが、自分自身が世界の中心においでの方が山ほどいるのですからまあ、中心がどれだけあるのかわからないのがこの世の中ですのでせめて広告代でも・・・と思ったら甘いんですよねえ。
なんせ誰にも使ってもらえないのですから広告代だって入らない。来るのはいちゃもんばかり。なーんだいつもの通りじゃん、てな具合。
無料なんだから使うほうも自己責任で使えや、作ってる方は誠心誠意作ってんだからよー、といっても通じませんわねこのご時世。

ま、やっと本題に戻りますが、AdSenseの話を書く気になったのは、冒頭でも触れましたが、審査に通らないとか通すためには云々という話が多いという話を聞いたからでした。

私自身は上述の通り、ボタンを押したっきり、何もしていません。ですので余計びっくりしました。
申請期間中の記事の更新もなし、記事数も少なく、一日のページビューなど口に出すだに烏滸がましいこのブログです。100そこそこです。

審査が通らないと話を聞かされてから試しに検索してみると、確かにそういう記事がどっさり出てきます。
中には涙ぐましく申請前にダミーサイトを作るだのサイト利用約款を作るだの(これはプライバシーポリシーという形で私も最近ページを作りました。確かにGoogleに追跡されてるよ!という警告を表示するのは賛成でしたので)なんだか偉そうに「審査合格」を指南しているサイトも多々見受けられ、ほとほと考え込まされました。

一応申し添えますが、審査合格指南者の言っていることはすべてこのブログには当てはまりません。だから、審査に通りたいなら彼らの言うことを聞いても無駄でしょう。なぜなら、ここに実例があるから。

確かに、出稿主がなんでこんなブログに出稿したいかと考えたかはわかりません。そして、出稿主の期待もむなしくページビューもなく実際に支払われる額も\100円未満。そんなサイトでも何もしなくても彼らの言うところの審査に通りました。

ま、出稿先としてまるで魅力がないことは明白なのであっさり広告出稿停止なんてことになりそうですが、審査に通らないということでお悩みな方には何かこのブログにヒントがあるのかもしれませんよ。

そうそう、AdMobのほうですが、こちらはなんと
¥0円
です。だって自分で検索してもGoogle Playで見つかんないんだもんなあ。当たり前ですよねえ。それに私が作ったゲームにも魅力がないってことです。残念ですが、まーそんなもんかなあ、くらいの気持ちで次に行きましょう。自分でもやってないし(アイディアを形にするのが好きなので形になってしまった後は・・・まぁお察しください)
そもそも、自分が作ってるものなのに自身のブログで宣伝もせず、むしろこのブログで公開しているプログラムがらみというと、主に自分が利益を得ない洋ゲー日本語化用スクリプトとかが主ですからねぇ。
見る人が見ればバカに見えることこの上ありますまいなあ。

本当にお恥ずかしい話ですが、当ブログは恥を記録してまいるのが主眼ですので、AdSenseやAdMobネタを提供してくださったGoogleさんに、今回もいいネタをいただいた気がしております。

ご清聴ありがとうございました。

2017年2月20日月曜日

unityでのGoogleMobileAdsパッケージインポート時のエラー

恥の記録です。

以下、Google Mobile Ads Unity Plugin v3.2.0の場合です。

unityでandroid向けにAdMobを仕込もうとしてこちらからGoogleMobileAds.unitypackageをインポートしたときに
Unable to find the Android SDK manager tool.  Required Android packages (extra-google-m2repository, extra-android-m2repository) can not be installed.  Android SDK path not set.  Set the Android SDK property using the Unity "Edit > Preferences > External Tools" menu option on Windows or the "Unity > Preferences > External Tools" menu option on OSX. Alternatively, set the ANDROID_HOME environment variable
とか説教される場合があります。
エラーメッセージではSDKが見つからないだのパスを正しく指定しろだの環境変数を設定しろなどなんだかんだと仰せになっておいでですが、全部大嘘ですのでご注意ください。

実際には(unityではなく)Adndroid SDKのGoogle Play Servicesパッケージがインストールされていないと怒られるわけですが、さらにGoogle Play Servicesには2つのリポジトリパッケージがインストールされていなければなりません。
つまるところ、SDK ManagerでExtras から以下の三つをインストールすることで解決します。

  • Android Support Repository
  • Google Play services
  • Google Repository

実は公式(英語版)のページにはAndroid Support Repositoryを入れろという記載はないのですが、実際には必要です。
まあ、そもそも日本語版の同ページにはパッケージのインストール元の記述すらありませんが・・・。

わかった後でエラーメッセージを見返してみると、extra-google-m2repositoryとextra-android-m2repositoryが見つからないよ、と仰せなので、まあこれがそれぞれのリポジトリのパッケージなんだろうなと。

まあ、こんな程度で躓いているような情けないありさまです。

2017年1月29日日曜日

Theme Hospital + CorsixTH 0.6 ゲームテキストの和訳

誰からも望まれていませんし、例によって需要もあるとは思えませんが、Theme Hospital + CorsixTH 0.6 ゲームテキストを日本語に訳してみました。
  • 日本語化済みファイルはこちら
    クリックいたしますと、ja_JP.lua というファイルがダウンロードされます。
    ご利用にはファイルを CorsixTH/lua/language ディレクトリにコピーしてゲームを起動し、設定から日本語を選択してください。
  • 作業シートはこちら
    機械翻訳がほとんどですので、原文と比較したり自分流に訳す場合にコピーしてご利用ください。
です。よろしければご利用ください。

以上です。

以下たわごとです。

いつだったか、相当前にOriginからのプレゼントということで無料配布されていたテーマホスピタルというゲームがあったのを思い出して、先の金曜日、初めて起動してみました。

まーなんというか、さすがに古いゲームだけあって画面は小さいし文字も汚いし英語だし、ということで起動直後にそっと閉じてしまいました。

しかしながら、せめて日本語化できれば違う印象を持つかもしれないと思いまして、ざっくりgoogleで検索したところ、本体の日本語化はないようですが、こちらのMiyaoka Noteさんというサイトで紹介されている自称"re-implement the game engine of Theme Hospital"とはばかりなく言い切るCorsixTHという存在を知りました。Miyaoka Noteさんは2012年にCorsixTHの日本語化を行なっておいでで、その成果物はgithubで公開なさっておいでです。

そこで、これは渡りに船、とばかりにさっそく使用させていただいたのですが、あまりゲーム内テキストが日本語化されません。

ちょっと失礼ではありますが正直がっかりして、せっかくいただいたので言語定義体をエディタで見てみると、これって定義体というよりLua言語で書かれたプログラムで、文字列を直接の変数に突っ込んでるという強烈な仕様だということを知ってびっくりしました。
これはおそらく、言語ファイルを作成された後で参照される変数名が変わったとか、いろいろあったのでせっかくの日本語データがゲームに反映されないのかもしれません。

とは申せ、仕組みとしては変数の値を変えるだけ、という設計方針はわかりましたので、それなら変数名と代入されている英文が分かれば全翻訳可能という理屈になります。単純明快です。

そこで、毒を食らわば皿まで、ではありませんが、土曜日にちょっとやってみようと思い立ちました。

で、そうなると、今度はどうやって訳元の英文データを入手すればいいのかを調べてみますと、公式で解説されていましたので、さっそく生成してみますと、Luaではテーブルというようですが、表現形式としてはC言語でいう構造体のような感じで定義されており、一つ一つ構造体名とメンバ名にバラすのもまとめるのも簡単なスクリプトを書けばすぐできるということが分かりました。

なぜバラバラにしようとするかというと、私がこれまで行ってきたゲームなどの翻訳シートと同一の形式にし、かつ訳文と原文をいつでも対比できる形式に変換したいからです。

この形式のメリットは、原文と訳文が一対一で参照や再翻訳がしやすく、しかも原文を複数行、まとめてgoogle翻訳さんやWeblio翻訳さんなどにコピーすれば、訳文がたちまち得られ、しかも翻訳結果は加工しなくてもそのままシートにキッチリ再ペーストできるという点にあります。
それに、ソースを直接いじるよりもはるかに作業がしやすい。いちいちソース単位でコミットしなくてもセル単位で更新履歴が残ります。これはきわめて大きなメリットです。

翻訳結果があまりにも頓珍漢だったら多少は手を入れますが、原則として一度シート化してしまえば、この通り私はせいぜいコピーとペーストしかすることがありません。

結果として土曜日中にluaソースから英文と変数名が対になったTSVファイルを作って、またluaソースへと戻す2本のスクリプトを書き、あとはただコピー&ペーストを繰り返すだけで完了し、日曜日にはある程度プレイして確かめることも含めて「概ねできました、よければどうぞ」などと言えてしまう寸法です。
本当にgoogle翻訳さんをはじめ、機械翻訳を使わせてくださる各社には感謝に堪えません。

折角Miyaoka Noteさんがおつくりになられたデータが現にあるのだから擦り合わせて取り込もうとも思ったのですが、どのバージョン用のデータかわからない、ほとんどゲームをやっておらずどの文章がどこで表示されるべきとされていたのか調べてすり合わせるよりgoogle翻訳にコピペしたほうが早い、といった理由で現時点では反映しておりません。
著作権の問題もありますし、公開するデータとして使用するには適さないということもあります。

ところで、CorsixTH側の問題なのですが、表示したい文字列が長すぎると、ゲームがクラッシュします

正確には、クラッシュというよりは間抜けにも64bitアプリなので際限なくメモリをどんどん食いつぶしていって、最後にはスラッシングを起こしてOSを巻き込んでくれます。

原因は単純で、すぐにわかりました。

横文字文化圏の人には単語ごとに空白を入れない言語があるということを知らないのでラインブレーク処理が完全に抜け落ちていて、できるわけがないのにどうにかしてワードラップできないかと延々処理を続けるからです。まあ、世の中にはマルチバイト文字があるということすら想定していないスバラシイ人たちも大勢いるわけで、この程度はどうというこたあありませんわね。Capitalism Labもそいつで苦労しましたし。

そんなわけで、訳文を自前で修正なさる方は表示される領域の大きさに合わせて自前でホワイトスペースを入れ、CorsixTHがラッピングできるようにしてやらなければなりません。

シートから作ったTSVからのluaソース生成スクリプトにはその辺を考慮したコードが入っており、スクリプトは冒頭にリンクいたしました作業シートにて「スクリプト2」として公開しておりますので、よろしければご利用いただければ幸いです。

作業シートには、クラッシュとなる原因となる訳文を特定する方法なども記載しておりますので、そちらもよろしければご参考に供せれば幸いです。

それにしても、機械翻訳でも何でも、母国語となるとドーンと印象が変わりますねぇ。
和訳が簡単そうだからという理由で手を付けてみましたが、ゲームも実際に面白そうです。
これからちょいちょい、プレイしてみたいと思います。

以上、駄文にお付き合いいただきまして、誠にありがとうございました。

2016年2月15日月曜日

Capitalism Lab和訳シートの編集を匿名ではできなくします&チュートリアルの和訳を完了しました

あくまで編集権なので、翻訳結果だけほしい人にはこれまで通りご利用いただけます。ご安心ください。

ダウンロードも自由にしていただいて結構ですし、どうしても匿名で編集しなければならないという事情があるのなら、スプレッドシートをご自分のドライブにコピーすれば自分がオーナーとなりますので、あとは煮ようが焼こうが思いのままです。

今後ともご利用いただければ幸いです。

さて、表題の対策をとるに至った理由ですが、とても残念でならないのですが、編集する気がないにもかかわらずシートを加工してしまう人が後を絶ちません。

先日のいたずらの件は論外なので措きますが、それ以外にも故意ではないとは思いますが、スプレッドシート内にワークシートの複製をいくつも作っておさらばする人とか、ワークシートを追加したままおさらばしちゃう人とか、何がしたかったのかわかりませんが、そういう人が何人もいます。

ダウンロードするだけの版も用意しているのにそれを使わずわざわざシートにくるけどやっぱり使い方が分からず、挙句にゴミを残しておさらば、という感じなんでしょうかねぇ・・・?

ここ数日は本家フォーラムのDavidさんが用意してくれた2.7.25Cの新規追加分の和訳とチュートリアルの和訳作業をしていてちょくちょくスプレッドシートを触っていたのですが、その間も何度かこういうことが続いて、見つけるたびに元の版に戻したりしてきましたが、公開してからわずかな日数を経ただけなうえ、もともと利用者が少ない中でこれほどの事故(?)率となると・・・ちょっと考え込まざるを得ません。

幸い、後にも先にも編集したのは私のみですので、コメントだけ投稿可とさせて頂きます。
もし万が一編集権がほしいという奇特なかたがおられましたら、お申し出頂ければ編集者としてご招待いたしますので、よろしくお願いいたします。

さて、チュートリアルの件ですが、結局和訳した上でアポストロフィの文字コード0xA1,0xAFをバイナリエディタで直接テキストファイルに埋め込む必要がありました。こうなると人によってはテキストファイルではなくバイナリファイルとしてしか扱えないでしょうから、書庫ファイルにまとめて公開いたします。
但し、使い方は説明しません。まあ、置き換えるだけなんですけど、うっかりオリジナルに上書きしちゃったとかいうようなトラブルに付き合う気はないので、お察しくださいませ。

でも、まあ・・・私自身チュートリアルをやったことがなかったので知りませんでしたが、もともとの英語版オリジナルでも途中で進行不能になるバグがあったり、表示されるべきテキストが表示されなかったり、インジケートされる場所が頓珍漢だったりと、スゴイバギーなつくりでした。

それにもかかわらず誰も指摘せず、従って修正されてこなかったのですから・・・世界中のだれもやってないんだと思います。
多分、みんなCapitalism2のほうでチュートリアルをこなしたんだろうと思っています。

和訳する必要がなかったかなぁ。

ま、やっちゃったものは仕方がありませんので、どうぞこちらよりダウンロードいただければ幸いです。

あと数日するとCities SkylinesのDLCが来ちゃうので、公開済みMODの対応作業に入りますので、もし何かあっても対応が遅れてしまうかもしれません。
その際はなにとぞご容赦ください。

以上です。

2016年1月27日水曜日

Capitalism Lab 日本語化(和訳)ファイル一式(現状ほぼ機械翻訳)

** 2016/1/29 追記 **
こちらでご紹介した翻訳済みファイルは相当不完全です。
現在ではここでご紹介したものより格段に完成度が上がっておりますので、こちらはもう使わないことをお勧めいたします。
完成品だけお求めになられてしまうことはやむを得ませんが、もっといい訳がありますので、ぜひ最新のものをお使いいただければ幸いです。
あまりにこの記事ばかり閲覧数が上がるので不安になりましたので、以上追記いたします。
** 追記ここまで **

あー。

本当に人気のないゲームで誰も和訳をしようとしないのに、Capitalism Lab 日本語化 のキーワードでこのblogを引っ掛けてしまうお方がごく稀においでのようなので、罪悪感を感じてしまいました。

そこで、ほぼすべて機械翻訳で大変恐縮ではありますが、翻訳済みファイルをご提供いたします。
こちらからダウンロードください。(2016/2/1削除)

なお、これでも英語がどっさり残ります
これは本体側の不備で、エンライトさんが定義した方式で翻訳しても本体のプログラムがそもそも翻訳済みテキストを見てやしねえ、いや丁寧に言うと反映してくれやがらないのであります。

それでも、Translate.txtという、ユーザ側で勝手に作る翻訳ファイルのほうはまだ見てくれることがありまして、訳されなかった英文をTranslate.txtに追記し、さらにその和訳を追記すれば和文として表示される場合があります。

和訳されずに残っている英文を見かけたらすかさずその文章をメモして、Translate.txtに追記し、和訳を考える。そういう作業が必要になります。
いまどきこんなのってあるかぁ?ってレベルですが、まあ、そういうもんだと思ってあきらめましょう。
当然、私もそんな手間はかけていないので、頓珍漢な邦訳をお楽しみいただけます。

ダウンロードしたファイルはtarで固めてbzip2で圧縮してあります。
解凍したファイルはいずれもtranslateディレクトリに放り込んでください。
translateディレクトリがないとかそういう質問はコメント欄に入れないようにしてくださいね
直接エンライトのユーザサポートに連絡してください。またはこちらをご覧ください。

なお、圧縮ファイル中に"Capitalism Lab 和訳作業シート.xlsx"というファイルがあります。
これが今回の翻訳テキスト作成の元ネタで、どれが機械翻訳でどれが人間翻訳かを確かめる際にご利用ください。くどいようですが、今回追加したほぼすべてが機械翻訳です。私自身が気にしてない文章は全部放置です。
拡張子がxlsxとなっておりますが、excelで作成したものではなく、googleスプレッドシートからexportしたものです。要するにgoogleスプレッドシートでの利用を前提としているっちゅうことです。

シートの内容から翻訳結果をゲームプログラムが解釈できるファイル形式に変換するスクリプトも作成してありますし、シートにはそのスクリプトへのリンクも記述されているので、ご自分のお好みで訳を適宜修正・追加・削除なされました際はそちらをご利用ください。

私のgoogleドライブ内にある元ネタファイルを公開すれば簡単ですが、そこまでご奉仕するつもりはない。ドメイン名やら本名やらメールアドレスやらハズカシイ
なお、デフォルトで付属してくるフォントは中国語用なのは以前触れた通りで、日本語フォントに変更する方法も以前触れたとおりですのでそちらをご参照ください。
なお(なおばっかりだね)ご参照頂いた記事からのフォントファイルへのリンクだと404になっていました。
どうぞこちらからダウンロードください。

これでCapitalism Labのユーザが少しでも増えてくれればうれしいです。

2013年12月14日土曜日

結局googleに頼ってしまう

この間借りさせていただいているblogサービスもgoogle様のご支配下にありますが、以前google等に頼らず自力で逆ジオコーディング、ということを言っていましたが、結局google様のお慈悲にすがることにしました。

というのは、web apiを利用させていただくのではなく、(逆ジオコーディングにはGoogle Mapと併用しなければ利用できない規約があるためです)Google App Engine ちゅうのがあるってことを知ったからです。

ここは、まあいわばただのホスティングサービスなんですが、おもしろいのは無料であること(!!)、Tomcat(!!!)が利用可能であること。
すなわち、android用に作ったクラスがそのまんま移植作業なしで動いてしまうという点です。

最近まではpyとかだけだったらしいんですが、そこはウラシマですから存じ上げません。
 (Cとsedとperlとshばっかりなので全く知りませんでした。 )
さらにすごいのは、httpsをしゃべってくれること(証明書付きで!)

オレオレ証明書ならいくらでも用意できますが、いちいち警告が出るのが(いくら経路を暗号化するだけの目的ですよ、と申し上げたところで )当然不審をそそりますし、だからといって経緯度情報は大切なプライバシですから経路上で暴露しながらパケットが到着しても困ります。

その点、お仕着せのhost名を使う限り信頼済みとなっているのがありがたいです。

市区町村レベルの情報を返すだけとはいえ、そこはインターネットですからその仮想パス上にはNFCとかKFCとかSDKとかAPIとか(あれ?話題のあそこなんだっけ)不思議な団体が目を光らせている可能性は排除しきれません。
受け取るのは携帯からのリクエストを想定している以上、経緯度とIPアドレスといった個人が特定できる情報ですからやはりある程度は神経質にならざるを得ません。

そりゃ証明書を買って自鯖でやったほうがいいに決まってます。
実際、このサービスは無料版の場合、処理速度はandroid実機で処理するのとどっこいどっこい。
DBも特殊。いついきなりサービスを終了するかもわからない。
電気代や回線代の分お得ですが、より柔軟なサーバ側のカスタマイズにも向きません。

でも結局お金がない。これにつきます。
これだけでキラキラ輝いて見えます。

しかもandroidとソースは一緒ですからどちらかメンテすれば自動的にもう一方に適用できるというすばらしさ。
修正モジュール、サーバ側はperl,端末はjavaで同様のロジックを・・・とかだったら鼻血が出ます。

携帯もドメイン管理もホスティングも検索もweb apiもblogも・・・ぜーんぶgoogle・・・
無料DDNSはもうやらないのかなぁ
 最後の砦、携帯電話の番号だけはgoogle先生にお教えしておりませんが、携帯メアドはGoogle App Engineに登録する際に教えちゃいました。

どうでもいいけど送信者アドレス指定受信って日本で普及しているの知らないのかなgoogle大先生。日本ではxxx@yyy.zzzからメールが送られるから受信許可しといてねって一言ある商習慣をガン無視。
これがアベノミクスってやつかな。キッシンジャー外交かな?

意地でもMicrosoft accountを作らないアタクシとは思えないほどキモチワルイ状況です。
iOSとどっちだ!ってくらい。

Microsoftも仲間に入りたそうに見ているわけだわなぁ