iPhoneを買った
化粧箱 pic.twitter.com/N5LDehRHg2
— メァ卜ﾉﾚー (@maretol) 2016年12月21日
買った。なお数週間前
（多分）初の Apple 製品 pic.twitter.com/uHeMA504X7
— メァ卜ﾉﾚー (@maretol) 2016年11月10日
これが最後のApple製品になると思ってた。
iPhone7じゃなくて6Sなのでやや古い。まあ気が向けば来年また買い換えるでしょう多分。
購入したのはスーパーマリオランが遊びたかったため。ただそれだけ。
ゲームのためにハードごと買うのはもはやゲーマーの意地でもあり常識でもあるので個人的には特に衝撃ではないのだが、まあ世間的にはそうでもないらしい。
ちなみにAndroid版は来年出す予定らしい。つまり待ちきれなかったのだ
買ってわかったことがあるが、やはりiPhoneはハードウェアの設計がすごいっぽい。
なんというか、持っていて愛着が湧きやすいというか、手に握っていたくなるというか、そういう魅力がある。
さわり心地や握り心地がいいのだ。たぶんそう設計されてる。
できればカメラの出っ張りをどうにかしてほしかったが。
あと思ったこととしてOSの設計思想もだいぶ違う。AndroidとWindows 10 mobile(Windows Phone)は戻るボタンで戻ってアプリを終了するという考え方が強いがiPhoneはホームボタンしかないのでそれを押すことで中断する。ユーザーに終了の権限がほとんどない（タスクマネージャーで手動終了できるがあれで終了したからと行ってバッテリーの持ちは変わらないらしい）。
ただやっぱりコントロールのためのUIが画面上にあるのはつらい。画面が大きくなってきたこともあってかつらい。左の画面端からスワイプしたら戻れることが多いけどね。
持って初めて分かったが、ハードウェアとしての完成度は高い。ソフトウェアとしては、ちょっと古い部分が厄介になってきてる。
そんな印象
MySQLで日付を計算する
SQLで今の時間をとるにはcurrent_timestampを使っていた。べつに問題ないし、どんなふうに出てくるかというと
> SELECT current_timestamp
って打ったらわかる通り。
これを使って動的に今から10分以内であれば～～という比較をすると
> ~ WHERE time_column>current_timestamp '-10 min'
とやっていた。PostgreSQL 8.1.6（すごくふるい）ではこれで通っていた。
が、MySQL 5.7.6で同じ条件を付けると通らなかった。厳密にいうと通るのだが、常にfalse判定されてるらしくtrueで出てきそうな行も出てこなかった。
mysql> select current_timestamp > current_timestamp '-10 min' ;
+---------+
| -10 min |
+---------+
| 0 |
+---------+
1 row in set (0.05 sec)
見た感じだと'-10 min'の記述が悪いらしい。
mysql> select current_timestamp > current_timestamp - 10;
+--------------------------------------------+
| current_timestamp > current_timestamp - 10 |
+--------------------------------------------+
| 1 |
+--------------------------------------------+
1 row in set (0.00 sec)
なるほど確かにだ。じゃあ10分というのを変換するにはどうするかと考えたが（上のでは-10秒）
mysql> select current_timestamp > current_timestamp - '0000-00-00 00:10:00';
+---------------------------------------------------------------+
| current_timestamp > current_timestamp - '0000-00-00 00:10:00' |
+---------------------------------------------------------------+
| 0 |
+---------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
あれ。だめだった。 素直に10分を600秒にしてもいいのだがせっかくだしいろいろやってみる。
mysql> select current_timestamp - '0000-00-00 00:10:00' ,current_timestamp;
+-------------------------------------------+---------------------+
| current_timestamp - '0000-00-00 00:10:00' | current_timestamp |
+-------------------------------------------+---------------------+
| 20161214152055 | 2016-12-14 15:20:55 |
+-------------------------------------------+---------------------+
1 row in set, 1 warning (0.00 sec)
時間が変わってないところを見るとそもそも引き算の対象としてはとれないらしい。Warningにもそう書いてある（ Truncated incorrect DOUBLE value: '0000-00-00 00:10:00' とのこと)
mysql> select current_timestamp - 00:10:00 ,current_timestamp;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ':10:00 ,current_timestamp' at line 1
mysql> select current_timestamp - 00-00-00 00:10:00 ,current_timestamp;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '00:10:00 ,current_timestamp' at line 1
うーん、素直に600秒で引き算するのが一番楽そうだ
mysql> select current_timestamp - 600 ,current_timestamp, current_timestamp>current_timestamp-600;
+-------------------------+---------------------+-----------------------------------------+
| current_timestamp - 600 | current_timestamp | current_timestamp>current_timestamp-600 |
+-------------------------+---------------------+-----------------------------------------+
| 20161214153421 | 2016-12-14 15:40:21 | 1 |
+-------------------------+---------------------+-----------------------------------------+
1 row in set (0.01 sec)
あれ？6分で引かれてる？
mysql> select current_timestamp - 10000 ,current_timestamp;
+---------------------------+---------------------+
| current_timestamp - 10000 | current_timestamp |
+---------------------------+---------------------+
| 20161214144353 | 2016-12-14 15:43:53 |
+---------------------------+---------------------+
1 row in set (0.00 sec)
つまり、下から2桁を秒、下から3,4桁を分、という風に扱ってるらしい。
まさかこんな仕様だとは思ってなかった
Google Cloud Engine の Cloud SQL に .sql を読ませる
続き。
結局なんで読めなかったかというと文字コードがUTF16LEだったからのようだ。
というかなんで mysqldump の出力が UTF8 じゃないのか。まあいいとして。
GCPのCloud SQLに対応する形で .sql ファイルを出力するのは
Cloud SQL にインポートするデータのエクスポート | Cloud SQL | Google Cloud Platform
これの通り。
> mysqldump --databases [DATABASE_NAME] -h [INSTANCE_IP] -u [USERNAME] -p --hex-blob --skip-triggers --default-character-set=utf8 > [DATABASE_FILE].sql
ただまあ罠があってこれじゃあ日本語が取り出せない（文字化けする）。んで、--default-character-set=utf8をutf8ではなくbinaryにする。
ちなみにutf8にしても出力ファイルはutf8じゃなかったんだけどね。だから引っかかったんだけどね。
あとは出てきた .sql ファイルをutf8にしてあげて読み込む。ひょっとしたらどこかでつまずく可能性はあるけどとりあえずこれで自分のところはうまくいった。
Windows で nkf が使いたい
文字コード変換するぞーってなってnkfを思い出すもWindowsにはそんなものない。
でもBash on Ubuntu on WindowsならUbuntuだしnkf走るじゃんBashで普通にWindowsのファイルいじれるし。
$ sudo apt-get install nkf -y
E: パッケージ nkf が見つかりません
うそやろ
ちょっと環境いじりまくってたのでaptのリポジトリがなんかいい感じに動いてくれてないことがある。
なおしたいけど時間がないのでtar.gzファイルをそのまま落として解凍するかー。
$ make
cc -g -O2 -Wall -pedantic -c nkf.c
make: cc: コマンドが見つかりませんでした
make: *** [nkf.o] エラー 127
まじか。幸いgccはapt-getで入った。
$ make
cc -g -O2 -Wall -pedantic -c nkf.c
In file included from nkf.c:30:0:
nkf.h:54:19: fatal error: stdio.h: そのようなファイルやディレクトリはありません
compilation terminated.
make: *** [nkf.o] エラー 1
うそやろ
続きは解決したら書く
結局エディタのエンコード変えて保存する方法つかった。
たぶんこれが一番早いと思います
GCPのCloud SQLにmysqldumpで出力したファイルを読ませたい
mysqldumpコマンドには--default-character-setというどう見ても文字コードを設定する引数がある。
--default-character-set=utf8
とするとutf8で出力されそう。されそうだが、実際はUTF16LEで出力されてた。しかも日本語は文字化け。
--default-character-set=binary
で出力するといいそうだ。
ところがこれをGoogle Cloud PlatformのCloud SQLにアップロードしようとしてもうまくいかない。
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'USE response;��-'.
文字化けはそのまんま。
つまるところオプションを入れてあげなければならないらしい。だがオプションを付ける方法がわからない。API見た感じだとないっぽいんだが。
Instances: import | Cloud SQL Documentation | Google Cloud Platform
内部的にはmysqlのはずなのでどうにかする方法はあると思われる……
解決したら追記します。誰か知ってたら教えて
Titanfall 2 をひと段落
- 出版社/メーカー: エレクトロニック・アーツ
- 発売日: 2016/10/28
- メディア: Video Game
- この商品を含むブログ (2件) を見る
FPSタイトルの中ではかなり新参者のTitanfall 2をやってる。現在キャンペーン（シングルモード）を終えて、マルチプレイに励んでるところ。 ちなみにプレイしてるのはPC版。上のリンクはPS4版。まあどれでもゲーム内容は同じなんで。
Titanfallシリーズは前作が1、今作が2で、1は2年前に発売された。NPCをクラウドサーバで処理させることにより10人程度のプレイヤーだけでも戦場に多数の敵・味方が存在するといういかにも今のテクノロジーを使ったゲーム。ただ、前作ではシングルモードがなかったこともありほぼマルチ専用ソフトとしての形が強かった。
それがある種の批判だったこともあり、今作ではしっかりしたシングルモードが追加されたほか、それの評価もかなり高い。一方で、いくつかの面においては前作から評価を落としたところもある。具体的には、
- Titanの種類が増えたにもかかわらず装備が固定された
- Titanに乗り込むシーンやとどめのシーンが3人称視点になり、迫力の面が減った
- Titanの上に乗る（乗り込むのではない）ロデオアクションが簡素化された
- ステージの構成が前作より簡略化され、パルクール要素や立ち回り面での幅が減った
- 一時的なパワーアップアイテム「バーンカード」の廃止
などなど。まあまだ発売直後なので、立ち回りとかは今後変わってくる恐れはある。
具体的に、割とあちこちのレビューですでに言われていることだが、全体的にロマンが減ってしまったという感じがする。
ロデオアクションは正直1ではあまり有用性がないもので、対タイタン用の武器を持ってロデオ→コンピュータ部分に直接攻撃→近すぎて爆風に巻き込まれ自滅というパターンも多かった。
タイタンも前作は高機動、バランス、重装甲というようなバランスだったため、数を単に増やせばバランス調整・差別化に苦労することも容易に想像できる。
そういった要素を比べるとカットされた意味合いはわからなくもない。
あったところでゲームにプラスにならないならばっさりカットするのは英断といえるだろうし、世の中足し算だらけで収束できないゲームも数多く存在する。
でもタイタンに乗り込むとき、とどめを刺すときの3人称視点はあまり好意的にはなれない。かっこいいアクションを見せたいという感覚はわからないでもないが、あの1人称視点こそタイタンに身を預ける、一種の信頼を演出で来たんじゃないだろうかと思う。
あと、バーンカードがなくなったのは個人的にちょっと痛い。あれは結構、戦略の幅を持たせることができてたと思うんだが。
まあ戦略の幅はつまるところ複雑さにもつながるので、システムをわかりやすくするうえでは仕方がなかったのかもしれない。
もちろんよくなった点も多い。
新しい武器や戦術（サポートアイテムのこと）はアクションに幅を持たせ、新たな立ち回りを要求してくるし、何より装備の数は増えた。
カスタマイズできる要素も増えたため（個人的にあまり興味はないにせよ）プレイするモチベーションの確保もされている。
何より今作で高評価を受けているキャンペーンモードは、ゲーム全体で減ってしまったロマンを十分なほどに補充してくれるものだった。 バディ物の正統派な形というべきか。会話シーンがもうちょっと多かったらよかったかなぁって思ったけど、まあ会話しながらドンパチやるのはやりすぎると冷める原因にもなりかねないからちょうどいいのかも。
タイタンへの信頼という面ではオンラインマッチでもタイタンが結構しゃべるし、脱出時にはモニターに「また会いましょう」とか表示してるのが結構かわいい。ごめんね無茶な立ち回りして。
前作では有料だったDLCも（前作の過疎を受けてか）すべて無料で配布される形をとった。なんと第1弾は前作の看板マップであった「Angel City」だ。
今作は最初はわかりやすいマップで、後々複雑なマップを解禁していくという方式をとるのかもしれない。
まとめると、より多くのプレイヤーを獲得すべく洗練された、されていったゲームという感じ。
それは前作の複雑であったり、不要であった要素を取り除き、外連味をプラスし、外観をかっこよくスタイリッシュにして、とっつきやすくしようとした痕跡が見える。
もともと前作の時点でポテンシャルは高いゲームだったので、それを十分に生かしつつきちんとステップアップしたという感じである。
いいゲームなのでもっと多くの人に触れてほしいところでもあるが、いかんせんFPSが飽和状態の市場では結構厳しいか。
マルチプラットフォーム同士での対戦ができれば……とも思ったが、それはそれで要らぬ対立を招きかねないのでもある。
とりあえず30時間ぐらいはプレイしてみようと思ってる。
あまりうまくはないのでどこまで続くかはわからないが。
Google App Engineのリポジトリがクローン出来なかった
解決した。どうやらgitの設定が悪さをしていたらしい。
単純に解決法はこれ
コマンドだけ先に答えを書くなら
> git config --list --system
で credential.helper=manageがあったら
> git config --system --unset credential.helper
を打ってcredential.helperの設定を消してあげるといい。あとはgcloudのコマンドを入力するとクローン完了。
で、ここまでやって解決法のリンク張るだけだったらちょっとあれなので原因追及。
というか解決できずあれこれ探してたら見つけたcredential.helperについて調べた。
credentialという言葉が信任状とか証明書とかその辺の意味なので言葉通り認証関係の情報を扱う設定のよう。
Windowsの場合はGit Credential Manager for Windowsがあるらしく、これがそのcredential.helperを設定していたっぽい。
ちなみに役割としてはリモートリポジトリにアクセスする際の認証情報をWindowsの資格情報マネージャーに保存するもの。 Visual Studio Onlineのサービスなどでも使用されてる感じ。
gcloud source repos clone hogehogeのコマンド自体は中でgitが動いているだけなので、おそらくそこの認証情報を勝手に解決しようとする動きが今回の原因の模様。
設定は1つ消したわけなので、ひょっとしたら今後のgitの使用の際に引っかかる可能性はある。覚えておこう。
