2018-07-28

Go での開発環境に Makefile を導入したメモ。

dt に Makefile を導入しました。

雑に始めた Go での開発環境のメモ。 - 全力で怠けたいで↓みたいなことを書いたのですが、

いくつかコマンドを Github で公開しているのですが、Github の Release に登録するためのバイナリの作成やアップロードが面倒です。
そこで、コンパイルには gox を、Github にアップロードするために ghr を利用しています。
実際のところは、↓こんな感じに雑なシェルスクリプトを書いて、パッケージディレクトリで叩いています。

やっぱり面倒だったので Makefile を導入しました。
今まで JVM 系の開発が多かったので Makefile を使ったことはないのですが、Go での開発ではよく使われているみたいですね。

https://github.com/ebc-2in2crc/dt/blob/master/Makefile

GOCMD=go
GOBUILD=$(GOCMD) build
GOCLEAN=$(GOCMD) clean
GOTEST=$(GOCMD) test
GOGET=$(GOCMD) get
NAME := dt
CURRENT := $(shell pwd)
BUILDDIR=./build
BINDIR=$(BUILDDIR)/bin
PKGDIR=$(BUILDDIR)/pkg
DISTDIR=$(BUILDDIR)/dist

VERSION := $(shell git describe --tags --abbrev=0)
LDFLAGS := -X 'main.version=$(VERSION)'
GOXOS := "darwin windows linux"
GOXARCH := "386 amd64"
GOXOUTPUT := "$(PKGDIR)/$(NAME)_{{.OS}}_{{.Arch}}/{{.Dir}}"

.PHONY: deps
## Install dependencies
deps:
	$(GOGET) golang.org/x/tools/cmd/goimports
	$(GOGET) github.com/golang/lint/golint
	$(GOGET) github.com/codegangsta/cli
	$(GOGET) github.com/mitchellh/go-homedir
	$(GOGET) github.com/Songmu/make2help/cmd/make2help
	$(GOGET) github.com/tcnksm/ghr

.PHONY: build
## Build binaries
build: deps
	go build -ldflags "$(LDFLAGS)" -o $(BINDIR)/$(NAME)

.PHONY: cross-build
## Cross build binaries
cross-build:
	rm -rf $(PKGDIR)
	gox -os=$(GOXOS) -arch=$(GOXARCH) -output=$(GOXOUTPUT)

.PHONY: package
## Make package
package: cross-build
	rm -rf $(DISTDIR)
	mkdir $(DISTDIR)
	pushd $(PKGDIR) > /dev/null && \
		for P in `ls | xargs basename`; do zip -r $(CURRENT)/$(DISTDIR)/$$P.zip $$P; done && \
		popd > /dev/null

.PHONY: release
## Release package to Github
release: package
	ghr $(VERSION) $(DISTDIR)

.PHONY: test
## Run tests
test: deps
	$(GOTEST) -v ./...

.PHONY: lint
## Lint
lint: deps
	go vet ./...
	golint ./...

.PHONY: fmt
## Format source codes
fmt: deps
	find . -name "*.go" -not -path "./vendor/*" | xargs goimports -w

.PHONY: clean
clean:
	$(GOCLEAN)
	rm -rf $(BUILDDIR)

.PHONY: help
## Show help
help:
	@make2help $(MAKEFILE_LIST)

ハマったこと

"Each line in a makefile target recipe is run in its own shell session."
-> makefile のターゲットの各行は、それぞれのシェルセッションで実行されます。

完全にハマってた……https://t.co/UCDGUBdwLj
— えび🦐🍤 (@ebc_2in2crc) July 28, 2018

2018-07-26

雑に始めた Go での開発環境のメモ。

プログラミング golang

少し前からちょっとしたことをするときに Go を使い始めたので、その開発環境のメモ。

書くこと

エディター
ビルド
公開
公開しているコマンドたち
まとめ

エディター

だいたい Goland で書いています。
コード補完、クイックフィックス、リファクタリングなどの機能がとても優秀で、初学者でも詰まることなくコードを書けるので助かっています。

ビルドと公開

ビルド

Goland 上で Run するかシェルから go run / go build するのがほとんどです。
コード量やファイルも少ないので、今のところはこれで事足りています。

公開

いくつかコマンドを Github で公開しているのですが、Github の Release に登録するためのバイナリの作成やアップロードが面倒です。
そこで、コンパイルには gox を、Github にアップロードするために ghr を利用しています。
実際のところは、↓こんな感じに雑なシェルスクリプトを書いて、パッケージディレクトリで叩いています。

#!/bin/sh

CURRENT=`pwd`
PGNAME=`basename ${CURRENT}`
BUILD_DIR=build
PKG_DIR=${BUILD_DIR}/pkg
DIST_DIR=${BUILD_DIR}/dist

if [ -z "$1" ]; then
	echo 'compile.sh <tag>'
	exit 1
fi

TAG=$1
PACKAGE=.

if [ -d ${PKG_DIR} ]; then
	rm -r ${PKG_DIR}
fi
mkdir -p ${PKG_DIR}

gox \
    -os="darwin windows linux" \
    -arch="386 amd64" \
    -output "${PKG_DIR}/${PGNAME}_{{.OS}}_{{.Arch}}/{{.Dir}}" \
    $PACKAGE

if [ -d ${DIST_DIR} ]; then
	rm -r ${DIST_DIR}
fi
mkdir ${DIST_DIR}

pushd ${PKG_DIR} > /dev/null
for P in `ls | xargs basename`
do
	zip -r ${CURRENT}/${DIST_DIR}/$P.zip $P
done
popd > /dev/null

ghr ${TAG} ${DIST_DIR}

公開しているコマンドたち

日付時刻を簡単に計算 / フォーマット変換できる dt というコマンドと、西暦と和暦を相互変換する
wareki というコマンドを公開しています。

まとめ

こんな感じの開発環境でやっていますが、gore や ghq や peco などといったとても便利なツールがあるみたいなので、これからもどんどん変わりそうです。

2018-05-20

日付を計算したり、日付の書式を変換する dt コマンドを作りました。

productive command y2

日付を計算したり、日付の書式を変換するコマンドを作りました。

github.com

書くこと

なにができる？
使い方
インストール
動機
まとめ

なにができる？

日付の加算と減算
日付の書式を変換

これだけをしてくれるコマンドです。

使い方

システム時刻の1年3ヶ月20秒後を求める

$ date "+%Y/%m/%d %H:%M:%S"
2018/05/12 17:30:00

$ dt now +1Y +3M +20s
2019/08/12 17:30:20

計算元の日付を指定

$ dt "2018/05/12 17:30:00" +1Y +3M +20s
2019/08/12 17:30:20

日付の加算

$ dt "2018/05/12 17:30:00" +1Y
2019/05/12 17:30:00

$ dt "2018/05/12 17:30:00" +1M
2018/06/12 17:30:00

$ dt "2018/05/12 17:30:00" +1D
2018/05/13 17:30:00

$ dt "2018/05/12 17:30:00" +1h
2018/05/12 18:30:00

$ dt "2018/05/12 17:30:00" +1m
2018/05/12 17:31:00

$ dt "2018/05/12 17:30:00" +1s
2018/05/12 17:30:01

# '+' は省略可能
$ dt "2018/05/12 17:30:00" 1Y 3M 20s
2019/08/12 17:30:20

日付の減算

$ dt "2018/05/12 17:30:00" -1Y -3M -20s
2017/02/12 17:29:40

入力フォーマット

# コマンド標準
$ dt "2018/05/12 17:30:00" +1Y +3M +20s
2019/08/12 17:30:20

# RFC822
$ dt -o def "12 May 18 17:30 MST" +1Y +3M +20s
2019/08/12 17:30:20

$ dt -o def 1526113800 +1Y +3M +20s
2019/08/12 17:30:20# unix 秒

自動判断されるフォーマット

入力フォーマットを指定

# unix ミリ秒
$ dt -i unixm -o def 1526113800000 +1Y +3M +20s
2019/08/12 17:30:20

# カスタムフォーマット
$ dt -i "02-Jan-06 15:04:05" -o def "12-May-18 17:30:00" +1Y +3M +20s
2019/08/12 17:30:20

出力フォーマット

デフォルトは入力フォーマットと同じ。

$ dt "2018-05-12 17:30:00" +1Y +3M +20s
2019-08-12 17:30:20

$ dt 1526113800 +1Y +3M +20s
15300622820

出力フォーマットを指定

$ dt -o def 1526113800 +1Y +3M +20s
2019/08/12 17:30:20

$ dt -o "02-Jan-06 15:04:05" 1526113800 +1Y +3M +20s
12-Aug-19 17:30:20

ヘルプ

$ dt --help
# ...

インストール

Homebrew

$ brew tap ebc-2in2crc/dt
$ brew install dt

Developer

$ go get -u github.com/ebc-2in2crc/dt/...

手動

https://github.com/ebc-2in2crc/dt/releases からダウンロードした zip ファイルを展開した中にあるファイルを、パスの通ったディレクトリに入れる。

動機

DB に格納されている日付が unix 秒だったり、それに対する加減算をしたり、入力と出力で日付のフォーマットが異なっていたりするのが面倒くさくて作りました。date コマンドでも同じことはできなくもありませんが……

実装言語が Go なのは、以前チュートリアルをやったきり触っておらず文法そのほかすべてをきれいに忘れてしまったので、再入門するつもりで選びました。

まとめ

バグとかあると思いますし、「おそいよ！」とか「こーしたら使いやすくなる」とかあったら、イシュー作ったり声かけてもらえると嬉しいです。

ということで dt コマンドの紹介でした。

2018-05-12

西暦と和暦を変換する wareki コマンドを作りました

productive command y2

西暦と和暦を変換するコマンドを作りました => Docker に対応しました

github.com

書くこと

なにができる？
使い方
インストール
動機
まとめ

なにができる？

西暦を和暦に変換
和暦を西暦に変換

これだけをしてくれるコマンドです。

使い方

西暦を和暦に変換

$ wareki 2018
H30

西暦を省略すると今年の和暦に変換

$ wareki
H30

$ date "+%Y/%m/%d"
2018/05/10

和暦を漢字で出力

$ wareki --kanji
平成30

年月日を指定すると厳密に変換

$ wareki 1989/01/08
H1

$ wareki 1989/01/07
S64

和暦から西暦に変換

$ wareki --heisei 30
2018

$ wareki --showa 64
1989

ヘルプ

$ wareki --help
NAME:
  wareki - 西暦を和暦に変換する

USAGE:
  wareki [options] [AC]

DESCRIPTION:
  AC に指定した西暦を和暦に変換します.
  和暦の元号は西暦に応じて自動的に決まります. たとえば, 1989/01/08 を指
  定すると H1 (平成1年) に, 1989/01/07 を指定すると S64 (昭和64年) に
  なります.
  AC は省略でき, デフォルト値はシステム日付になります.
  デフォルトでは, 元号は英大文字1文字で出力しますが (e.g. H) --kanji オ
  プションを指定することにより漢字で出力することもできます (e.g. 平成)
  また, --meiji, --taisho, --showa, --heisei オプションにより, 和暦か
  ら西暦に変換することもできます.

OPTIONS:
  --meiji value, -M value   明治から西暦に変換します (default: 0)
  --taisho value, -T value  大正から西暦に変換します (default: 0)
  --showa value, -S value   昭和から西暦に変換します (default: 0)
  --heisei value, -H value  平成から西暦に変換します (default: 0)
  --kanji, -K               元号を漢字で出力します
  --help, -h                このヘルプを表示します
  --version, -v             バージョンを表示します

インストール

Homebrew

$ brew tap ebc-2in2crc/wareki
$ brew install wareki

Developer

$ go get -u github.com/ebc-2in2crc/wareki/...

手動

https://github.com/ebc-2in2crc/wareki/releases からダウンロードした zip ファイルを展開した中にあるファイルを、パスの通ったディレクトリに入れる。

動機

「今年は平成何年だったかな？」が覚えられなくて作りました。ブラウザで「平成」をググればすぐに出てくるのですが、それも面倒だったので。

まとめ

バグとかあると思いますし、「おそいよ！」とか「こーしたら使いやすくなる」とかあったら、イシュー作ったり声かけてもらえると嬉しいです。

ということで wareki コマンドの紹介でした。

2018-04-14

外から得られた学びを自分たちの現場に適用するには？まずは、現場の状況や制約に照らし合わせることから始めよう - カイゼン・ジャーニーを読んで

productive 読書会

私たちも数多くの挫折を味わってきました。やはり、現場を変えるなんて一人では進めることができないのでしょうか。
　そんなことはありません、ということが言いたくて私たちはこの本を書きました。一人から行動を起こすことはできます。そして、その行動が次の進展をつくります。この本では、私たち自身がこれまで経験し、実践してきたことを下敷きにして、どのようにして始めて、周りを巻き込み、前進していくのかを具体的に示しました。
　私たちは、この本が現場を変えていく人たちに寄り添う存在になって欲しいと願っています。(Foreword より)

早いものでもう4月。1年の4分の1が過ぎ去った事実をなかなか受け入れられない時期ですが、そんな時期に今年最高の1冊になるだろう素晴らしい本に巡り会えたので、感想を記しておきたいと思います。

読んだのは、Twitter のタイムラインで話題をさらっているカイゼン・ジャーニーです。

www.shoeisha.co.jp

ストーリー仕立てでとても読みやすく、そして全編にわたって学びがあるのですが、その中でも「最初の一歩はこれ！」と強烈に思わされたことが、まさに第1部の第01話に書かれていました。

外に出て知見を得ていくにあたって、覚えておかなければならない大事なことがある。外から得られた学びを、そのまま自分たちの現場や仕事に適用しようとしても、たいていうまくいかない。自分たちの「状況」に照らし合わせてみることが必要だ。(013ページより)

ところで、これはどういうことなのでしょうか？すぐあとに「うまくいかない」具体例が書かれています。

これは、キーワードだけで技術やプロセス、プラクティスを引っ張ってきて、現場に手段のみを持ち込もうとしたときも同じことが言える。キラキラした言葉に心を持っていかれてはならない。(013ページより)

たとえば、自分の Twitter のタイムラインやはてなブログでは、

実業務ではアジャイルなど使い物にならない！と言われた
Git を使えないどころか部内には知っている人が誰一人としていなかった
テストコードを書くと工数がかかるからダメだと言われた
プロジェクトに関係のない活動は一切禁止と言われた

こういったツイートやエントリーを目にしない日はない、IT 業界あるあるネタの1つです。

社内の状況や文化に不満を感じる日々、発奮して社外の勉強会に参加してみた→素晴らしいスピーチ！実際に成されたカイゼンとその原動力となったプラクティス！→自分も社内でやってみよう！！→よくて無反応、ともすれば猛烈な反発にあう→社内の文化も組織も人もまるでだめ、向上心も技術者としてのプライドもない人たちばかり……ことの大小はあれ、Twitter やはてなブログでもよく目にする話しですし、多くの人が経験していることだと思います。

では、どうすればいいのでしょうか？

実際に現場をカイゼンする原動力となった技術やプロセス、プラクティス……そういったものを使わずして、自分たちの現場をカイゼンすることが出来るのでしょうか？

当然浮かび上がってくる疑問ですが、その疑問に対する答えも用意されています。

私たちは、他者の実践の背景にどんな状況、制約があったのかを理解し、自分たちの状況、制約の下ではどのように実践するべきなのか捉え直さないといけない。(013ページより)

自分は SI 業界の経験が長いので、たとえとして ERP パッケージを会社に導入することが浮かび上がりました。

たとえば、高価な ERP パッケージを買ってもそのままではおそらく業務は成り立ちません。会社の業務に合うようにカスタマイズするのか、逆にパッケージに合うように業務を変えてしまうのか、あるいは費用と効果がバランスする妥協点を見つけ出すのか……やり方の幅も深さもさまざまですが、少なくとも ERP パッケージを買って導入して終わり、ではありません。

つまり、技術やプロセス、プラクティスというものも、他者が成功した実践そのままを自分の現場に持ち込もうとしても、うまくいくはずがないということです。成功した他者が実践している技術やプロセス、プラクティスがどんなに優れていても、カイゼンに成功した他者と現在進行系で苦しんでいる自分の現場とでは、そもそも練度がまったく違いますから、成功した他者が実践していることをそっくりそのまま自分の現場に持ち込むのは非現実的です。

実際に現場をカイゼンする原動力となった技術やプロセス、プラクティスは当然持ち込むし使うとしても、なにを・いつ・どうやって・どこに・どれくらい持ち込むのか、これを考えて持ち込まなければなりません。

自分の現場はなにが足りていないのか？組織の文化はどうなっているのか？その組織を構成する一人ひとりはどう考えているのか？日々忙殺されている業務のなかで、何ができるのか・何からなら始めていけるのか？ ……それを考えずして技術やプロセス、プラクティスを持ち込んでも労多くして功少なし、でしょうが、それを考えることができれば、それがカイゼンを成功させる第一歩になる。第1部の第01話の解説役である石神氏はそう説いています。

これを読んだとき、「この本は絶対にすごくいい本だ」と感じました。そして、実際に読み終わってもその印象はまったく変わりませんでした。
折に触れて読み返したい、そう思った本です。

最後に、誰もが気になる江島のモデルについて Afterword から引用させてもらって、感想を〆ます。

江島には特定の中身なんてなくて、状況を変えようと奮闘する人たちそれぞれの人にとっての分身なのだと思います。私たちは、この本の主人公が読者のみなさんの分身であって欲しいと思っています。
日本中の現場に、この本のようなお話が生まれることを願っています。今度は、あなたのお話を聞かせて欲しい。主人公はあなただ。(Afterword より)

2017-10-24

zlib を利用してデータを圧縮 / 展開するコマンドを作りました

productive Java command y2

zlib を利用してデータを圧縮 / 展開 *1 するコマンドを作りました。

github.com

書くこと

なにができる？
使い方
インストール
動機
まとめ

なにができる？

データを zlib で圧縮
zlib で圧縮されたデータの展開

これらをしてくれるコマンドです。

使い方

ファイルの圧縮

$ echo -n 'zlib' > decompressed.txt
$ zlib --compress < decompressed.txt > compressed.txt

圧縮ファイルの展開

$ zlib --decompress < compressed.txt
zlib

圧縮と BASE64 エンコード

$ echo -n 'zlib' | zlib --compress | base64
eJyryslMAgAEZAGy

展開と BASE64 デコード

$ echo -n 'eJyryslMAgAEZAGy' | base64 --decode | zlib --decompress
zlib

ヘルプ

$ zlib --help
zlib is row zlib compression commandline program.

usage: zlib [options]

  -c, --compress    compresses the input
  -d, --decompress  decompresses the input
  -h, --help        display this help
  -v, --version     display program version

インストール

Homebrew

$ brew tap ebc-2in2crc/zlibcmd
$ brew install zlibcmd

手動

https://github.com/ebc-2in2crc/ZlibCmd/releases からダウンロードした zip ファイルを展開した中にあるファイルを、パスの通ったディレクトリに入れる。

動機

zlib はほとんどのプログラミング言語がライブラリーを提供していますが、フロントエンドのツールが見当たらなかったので作りました。 *2

実装言語が Java なのは、書こうとしたときに「Java なら Inflater クラス使えば OK」と教えてもらったからです。書いているときはあとで Go で書き直すつもりでしたが、コンピュータ業界には Goを禁止 *3 している会社も少なからずあることを思い出し、これはこれで残すことにしました。

自分が扱うデータ量が少ないので、実行効率とかはあまり考えていません。

Ruby ならこんなに楽だった

#! /usr/local/bin/ruby

require 'zlib'

inz = Zlib::Inflate.new
STDIN.each { |line|
  puts inz.inflate(line)
}

まとめ

バグとかあると思いますし、「おそいよ！」とか「こーしたら使いやすくなる」とかあったら、イシュー作ったり声かけてもらえると嬉しいです。

ということで zlib コマンドの紹介でした。

*1:伸張

*2:プログラマーは自分でフロントエンドのコマンドを書いているのかも？あと、作ったあとに探したらずばりそのものがあった

*3:Go の開発環境だけなく、Go で作られた実行ファイルも禁止

2017-10-15

Eclipse Oxygen で SVN プロジェクトをインポートして Validate Repository Location operation failed になったときのメモ

Eclipse

Eclipse Oxygen の Subversive プラグインで SVN プロジェクトをインポートして Validate Repository Location operation failed になったときのメモ。

書くこと

環境
起こったこと
やったこと
参考にしたページ

環境

mac OS Sierra
Eclipse Oxygen (4.7.1a)
Subversive 4.0.5

起こったこと

SVN プロジェクトをインポートすると Validate Repository Location operation failed と表示され、インポートができない。

f:id:ebc_2in2crc:20171015002754p:plain

メッセージにしたがって Preferences > Team > SVN > SVN Connector タブの SVN Connector を確認すると、たしかに空欄になっている。しかし、GetConnectors ボタンからコネクターをインストールしても状況は変わらない。

やったこと

Help メニュー > Install New Software を選択して、Work with: 右の Add ボタンでリポジトリーを追加する。

f:id:ebc_2in2crc:20171015002838p:plain

Work with: で追加したリポジトリーを選択して必要なものをインストール。

f:id:ebc_2in2crc:20171016225105p:plain

これで SVN プロジェクトをインポートできるようになる。

参考にしたページ

stackoverflow.com