詩と創作・思索のひろば

ドキドキギュンギュンダイアリーです!!!

Fork me on GitHub

2014年買ってよかった！ 本を読む人におすすめの文房具3点

f:id:motemen:20141210004127j:plain

今週のお題「今年買ってよかったもの」〈2014年をふりかえる 2〉

小説を読むときにもおすすめできるけど、どちらかというと実用的な本を読むときに。

透明のポストイット

読書のとき、気になるところに印をつけながら読むというのはみんなやることだと思うけど（このエントリで紹介するのは全部その前提なので、そうじゃない人はちょっと……）、その際もっとも敷居が低いのは付箋だろう。本を傷つけないし、貼り直せるから、自由にぺたぺたと貼れる。敷居が低いのはいいことで、この部分が気になるけれど、わざわざ書きこむほどでもないんだよな……などと躊躇して書かなかった結果、後からあれなんだったっけ、と迷うことがない。

そういう付箋のなかでもこれが優れているのは、本体が透明なので、文字に重ねて貼りつけられるところ。不透明な紙の付箋だと、行を避けて貼ったり、本文を隠してしまったりして微妙にストレスが溜まってしまうところだ。難があるとすればホコリを貼りこんじゃうとちょっと見た目がわるいところか。

ポスト・イット ジョーブ 透明見出し 44x6mm 20枚x9色 680MSH

ポスト・イット ジョーブ 透明見出し 44x6mm 20枚x9色 680MSH

蛍光マーカー

これが最もライフチェンジングで、最高だった。

いくら付箋が良いものだといってもやはり直接の書きこみに勝るものではなくて、付箋が行単位のハイライトしかできないのに対し、書きこみなら文、単語単位で強調できる。貧乏性の自分も文庫や新書など、安い本はあえて汚していこうという気持ちで鉛筆やボールペンで線を引いてみたりもしたのだけれど、どうしても線がへろへろになってしまって、きちょうめんな方ではないとはいえ、後から見返したときに心地よいものではない。蛍光ペンでのハイライトなんてもってのほかだった。

ステッドラーのこの蛍光マーカーはよくある平たいペン先の蛍光ペンと違い、クレヨンのような書き心地なのが特徴。これがすごい！　線が歪んでしまっても、そのままペン先をぐりぐりと動かしてしまえば外したところを塗りつぶすようにハイライトできる。水性のペンだと線を重ねるたびに色が濃く、紙がふやけてしまうので一発書きの趣があるところ、これはやり直しが効くので気楽だ。ぜんぜん感覚が違う。使ってみればわかります。

ステッドラー 固形蛍光マーカー テキストサーファー ゲル 264 PB3 3色セット

ステッドラー 固形蛍光マーカー テキストサーファー ゲル 264 PB3 3色セット

ブックダーツ

これは……一見おしゃれアイテムのようだけど、意外と馬鹿にできないやつ。

上で紹介した文房具たちも、かように便利千万なものであるのだけれど、ひとつ弱点があって、それは本とともに持ってくるのを忘れてしまうと無力な点だ。いつもとちがうカバンで出かけて本を取り出すと付箋やペンが手元になく、印がつけられなければ読めないと怖じ気づいて、スマホで電子書籍を読みはじめてしまうのはよくある話。

ブックダーツはページをクリップのように挟むので、しおりのようにも、行を示すようにも使え、こういったときにも役立つ。ブックダーツを挟んでおいて、あとで線を引くなり付箋を貼るなりすればいい。紙を傷つけそうなのと意外と重みがあるので常用はしないけれど。

いやいやこれも忘れたら意味ないでしょ、と思うかもしれないが、ブックダーツの便利なところは、本そのものに収納が可能なところだ。読みはじめるときに、裏表紙にでも4、5個挟んでおけば、本を持ちだすときにはかならずこのブックダーツもついてくるわけだ。かくして安らかな読書の時間を楽しめる。

【BOOK DARTS】ブックダーツ　チョコラベル75個ミックス

【BOOK DARTS】ブックダーツ　チョコラベル75個ミックス

紹介したうちのひとつだけでも便利なので、どうぞご活用ください。

ソースに一行追加するだけですべての HTTP 通信をロギングするモジュールを書いた #golang

Go

こちらです。Perl でいうと Devel::KYTProf に性質がちかい。

motemen/go-loghttp · GitHub (GoDoc)

使用例

たとえばこういうコードに…

package main

import (
    "io"
    "log"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get(os.Args[1])
    if err != nil {
        log.Fatal(err)
    }

    io.Copy(os.Stdout, resp.Body)
}

% go run main.go http://example.com/
<!doctype html>
...

一行追加すると:

package main

import (
    "io"
    "log"
    "net/http"
    "os"

    _ "github.com/motemen/go-loghttp/global" // ← この行
)

func main() {
    resp, err := http.Get(os.Args[1])
    if err != nil {
        log.Fatal(err)
    }

    io.Copy(os.Stdout, resp.Body)
}

% go run main.go http://example.com/
2014/12/02 13:36:27 ---> GET http://example.com/
2014/12/02 13:36:27 <--- 200 http://example.com/
<!doctype html>
...

こんな風に（log パッケージを使った）ログが自動的に吐かれるようになります。

特定のクライアントだけログを吐きたいのなら:

import "github.com/motemen/go-loghttp"

...

client := http.Client{
        Transport: &loghttp.Transport{},
}

loghttp.Transport の LogRequset、LogResponse フィールドを設定することで、どのようにログを出力するかをカスタマイズできます。（デフォルトでは上記のように標準の log パッケージを使用してます）

仕組み

loghttp は loghttp.Transport という struct を提供していて、これが http.RoundTripper を実装しているので http.Client の Transport フィールドとして設定できます。http.Cilent が HTTP リクエストを実行する際にはこの Transport を介して行いますが、loghttp.Transport は通常の HTTP 送受信に加えてロギングを行うような実装になっているので、このように HTTP 通信に引っかけてリクエストとレスポンスのロギングを行うことができるわけです。

さらに github.com/motemen/go-loghttp/global パッケージでは http.DefaultTransport を loghttp.DefaultTransport に書き換え（！）しているので、インポートするだけですべての HTTP 通信が（標準の http パッケージを利用していれば）標準エラー出力に表示されるようになります。

The Way to Go: A Thorough Introduction to the Go Programming Language (English Edition)

The Way to Go: A Thorough Introduction to the Go Programming Language (English Edition)

#github tips: hub pull-request の向き先がリポジトリのデフォルトブランチにならないとき

Git GitHub

引数なしの hub pull-request を実行すると、リポジトリのデフォルトブランチに向けたプルリクエストを作ってくれます。このデフォルトブランチはふつう master を向いてますが、変更可能なので Git Flow で言う develop 的なブランチをデフォルトブランチにしているプロジェクトもあると思います。

さて、このデフォルトブランチをプロジェクトの歴史の中のどこかの時点で変えると、新しく clone したリポジトリで hub pull-request すると当然 develop に向けてプルリクエストを作りますが、デフォルトブランチの変更以前にこのリポジトリを clone していたリポジトリで hub pull-request すると master に向けたプルリクエストを作ろうとしてしまいます。-b develop すれば develop を向くのだけど、これは事故の元……。

原因

hub pull-request は -b {base} が与えられなかったとき refs/remotes/origin/HEAD という ref （GitHub のデフォルトブランチはこれに対応しています）を参照し、これが向いている先をデフォルトブランチとみなして、そのブランチに向けたプルリクエストを作成します。この origin/HEAD という symbolic ref は git clone 時に作成されるのですが、それ以外のタイミングでは更新されることがない。そのため、途中からデフォルトブランチを変更しても古いリポジトリでは追従できないわけです。

対策

以下のコマンドを実行する。

% git remote set-head --auto origin
origin/HEAD set to develop

リモートの Git リポジトリの HEAD を、手元に反映させます。めでたし。手元の HEAD がどうなっているかは、以下のコマンドで確認できます。

% git symbolic-ref refs/remotes/origin/HEAD

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

はてなで一緒に働きませんか？