ごらくらいふ

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

vimをビルドするスクリプト書いたらただそれだけでも捗りがあった

自分好みの./configureオプションをどこかに残しておきたかっただけなんだけど、そのままmakeしてしまえと思ったのです。

makeがだばだばと状況を吐き出す姿は頼もしい…

dotfiles/build-latest-vim at master · yajamon/dotfiles · GitHub

一応 2017-12-01現在のコードを転記しておくと以下のとおり。

#!/bin/bash

readonly VIMREPO=$GHQ_ROOT/github.com/vim/vim

cd $VIMREPO
git fetch --all --prune
if [ $(git rev-parse master) = $(git rev-parse origin/master) ]; then
    param=""
    while [ -z $param ]; do
        echo -n "Already up-to-date. continue?(yN): " >&2
        read -r param _trush
    done
    if [ $param != "y" ]; then
        exit 0
    fi
fi

git checkout master && git merge --ff origin/master

make distclean
./configure --with-features=huge \
    --enable-perlinterp \
    --enable-rubyinterp \
    --enable-luainterp \
    --enable-fail-if-missing \
    --prefix=/usr/local
make
sudo make uninstall
sudo make install

更新が無い場合にはワンクッション置くところが工夫したところで、捗りポイントかな。

コミットハッシュを見て差分の有無を確認したり、readできちっと値を取り出したり、知見が生きている。

yajamon.hatenablog.com

qiita.com

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

sedを使って$PATHの中身を一行ずつ表示する

区切り文字:を半角スペースにしてforで回すという回り道をしてしまったので備忘。

\nでいいじゃんっていう。

echo $PATH | sed -e "s/:/\n/g"

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

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

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

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

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