詩と創作・思索のひろば (Poetry, Writing and Contemplation)

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

minimatch(node.js で path match するライブラリ)のチートシートを作った

minimatch っていうのは Gruntgulp.js その他あちこちで(npm もらしい)使われてるグロブマッチライブラリです。最近よく gulp を使ってるんだけど、毎回 gulp.src() の書き方で迷ってしまう。調べた結果 minimatch に行き当たったんだけど各種 glob 実装のドキュメント読んで把握しろ、という感じでよく分からなかったので早見表を作った次第です。

https://github.com/motemen/minimatch-cheat-sheet

確認用にテストを書いていて、そのテストケースからドキュメントを生成してるので間違いはないはずです。説明が間違ってる、この例も乗せた方が見やすいだろ、とかあればプルリクください。

折角なので日本語版を書いておきますね。

基本

  • * はパスセパレータを含まない任意の文字列にマッチ
  • ** はパスセパレータを含む任意の文字列にマッチ
  • ? はパスセパレータでない任意の1文字にマッチ
パターン マッチする マッチしない
xxx.* xxx.yyy, xxx.y.z abcxxx.yyy, xxx.y/z
xxx/*/yyy xxx/abc/yyy xxx/yyy, xxx/abc/def/yyy, xxx/.abc/yyy
xxx/**/yyy xxx/abc/yyy, xxx/yyy, xxx/abc/def/yyy xxx/.abc/yyy
xxx/**yyy xxx/yyy xxx/abc/yyy, xxx/abc/def/yyy, xxx/.abc/yyy
x?y xAy xy, xABy, x/y

ブレース

  • {foo,bar} は "foo" と "bar" に展開
  • {1..3} は "1", "2", "3" に展開
パターン マッチする マッチしない
{foo,bar} foo, bar baz
{x,y/*}/z x/z, y/a/z y/z
foo{1..3} foo1, foo2, foo3 foo, foo0

否定

  • ! で始まるパターンは真偽を逆転させる
パターン マッチする マッチしない
!abc a, xyz abc

コメント

  • # で始まるパターンはコメントとみなされて何にもマッチしない
  • \# とすることでエスケープできる
パターン マッチする マッチしない
#abc abc, #abc
\#abc #abc abc

extglob

  • +(pattern) は pattern の1回以上の繰り返し (/(pattern)+/)
  • *(pattern) は pattern の1回以上の繰り返し (/(pattern)*/)
  • ?(pattern) は pattern の0回または1回の出現 (/(pattern)?/)
  • @(pattern) は pattern そのもの (/(pattern)/)
  • !(pattern) は pattern にマッチしないというパターン (/(?!pattern)/)
  • カッコ内のパターンは | で連結可能 (/(foo|bar)/)
パターン マッチする マッチしない
a+(xy) axy, axyxy a
a*(xy) a, axy, axyxy
a@(xy) axy a, axyxy
a!(xy) ax axy, axyz
a+(x|y*z) axx, ayzxyzxx, axyAAAz axy, a

デザイン4+1の基本ルール: 『The Non-Designers Design Book』を読んだ

なんかで Kindle の洋書が安かったときに何となく買っていた『The Non-Designers Design Book』を読み終えた。素人のための……というよりは新人デザイナーのための本のようなのだけど、エンジニアの自分が読んでも面白かったので書いとく。日本語版もある。

4つのルール

曰わく、デザインには基本的な4つのルールがある。それぞれの頭文字を取ると "CRAP" ……となるのだけれど、これは上品な単語ではないのでそう示唆されるだけではっきりとは書かれない。ともかく、各々に対応する原則は以下のとおり。

  • Contrast(コントラスト)
  • Repetition(反復)
  • Alignment(整列)
  • Proximity(近接)

これらにどういう意味があり、どう活用すべきであるか。本で紹介される順に書いていく。

Proximity

意味的に関連する要素どうしを近くに置いてグルーピングする。逆に直接関係のない要素どうしは離して配置する。そうすることで、ページ内の情報を組織化できる。

Alignment

ページ上の要素どうしを視覚的に関連づける。たとえ二つの要素が離れていても、同じように整列されていればそれらは関連しているように感じられる。安易に中央揃えしない! 右でも左でも、一方に要素を揃えることでより強く関連づけられる。組織化と統一が目的。

Repetition

色やフォントなどの視覚的な要素を繰り返し、一貫性を持たせる。これは1ページ内のことに限らなくて、例えば数ページに渡る文書でも、見出しや罫線といった部分の体裁を同じに整える。ここでは統一と視覚的に関心を持たせることが目的。

Contrast

2つの要素の違いを際立たせる。要素どうしがなんか違うという状況では単に間違えてるだけに見えてしまう。ここで違いというのは色とかフォントとか文字サイズだけじゃなくて、横長の罫線に対して縦長のカラムを置くとか、そういうことでもいいらしい。目的はページに関心を持たせること。

至上のルール

以上4つの法則に加えて、何度も何度も繰り返されるいちばん基本的なルールは、"Don't be a wimp"。怖気付くな! コントラストを作るなら中途半端じゃなく思いっきりやる、空白を怖がらない。等々。ホントに何十回と言われるのでよっぽど大事なことなんだろう。

タイプについて

それからタイプ(書体?)についての話も面白かった。CSS だけからなるこれまでの経験で、フォントの違いには serif、sans-serif と等幅とあと装飾的なの、くらいしか区別できていなかったけれど、本当はもっといろいろある。特にこれまで serif だと認識していた中にも Oldstyle, Modern, Slab serif なんてカテゴリがあるんだそうだ。この章を読み始めたときはそんなの気にするのアルファベットを日常的に使ってる人間だけで日本語ユーザの自分には関係ないだろう、と斜に構えていたのだけど、読んでみて、実際に試してみると、確かに……と思えてしまったので面白かった。これらの違いを理解して、うまくコントラストを作ってやることが大事。

まとめ

4つのルールなどといっても、聞いてみればそりゃそうだろうという気もするかもしれない(自分はちょっとした)。けど本当に大事なのは、こういったルールに名前をつけて、自覚的になることだ。自分がデザインしたページに違和感があるときに、その原因は何なのか名前を上げることができるようになることが重要である。そうすれば、何となく今ひとつに感じてしまうデザインを確実によりよくできるはずだ。……とまあ実際に実現可能かどうかは別として、これまでは結局センスの産物なんだろうと思っていたデザインを、新たな視点で見られるようになったと思う。

Kindle 版の場合はカラーで(タブレットやスマートフォンで)読むのがオススメ。

The Non-Designer's Design Book (3rd Edition) (Non Designer's Design Book)

The Non-Designer's Design Book (3rd Edition) (Non Designer's Design Book)

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

ノンデザイナーズ・デザインブック [フルカラー新装増補版]

  • 作者: Robin Williams,吉川典秀
  • 出版社/メーカー: 毎日コミュニケーションズ
  • 発売日: 2008/11/19
  • メディア: 単行本(ソフトカバー)
  • 購入: 58人 クリック: 1,019回
  • この商品を含むブログ (105件) を見る

4つの原則の日本語訳はこのスライドを参考にした。とても分かりやすいし、本の内容がかなり補強されると思う。

スーパーハッカーの夢を諦め、普通自動車免許を取得しました

photo by Thomas Hawk

表題の通りです。実のところ、もう一年も前のことになります。

優秀なエンジニアの多くが自動車免許を所持していないことは有名な事実です[要出典]。私も彼らに憧れ、免許を持たずに生活していましたが、歳を取るにつれ「自分はスーパーハッカーにはなれない」と次第に実感してきたこと、新たな自分に変身したい、という思いと、あまりに暇でヤケになった気持ちから思い立って自動車学校に入学したのが一昨年の年末です。会社に通いながらの教習でしたが、週末と早退・遅刻を活用することで、半年かけて免許を獲得しました。当時のチームメイトに感謝。

すべてを終え、保有者サイドに堕ちてしまった私からそうでないあなた方に伝えられることは……「初心者マークの車に近づくな」。いち歩行者しかなかった頃は車であればどれも同じやろと考えていましたが、運転する側になると全然違う。初心者マークの車は生まれたての子馬のような存在です。それでいて研ぎ澄まされたナイフのようでもあります。近づかず、優しく遠巻きに見守ってあげてください。それがお互いのためです。

あと教習日記をつけていたのをブログで公開します。まだひと記事しかありませんが、随時更新していきますのでご購読くださいね。(実際の日付を使ってるので古い記事になります)

http://karimen.hatenablog.com/

最後に、自動車を運転するとはどういうことか、と尋ねられましたら、私はこう答えようと思います。「それは魚になって泳ぐ夢のようだ」。この意味が分かるようになる日があなたにもきっと来るはずです。

一発合格!普通免許超速クリア問題集

一発合格!普通免許超速クリア問題集

AdSense のレポートを CLI で確認できるツールを書いた

Go

motemen/adsense-report-cli · GitHub

例によって go get github.com/motemen/adsense-report-cli でインストールできます。

使用例

デフォルトで、直近 7 日間の日毎の収入を表示します。

% adsense-report-cli
DATE            EARNINGS (JPY)
2014-07-01      1
2014-07-02      0
2014-07-03      2
2014-07-04      0
2014-07-05      0
2014-07-06      1
2014-07-07      0

(数字はサンプルです)

dimension, metric などのパラメータを指定することで、自由に知りたい情報を取得することができる。dimension と metric については Metrics and Dimensions - AdSense Management API — Google Developers、日付の指定方法については Using Relative Date Keywords - AdSense Management API — Google Developers を見るとすぐに分かると思います。

% adsense-report-cli -dimension=MONTH -metric=PAGE_VIEWS -from=startOfMonth-3m -to=today
MONTH   PAGE_VIEWS
2014-04 500
2014-05 500
2014-06 1000
2014-07 300

(数字はサンプルです)

前準備

Google の API を使うので、OAuth 認証のために https://console.developers.google.com からプロジェクトを登録する。またその際、

  • "APIS & Auth" > "APIs" より "Adsense Management API" を有効にする
  • "APIS & Auth" > "Credentials" > "OAuth" > "Create new Client ID" より "Web Application" を登録し、Redirect URI として "http://127.0.0.1" を登録する
    • f:id:motemen:20140707134259p:plain

  • 登録したアプリについて "Download JSON" から client_secret_XXXXX.json をダウンロードし、~/.adsense-report-cli/client_secret.json に置く

必要があります。あとは初回起動で OAuth 認証するだけ。大変だけどがんばって!

応用例: tmux のステータスバーに今日の収入を表示する

誰だって自分の収入は気になるもの。ステータスバーに収入を表示して、自然と目に入るようにしてみては?

以下のスクリプトと設定で表示してみた例です。う〜ん便利

f:id:motemen:20140707135226p:plain

(数字はサンプルです)

# ~/.tmux.conf
set-window-option -g status-right "#[fg=green]#(adsense-todays-earnings)#[default] | %Y-%m-%d(%a) %H:%M:%S"

Show today's AdSense earnings using https://github ...

Known issues

  • 複数の dimension, metric に対応していない
  • 複数アカウントに対応していない
    • あとから気づいたのでやってない。ちょっと書いたらすぐ対応できそう。

motemen/adsense-report-cli · GitHub

現在 Chrome で開いているプルリクエストを一発でチェックアウトするスクリプト

プルリクエストをレビューしていて diff を見たら意外とでかいぞ手元で1コミットずつ見るか……となったときにブランチをいちいち確認してチェックアウトするのが面倒なので一発でやってくれるシェルスクリプトを書いた。

chrome-cli を使うので OSX のみ。もうこれでオチたようなもんだけど、以下をパスの通った場所に置いたらオッケーです。Chrome で現在開いているタブが GitHub のプルリクエストページであるとき、その PR に対応するブランチをチェックアウトしてくれる。リポジトリオーナーではない所からのプルリクエストの場合は、ユーザ名と同じ名前の origin を登録してブランチをチェックアウトします。

Git: checkout "this" (currently shown in Chrome) P ...

f:id:motemen:20140704132228p:plain

こんな感じに動く。シェルスクリプトで文字列操作するの面倒だなーと思ってたけど、Chrome の中なら JavaScript が使えるので便利だった。

私の死亡戦略: 『生命保険のカラクリ』を読んだ

生命保険といえばときどきテレビで詐欺のニュースやってるなあ、程度の知識しかなかったのだけれど、Kindle で入門してみたらけっこう面白かった。

生命保険のカラクリ

生命保険のカラクリ

社長(当時)によるまじぽかさんのコスプレでも有名なライフネット生命の副社長(今は社長のようだ)による本。

生命保険の機能

大雑把にまとめると、生命保険には2つの機能がある。

  • 保障(死亡・医療)
  • 貯蓄

保障ってのは普通に考えた意味での保険だ。みんなでお金を出し合って少しずつ積み立てておき、不慮の事態に遭遇した人に一定のお金を支払って扶助してやる、というもの。こういった仕組みで、人々にわたってリスクをならしている。いざという時の備えというのはコツコツと貯蓄をしていれば賄えるはずだが、貯蓄の量がほぼ時間に比例するのに対し、リスクは自分のことを待ってはくれない。明日にでも、空から降ってきた女の子が自分の頭蓋を直撃するかも分からないのだ。そんなわけで、個々人の観点から見ると、時間にわたってリスクをならしているのだと見ることもできる。これをこの本では「時間を金で買う」という表現で繰り返している。こちらは基本的に掛け捨てになる。保険会社がしているのは「リスク請け負い」と呼べる。

貯蓄も普通に考えた意味での貯蓄だ。掛金は積み立てられ、契約が満期になったタイミングで(運用益を加えた上で)返還される。たくさんのお金を預かる業務の性質上、こういった機能の商品が出てくるのも自然なことのように思える。それとも、月々一定額を支払っておきながら、運悪く(運良く)死ななかったときには金が手に入らないことを不満に思う客がいるからなのかもしれない。こちらの場合、保険会社は「資産預かり」をしている。

生命保険商品の種類

保険商品の種類には3つある。

  1. 定期保険
  2. 養老保険
  3. 終身保険

定期保険は前の機能分類で言うと「保険」のみの機能。なので掛け捨てだ。10年や20年といったスパンで加入し、期間内に死亡すると保険金が支払われる。満期になっても、契約を更新することで保障を続けることができる。もちろん死亡リスクは高齢になるほど高まっていくので、更新するたびに保険料も高くなっていく。

養老保険は「保険」+「貯蓄」。これは契約期間内に死亡すると保険金が支払われる点では前と同様だが、死亡せずに満期を迎えると満期金を受け取ることができるというもの。積み立ててきたお金が無駄にならないように思えるので、契約者としては嬉しいのかもしれない。ここで、途中で死亡した場合に支払われる金額にはそれまで積み立ててきた分のお金も含まれている。500万円の商品であれば、契約開始直後に死亡した場合は全額500万円が死亡保険金として支払われるが、300万円積み立てた時点で死亡した場合は200万円の死亡保険金+300万円の貯蓄により500万円の保障額となる。

終身保険も養老保険と同様だが、これは一生涯の死亡保障をおこなうもの(満期が100歳を超える年齢に設定されている)。老齢になるほど死亡リスクは高まっていき、保険料も高くなるので、若いうちから予め将来の分の保険料を含めて多めに支払っていることになる。まあこの構造は他の保険でもいっしょ。

医療保障

ここまで書いてみると、「ケガ・病気のときはどうするのか?」と疑問に思う。ぽっくりと死んでしまってお金が残るならそれはそれでいいけれど、重い病気を抱えて治療費はかかるわ食い扶持は減らないわとなったら大変そうだ。むしろこっちの方が心配だとも思える。 まあここのあたりの話はあまり仕組みめいていなくて、たんに制度的な話だったので(興味がなくて)ちゃんと理解できていないのかもしれないけど、

  • 三割の自己負担に加えて高額療養費制度というのがあるので、治療費がかさばる場合でも出費は比較的抑えられる。
  • 入院日数は短縮化の傾向にある。(医療保険は入院保障・手術保障というのが標準的らしい)

というところを鑑みると、体のガタが出始めるまでに貯蓄しておくというのでも賄えるのかもしれない。まあ自己負担率がこれからどうなるかは分からないし、まとまった出費があることに間違いはないので、公的の保障を補完するものとして備えておくという手はあるだろう。

何を選ぶべきか

まず、

  • 生命保険は少ない出費で大金を手にする手段ではない。(これに気づいたのが一番の収穫だった)
  • 時間をかけてよい将来への備えという点では、貯蓄をすればよい。

という前提で、

  • 複数の人間の人生がひとりの人間の収入に依存している場合は、死亡保障に入っておいたほうがよさそう。片肺運用は怖い。その場合、例えばサラリーマンなら定年後を過ぎての保障はいらないだろう。生きていたところで稼ぎを産みだすわけではないからだ。
  • 貯蓄は満期で受け取れるボーナスなどではなく、あくまで貯蓄だと分かった上で、必要そうだと思う分だけしてみてもいいかもしれない。保険会社が倒産したときのリスクと天秤にかけつつ、銀行に預けるよりはマシかどうか。全然調べてないけど、金利はたぶんいいんだろうな。

おわり

顧客・企業それぞれの観点から保険の仕組みを知ることができたのはけっこう楽しかった。数理的な部分も面白そう。ただ、企業の中の人が書いているわけなので自社に有利に話を進めているところはあるのかもしれない(ライフネット生命は貯蓄を扱っていないらしいので、そういう点とか)。日本では死亡保障が、欧米では貯蓄商品が人気らしいのだけど、その差がついた経緯も平易に説明してくれていて、知識ゼロでもかなり理解した気分になれる。

生命保険のカラクリ

生命保険のカラクリ

ghq 最近の変更とこれから

ghq

ども、ghq の方から来ました。各方面から PR いただいたおかげであれから機能がぐんぐん増えました。現在の最新バージョン 0.4 とリリース当初のバージョンを較べると:

  • GitHub (Enterprise), Google Code だけでなく、Git もしくは Mercurial に対応しているリポジトリであれば clone できるようになりました。
  • GitHub からの clone 時、ghq get -pssh プロトコルを使用します。
  • ghq get -shallow で、shallow clone(履歴を辿らない clone)を行います。Git のみ。
  • ghq get git@github.com… みたいなこともできるようになりました。
  • ghq import starred 時に GitHubAPI トークンを指定できるようになりました。
  • Homebrew tap ができました: https://github.com/motemen/homebrew-ghq
  • ghq.<url>.vcs 設定値で、リモートの VCS を明示的に指定できるようになりました。こんな感じです:
[ghq "https://ghe.example.com/"]
vcs = git

……などなど。ここで PR くださった方の名前はいちいち挙げませんが、ありがとうございます。おかげさまで大変たのしく過ごしております。

Tips

git-config には url.<url>.insteadOf, url.<url>.pushInsteadOf というキーがあり、これらを設定することで、それぞれ clone (fetch) や push 時に与えられた URL を書き換えてアクセスするよう Git に指示できます。

[url "git@github.com:motemen"]
pushInsteadOf = https://github.com/motemen
[url "git@ghe.example.com:"]
insteadOf = https://ghe.example.com/

こういう設定にしていると、git clone https://github.com/motemen/pusheen-explorer で clone したリポジトリからでもそのまま push できるようになりますし、git clone https://ghe.example.com/some/repo したときには ssh プロトコルを使って clone するようになります。ghq に限りませんが、便利な設定です。

これから

今後入れたい大きな変更としては、ghq import を ghq 本体の外に出すというのと(ghq import pocket は個人的にはスゲー便利だったんだけどたぶん誰も使ってない、標準入力から URL のリストを取って ghq get できるようにすればいいかな?)、検討中ですが設定ファイルを gitconfig から分離するってのがあります。考え中のところなんで、ご意見ご要望ご PR などございましたら GitHub のほうまでよろしくお願いいたします。