ごらくらいふ

プログラミングしたりゲームしたり

gitのコミットハッシュを見て、処理を続行するか判断する

結論

git rev-parseでコミットハッシュを取得できる。

たとえば、リモートで変更があるかどうかによって、処理を分岐させることができる。

git remote
# origin
# upstream

git fetch --all --prune

if [ $(git rev-parse master) = $(git rev-parse upstream/master) ]; then
    echo "Already up-to-date" >&2
    exit 0;
fi

# heavy logic
git checkout master && git merge --ff upstream/master && git push
make

参考リンク

dateコマンドで日付からミリ秒までフルに取りたい!

date +"%F %T.%N"
# 2017-11-09 12:35:31.678900889

%F%Y-%m-%dと同じで、%T%H:%M:%Sと同じ。 なので、「日付はスラッシュ区切り、時間はコロンなし」というフォーマットにするなら以下のように書く。

date +"%Y/%m/%d %H%M%S.%N"
# 2017/11/09 123531.678900889

雑感

man dateから/sameすると色々あった。

参照元

DDDエリック本を読んでいる:RepositoryとFactoryの関係

DDDについてEric本を読んでいたところ、オブジェクトの生成やシリアライズについての指針が参考にできそうだったので、メモ。

  • Factoryはオブジェクトのライフサイクルにおける始まりを処理し、リポジトリは中期から終わりを管理するのを助ける。
  • リポジトリはデータに基づいてオブジェクトを生成するので、多くの人はリポジトリのことをファクトリであると考える。
  • しかし、格納されたオブジェクトを再構成することは、新しい概念オブジェクトを生成することとは異なる。
  • リポジトリのクライアントには、オブジェクトがメモリにあると錯覚させなければならない。
  • リポジトリがオブジェクトの生成をファクトリに委譲すれば良い。

重要なのは末尾の項目で、リポジトリシリアライズされたデータを永続化媒体から(アダプタを介して)取得して、ファクトリに流し込んであげればよい。

雑念

  • (いや、アダプタを介して取得したデータが全て特定のシリアライズに統一して良いのだろうか…?)
  • (永続化媒体ごとにアダプタがあるなら、アダプタごとにシリアライズの方式が異なる…?)
  • (つまりアダプタがファクトリを持つ?)
  • (むしろリポジトリがアダプタ…?)
  • (ファクトリのパターンはファクトリクラスでもファクトリメソッドでもビルダーでも状況に応じてチョイスしてね、みたいな感じだった)
  • Kindleのハイライトめっちゃ便利だ…)

参照元

エリック・エヴァンスドメイン駆動設計

  • 第2部 モデル駆動設計の構成要素

より

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

Git Bash on Windowsでパス区切り文字をバックスラッシュに変換する(そしてExplorer.exeでカレントディレクトリを開く)

Git Bash on WindowsからExplorer.exeを呼び出す場合、パスの書式をWindowsに寄せておく必要がある。

結論

# aliases
alias convertFullPathToWindowsFormat='sed -e "s/^\\/\\([a-zA-Z]\\)\\//\\1:\\\\/" | sed -e "s/\\//\\\\/g"'
explorer /e,$(pwd | convertFullPathToWindowsFormat)

構成要素

/\に変換する。

cd ~
pwd | sed -e "s/\//\\\\/g"
# \c\Users\name

ドライブレター対応

/c/hogehogeからc:/hogehogeに変換する

cd ~
pwd | sed -e "s/^\/\([a-zA-Z]\)\//\1:\\\\/"
# c:Users/name

動いているプロダクトが正しい。

本当はこの硬いプロダクトをもっちり弄ってもちもちにしてやりたい。 でもそんなコードは他の人にとっては要らない。なぜなら金にならないから。 機能として売り込むこともできなければ、きっとコスト削減にもならないのだから。

issueがなければ書いてはいけない。課題でなければissueにしてはいけない。

書いたならばレビューを受けさせる必要がある。

金にならないコードを書くことと、ただツイートをすること、どちらが無害かと言えばツイートでもしてることだ。 同じ金にならないにしても、レビューコストをチームに払わせないのだから。

雑記:PSVRが欲しい。(せめて定価で。)

PSVR、ほしい。もう発売からどれだけ立つよ。(2016-10-13発売。もう1年!)

新モデルも発売間近。各地の予約はとうに枯れ果ててる。

ソフトメーカーにはもう少し耐えていてほしい。売上が上がらないことに、イベントトラッキングがインストール指標ばかりであることに。 ハードだけ確保して使用しない購入者から、ユーザーに浸透するときが来る…はずだから…。

ハードが売れてもソフト側にお金が回らずに萎えてしまったらプラットフォームとして死んでしまうのではよ、浸透はよ。俺のVR体験を奪わないでくれ。

とりあえずユーザーとしてできることとして、ソフトだけ先に買っておこうって。 PSVRを買う意思があることを、ソフト購入という形で示しておけば、粘り強くPSVRを出荷してくれると思う。

デレマスVRをはやくやりたいんだよ!!!

あと近年まれに見る完成度の釣りゲーin VR。楽しみです。とりあえずソフトだけは買います。