basyura's blog

あしたになったらほんきだす。

Redmine - 未完了バージョンの内容をメールする

Redmine のバージョンが放置プレイ。リリースされてるのかされてないのか分からないチケット群。

通常はリリース時に状況確認するのだけど、最近はリリース作業から離れていたので Redmine との関わりが薄くなっていた。お任せ状態にしてメンテは特にせず。気がついたら荒れ放題。うるさい Redmine おじさんは必要で、こまめにフォローとメンテをしないとダメだなと再認識。

自分が居なくなったらどうなるんだろこれ・・・みんな便利さは感じているようなのだけど・・・まあいいや。

実際にはちょっと違うけど (固有の処理が入っているので)、以下のようなスクリプトを jenkins で定期的に実行することにした。

# スクリプトと同じディレクトリに config.yaml を置いておくこと
#
# 例)
# url: http://xxx.xxx.xxx.xxx/redmine
# api_key: abcedfgabcedfgabcedfgabcedfgabcedfgabcedfg
# smtp: smtp.dummy.org
# from: dummy@dummy.org
# to:  sample@dummy.org
# subject: "Redmine から出荷状況のお知らせ"
# message: "直近 2 週間と過去の完了していないバージョンをお知らせします。"
#
require 'open-uri'
require 'json'
require 'uri'
require 'date'
require 'net/http'
require 'net/smtp'
require 'yaml'


def issue_id(issue)
  issue['id'].to_s.ljust(5)
end

def status_name(issue)
  issue['status']['name'].ljust(6)
end

def author_name(issue)
  issue['assigned_to']['name'].ljust(11)
end

config_path = File.join(File.expand_path(File.dirname(__FILE__)), 'config.yaml')
config = YAML.load(open(config_path, &:read))

src_url = config['url']
api_key = config['api_key']

url   = URI.parse(src_url + '/projects/1/versions.json?key=' + api_key)
json  = JSON.parse(open(url, proxy: false).read)
limit = (Time.now + 60 * 60 * 24 * 14).strftime("%Y-%m-%d")

buf = []

for version in json['versions'].select{|v| v['due_date'] != nil}.sort_by {|v| v['due_date'] }
  next if version['status'] == 'closed'
  next if version['due_date'] == nil
  next if version['due_date'] > limit
  buf << ''
  buf << sprintf("■ %s - %s〆 : %s", version['name'], version['due_date'], version['description'])
  buf << ''

  url_format = "%s/issues.json?fixed_version_id=%s&status_id=*&key="
  url  = URI.parse(sprintf(url_format, src_url, version['id'], api_key))
  json = JSON.parse(open(url, proxy: false).read)
  # 終了(5)が下に行くようにソート
  issues = json['issues'].sort do |a, b|
    if a['status']['id'] == 5
      1
    elsif b['status']['id'] == 5
      -1
    else
      a['status']['id'] <=> b['status']['id']
     end
  end

  closed = false
  for issue in issues
    if issue['status']['id'] == 5 && !closed
      buf << "  ---"
      closed = true
    end
    buf << sprintf("   #%s %s %s %s", issue_id(issue), status_name(issue), author_name(issue), issue['subject'] )
  end
end


Net::SMTP.start(config['smtp'], 25) {|smtp|
  smtp.send_message(<<-EndOfMail, config['from'], config['to'])
From: #{config['from']}
To: #{config['to']}
Subject: #{config['subject']}

#{config['message']}  

  #{buf.join("\n")}
  EndOfMail
}

メールが飛んで来ると Redmine おじさん作業を始め、メンテしろよコメントを入れていく。2 週間程度でようやくスッキリ。満足した。

ヘッドセットに USB コンバータをかますと音が良くなる

会社で使ってるヘッドセットなんだけど安いやつなので音が悪い。自分で聞く音も微妙だけど僕が話した声を聞く側も辛い音になる。あまり気にしてなかったのだけど頻繁に言われるので変換ケーブルをかましてみた。

結果、音が改善された。聞く音もノイズが無くなって喋る方も特に問題ないと言われるようになった。コスパかなり良い。良いヘッドセットを買うより良いかも。良かった良かった。

Buffallo 以外にもいくつか変換器があるのだけとまぁまぁ値段がするし、体感できるほど良くなるどころか悪くなる可能性もあるので保留。

iPhone の EarPods を使う場合はさらに変換コネクタをかます。音を聞くだけならこっちの方がかなりクリアに聞こえるのだけどマイクが周りの音を拾いすぎてダメダメ。聞くだけの時は EarPods で、喋る可能性がある場合はヘッドセットを使っている。

リモートワークしたいなぁ

当たり前にリモートワークできる選択肢が有るのと無いのとでは大違いだよなぁ、と (羨ましいの意)。もうずっと前からリモートワークを希望しているのだけど未だ実現ならず。トライアルが始まってるけど子育てとか介護などの "理由" がある場合だけ。

実際にリモートワークできたとして家環境はかなり大事そうだ。家ではミニテーブルに PC をのせて絨毯にクッションを置いて座りながらなので長時間はきつい。ソファーに持たれてやったりもするけどまぁまぁしんどい。座り込むんじゃなくてきちんとした椅子とテーブルが必要そうだ。

環境も大事だけど運動量が激減しそう。通勤の行き帰りでまぁまぁ歩くし、昼ごはんに出たりトイレに行き来するだけでもまぁまぁ歩く。家にいるとずっと座り込んでしまうし、歩くといってもしれてる。昼は外に出るとか合間に運動を入れるとかの考慮が必要そうだ。

メリットはもちろんある。第一に集中できる。第二に気兼ねなく気分転換や休憩ができる。これはでかい。合間に洗濯したりクリーニングを出しに行ったりすれば週末に溜め込まずに済む。夜飯の買い出しや準備もできればさらに良い。通勤電車に乗らなくて済むし雨に当たらなくて済むのもよい。

現在の状況を考えると週に 2 日ぐらいリモートワークできるとバランス良さそう。

まとめると、条件で優先するのはいいけど限定するのはただの不公平でテンションが下がるというただの愚痴の書きなぐり。

冷蔵庫を買い替え

何年前に買ったのか覚えてないけど冷蔵庫がブインブイン音を出し始めて辛くなったので買い替え。交換が決まると冷蔵庫が悟ったのか静になる不思議。10万以内、180L以内ぐらいで探したのだけど選択肢がほとんど無かった。180L を超えると値段が一気に跳ね上がって 15 万からだし、それ以上もざらにあって 40 万が並んでたりする。冷蔵庫ってこんなに高かったんだという驚き。一回買ったら最低 5 年は使うだろうし、通常はもっと使うだろうからサイクルを考えると値段が跳ねるのも仕方ない感はある。個人的に値段はもうちょっと高くてもいいのだけど、その分サイズがでかくなってしまう。このあたりがちょうど隙間になっていてユーザー層の狙い目な気もするのだが、高いのを買わせたいメーカーが右に習えしているのだろうか。BALMUDA あたりがトースターに続いてハイエンドな高機能中型冷蔵庫を出したりしないかなぁと期待。次に買い換えるのが何年後になるかは分からないけど。あと、こまめに冷蔵庫周りは掃除しないといけないことも悟った (かなり汚かった)。

git fetch は要らないと思っていた

リモートにある新しい資源が欲しいなら pull すればいいじゃん。fetch だけじゃ資源が置き換わらないから手間じゃん?そう思ってた。複数のブランチを頻繁に行き来するようになるまでは。

pull → fetch + merge
  • fetch ・・・ リモートから資源を取ってくる
  • merge ・・・ ローカルにリモートの資源をマージする。手元に変更がある場合はマージコミットが作られる。

こんな時に便利。

feature ブランチで開発していて 分岐元の最新資源に対して reabse したい場合。

  • わざわざ checkout 済みのブランチに切り替えて pull した後に元のブランチに戻る必要がない。

feature ブランチで開発していて分岐元や他のブランチの最新資源とのグラフを見たい場合。

  • わざわざ checkout 済みのブランチに切り替えて pull した後に元のブランチに戻る必要がない。

feature ブランチで開発していて別のブランチの資源やログを見たい場合

  • わざわざ(略

ということで、fetch べんり。

リモート追跡ブランチは、リモートブランチの状態を保持する参照です。 ローカルに作成される参照ですが、自分で移動することはできません。ネットワーク越しの操作をしたときに自動的に移動します。 リモート追跡ブランチは、前回リモートリポジトリに接続したときにブランチがどの場所を指していたかを示すブックマークのようなものです。
Git - リモートブランチ