金はチケットである

金はチケットである

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

金の入力

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

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

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

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

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

金の出力

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

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

金とサービス

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

いつも行っている美容室で、普段髪を切るのに 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章 素晴らしきハッカー

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

Swift の Promise ライブラリの BrightFuture と Craft を使ってみたら Craft のほうが良かった

TOC

はじめに

最近 Swift でアプリを書いているんだけど、 promise のライブラリをどうしても使いたくて色々見ていたら、
なんか BrightFuture っていうやつが Star が多いように見えて
しばらくつかってみたけど、then でつなげた結果を次に返すみたいなのができそうになかった。
Craft は js の promise と同じように使えて、 chainable なので便利だった。

Craft 使用例

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
let moge = "moge"
let promise = Craft.promise({
  (resolve: (value: Value) -> (), reject: (value: Value) -> ()) -> () in

    // post の処理
    Alamofire.request(Router.Ticket).responseObject { (request, response, ticket:Ticket?, error) in
        if (ticket != nil) {
            resolve(value: ticket!.token!)
        } else {
            reject(value: NSError(domain:"error occured", code:404, userInfo:nil))
        }
    }
})
promise.then({(value: Value) -> Value in

    println("promise 1 value 1 is ")
    println(value) ; 1コメのやつ

    let promise = Craft.promise({(resolve: (value: Value) -> (), reject: (value: Value) -> ()) -> () in
        Alamofire.request(Router.Ticket).responseObject { (request, response, ticket:Ticket?, error) in
            if (ticket != nil) {
                resolve(value: "2komenoyatu!!!!!!!!!!!!")
            } else {
                reject(value: NSError(domain:"error occured", code:404, userInfo:nil))
            }
        }
    })
    return promise
}).then({(value: Value) -> Value in
    println("promise 2 value 2 is ")
    println(value) ; 2コメのやつ
    return "mogo"
})

幾つか気づいた点

  • (2015/2/16追記) release build で最適化されるとうまく処理できず死ぬので注意 > http://qiita.com/jumbOS5/items/d4941439a0b3a3534396
  • promise.then のところは続けて書かないとダメ。つまり( ).then({ … っていう感じ。
  • swift のコンパイラがダメなのかわからないけど、 responseObject がねぇよって言われてて、
    意味分かんないから println とか入れるとコンパイラが通る。 甚だ謎。

所感

やっと promise で楽に書けそう。

参考URL

https://github.com/Thomvis/BrightFutures
https://github.com/supertommy/craft

Clojure で 一部分だけテストがしたい Using Midje

TOC

ruby と比べて、 clojure のテスト

普段書いている ruby と比べて、圧倒的に clojure の方が良いところはテストの実行速度だ。
比べ物にならないくらい早い。DB にデータとか入れてないからかもしれないけど。
基本的に保存したら結果が出ている。 repl の立ち上がりとか、最初のテスト読み込みとかはクソ重いけども。
さて、普段は rspec でテストを書いているが、 describe “hoge test “, filter:true do … とかすると
filter ができるのだが、 clojure ではどうやるのだろうか。調査してみた。

test のメソッド filter をどうやるか?

; in repl.clj
(defn filter-autotest []
(require 'midje.repl) (midje.repl/autotest :filter (fn [fact] (:filter fact) ))
)

(defn all-autotest []
(require 'midje.repl) (midje.repl/autotest :filter (fn [fact] true))
)

; in test
(fact :filter "do something great test"
 (is true)
)

上記をrepl 内で定義しておき、
(filter-autotest) か (all-autotest) かを評価する。
そうすると、 filter-autotest の場合は filter つきだけが、
all-autotest の場合は全てが実行される。

repl で最初に定義されていてほしい

repl を起動するたびにいちいち定義するのは面倒くさいので,
こちら
を参考にして設定することで, 起動時に load するようにした。

+++ b/dev/user.clj
@@ -0,0 +1,29 @@
+(ns user
+  (:require
+    [clojure.repl :refer :all]
+    [clojure.tools.namespace.repl :refer [refresh]]
+    [midje.sweet :refer :all]
+    [midje.repl :refer :all]
+    )
+  )
+
+(defn filter-autotest []
+  (require 'midje.repl) (midje.repl/autotest :filter (fn [fact] (:filter fact) ))
+)
+
+(defn all-autotest []
+  (require 'midje.repl) (midje.repl/autotest :filter (fn [fact] true))
+)
+
+(defn start
+  "Start the application"
+  []
+  )
+
+(defn stop
+  "Stop the application"
+  []
+  )
+
+(defn reset []
+  (stop)
+  (refresh :after 'user/start))

+++ b/project.clj
@@ -20,7 +20,8 @@
-  {:dev {:dependencies [
+  {:dev {:source-paths ["dev"]
+         :dependencies [

注意点

(fact "do something"
 (fact "do2"
  ....

のように、 fact でネストした場合は filter に引っかからないので、
この場合は 最初の fact を fact-group に修正してあげましょう。

所感

これがわかってよかった。開発効率が ちょっと上がった。

Datomic まとめ

TOC

datomic まとめ(追記していく)

datomic 自体の説明

省略。
いつか書くかも。 他に良い記事がたくさんあるので。

datomic 本当のところ(使いながら追記していく)

created_at, updated_at は持つ必要がない

rails で mysql とかつかって作るときだと当たり前のように created_at とか updated_at を持っているけど、
datomic を使う場合は必要ない。
stack over flow に、持ってた方が良い?などの質問に対して、 おれは created_at 入れているみたいな意見があったけど、別にいらないと思う。

; -------- 一応コピペしとく
(def db-url (ref ""))
(dosync
  (ref-set db-url  "datomic:free://localhost:4334/hoge"))

(defn setup-db [db-url]
  (d/create-database db-url)
  (d/transact
    (d/connect db-url)
    (concat
      (ds/generate-parts d/tempid (dbparts))
      (ds/generate-schema d/tempid (dbschema)))))
(defn setup-testdb []
  (dosync
    (ref-set db-url (str "datomic:mem:" (d/squuid))))
  (setup-db @db-url)
)

(defn connect-db []
  (d/connect @db-url)
)

; -------- ここが本質
(defn history [eid]
  (d/q
    '[:find ?e ?a ?v ?tx ?added
      :in $ ?e
      :where
      [?e ?a ?v ?tx ?added]]
    (d/history (d/db (connect-db)))
    eid
    )
)

これで帰ってくる値は [entity_id, attribute_id, value, transaction_id, added?]
で、これらが引けるということは created_at, updated_at をあえて持たなくて良い。

#<HashSet [
[17592186045436 74 this is new emotion. 13194139534331 true],
[17592186045436 73 0 13194139534331 true],
[17592186045436 72 17592186045423 13194139534331 true],
[17592186045436 71 17592186045421 13194139534331 true],
[17592186045436 75 17592186045432 13194139534331 true],
[17592186045436 70 #inst “2014-12-12T00:11:51.228-00:00” 13194139534331 true],
[17592186045436 71 17592186045422 13194139534333 true],
[17592186045436 71 17592186045421 13194139534333 false],
[17592186045436 74 hogera! 13194139534333 true],
[17592186045436 74 this is new emotion. 13194139534333 false]
]>

サンプルをはるとこんな感じで帰ってきている。(手動で sort 済み)
これは 13194139534331 と 13194139534333 のトランザクションでインサートされたこと、
71, 74 の属性が 変更されたことなどが読み取れる。

where での絞込みでは、nil のものは消えてしまう(datomic というより datalog)

1
2
3
4
5
(d/q '[:find ?token ?arn
     :in $ ?uid
     :where
      [?dt :device_token/user ?uid]
      [?dt :device_token/endpoint_arn ?arn]

などとしたとき、 device_token のレコードに、 arn をもともと空文字列か何かを入れておかないと、
filter されてしまう。endpoint_arn がないときに、それを作って格納みたいなコードを書こうとしたとき
ちょっと困った。

個人的に datomic を立てている設定

https://github.com/pointslope/docker-datomic-example.git を使って、 fig で up している。
datomic console 付きで立つ。

datomic console から接続するときに HornetQException errorType=SECURITY_EXCEPTION message=HQ119031: Unable to validate user: vzk3d3j04aRQgPmXi6zwfYPxAGOeaWZ1vEdir5GdwtE=

unable to validate user が出た。
これは、 transactor に対して 3つ以上の接続をした時に出る模様。
いったん接続している peer を落としてみたら、無事に接続できた。
そういう意味では、datomic console を使って本番DB をみたいなら、必然的に 待ち受けている peer は 1つになる。
まぁ基本的にはそれでいいのかな。

参考資料(便利)

Mac で Wirelss な Lenovo の Keyboard を使う

無線キーボードを買った

thinkpad の無線キーボードを買った のだけど, firefox で使うスクロールが、 middle click が暴発してそもそも使えなすぎだった。
具体的にはスクロールして欲しいところが、中クリックをおしたことになっていた。

解決

  • karabiner である程度設定は基本
  • seil で変換、無変換を使用できるようにする
  • firefox 中クリック問題、および iTerm2 で中クリックコピペされちゃう問題はSmart Scroll を使う とすべてが解決した。

所感

結構はまったけど解法が見つかって嬉しい。
危うく1万ドブに捨てるとこだった。
有料アプリになるかもだけど、評価が終わった場合これは買ってしまっていいだろう。

参考資料

Rubykaigi 2014/ 1日目

RubyKaigi first day

とりあえずまとめてみた。

(key note) Building the Ruby interpreter – What is easy and what is difficult?

何が簡単で、何が難しいのかという話。

メモ

パフォーマンス

パフォーマンスを単純に上げるのは簡単だが、メンテし易さなどとトレードオフの関係にあるので、
メンテしやすく、さらにパフォーマンスを上げるのは簡単ではない。

VM

VM や JIT コンパイルの仕組みなどを作るのはそんなに難しくない。
しかし reliability を保ちながら作るのは難しい。

メンテしやすさ

Ruby の実装を Ruby で実装すればわかりやすいしメンテしやすい。
ruby のコードをいじったあとでは、 テストとか全部通ればまだ良い方(ダメだったら全部通らないから)。

並列性

単純にカーネルレベルスレッドの仕組みを作るのは簡単だが、 ruby のユーザに残念体験を与えないためにあえてそうしてない。
また、スレッドを適切に扱える技術者(ウィザード)は数少ない。という説明もされていた。
同時実行性があり、バグの再現実効性が低いのも大変である。

GCアルゴリズム

ライトバリアを実装するのは簡単だが、拡張ライブラリなどにも実装するのは大変。

性能評価

仮想のサーバでは性能評価が難しいので、物理サーバが必要。
実行時間とはなにか。メモリ使用量とは結局なんだろう(平均?最大?)。

コミッターになるには

ただコミッターになるのは、matzにコミッター権限貰えばよい。
しかし、デベロッパーとして参加するのは大変。

Ruby(処理系)をもっと知るために

Rubyソースコード完全解説
http://i.loveruby.net/ja/rhg/book/
Ruby Under a microscope
http://shop.oreilly.com/product/9781593275273.do
(日本語翻訳中らしい)

もっと良い技術者になるために

新しい技術を調べて
- ブログを書いて
- 議論をし
- sns でチャットして
- 会議に参加して
- カンファレンスで発表
していきましょう。

所感

さすが ruby コミッターという凄さがあった。
普段 GC とかあまり意識しないけど、知識としてきちんと知っておかなきゃダメだなと思った。

Controller Testing: You’re Doing It Wrong

やりかた間違ってるよ的な煽りタイトル。

メモ

ダメなことあるある

  • いろんなことをテストしようとしちゃっている
  • 全部スタブしちゃってる

コントローラのテストでやるべきこと

  • authorization
  • リソースの存在
  • レスポンスの形式

命令的ではなく、宣言的に

  • チェックリストのようにテストを書こう

実際問題

  • 5/6 の、今年やったプロジェクトでは、コントローラベタ書きwww

なぜファットモデルのほうが良いのか

  • ActiveModel で作っておくと良い
  • すごく簡単なロジックでもコントローラに書いていて, それが変更による変更.. となるとすぐ太ってしまう。
    – モデルにしておくほうが良い

まとめ

  • テストは宣言的に、シンプルにかけ
  • コントローラにロジックかくな、モデルにかけ

所感

英語のセッションだったけどそこそこ聞き取りやすい英語でよかった。
それでも完全に内容を把握できたわけじゃあないけど。

Continuous Delivery at GitHub

ギッハブ社で行っている継続的デリバリについて
(普段会社で行っていることはメモってなかった)

メモ

feature flags

ある機能を入れるときには、

def some_new_feature_enable?
  something and user.is_stuff?
end

的なものを書いて、それが良さそうなら true に書き換えるなどして切り替えできるようにしていた。
(そういえば前職でもそういう仕組みがあった。)

ブランチコントロールの話

  • 長いことブランチを活かしておくと臭ってくるやん?
  • たとえば rails2 から rails3 に上げるみたいなプロジェクトがあった(実際に)。 – RAILS3=true てきな環境変数で rails3? みたいなコードを書いて条件分岐して master につけていった。

フィードバック可視化

ちゃんとしててすごく良かった

所感

機能をフラグで管理する( redis とか使ってもいいかも) のは確かに良い物かもなぁと思った。
ただ、ゆうてもこういう仕組みはものすごく大きい変更に関してはやっていけない気もした。
ブランチコントロールの話は、twitter では、うちは無理だ、とか出来そうにないとか、怖いとか
そういう反応が散見された。
確かに怖いは怖いし、実際、まとまった機能をつける場合は,
mediuamfeature/master みたいに master からきって、
mediuamfeature/feature_branch で mediuamfeature/master に pull req だしつつ
ある程度育ったら mediuamfeature/master で master を pull rebase で差分を取り込む感じでやっていた。
これは議論の余地はあるなぁ。

What’s wrong with your app?

これも割りと釣りタイトルっぽくて聞いたけど、内容は heroku チームと、heroku 使ってるヒトの H12 とかいう
エラーの原因がなんなのか?みたいな話だった。
heroku に特化した感じであんまりだったので省略。

Non-Linear Pattern Matching against Unfree Data Types in Ruby (Egison Pattern Matching in Ruby)

egison っていうパターンマッチのプログラミング言語と、その ruby gem の話。
あんまり直接メモはしてなかった。

メモ

  • 様々なパターンマッチがあって、圧倒的な少ない記述量で、たとえばポーカーの役判定などができる。
  • 麻雀の役判定も!(これはすごいことだ!!!!)
    – 複数の判定もできるとのことなので工夫すれば全部役を本当にだせる?
  • 今注目されているプログラミング言語にも選出
  • 東京大学のカリキュラムにも!

所感

めっちゃすごい。
通常のコードでも綺麗に簡潔に書けそうだ。
とりあえず試しに使ってみると良いかも。
すげぇどうでもいいけどググらビリティ低すぎる。

Hypermedia: the Missing Element to Building Adaptable Web APIs in Rails

とりあえずこの日一番ヒットというか、一番驚いたのがこのセッション。

メモ

API の変更

変更マジしんどい。
/v1/hogehoge を /v2/hogehoge とかにすると必ず api の変更が必要

FizzBuzzaaS の話

fizzbuzz を返す api サーバ。
100までの数値に対応している。

この api にテストを書こうとすると
/fizzbuzz/endpoint/1
/fizzbuzz/endpoint/2
/fizzbuzz/endpoint/100

となって、/fizzbuzz/endpoint のところはハードコードだし、
最後の値は数値を for とかで回すことになる。
それを、最初のレスポンスが nextUrl 的に、次の値を渡してくれれば
iterator で問題なくテストできる(当然最後もわかるし、100が変わっても大丈夫)。

そこで hypermedia

HTML もそうだけど、次へのリンクや、前へのリンクなどはちゃんと付いている!
ブラウザのバージョンがかわっても全然大丈夫!

じつはそういう規格がある。 Uber, HAL, JSON-LD など..

HTML で web の API が表現可能!

それで作ったのがこれ

使い方としては

設計順かいてあったけど、メモれてない..
状態遷移を書く、はすごく重要だと説明されていた。

まとめ

ここの qiita でほぼ書いてある

所感

正直言ってこの発想はなかった!と思った。
会場も、なるほどそうきたか!みたいな感じだった。
ただ、実際つかっている HTML の構造変えたくなったりしないのかなぁとか、
疑問はあったりする。
あ、というか api 用の HTML(view) を書いておけばいいのかな。
まぁ一つの手段としてこれはすごくあるなぁと思った。
API から web を作るのは、すごく手間ではないけど、二度手間であることに変わりはないし。

“Gem of this Week” - building culture and making gem

ドリコムのヒトの話。
gem 作って共有する文化づくりのための工夫のお話。
今週のgem(媒体がチャットなのかメールなのかは不明)を作って、 gem を作る週間を作った。
社内用の rubygems 的なものを作った (drecom gem)。
これで gem publish みたいなことができた。
ヒアリングして不安を潰すことでそういう文化を作った、っていう話だった。

最後に

すごくいろいろいい話をきいた。
どうでもいいけど、たったこれだけまとめるのに 2時間くらいかかってる。