Powershellに入力リダイレクトは存在しない(今のところ
ファイルから入力するケースというのは結構ある。mysqldumpで輩出したファイルを読ませたりとか。
# echo < file
こんな感じで入力する。ところがPowershellでは
> echo < file
発生場所 行:1 文字:6
+ echo < file
+ ~
演算子 '<' は、今後の使用のために予約されています。
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : RedirectionNotSupported
こうなる。じゃあエスケープか何かがあるかというとない。
出力では Out-File というコマンドがあるが、じゃあ入力では?と思ったらない。
もしかしたら何か方法があるかもしれないが調べてみても出てこない。仕方がないのでcmd
って打ってコマンドプロンプトでやろう(コマンドプロンプトではリダイレクト入力できる)
第n何曜日を計算する
いくつかの祝日とかゴミ捨てとかはmmddであらわされず、基本的に特定の月(あるいはすべての月)の特定の回数目の曜日に行うと決まっている。
祝日はまあその手のAPIサービスを使うとして、ゴミ捨てなどをデータベースに入れるにはどうしたものかと思いつつ、とりあえず毎月特定の日に起こるイベントをまとめたテーブルを作ることにした。
毎週起こるイベント(燃えるゴミの日とか)はエブリウィークのテーブルにしつつ、毎月第一水曜日の燃えないゴミの日などを管理するという感じ。
カレンダーとかリマインダーのデータベース設計したことないんだけど何かいい資料があるなら教えて。
とりあえず第n何曜日の定義はその月の何回目何曜日かということで、抽象的すぎるから具体的にみんな大好き月曜日で考える。
第1月曜日その月の1日~7日の中にある。1日が火曜日なら7日が月曜日、1日が日曜日なら2日が月曜日。
同様に第2月曜日は8日~14日の中にある。あるいは第1月曜日の日付を把握できたのであればその日付に7を足せばいい。後は同様に考えればいい。
以上からまず計算に必要な要素は
- その月のどこかの日付と曜日(基本は第1日が計算しやすいと思われる)
さえあればとりあえず計算できる。
MySQLなら特定の日付の曜日を取得する関数はDAYOFWEEK
(日曜日はじめ)とかWEEKDAY
(月曜日はじめ)があるのでそれを使えばとれる。
mysql> SELECT WEEKDAY(yyyymm01);
これの答えがyyyy年mm月1日の曜日である。WEEKDAY
の月曜日は0で返ってくるので、7進数で考えて、7からこれの答えを引くと月曜日までの日数が分かる。
もうちょっと具体的に2017年1月で考えて、
mysql> SELECT WEEKDAY(20170101);
+-------------------+
| WEEKDAY(20170101) |
+-------------------+
| 6 |
+-------------------+
1 row in set (0.03 sec)
1月1日は6=日曜日だ。では2017年1月の第1月曜日は
mysql> SELECT 7-WEEKDAY(20170101);
+---------------------+
| 7-WEEKDAY(20170101) |
+---------------------+
| 1 |
+---------------------+
1 row in set (0.00 sec)
つまり1日後、1月2日ということになる。
mysql> SELECT 20170101+(7-WEEKDAY(20170101));
+--------------------------------+
| 20170101+(7-WEEKDAY(20170101)) |
+--------------------------------+
| 20170102 |
+--------------------------------+
1 row in set (0.05 sec)
まあこうでもいい。週ごとに以下数字から引けて、1日の日付に足せばいい。
func | sun | mon | tue | wed | thu | fri | sat |
---|---|---|---|---|---|---|---|
WEEKDAY() | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
あるいは足し算で出てきた結果と足す形にした方がいいかもしれない。そこは適宜数字を変えるとして。
そして第2曜日以降は各々の数字に7を足す。第2月曜日なら7+7という感じ。
この辺りは関数化して求められるようにするのが理想だろう。たぶん。
すでにあったら申し訳ねえが教えてくだされ
追記
なんかDAYOFWEEKだとうまくいかなかったから削除。理屈は同じだけど考えるのが面倒なのでやりたい人は勝手にどうぞ
FGOの1部が完結した
Fate/Grand Orderというゲームがある。開発はディライトワークスとタイプムーン。
これが昨日(2016/12/25)に完結した。
完結したという表現はやや語弊があるが、諸々思ったことがたくさんあったので記しておきたくなった。
一応酒を飲み酔ったニワカ月厨が喚いてるだけなのでそれは気に留めていただきたく。
以下、FGO本編及び2015年7月から2016年12月までに行われたイベントのネタバレを含むかもしれないし、含まないかもしれない
もともとこのゲームは初期勢だった。 初期勢なので、伝説の48時間メンテや1章のワイバーン地獄、 さらには低レア配布イベントというイベントとも言えないイベントからやっている。
当時は型月(Fate)にややはまりつつのニワカだったのだが、やる夫スレ系掲示板で型月厨が多い環境にいたこともあり 興味を増しつつあった。
それはそれは、当時はあまりいいゲームとは言えないものだった。 取ってつけたようなシナリオ、慣れていないことが分かる運営の対応、 相次ぐ緊急メンテナンス。 おそらく有象無象のソーシャルゲームでもよくあるダメなゲームの形だったと思う。
恥ずかしながらゲーマーを名乗りつつ、遊んだことのあるソーシャルゲームは現状 後にも先にもFGOのみなので、比較対象はない。ただ、当時はその調整不足の難易度が 逆にゲーマー的に限られたリソースでどこまで行けるかという執念を焚き付けたのは覚えている。
途中イベントに参加しなくなったり、少しログインしなくなったりというモチベーションの上下はあったが、 そうしているうちに1年と5ヶ月ほどが経ったのだ。
型月の一番の魅力はどう考えてもきのこの文章だと思う。
良くも悪くも中二病を刺激する文章と設定、それらが綿密に組み合わさった上で王道を収めるシナリオは 最高の作品になっている。社長が惚れたのも納得である。
FGOは始まったばかりのときはソーシャルゲームの鉄則を守っていた。
それは要はログイン率を上げ、プレイ時間を増やさせる一種のノウハウだろうと思う。
例えば、3分に1回のペースで戦闘(プレイヤーの介入)を行わせる。 1つのイベント・シナリオでは一定量以下の文章に収める。などなど。
そのような決まりごとは徐々に剥がれていった。
当初シナリオは東出祐一郎さんと桜井光さん(それぞれFateシリーズの外伝を執筆)が担当し、 シナリオ監修に徹していたきのこは徐々に仕事量を増やしていった。
イベントのシナリオを書いてと言われ1日で書き上げたり、設定を作ったからイベント追加しようって言ってみたり。
文章量も徐々に増え、サービス開始1年後の2016年7月には本編6章で500kbを書き上げた (しかもマスターアップ数ヶ月前に一度全て破棄、書き直しという展開)。
イベントやシナリオでは地の文が増え、独白が増え、さらにもともとエロゲ・ノベルゲーであったノウハウを活かし イラスト・演出を豪華にしていく。おそらく振り回されたデイライトワークスは大変だっただろう。
BGMは増え、演出は豪華になり、キャラクターの魅力は極限まで磨かれていく。 ときにはひたすらキャラクターが会話するだけで戦闘すらないシーンすら追加された。 だがそういった会話の数々で、当初使い捨てにようにでていたキャラクターは イベントで掘り下げられ、設定が追加され、 加えて新たなキャラクターは全てに魅力を付与された。 終盤の本編では新旧合わせて20人近いキャラクターが動き、考え、戦い、守り、そしてほぼ例外なく散った。 とてもまともなシナリオライターでは持て余すキャラクターたちを動かしきったのだ。 動かしきって、活かして生かした上で、散らせたのだ。
某所ではシナリオマーケティングという言葉が生まれた。
シナリオ中で活躍し、それ故ガチャを回して欲しくなるというものだ。
それは高レアもさることながら、低レアとて例外ではなかった。
Fateシリーズの外伝の1つにApocryphaというのがある。
これは1つのイフの世界の話で小説版と漫画版が展開されているが、実はこれはもともと 携帯電話向けのゲームとして開発したかったものだという。 それが没となり、材料だけ用いて再度作り直した小説がApocryphaだそうだ。
おそらく、それでやりたかったことの1つが叶えられたのだろう。
最終決戦はレイドボスイベントだった。おそらく終わったらシングルモードとして実装されるが、 みんなで最後のボスと戦うという演出をしたかったのだろう。没になったApocryphaでやりたかったことだと思う。
そのお祭り感といったら、レアドロップの魔神柱が刈りつくされるという最終イベントならぬ 採集イベントなどと言われた。だが、そのお祭りから一転、終わった直後は感動の感想が流れた。
皆が盛り上がり、皆が動き、皆が感動して終わる。
終わり方としてはこれ以上のものはないだろう。おそらく最高の終わり方だ。
オンラインゲームやコンシューマーゲームでは多分ここまでの演出はできない。
1年半という短くない時間を様々な形でともにしたゲームと ソーシャルゲームという形ではおそらく最善で最高の形だと思う。
終わったあとに、余韻で残ったスタミナを消費することすらためらわせたのだから驚くべきことだろう。
物語を完結させるというのは難しい。
小説や漫画やあるいは何でもいいが、何か物語を作ろうとした場合まず難しいのは出だしだと思う。
始まりを作る。一文目、一コマ目、それらは悩んで始めることになる。
だが、それは始まってしまえばそう難しいものではない。 設定が増え、キャラクターが増え、やりたいことが増えていく。 そういうものだ。経験があればよくわかると思う。
しかし、終わらせることは難しい。
プロの作家でさえ、プロの漫画家でさえ、なんであれ、美しい終わりを作ることは至難の業だ。
一体どれだけの作品が終わることができずにいるか、終わらせてもらえずにいるか。
深夜アニメのように最終回までの話数が決まっているならいいが、 ソーシャルゲームのように人気がなくなる=終了、つまり人気がある限り終わることができないわけで、きれいに終りを迎えるのはほぼ不可能だろう。
事実、ソーシャルゲームは基本的に「イベントが本体」であり、継続的な運営によって成り立つものだ。
ましてやソーシャルゲームにスタッフロールの流れるエンディングなど普通はない(と思っている)。
だが、イベントを脇役にして、本編を主軸として、FGOは終わらせた。2部があるとは言われているが、まず終わらせた。
それも、人々を衝き動かすほどの終わり方をした。感動させる終わり方だった。
始めるのは難しいが、無理ではない。だが、終わらせるのは至難の業だと思っている。
やっていたら、どこまでもやりたくなるのが作る者の心理だ。 風呂敷は広げ続けたくなるものだ。
でも、終わらせたのだ。
蛇足もなく、やや(伏線回収の)不足こそあれど、型月では割とよくあることなので そのうち回収されるだろう。
終わらせた。それだけで賞賛に値すると思っている。
1つだけ気になることがある。
ディライトワークスの社長に庄司顕仁という人物がいる。
実は彼の名前は、ある時までFGOのスタッフクレジットに載っていた(と思う。確認ができてない)。
今はこの名前が消えている。どこにもないのだ。
そしてFGOは割とリアルのイベントを多くこなしている。ニコ生やマチアソビなど、様々な場所に出て、 スタッフも顔を出している。
だが、この人物だけはどこにも出てこないのだ。
初期の初期、型月の恥晒しとしてFGOが扱われていた頃、彼に対するヘイトは凄まじかった。
この仕事も社長(武内崇)の知り合いで取ってきたとか言う話だった。
正直に言うと完全な擁護こそできないが、しかしここまでの型月の無茶振り対応、最悪 きのこの「じゃあもうFGO畳む」という発言で本当に畳んでしまいそうな運営方針をしている あたり、小さなディライトワークスをうまく支えている人物だと思っている。
もちろん内情は全くわからないのでなんとも言いようがないが、 この人物が本当に実在しているのか、それが気になるのだ。
ともかく、彼も含め、ディライトワークスのスタッフとタイプムーンのスタッフ、 そしてFate/Grand Orderに関わったすべての関係者に感謝と敬意を示したいと思う。
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
うそやろ
続きは解決したら書く
結局エディタのエンコード変えて保存する方法つかった。
たぶんこれが一番早いと思います