ファイル名が違ってgitの状態がおかしくなる
原因もなぜそうなったのかもよくわからない問題だけど一応記す。
git + github で readme ファイルを修正してコミットしてプッシュしてマージした。したが、どうもおかしく変更が適用されていないっぽい。
コミット忘れかと思ったがコミットしているし、readme ファイルそのものは変更されていてリポジトリのトップに表示される readme だけ変更されていなかった。
あららおかしいぞと思いつつ VSCode の git を見るとコミット対象に README がある。
> git status
をしてみたところコミットされていないしインデックスに登録もされていないとのこと。
おかしいぞと思いつつ > git diff
をしたところ修正前のものと修正後のものが出た。ただ、修正自体はコミットしたはずである。
実際、>git add -A
や >git commit -am "commit"
とかやってもコミット対象はないよ、加えるファイルもないよと出る。
VSCodeの機能でコミットしようとすると今度はエラーが発生したと出た。
よく見たところ追加対象の “README” と実際にファイルとして存在する “readme” は違うファイルのようで、どういうわけか二つの名前のファイルが1つの存在として扱われているため起きていたみたいだった。詳しいことはわからん。でもファイル名が違っていた。
とりあえず対処法としては
> git reset --hard HEAD
で戻して
> git status
で確認。この時点で変更はないと出る。たぶん修正前に戻っている。
そしたら
> git mv README readme
で名前変更。あとは
> git add -A
> git commit -am "commit"
でコミットして
> git status
あたりで確認して、問題なければプッシュ。とりあえずこれでどうにかなった。
原因はわからないが、ファイル名に気を付けるといいと思われる。
ゼルダの伝説Breath of the Wildでガノンを討伐した
- 出版社/メーカー: 任天堂
- 発売日: 2017/03/03
- メディア: Video Game
- この商品を含むブログ (13件) を見る
このゲームがいかに素晴らしいかはたぶんもう聞き飽きたのではないかというぐらい聞いたと思う。
いろんな要素について各ゲームサイトや個人サイト、それこそTwitterなどでも言われるように、このゲームはとても素晴らしいゲームであった。
具体的に言うと、このゲームには明確な欠点があるのに点数を出すときには満点になってしまうというぐらいすごいゲームなのである。
実際、
- 割と多いフレームレートの低下、いわゆる処理落ちやプチフリーズ
- 基本的に道順が存在しないためかなりの強敵からザコ敵までがごった煮になっておりややおおざっぱなバランス調整
- 複雑なユーザーインターフェース
- 動物要素の希薄さ。犬とか馬を撫でられないとか、猫がいないとか
という欠点はある。あるにはあるが、そんなものがあったところでこのゲームは神ゲーなのだ。本当に神ゲーなのだ。
- このゲームは素晴らしく、間違いなくゲーム史に残る傑作である
という美点一つでひっくり返る。
いろいろやったが、現在のクリア率は30%を切っている。
ぶっちゃけオープンワールドゲームでこういった要素を100%にするのはあきらめているので、50%ぐらいを目指そうかなぁとも思っているがやや葛藤中でもある。
いっそ試練の祠・祝福の祠のコンプリートでもいいかもしれない。
ちなみにタイトルが「ガノンを討伐した」になっているのはそのため。とてもじゃないが、クリアしたとは言いにくい。おそらくまだ踏んでいないハイラルの大地があり、見ていない敵や生物や植物があり、知らないものだらけだろう。
このゲームをクリアしたというには、まだまだ遊び足りない。
とりあえず、祠探しの旅を続けながらたまに大妖精の泉を復活させたり敵を屠り去ったり料理を作ったりしながらハイラルの大地を駆け回ることにする。
しかしそうやってるとゼルダ姫の語り掛けに申し訳なさを感じる。感じざるを得ない。
リンク……まだですか……?って感じがする。ごめん、もうちょっと遊ばせて
どうでもいい(よくはない)けど、今作は追加ダウンロードコンテンツもあるんだよね。
なんでも追加コンテンツは裏ゼルダ(ダンジョンだけ新しくする+ダメージ増加)と、追加シナリオらしい。
ダンジョンは1つ当たりが小さめで、既存のゲームでいうとゲームエンジン的な特性を使ってる当たりPortalに近いし、ネタ自体は問題なさそう。
追加シナリオは……どうなるんだろうか。
オープンワールドゲームの問題の一つにシナリオをなぞる都合上どうしても広い世界を一本道にたどるというケースが多い。今作のゼルダはその辺もうまく解決していたけど、追加シナリオがどうなるか。
そういえばシナリオで思い出したけど今作ってゼルダシリーズの時系列のどこにあたるんだろうね。
風タクの世界に近そうだけど、あの世界一度海に沈んでるし、沈む前なら沈む前でガノンの様子とかがかみ合わない気もする。
まあそこまで重要な要素ではないか。
とにかく、いいゲームだった。
次回作もDLCも楽しみだし、20年後、再びこれを越えていくようなゲームが生まれるかもしれないと思うとこの先も楽しみになる。
素晴らしいゲームは、その作品だけでなくゲームそのものの未来も照らすいい例だったと思う。
Cloud SQL のタイムゾーンを変える
SQLの current_time とか now() はサーバ側のタイムゾーン設定に依存してるのでCloud SQLなどではタイムゾーンが日本と違ったりすることがある。
Cloud SQLも例にもれずデフォルトだとこういう設定になっている
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | UTC |
| time_zone | SYSTEM |
+------------------+--------+
2 rows in set (0.34 sec)
中身はMySQLだが設定ファイルを直接いじったりは出来ないのでCloud SQLの管理画面からフラグを操作すればいい。
詳しくはここ。これが公式ドキュメント。
Configuring Cloud SQL Flags | Cloud SQL for MySQL | Google Cloud Platform
タイムゾーンはdefault_time_zone
を +09:00 にしてあげればJSTになる。
ちなみに変更するとこんな感じになる。
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | UTC |
| time_zone | +09:00 |
+------------------+--------+
2 rows in set (0.15 sec)
ほかにも設定関係はここで変更してあげればいいっぽい
MavenでCheckstyle
開発環境にEclipseではなくVisual Studio Codeを用いていて、ビルドツールはコマンドラインでMavenのコマンドをたたいている。
で、Pythonを書いているとpep8なるものがありコーディング規約をチェックしてくれたり、Goだと言語仕様レベルでコーディング規約を定めてくれていることもあり、Javaでもそろそろコーディング規約のチェックツールを導入するかなーと思った。
Javaでのコーディング規約チェックツールにはCheckstyleというツールがある。これを使えばいいことまではすぐにわかったのであるがMavenを使っていることだしMavenで実行させたい。
Maven用のCheckstyle Pluginはちゃんとある。
Apache Maven Checkstyle Plugin – Introduction
しかし日本語資料はこれでもかというぐらい見つからなかった。厳密にはあったのだが、Maven2での資料でMaven3ではなかった。
なのでここに軽く示す。
Apache Maven Checkstyle Plugin – Usage
示すって言った直後にあれだけどここのページの下部にあるExampleを大体コピーで構わない。バージョンには気を付けるのと、設定関係の値(configuration下)は考えた方がいい。
configLocation値とかは書かなくても動くし(Checkstyle自体がデフォルトでSunの規約となっているのでおそらくそれで動いてくれる)
で、走らせた結果日本語が文字化けしてめちゃくちゃエラーを吐いている。つらい。5471個もエラーが出た。つらい
でも日本語使ってるからエラーというわけではなく、出力がUTF-8だからこうなってっぽい。
一応CHCPコマンドで文字コードを変えることはできるが、それでも一部文字が上手く表示されないようだった。
出力をShiftJISにするか、あるいはエラーメッセージを英語で出力するかの解決法しかないと思われる。一時ファイルに出力させてそれをエディタで見るのも一つではあるが、それもそれで面倒。
一番楽なのは出力を英語にするやつだと思う。でもどうすればいいかわからない……
Eclipseとか使いたくない人がWindowsでJavaの開発環境を作る
Javaの開発環境を調べていたら毎回毎回Eclipseの情報が出てくるが、なんとなくあのIDEを使いたくない場合はこういう風にしようって感じの話。
ざっとまとめるとこんな感じで開発してる
- エディタ : Visual Studio Code
- ビルドツール : Apache Maven
- シェル : Windows Powershell
- バージョン管理 : git
まあぶっちゃけたことを言うと一番苦労するのはVSCodeの環境を整えることでGitはGit for Windowsとか入れればいいしMavenはZIPで落として適当なところに解凍してパスを通すのが楽。
パッケージ管理システムを使うならChocolatyあたりを使うといい。この場合もPowershellになる。
ところでシェルをPowershellにしているが、実をいうとBashを使いたかった。
Bash on Windowsでも同じプロジェクトを操作することができるが、一つ問題点としてBashとWindowsの環境が切り離されているというところ。WindowsにGitを入れてもBashの方ではGitが呼べない(厳密には2017年4月のCreater Updateで呼べるようになるらしいが)ので、Bash環境の方にLinux用のGitやMavenを入れる必要がある。
が、現状(バージョン1607)ではBash on WindowsでJava実行時に問題が起きるのでそれができないという問題がある。また、Bashの方からWindowsのMySQLへのアクセスとかしようとするとソケットでエラーが出てくるためあまりよろしくない(解決できるかもしれないけど時間かかるしわからなかった)。これはこれでBash側にMySQLサーバ立てればいいところでもあるが。
VSCodeの開発環境は拡張機能でJavaの言語サポートがあるためそれを使うのが一番簡単だと思う。
Red Hatのやつが特に問題なく入ってくれると思う。Language Support for Java™ by Red Hatってやつ。
各種MavenのプラグインはPOMに直接書き込むことになる。これが面倒だなぁと思うならGradleに移行するのもいいと思う。最近ならプラグイン関係はMavenにもGradleにも対応してると思うし。
Mavenのプラグインは基本的に好みだが、おススメするところでは
あたりは入れておきたいと思う
Bash on Windows での .bash_profile の扱い
環境変数やらを扱う際に使うときは .bashrc と .bash_profile の二つがある。これらの違いはログイン時に読み込まれるかシェル起動時に読み込まれるかの違いがある。
参考
これによると .bashrc はシェル起動時、.bash_profile はログイン時とある。
通常ならこれでいいのだが、さて Bash on Windows ではどうなるのか。というのも、ログインタイミングはユーザログイン時なのか bash 起動時なのかわからない。シェル起動時というのは bash 起動時でいいのか。
で、(わかっている)結論から書くと、bash 起動時はログインとは取られていない。
そもそもデフォルトではホームディレクトリに .bash_profile はないのでひょっとするとログイン時という処理は特別な扱いをされていて読み込まれないのかもしれない。
もし環境変数を設定したい場合は .bash_profile ではなく .bashrc に書いておくのが安パイかもしれない。でも正しい処理ではないのであくまで Bash on Windows ではそうしておく程度に考えた方がよさそう。
ちなみにシェル再起動のコマンドは exec $SHELL -l
で再起動する。何かあれば .bashrc に書き足した後にこのコマンドを実行すればとりあえず使えるようになるはず。
本当はちゃんといくつかのパターン(再起動とか)で検証するのが正しいんだろうけど時間がないので誰かやってくれると助かる。
Nintendo Switchを買った
いよっし pic.twitter.com/APHBcJA133
— メア卜ノレらしい (@maretol) 2017年3月3日
買った。発売日に手に入った。天よありがとう。
で、触った感じ
まず本体。排熱用のスリットはやっぱちょっと熱を持つ。40度ぐらい。配置的にも携帯モードで遊んでもまあそんなに気にならない。
重さもまあそれなり。重いほどではない。劇的に軽いわけでもない。昨今のタブレットなら普通ぐらいか。
スタンドもあるが角度が固定で結構急なのでちょっとキツイかも。出来なくもない程度。ちょっと頼りないけどちゃんと支えてくれる。
本体側のボタンは電源、音量のみ。あとはコントローラにいくつか。特に押しにくいこともなくいたって普通。
コントローラはJoyConと別にProコンを購入。JoyConは小ささが目立つ感じ。慣れればそこまで気にならないがスティックのストロークがやや浅い感じ。ボタンは小さめだけどまあこれも問題はなし。トリガー関係も良好。HD振動はまだ体験してないが、普通の振動でもiPhoneのようにメリハリのついた振動の感じ。iPhoneとその他のスマホを持っている人にはわかると思う。
Proコンは結構大きめ。WiiUプロコントローラと比べてもちょっとでかいかも。WiiUのときはProコンがWiiUゲームパッドのボタン類を再利用してる感じだったのに対してこっちは完全新規設計。従来のコントローラに近い。トリガーがPS3やPS4みたいに飛び出してるけど完全なデジタルボタンなので暴発の可能性は低そう。
加えてコントローラ類は全部マット処理がされてるので指紋とかは目立たない。これはとてもプラス。
OSはFreeBSDベースらしい。権利関係の表記でFreeBSD Kernelの表記があった。PS4もFreeBSDなんだけどなんだろうねこの流行?
全体的にキビキビと動く感じ。買ったばかりのAndroid端末を彷彿とさせる動きだった。
設定周りは割とすんなり。このあたりはWiiUの反省が生きてるっぽい。
ドックから外すと携帯モード・テーブルモードに起動、つけるとテレビモード。このあたりの動きもかなりしっかりしてる。
欠点はテレビ側が切替速度に対応しきってないところか。いいテレビがほしくなってくる
その他起動周りもかなりすんなり。3DS同様基本はスリープで起動に時間はかからない。ゲームを中断するのも容易。本体のボタンのほか、ホームボタン長押しで簡易メニューが出るのでそれを使うと画面の明るさ、機内モード、そしてスリープに入るのかを選べる。スリープは本体の電源ボタンでも行ける。
発売日にアプデもあったがそちらも特に問題なし。5分もしないで更新が終わった(と思う、うろ覚え)のでかなり良さそう。
どうでもいいけど周辺機器でコントローラなどを購入するとすごい勢いでUSB Type-Cケーブルが増える。まあ当然なんだが、なんかすごい侵食率。
あとProコンはBluetoothでPCにも容易に接続できるとのこと。なんかNintendoがこんなにオープンな規格を使ってるのは珍しい気がする。時代の流れだろうか。
バーっと書いたが、ぶっちゃけるとあんまり良く見てない。まだeShopにもアクセスしてない。
ゼルダが面白すぎる。このゲームはヤバイ。多分歴史に名を残す。時オカを越えてると思う。なんというか、これはオーパーツとかそういったたぐいのゲーム。明らかにおかしい。今までのオープンワールドゲームが「ただ単純に世界が広いだけでした」と言われると否定できなくなる気がする。
このソフトの前と後で、多分ゲーム自体も変わるんじゃないかと思うぐらい。
多分とりあえずクリアしたらまたなんか書くと思う。明らかにおかしいもん。本当にもう1つの世界があるって言われるレベル。頭おかしい。
- 出版社/メーカー: 任天堂
- 発売日: 2017/03/03
- メディア: Video Game
- この商品を含むブログ (8件) を見る
- 出版社/メーカー: 任天堂
- 発売日: 2017/03/03
- メディア: Video Game
- この商品を含むブログ (2件) を見る