Fig(docker Compose) で Rails する

追記

この内容は古いです、というか fig で建てるところまではコレでイケルと思いますが、実際には自分で fig で開発してないです。
フォルダの同期が以上に重たく、そのせいで rails console や server とかしても実用に耐えられないレベルのパフォーマンスしか出ないからです。
おそらく sync ディレクトリを変える、 rsync で送る、 イイ感じに出来たら pull する仕組みを創るなどすれば、うまくいくとは思いますが、
localhost での開発に慣れている場合、それはただの時間の浪費としか思えないと思います。
現在では開発環境として扱うのは難しいという判断に至りました(当然個人の感想です)。
参考までにrsync の記事も参照されると良いかもです。

メモ

ちなみに、 現在では、 fig は docker-compose になっている。
が、それに気づかず しばらく fig で進めた。

fig で rails は tutorial 通りでは動かなかった。
基本は tutorial にそってやったが、boot2docker 経由でやる場合に、
binding のあたりで、container 内からは呼べるけど、 boot2docker の中から呼べなくて、
その辺を修正した。
ちなみに、 postgresql がサンプルになっていたが、 mysql でやりたかったので適宜変更した。

fig.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
db:
  image: mysql:5.6
  ports:
    - "3306:3306"
  environment:
    - MYSQL_ROOT_PASSWORD=hogehoge

web:
  build: .
  command: bundle exec rails server --port=3000 --binding=0.0.0.0
  volumes:
    - .:/myapp
  ports:
    - "3000:3000"
  links:
    - db

fig run web rake db:create db:migrate

なぜか mysql に繋げなくなるパターンがあったが、
docker images でだした image を docker rmi で全て消してやり直したり、
それでも微妙だったので、 fig run db mysqld とかするといい感じになった。

所感

fig でやれたらよかったと思ったので、ちょっと時間がかかったけど、うまくできそうでよかった(小並感)

楽天カード(e-NAVI)の現地利用額(為替レート)は翌月12日まで照会できない

楽天カード(e-NAVI)の現地利用額(為替レート)は翌月12日まで照会できない

タイトルの通りであるのだが、電話で問い合わせたところ、
システム的に翌月になるまで照会が出来ないとのこと。
もし同じ要求がある人がいたら、翌月12日まで待つしかないので諦めよう。

Mac 開発環境 Setup 2015

新しい mac を手に入れた時にすること

これが非常に良さそう なので、一旦自分用に考えてみる。

気をつけるべきこと

  • 一番最初のセットアップ時に、 firevalut にチェックを入れるかどうか
  • 入れないほうがセキュリティ的にはどうかと思うけど、なんか変なハマり方しなくて良さそう

準備

あらかじめ Brewfile を作っておく

  • brew install rcmdnk/file/brew-file
  • この後使用するコマンドが依存している python ライブラリを入れる必要がある
    – sudo easy_install pip
    – pip install requests
    – brew file init vimtaku/Brewfile
    – あとは手順にしたがってすすめると push とかいろいろやってくれる

手順

xcode のインストール

1
xcode-select —install

homebrew のインストール

1
2
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew doctor

Brewfile からインストール

1
2
3
git clone https://github.com/vimtaku/Brewfile.git
cd Brewfile
brew file -f Brewfile install

homesick のインストール

ちょっと違うかも。

1
2
3
4
5
/usr/local/bin/zsh
gem install homesick
rbenv rehash
homesick clone vimtaku/dotfiles
homesick link
mac

GTD テンプレート

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

# Inbox

----
# 行動を起こす必要があるもの

## カレンダー
Google カレンダー参照

## 次に取るべき行動のリスト
### @会社
### @自宅
### @電車
### @暇

## 連絡待ちリスト

## プロジェクトリスト
### プロジェクトA
### プロジェクトB

## プロジェクトの参考情報

----
# 行動を起こす必要がないもの

## ゴミ箱

## 保留
### いつかやる・多分やるリスト

## 資料

----------------------------------------
# GTD の処理方法
1. 収集
-- トリガーリスト
2. 処理
-- ワークフローにしたがって振り分ける
3. 上記の行動を起こす必要があるもの(カレンダー、次に取るべき行動のリスト、連絡待ちリスト、プロジェクトリスト、プロジェクトの参考情報)と行動を起こす必要がないもの(ゴミ箱、保留、資料)
4. レビュー
5. 実行

# プロジェクトプランニング
プランニングについては、考える必要がないもの以外では、以下のとおりに進めると良い。
## 目的と価値観を見極める
## 結果をイメージする
## ブレインストーミング
## 整理
## 会議
## 情報収集
## 次に取るべき行動を判断

# 週次レビューの方法
基本的なレビューは随時行う。週次レビューは週に一度時間をとって行う。  
以下にそのまま項目を引用しておく。
## 雑多な紙類を集める。
## 処理を行う
## カレンダーのチェック(過去)
## カレンダーのチェック(未来)
## 頭のなかにあるものを出す
## プロジェクトリスト及び大きな目標のレビュー
## 「次に取るべき行動リスト」のレビュー
## 連絡待ちリストのレビュー
## プロジェクト候補のチェックリストのレビュー
## いつかやる・多分やるリストのレビュー
## プロジェクトの参考情報
## 創造的、かつ大胆に考える
gtd

GTD の本を読んだ

GTD の本を読んだ

この本

本の内容

大体読んだらわかることなんだが、
- http://w.browndots.net/20131008/task-management/gtd/restarttogtd12/
- http://postd.cc/gtd-in-15-minutes/
この辺によくまとまっているのでそちらを参照してもらうと良いかも。

所感

僕の尊敬するとある人が、GTD やってますと言っていて、それから何年も経つがやってみたいと思ったので、
本を買って読んでみたがとても良さそうに感じた。
頭のなかを一つのシステムに書き出すことによって、それについて考える時間が増えた実感があるし、
やるべきことが可視化されることは非常に良いと思った。あとは週次レビューをどう組み込むかかなぁと思った。

自分の場合どのような方法で実践するか

ツール

vim(qfixhowm のメモ) + dropbox でやる

これについては基本的に markdown で見るのが一番自分らしく、わかりやすいので markdown で管理する。
週次レビューについては、毎週金曜か土曜日に時間をとってやるのが良いと思った。

紙とマインドマップ

基本的には IT の仕事なので紙とマインドマップと vim があれば大丈夫かと。

qfixhowm のメモを dropbox のやつで見た時 iphone から見れるようにするやつ

がほしいのでどっかでつくる。

とりあえずでテンプレート作ってみた

http://vimtaku.github.io/blog/2015/02/18/gtd_template

gtd

金はチケットである

金はチケットである

金はチケットだ。
美味しいものを食べたり、サービスを受けるための交換手段である。
金はあればあるほどよい。より良いサービスを受けられるからだ。
ただ、金がそこにあるだけで幸せなのかというと、たぶんそうじゃあないと思う。

金の入力

金はどこからくるのだろう。
今日食べたご飯や、受けたサービスは、金を使って得られたものだ。
自分の場合、基本的には、金は会社から得られたものである。
会社はなぜ自分に金を払うのだろうか。
それは自分が、会社にサービスを提供した(もしくはするという契約を結んだ)からである。
富を創りだせるからこそ、金を払うのである。

金を手にすることは困難だろうか。
確かにそれは難しいことではある。
ただ、価値を提供できれば、それ相応の金を得られるはずだ。

単純に、金を稼ぐことは楽しい。
サラリーマンをやる上でも、給料が上がらないというのは面白くない。

富を創ること、が、完全に金に結びつくかはわからないが、
富を創ることで、お金をいくらでも得られるのだとかんがえると、
人生はいかに楽しいものかと思う。

現状の金の入力に満足出来ないなら、
自分が価値を提供できていないのだと振り返ることができるはずだ。
価値を生み出せるはずだと信じて、富を創る行動を始めたら良いと思う。

金の出力

金を使うのは簡単だ。
金は使えばすぐに無くなる。
サービスは、その相互の関係において値段が付けられる。

そういう意味で、納得出来ないサービス(買い物)はすべきでない。
そしてまた、納得出来ない価格(給料)でサービス(仕事)すべきでもないはずだ。

金とサービス

単純に、金を使うのは楽しい。
一般的に、良いサービスほどお金がかかる。
そういう意味で、金はチケットだと思う。

いつも行っている美容室で、普段髪を切るのに 3000 円かかるとしよう。
たまたまその美容室が混んでいて、どうしても髪を切りたいあなたが
たまたま入ったおしゃれな美容室は、すぐに髪を切ってくれて、 6000 円だったとしよう。
それでいつもよりクールな髪型になるんだ。

より良いサービスにはお金がかかる。
あなたはより良いサービスを受けたいと思う。
それにはチケットが必要なのだ。
(蛇足ではあるが、普段のサービスを受けるためにもチケットは必要である。)

金と価値感

一度良いサービスを受けてしまうと、元のサービスに戻るのが耐えられないと言うのは真実だと思う。
自分が富を創ることでお金を入力し、自分が良いと思うものにお金を出力する。
すごく自分勝手に聞こえるかもしれないが、日常の支出をメタに書いただけである。

金をどう使うかは、その人の価値観に依存する。
良いサービスを知らない、受ける必要がないなら、お金を稼ぐ必要がない。
断捨離というやつかもしれない。
仏教的に、ただ生かされているんだというロックで生きるならそれで良い。
自分は仏教的な考え方にはある種賛成だけど、それを楽しむなら人生長すぎると思う。
だから現時点では、仏教的考え方もあるなぁと思いつつも、
精一杯富を創る(サービスを提供する)ことに全力を注ぎたい。

自分が金を出力して受けたいサービス

振り返ってみると、基本的に自分が受けたいサービスは、音楽と勉強と食事と服と程よい住まいだ。
より良い音楽を楽しむ方法にはお金をかけてみたいし、
より自分がよく価値を提供できるように勉強(主により良い本をよんだり)したいし、 より美味しいものを食べて(いたい|みたい)し、
自分が着たいと思った服を着たいし、
自分が便利だ!、と感じるところに住みたい。
逆にいうと、ちょっと考えたくらいだったらこんなもんなのかと思う。

富として生み出したい、金以外の価値

金はチケットであればあるほどよいが、富を創ることで金以外に得られるものは、本質的には金より重要だ。
富を創るために時間を使うのは、自分の価値観では、とても有意義なことである。

所感

ふとポエムを書きたくなったので書いた。
ハッカーと画家を読んだせいで、最近のポエム熱がやばい。
おそらくこの文章も富である。
ただこの文章にお金を払う人がいないだけだ。
そういう意味で、文章を書き続ける(ブログ他)ことは、
富を生み出す行為だと思う。

ふとどうでもよいことを思ったが、仏教をロックと割り切るなら、この文章もロックであるはずだ。

さくらvps に CoreOS を入れる

さくらvps に CoreOS を入れる

基本的には http://qiita.com/yujiod/items/dc154120c4df2e938111 に従ってやれば行ける。

ただ、自分は VirtIO を ON にしたせいか、
ネットワークの設定のところで、

1
2
[Match]
Name=ens3

となっているところの ens3 は eth0 にしないと繋がらなかった。
(cloud-config も同様)

所感

英字キーボードを久しぶりに打ったけど慣れてないのでめちゃくちゃ辛かった。
何もはまらなければすぐできるとは思うけど、
普通にダウンロードとか調査とか考えたら1時間くらいかかると思う。

vps

Boot2docker 内に立てた Datomic Transactor + Peer のコンテナに対して、mac の Lein Repl で Datomic を操作する

boot2docker 内に立てた datomic transactor + peer のコンテナに対して、mac の lein repl で datomic を操作する

下準備(docker image の作成)

ここに Datomic の Dockerfile があった
ので、datomic の version は違うが修正したら、使えるだろうと思ってたら、使えた。

最終的な Dockerfile は こちら。 これを元に build する。

1
docker build -t datomicfree .
1
docker exec -ti {container_id} /bin/bash

などとして、デバッグしたりした。

実行環境の説明

MacbookPro -> boot2docker(vagrant) -> docker container
という構成になっている。

docker container 起動

最初、 boot2docker の vagrant の割り当てメモリが小さすぎて、 datomic が立たなかったので、
一度 vm を停止してから、割り当てを変更して

1
docker run -p 4334:4334 -p 4335:4335 -p 4336:4336 -m 512m -t-i datomicfree

などとすることで、うまく起動した。
結局、 port foward は 4334 だけで良いと思ったがそれだけではダメなので注意。

1
2
ssh -L 4334:localhost:4334 -L 4335:localhost:4335 -L 4336:localhost:4336 docker@localhost -p 2022
(password: tcuser)

lein repl

あとは repl から操作するだけ。

1
2
3
(def uri "datomic:free://localhost:4334/test")
(d/create-database uri)
(def conn (d/connect uri))

あとは先ほどの Dockerfile のリンクにもあるので、そちらを参照のこと。

所感

ちょっとハマったけど、これができたのは大きい。

If You Test Using realm.io Object, You Should Use RLMRealm.inMemoryRealmWithIdentifier

TOC

In test, You should use inMemoryRealmWithIdentifier

If you test using realm.io object, you should use RLMRealm.inMemoryRealmWithIdentifier.
I don’t know why, but I got error many times when I wrote some unit test by using realm.
The error is “swift_dynamicCastClassUnconditional”.
I struggled a lot, finally I got a solution.
First of all, below is my code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import Foundation

class FMUserCredential: RLMObject {
    dynamic var accessToken :String = ""
    dynamic var refreshToken :String = ""
    
    // 代替案
    private struct ClassProperty {
        static var _realm:RLMRealm? = nil
    }
    
    // Computed Property
    class var _realm: RLMRealm? {
        get {
            return ClassProperty._realm
        }
        set {
            return ClassProperty._realm = newValue
        }
    }
    
    class func realm() -> RLMRealm {
        if (FMUserCredential._realm == nil) {
            let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0] as String
            let realmPath = documentsPath.stringByAppendingPathComponent("db25.realm")
            let realm = RLMRealm(path:realmPath, readOnly:false, error:nil)
            FMUserCredential._realm = realm
        }
        return FMUserCredential._realm!
    }
    
    class func findAll() -> RLMResults {
        return FMUserCredential.allObjectsInRealm(realm())
    }
    class func find() -> FMUserCredential? {
        if (findAll().count >= 1) {
            return findAll().firstObject() as FMUserCredential?
        }
        return nil
    }
}

This class has static params realm, and when I test write, I set realm object.
But, I notice that I have to new realm object when I do test.
So, I changed my test code to use

1
2
let realm = RLMRealm.inMemoryRealmWithIdentifier("MyInMemoryRealm")
FMUserCredential._realm = realm

This worked fine.

About realm

Realm is maybe so fast but I think this is quite difficult to use.
Because I already had a lot of time to use it, actually I’m a cocoa beginner.
The cost of studying it is quite high. but I don’t know how difficult coredata is, so I cannot judge which one is better.

ハッカーと画家を読んだ

TOC

ハッカーと画家を読んだ

ハッカーと画家はポール・グラハムによって書かれたエッセイ集で、
何か得られるかなぁとおもって読んでみた。

全体的には、

  • スタートアップでしょ、普通
  • lisp 最高
  • プログラムは、人々がそれを読むために書かれるべきである. たまたま, それが計算機で実行できるに過ぎない.(by SICP)
  • 富はお金じゃない。富は作れる、コード書いて富を創ろう
  • ハッカーとはどんなひとたちか
  • 誰かに喜ばれるものを作るのではなく、特定のユーザに喜ばれるものを作れ
    – 仕事とかしてたらよく聞くよね、形を変えて。(ペルソナとかそういう

という感じだった。

今大企業にいるけど、再来月からスタートアップに join するにあたっては、結構背中を押してくれる内容だったと思う。

一応マインドマップに書いたメモがあるので、それを元に以下に記述する。
(飛ばしている章もある)

0章 メイドインUSA

  • ipod
  • デザイン

1章 なぜオタクはモテないのか

  • nerd であること(賢くありたい)
  • 学校は牢獄と同じで、若者たちが社会を邪魔しないためにあるもの
    – 中にいる学生たちがそれを変えるしかない

2章 ハッカーと画家

  • 数学者に憧れる必要はない。ハッカーはもっと画家のようであるべき。
  • 共感することの重要さ。これが良いものと偉大なものとを分ける。
  • プログラムは、人々がそれを読むために書かれるべきである. たまたま, それが計算機で実行できるに過ぎない.(by SICP)

3章 口にできないこと

  • 現代で自然と行われていることが、実は未来では当たり前にやっていないようなことで、それが現代における「口にできないこと」
  • それを見つけるにはいくつか方法がある
    – 災難をみつける。批難を受けているものに対して、自分で「その主張は真実であるか?」と問うことが重要。
    – 異端
  • 口にできないことを探す理由
    – 好奇心
    – 間違っていたくない
    – 頭脳に良い
  • 自分の考えを口にだすことはいろいろマイナスがある
    – どちらか意見を聞かれた時、まだ決めてない、と答えるのがベター
  • もっとも重要なことは、「考えたいことを考えられること」

5章 もう一つの未来への道

  • スタートアップは大企業の十倍の生産性がある
  • サーバサイドソフトウェアはめっちゃイイ
    – 使い勝手はダメかもしれないが、とにかく動くということ
    — (感想)今はスマホの時代、これからは IoT とか言われてるけどどうなっていくか。
    — (感想)事実、2010年ころくらいまでは Web アプリ(ゲーム)が大半を占めていが、今はそうではないのでここは話半分で良いと思う
  • サブスクリプションの課金がしっくり来るよねっていう話

6章 富の創り方

  • 富は創れる
  • 富とお金は等しくない
    – お金は交換媒体である
  • 富とは、ものやサービスなどを受けられること。

9章 ものづくりのセンス

  • 良いデザインは
    – 単純
    – 永遠
    – 正しい問題を解決する
    – 想像力を換気する
    – ちょっと滑稽
    – 難しい
    – 模倣する
    — 正しい答え + オリジナリティ
    – 奇妙である
    — lisp とか
    – 集団で生起する
    – 大胆である
  • 「俺ならもっとうまく出来る」と考える事がとても重要

10章 プログラミング言語入門

  • 静的型付言語と動的型付言語の決着はまだついてない
    – ポールは動的のほうが好き
    – (感想) swift のような、型推論があるものだったらいいとこ取りできてて最近は良いと感じている。
    – (感想) clojure は明示的に型を書かないから nil チェックとか頻繁にしなきゃいけなくて、その点 swift は便利. (scala とかもそうらしい)

11章 100年後の言語

  • 作りたくなったでしょ?

12章 普通のやつらの上を行け

  • ぶっちゃけプログラミング言語には力の差がある
  • lisp 強い
  • マクロがあることで何でもできる
  • スタートアップとかで利用例が少なくても気にするな、むしろ差別化できて良い

14章 夢の言語

  • ハックしやすい
  • 簡潔である
  • 書捨てのプログラムを書きやすい
  • ライブラリが豊富
  • 効率が良い
  • 時間
    – 長く存在

15章 デザインとリサーチ

  • 特定のユーザのために創ることが重要
  • とにかく早くプロトタイプを出すこと
  • 士気。プロトタイプを出すことによって士気が上がる。

16章 素晴らしきハッカー

  • 脳内に非常に大きいコンテキストを展開できる
  • 特殊な集中力
  • 最初はだれがいいハッカーかはわからない
    – 一緒に働いてみるとわかる
  • 自分を素晴らしいハッカーにすることができる方法があるとしたら、その方法とは、自分自身に対して次の契約を結ぶことだ。
    – 「退屈なプロジェクトの仕事は一切しなくて良い、その代わりに、中途半端な仕事はしない。」