読者です 読者をやめる 読者になる 読者になる

production.log

ピクスタ株式会社でエンジニアのマネージャーをやっている星直史のブログです。

シリコンバレー式 自分を変える 最強の食事のランニングコストを極限まで落とす方法 コーヒー編の更新

ダイエット

概要

以前の記事(シリコンバレー式 自分を変える 最強の食事のランニングコストを極限まで落とす方法)で全体的にコストを下げる方法を書きましたが、今回はコーヒー編でアップデートがあるので、その紹介をします。

前回紹介したスペシャリティーコーヒー

前回紹介した記事では1kg 3,126円 => 一杯15gあたり45円前後となります。

今回見つけたコーヒー

今回見つけたコーヒーはこちらです。

もちろんスペシャリティーコーヒーです。 品質管理を厳格にしているスペシャリティコーヒーでなければならないのは変わりません。

価格も1.3kg 2,268円です。量が多くなっている上に価格まで安い(!) 一杯15gあたり26円前後になります。

まとめ

これまで紹介した小川珈琲, パオコーヒー, 澤井珈琲を比較してみます。

名前 一杯あたりの価格
小川珈琲 75円
パオコーヒー 45円
澤井珈琲 26円

今回したコーヒーは小川珈琲と比較すると、66%も安くなります。

自分が実践しているタスク管理の方法を紹介

その他

背景

会社のメンバーが、タイムマネジメント(個人のタスクの管理とか優先度付け)の方法について困っていたので、自分がどうしているのかまとめてみようと思った。

オレ流タイムマネジメントの概要

自分の脳内メモリは有限であり

  • シングルスレッドで動きたい(作業中は他のことを考えたくない)
  • 作業中のタスク以外のことは、なるべく自分の頭から隔離させたい(他に任せられるならブン投げたい)
  • 新たなタスクがきた場合のルールが明確である
  • タスクスイッチする時のルールが明確である

という思想の基、辿り着いたやりかた。

用意するもの

Trello 個人レベルならこれで十分やろ!

実際の手法

0. Trelloに下記Listを作成する

  • あとでやる
  • 次にやること
  • 急いでやるべきこと
  • 誰かにお願いしている / 待っているもの
  • 特定の日付にやるもの

1. タスクが降ってきたら迷わずTrelloに突っ込む。

  • その際、どのListにいれるべきかを考えてる。
  • Listの中にすでに存在する場合は、線形探索で優先度を決める。

2. 実際タスクの実行の優先度

2-1. 各リスト(横軸)の優先順位

特定の日付にやるもの >= 急いでやるべきこと >>>>>>>>>>>>>>>>>> 次にやること >>>> あとでやること

といった感じ。

特定の日付にやるもののうち、その特定の日付が開始日であって、締め切りまで期間があるのであれば、急いでやるべきことや、次にやることに移し替えている。 また、誰かにお願いしている / 待っているもの についても同様。自分にボールが移ったら優先度を決定する。

あとでやることに関しては、自己研鑽系のものが多い。

  • 個人プロジェクトを進める
  • 読書
  • ブログ書く
  • 英語学習

などなど。 また、あとでやることを意識して実行しないと、目の前のタスクをただこなすマンになってしまい、思い描いた成長につながらない可能性があるので、気をつける。

2-1-1. 誰かにお願いしている / 待っているもの について補足

誰かにお願いする系のタスクは、なるべく早く、相手に渡すことを意識する。 なぜなら、クリティカル・パスを短くすることに努めるべきだからだ。 自分の場合、相手が待っているタスクのボールを持っている場合、高確率で優先度高にして、処理をしている。

2-2. リスト内(縦軸)の優先順位

必ず上から順番にタスクを実行する。
これをしないと、どっからやろう….って考えてしまうので、タスクをスイッチするときに無駄な判断をしてしまうからだ。

3. その他

上司から依頼されたタスクについては、期待値のすり合わせをする。 ここでいう期待は、納期の話。いつまでに欲しいかを確認する。 そうすることで

上司「これよろしく〜(今日中に終わんだろ)」
自分「わかったやで〜(ヌルゲーだし、明日でええやろ)」

== 定時を迎えたころ ==
上司「終わった?」
自分「えっ」
上司「えっ」

みたいな事がなくなるからだ。

あと、上司からの依頼はなるべく、こまめに進捗の速報を伝える。

マネージャーを経験したことがある人ならわかると思うけど、相手に納期付きのタスクを任せた場合、何日経っても音沙汰がないと、とても不安になるからだ。
※特に、新人、アルバイトさん、一緒に仕事をしてから間もない相手などなど…

自分がタスクをお願いされたときも必ずこれを意識している。

まとめ

やりかたはこれだけ。
考え方としては、タスクがふってきたら、外部(Trello)に流し、無駄なことを考えないようにする。
そのために、カテゴリと優先度を決まったフレームワークで処理することによって、脳内メモリ消費を抑える。
あとは、仕事でも私生活でも同じツールとかやりかたを使うと早く身につくし、効率的に動くことができる。

ファイル内の改行を置換するコマンド

メモ その他

2ファイル間で重複する / しない 行を出力する方法
こちらの操作をするときに、セットで、ファイル内の改行を置換するコマンドを調べることがあるので、
メモ程度に残しておく。

$ cat hogehoge.text
1
2
3
4
5

上記のファイルを1,2,3,4,5と出力したい場合のコマンド

cat hogehoge.text | sed -e :loop -e 'N; $!b loop' -e 's/\n/ /g'

2ファイル間で重複する / しない 行を出力する方法

メモ その他

タイトルの通り、何気に結構使う処理だけど都度調べているからメモとして残す。

a.text と b.textが以下の内容の時、1と 2,3,4,5を出力したい場合

$ cat a.text
1
2
3
4
5

$ cat b.text
2
3
4
5

$ sort {a,b}.text | uniq -u # ユニークな行を出力
$ sort {a,b}.text | uniq -d # 重複行を出力

Fitbit Charge HR™を購入して一年経過したので使用感をまとめてみる

その他

概要

Fitbit Charge HR™を購入して一年経過したので使用感などをまとめてみようと思います。

Fitbit Charge HR™とは

ワイヤレス心拍計 + 活動量計リストバンド ChargeHRで生活のリズムを感じよう。手首に巻くだけで継続的・自動的に心拍数とアクティビティをトラッキング。心拍数は1日中記録。トレーニング中のより正確な消費カロリーを知り、目標トレーニング強度の達成をサポート。トレーニング時間を最大限に活用できる。歩数・距離・消費カロリー・アクティブな時間・階段を使って上った階数を記録。OLEDディスプレイで目標への進捗状況や同期中のスマートフォンへの着信をリアルタイムで確認。一日の終わりには睡眠中の動きを自動で計測。朝にはサイレントアラーム(バイブレーション)でやさしく起こしてくれる。ワイヤレスでスマートフォンやパソコンと同期して、目標達成へのモチベーションをアップ。健康な体は心から。

ごっそり引用してきましたが、Fitbitをつけると下記のことがトラッキングされます。

  • 時間
  • ストップウォッチ
  • 脈拍
  • 消費カロリー
  • 歩数
  • 歩行距離
  • 登った階段の段数
  • 睡眠傾向

またダッシュボードでは下記の項目などを可視化してくれます。

  • 摂取カロリー
  • 睡眠の傾向
  • 運動量推移
  • 摂取水分量

ここは良かった事

1年使用して良かったところを紹介していきます。

電池の持ちが良い

購入時に色々なウェアラブルバイスと悩んだのですが、電池の持ちが良いのはかなり大きいと思います。 公式ではフル充電から5日間使用可能とありますが、だいたいあっています。 これは1年経過した後もバッテリーの劣化などは感じられず、気になったら充電というレベルです。

また、5日間はお風呂以外の時間は寝ている時間も含めて装着できるので、めんどくさがりには最適だと感じました。

ストップウォッチが結構便利

Fitbitについているボタンを長押しするとストップウォッチになるのですが、この機能を使うシーンが結構ありました。 スポーツをしている時はもちろんですが、 たとえば、ミーティング時に「3分考える時間をとります」というシーンでも使えるので、結構便利でした。

1万歩歩くと謎の達成感がある

1万歩歩くと、バイブレーション機能が作動し、ブルブル震えて"Congratulations"と表示されます。 ただそれだけの機能ですが、結構嬉しかったりしますw
ちなみに、1年間で1日の最高歩数は3万歩でした。

ここは使ってるうちにやらなくなった事

購入当初はやっていたのですが、次第に使わなくなった機能などを紹介します。

摂取カロリーの入力

ダッシュボードで食べたものを入力すると摂取カロリーがわかるので、消費カロリーと合わせて、カロリー収支を教えてくれる機能があるのですが、 食べたものを入力するのが物凄くめんどくさくてやめてしまいました。

食品データベースや、入力補助機能自体は結構優秀なのですが、 さすがに1日に食べる食品数が多すぎて途中で入力を諦めてしまいました。

同様に、水分量の入力もめんどくさくてやめてしまいました。

Fitbit装着による運動のモチベーションが上がらない

最初はモチベーションがあがってました。 運動開始時にストップウォッチスタートして、心拍数とか計りながらランニングする...とか。

が、数ヶ月もすると、電気毛布にくるまりながら、ポテチ食べてネットをする毎日になってしまいました。

購入時の運動系機能に対する動機が興味でしかなかったので、今はぶっちゃけ時計の機能しか使っていません。 次に腕時計を買うなら機械式とかのアナログ時計を買います。

ここは悪かった

1年間使っていれば、悪い面も見えてきたのでそれも紹介します。

壊れた

購入から11ヶ月目にいきなり壊れました。 5分に1回再起動し、時間が同期されず、1時間に7分もズレが生じる有様でした。

ただ、サポートに連絡したところ1時間後に新品を送ってくれる旨の連絡がきました。 今手元にあるやつはそのままで良いとのこと! しかも、最新バージョンを送ってくれるとのこと!

サポートは神対応でした!

外装が剥がれてくる

ウェアラブルバイスだと思いますが、基盤を隠蔽するためのシリコン素材が剥がれてきます。 単純に経年劣化だと思いますが、知り合いのFitbitも同様の問題があったので、1年でこれは結構チープな作りなのだなぁと思いました。

瞬間接着剤を使えば元通り問題なく使えるのですが...。

睡眠のトラッキングがあてにならない

自分は寝返りをよくうつタイプなのかわからないのですが、 実際は7時間寝ていても毎晩3時間程度しか眠れてないようなトラッキングになってしまいます。

こればかりはよくわからないのですが、「よく眠れていますか?」とFitbitから聞かれると、余計な御世話だ!!と思ってしまいます。

装着してなくても消費するカロリー

Fitbitは消費カロリーもトラッキングしてくれます。 購入当初は、脈拍、歩数、階段、移動距離から消費カロリーを算出してくれているのだと心底感動していたのですが、 ある日、装着を忘れて1日を過ごし、帰ってきてから同期をしたら、装着していないのにもかかわらず、1,800kcal消費したことになっていました。 基礎代謝の分かもしれませんが、これにはがっかりしました。

まとめ

振り返ってみると、ネガティブな印象の方が多いなぁといった感じです。 運動系のトラッキング機能について、興味本位で買ったのですが、あっという間に飽きてしまいました。 おそらく、どのウェアラブルバイスを使ったとしても、すぐ飽きるのではないかと思います。

ただ、トラッキングの精度があまり良くないと感じたのと、作りがチープで購入1年以内に壊れているので、 長くは使えない事を念頭に置いた方が良いかと思います。

@t_wada さんの「Mac の開発環境構築を自動化する (2015 年初旬編)」をAnsible ベストプラクティスに則り書き換えてみた

Ansible Mac インフラ周り

概要

t-wada.hatenablog.jp

Ansibleでmacの環境構築する際、id:t-wada さんの上記の記事を参考したのですが、 Ansible Best Practicesに沿っていなかったので、書き直してみました。

Ansibleを動かすまで

こちらは、t_wadaさんの記事のままです。

sudo xcodebuild -license
xcode-select --install
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew doctor
brew update
brew install python
brew install ansible

どこを直したのか

twada/macbook-provisioning

hoshinaoshi/macbook-provisioning

本家とforkしたリポジトリを比較しながら、修正した点を挙げていきます。 階層構造も修正しています。

【本家】

.
├── LICENSE
├── README.md
├── hosts
├── localhost.yml

【修正後】

.
├── LICENSE
├── README.md
├── ansible.cfg
├── group_vars
├── hosts
├── localhost.yml
├── roles
│   ├── homebrew
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   │       └── main.yml
│   ├── homebrew-cask
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   │       └── main.yml
│   ├── oh-my-zsh
│   │   ├── defaults
│   │   ├── files
│   │   ├── handlers
│   │   ├── meta
│   │   ├── tasks
│   │   │   └── main.yml
│   │   ├── templates
│   │   └── vars
│   └── ricty
│       ├── defaults
│       ├── files
│       ├── handlers
│       │   └── main.yml
│       ├── meta
│       ├── tasks
│       │   └── main.yml
│       ├── templates
│       └── vars
└── site.yml

*1

site.ymlを作成し、localhost.ymlをinclude

ベストプラクティスではsite.ymlをmaster playbookとします。 また、プロビジョニング対象の役割(production, stagingなど)ごとに実行するroleをまとめたplaybookも作ります。 今回はlocalhost.ymlのみですね。*2

これらのファイルはroleをincludeするだけに留め、ここに細かいタスクを書いていくことはしません。(後述)

ロールの割り振り

元々のlocalhost.ymlのタスクは大きく4つの処理をしています。

  • homebrew
  • homebrew-cask
  • oh-my-zsh
  • ricty

今回はローカル環境のみが対象ですが、複数のプロビジョニング対象があった場合に、個別に差し込めるようにするため、 これらのタスクをrolesディレクトリ配下にそれぞれの役割ごとに分割します。 directory-layout

loclhost.ymlに列挙された変数を各ロールに振り分ける。

loclhost.ymlにhomebrew_taps, homebrew_packages, homebrew_cask_packagesの3つが定義されていましたが、 これらはhomebrewとcaskで使用するので、

  • ./roles/homebrew/vars/main.yml
  • .roles/homebrew-cask/vars/main.yml

に記述します。

./roles/hogehoge/vars/main.ymlに変数を記述すると
./roles/hogehoge/tasks/main.ymlの実行時に自動で変数を読み込み、タスク内で使用することができます。

localhost.ymlに記述されているhandlersはricty用なので、ricty/handlers/main.ymlに移動

localhost.ymlに記述されているhandlerは、よく見るとRicty用の処理であるため、Rictyロールのhandlerとして定義します。 こちらは、varsと同様にhandlerも同role内のhandlerディレクトリに記述していれば、notifyをした際に呼び出されます。

- name: run fc-cache
  shell: fc-cache -vf

localhost.ymlでtasksとして記述された内容をroleに任せる。

これらのファイルはロールをインクルードするだけに留め、ここに細かいタスクを書いていくことはしません。(後述)

ここまでの書き換えで、各ロールにvars, tasks, handlerを分けることができたので、 localhost.ymlではロールをインクルードするだけにします。

---
- name: Setup my MacBook
  hosts: localhost
  connection: local
  gather_facts: no 
  roles:
    - { role: homebrew,      tags: [ homebrew ] }
    - { role: homebrew-cask, tags: [ homebrew-cask ] }
    - { role: oh-my-zsh,     tags: [ oh-my-zsh ] }
    - { role: ricty,         tags: [ ricty ] }

だいぶスッキリしましたね。

また、tagを切っておくと、指定したタグだけ実行 / 指定したタグをスキップなどができるので、追加しておきます。 ansible-playbook site.yml --tags "homebrew,ricty" ansible-playbook site.yml --skip-tags "oh-my-zsh"

playbook実行時の引数を極力減らせるように設定

HOMEBREW_CASK_OPTS="--appdir=/Applications" ansible-playbook -i hosts -vv localhost.yml

実行時にhostsの設定をしたり、HOMEBREW_CASK_OPTSを設定したりするのはめんどくさいので、

ansible.cfgを作成し、デフォルトの動作を設定をします。

[defaults]
hostfile = ./hosts

環境変数については、homebrew-caskのタスクの一部として実行するようにします。

- name: HOMEBREW_CASK_OPTS設定
  shell: export HOMEBREW_CASK_OPTS="--appdir=/Applications"
...後続の処理がずらずら〜

ここまでの設定で、実行時のコマンドが HOMEBREW_CASK_OPTS="--appdir=/Applications" ansible-playbook -i hosts -vv localhost.ymlansible-playbook -vv site.yml となりました。 シンプル!

まとめ

以上でAnsible ベストプラクティスを適用した、Mac の開発環境構築を自動化する (2015 年初旬編)です。

"mac ansible"などで検索すると、localhost.ymlにtasksがばーーーーーっと書かれたplaybookをよく目にする印象があります。

複数のプロビジョニング対象が存在する場合は、ベストプラクティスが有効だと思いますが、 構築する対象がローカル環境のみで、処理(や、ロール)が少ないのであれば、1ファイルにゴリゴリ書いても良いのではないかと感じました。

ただ、実際は、開発スタートをするまでにrbenvの設定をしたり、ミドルウェアの設定をしたりなんだりすると、localhost.ymlが肥大化してしまうのではないかと考えられるため、早め早めにロールだけでも分けて記述するのが落とし所かと思います。

こちらにコードを置いておきます。
https://github.com/hoshinaoshi/macbook-provisioning

今回Ansibleを初めて触ってみたのですが、ymlで書くのが地味に楽でした。
Ansibleの処理も「Ansible {{やりたいコマンド}}」で検索 => 1つ目の記事ではい理解〜というような感じでした。
自分は、初めての技術に触れるときは、初心者用の書籍を購入して、一読するのですが、Ansibleにおいては下記の書籍を買いました。

*1:中身が空のディレクトリは削除しても良いかも

*2:通常は複数のサーバーに対して行うので、若干無理矢理感がありますね

Rubyで使われるコロンの意味を調べてみた

Ruby

概要

Rubyを初めて触ったときに、(当時の自分が触っていた)C#JAVAではコロンが使われておらず、 これはどのような意味なのかがよく話からたかったので、まとめてみました。

:symbol
"symbol"

こちらの違いについてまとめます。

Rubyにおけるコロンの意味とは?

Rubyにおけるコロンは、シンボルといいます。

:symbol 一見文字列と同種に見えるが、内部的には数値として扱われます。 そのため、比較や検索などの速度面が文字列と比べると高速になります。

  • ハッシュのキー
  • メソッドの引数として渡すクラス名、メソッド名、変数名、定数名

などについては、はシンボルを使用したほうが良いでしょう。

リファレンスでは

リファレンスを引用します。

Rubyの内部実装では、メソッド名や変数名、定数名、クラス名など の'名前'を整数で管理しています。これは名前を直接文字列として処理するよりも 速度面で有利だからです。そしてその整数をRubyのコード上で表現したものがシンボルです。 シンボルは、ソース上では文字列のように見え、内部では整数として扱われる、両者を仲立ちするような存在です。 名前を管理するという役割上、シンボルと文字列は一対一に対応します。 また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。

文字列と見せかけて、内部の実装では整数として扱っている。といったところでしょうか。

検証してみた

> Rubyの内部実装では、メソッド名や変数名、定数名、クラス名など の'名前'を整数で管理しています。

つまり、メソッド名や変数名、定数名、クラス名を定義した瞬間にシンボルができるという意味です。 実際にやってみましょう。

class SymbolTest
end

symbol_var = 0

SYMLBOL_CONSTANT = 0

def symbol_method
end

p Symbol.all_symbols.include?(:SymbolTest)
=> true

p Symbol.all_symbols.include?(:symbol_method)
=> true

p Symbol.all_symbols.include?(:symbol_var)
=> true

p Symbol.all_symbols.include?(:SYMLBOL_CONSTANT)
=> true

見事に全てtrueを返しましたね。

> これは名前を直接文字列として処理するよりも 速度面で有利だからです。

文字列と数値なので、そりゃ高速になるだろうと反射的に思いましたが、こちらも検証してみます。

benchmarkというモジュールを使用して計測してみます。 実際のやり方はこちらを参考にしました。 Ruby でベンチマークを取る方法 - Qiita

require 'benchmark'

Benchmark.bm 10 do |r| 
  str = "0123456789"
  str_hash = { "0123456789" => 1 }
  r.report "String" do
    9999999.times { str_hash[str] }
  end 

  sym = :"0123456789"
  sym_hash = { "0123456789" =>  1 }
  r.report "Symbol" do
    9999999.times { sym_hash[sym] }
  end 
end

                 user     system      total        real
String       1.190000   0.000000   1.190000 (  1.190577)
Symbol       0.810000   0.000000   0.810000 (  0.815450)

文字列に比べて、シンボルは30%前後早くなっていますね。 すごいぞシンボル。

> 名前を管理するという役割上、シンボルと文字列は一対一に対応します。 また、文字列と違い、immutable (変更不可)であり、同値ならば必ず同一です。

同じ名前のシンボルであれば、いくつ生成してもオブジェクトIDが1つという意味ですかね。

hoge1 = "hoge"
hoge2 = "hoge"
puts hoge1.equal?(hoge2)
=> false

puts hoge1.object_id
=> 70281989413340

puts hoge2.object_id
=> 70281989361520

sym1 = :hoge
sym2 = :hoge
puts sym1.equal?(sym2)
=> true

puts sym1.object_id
=> 539048

puts sym2.object_id
=> 539048

こちらもリファレンス通りですね。

まとめ

冒頭でも書きましたが、Rubyにおけるコロンは、"シンボル"と呼びます。 一見文字列と同じように見えますが、内部的には整数と同様に扱われます。 そのため

  • 文字列と比較すると処理が高速
  • 同じ値であれば、生成されるオブジェクトは1つ。

また、クラス、メソッド、変数、定数を定義すると、その名前のシンボルも生成されます。

文字列とシンボルの使い分けとしては、

  • ハッシュのキー
  • メソッドの引数として渡すクラス名、メソッド名、変数名、定数名

などは、文字列ではなく、シンボルを使用したほうが良いでしょう。

こちらの本はRubyについて、今でもリファレンス的に使用している本なので、オススメします。
※今回のシンボルについては、ここまで詳細には書かれていませんが、全範囲を網羅的に書かれています。