「とりあえず入門書は読んだけど…」の次に進むプルリク駆動学習

学習 雑感 GitHub

汎用性の高い技術ポエム Advent Calendar 2015 の3日目の投稿です．

普段はつくったものの紹介とか技術的に調べたことのメモとか勉強会参加記事を書いていて雑感とかは大体ツイッターに書いているんですが，最近どことなく頭にこびりついていることがあるので整理がてらブログに書きます．

とりあえず入門書は読んだ問題

新しい言語やフレームワークを学ぶ動機は様々です． つくりたいものがあってそれをつくるための知識として，言語機能が魅力的だから，流行っているからなどなど… 僕は一番最初の理由で始めることが多いですが，どれが良いとかいう話ではなく Pros Cons があると思います． 例えば僕の場合はつくりたいものが先にあるので体系的に学ぶよりはチュートリアルなどをさっと済ませてしまって動くものに取り掛かるので知識が偏ったりします．

そしてとりわけ後者2つに多いのが「とりあえず入門書は読んだけど次どうしよう」問題だと思っています．実際に「何かつくるアイデア無い？」とか聞かれることはたまにありますし，入門書を読んだだけで終わってしまうケースもあり勿体無いと思います．（僕も身に覚えがあります…） なぜこうなりがちなのか考えてみると，入門は大体皆同じような道を辿って学習するので本にしやすくやることもはっきりしやすくて良いのですが，その後進む方向はより具体的になって人によってばらばらになるからじゃないかなと思っています．

そんなときはプルリク駆動学習？

この「とりあえず入門書は読んだ」問題の次に進むのに，最近「こうすれば良いんじゃないかなぁ」と思っているのが GitHub の Pull Request（プルリク）駆動学習です．ざっとまとめると次のような手順です．

  1. 入門した言語・フレームワークを使ったプロジェクトで気になるもの，貢献したいものを探す
  2. そのプロジェクトのコードを読みまくる，何かのツールなら使いまくる
  3. 小さくても良いので改善点や不満点が出てきたら実際にコードをいじって直してみる
  4. プルリクエストにしてレビューを受ける

1. 入門した言語・フレームワークを使ったプロジェクトで気になるもの，貢献したいものを探す

学んだ言語・フレームワークで書かれたものを探します．何か気になっているものがあればそれを，無ければ GitHub で検索 します． 何でも良いと思っていますが，次の点に注意するのが良いのかなと思います．

  • なるべく小さいものを選ぶ（大きすぎると読むのが大変で 2. で力尽きそうです．1000〜2000行ぐらいが良さそう？）
  • 作り捨てられたものではなくメンテされているもの，テストがあるもの
  • Issues や Pull requests で活発に反応がある
  • マージ前にプルリクエストにレビューが入っている（重要）
  • すでに詳しい知人がいれば，その人のプロジェクトとか

2. そのプロジェクトのコードを読みまくる，何かのツールなら使いまくる

読んでいるコードは「同じ言語・フレームワークを使うけれども自分よりも習熟した人」が書いたコードのはずなので，基本的に読むだけでもかなり勉強になると思います． また，（printf などをはさみながら）実際に動かしてみるとどこがどう動いているのか分かって良いと思います．

ここでは，コードの書き方だけでなく，関連ツール群の使い方とかテストの書き方なども読み取れます（なかなかそういうことは入門書には書いていないと思います）．

3. 小さくても良いので改善点や不満点が出てきたら実際にコードをいじって直してみる

そうこうしているうちに，「こういうオプションがあると便利なんじゃないか」とか「ここはこうコードを変えたほうが効率が良いんじゃないか」とか「ここ間違ってるんじゃないか」とか出てくると思います．（TODO とか FIXME で grep してみるのも有効かもしれません．）

ここでリポジトリを fork し，新しいブランチ（名前は変更内容を反映していると良いですが，小さい変更なら patch-1 とかでも良いと思います）を作成し，実際にコードを足したり修正したりしてみます．

おそらく一発でうまくいかないので，デバッグしたり色々試したりすることになります．新規追加ならその箇所のテストを，修正なら修正できたことが確認できるテストを実際に書いて走らせてみます．

4. プルリクを出してレビューを受ける

GitHub の自分の fork したリポジトリページに行き，プルリク作成ボタンを押します． 自分の変更の目的・理由や変更内容の説明をします．あと，素直に「初心者なのでレビューお願いします」と書いておいたり，レビューしてほしい点をまとめて書いておくとさらに良いかもしれません．

ここで受けるレビューがとても勉強になると思っています．merge する側にとっても修正や機能追加してくれるのはありがたいですし，merge した後は自分がメンテしないといけないコードなので，積極的にレビューしてくれる可能性が高いです． 指摘された箇所はガンガン直していきます．ただし，プルリク作成時は以下の点に注意したほうが良いと思います．

  • ローカルでテストが通ることを確認する
  • CONTRIBUTING.md がある場合は絶対読む
  • コードスタイルに気を配る

英語が必要になったりしますが，相手も人間なので頑張れば割と通じます．日本語の issue OK なリポジトリを探してみるのも良いかもしれません（1. がちょっと大変になりますが…） また，3. の時点で書ききれなかった場合でも [WIP] とタイトルの頭につけてとりあえずでプルリクを出し，プルリクの説明中に目的ややりたいこと，どこで詰まっているかを書けばアドバイスがもらえてプルリクを完成出来たりします．

僕の場合

僕の場合は

などなど… どれも学習の助けになったと感じていますし，自分の欲しかった機能が入ったりリリースノートに自分の名前が載ったりして良かったです．

まとめ

GitHub は単なるリポジトリホスティングサービスじゃなく，ある種の SNS だと感じているので，それを学習に生かせるんじゃないかというのが最初の考えでした． もちろん必ずこれでうまくいくと思っているわけではないですが，「とりあえず入門書は読んだけど次どうしよ…」となったときの進め方の1つとして有りなんじゃないかなと思っています． 思っていることを整理しながら書いたのでところどころ偉そうな文になっている気がしますが，僕も分かっていないことだらけなのでもっと実践していきたいです． 「試しにやってみた」とか「ここはこうやったほうが良い」とか「もっと良い方法知ってる」などありましたら，ぜひ教えてもらえると喜びます．

なお，（力不足ですが）僕のリポジトリはどれも日本語 OK プルリク歓迎です．

vimconf でブラウザ上で Vim を使う方法を発表してきた

Vim vimconf javascript browser

f:id:rhysd:20151122222718j:plain

今年も vimconf にスタッフ兼発表者として参加してきました．名札の名前が「ドッグ」でじわじわきました…

開場

当日は準備スタッフの作業のために 8:30 に会場へ．山手線の遅延に巻き込まれて 8:45 ぐらいに到着． 電源ケーブルの配線などをやりました．

Vim on Browser

vimconf での発表は今年で3回目です．最近趣味ではウェブのフロントエンド周りや Electron を触っているので，今回は便利プラグインとかの実用的な話からそれて "Vim on Browser" というタイトルで発表してきました． ブラウザ上で「本物の」Vim を動かす話です．

内容は Vim.js の紹介と，自分がそれを使いやすくするためにつくった react-vimjs というコンポーネントの紹介およびデモでした． ライブコーディングとかするのは今回初めてなので2，3回ほど事前準備していて，無事問題なくこなせたので良かったです．今回のネタはブラウザから簡単に試せるので，良ければ是非見て動かしてみてください．

Emscripten や React.js については時間の都合上あまり詳しく紹介できなかったので，興味がある方は本家のチュートリアルなどをご参照頂ければと思います．

Emscripten でビルドした Vim の JS コードは MB 単位なので，なかなかウェブサービスに載せるなどは難しいと思いますが，何か良いアイデアがあればちょっとした遊びサービスなどに乗っけてもらえると楽しいかもしれません．

その他の発表について

Vim の GitHub への移行

kaoriya さんの発表は PC トラブルにより発表資料が表示できなくなったため口頭のみでの発表でした（すごい）．Vim が GitHub に移行したのはかなり日本人コントリビュータ達の貢献も大きかったというのを知れて良かったです．

deopelete

Shougo さんのつくっている neovim 向け補完プラグインについて．今まで neocomplete ではどうしてもブロッキングしてしまってストレスになっていた部分が解消され，UX が改善されたらしい．neovim のプラグイン機構については日本語だけでなく英語でも情報が少ないので，実装についての情報もいっぱい出してくれると嬉しいなと思いました．

サーバクライアント式の YouCompleteMe に不満があるというわけではないらしいので，どっちが良いかは結構ユーザによって変わりそう．（YouCompleteMe はソースを気軽に追加できるような仕組みになってない？）

Vim script の書き方

rbtnn さんによる Vim script の言語紹介．いくつか気持ち悪いエッジケースとかはあるものの，Vim script はそこまで書きにくくなくて嫌いじゃないです．ただ，デバッグ方法はもうちょっとなんとかしたい…

libcall の話

kamichidu さんの libcall の話．パフォーマンスの話と聞くと，if_lua 使うのと比べてどうなんだとか，文字列にシリアライズして動的リンクしたバイナリから渡してきたデータをデシリアライズするコストとか，パフォーマンス面が気になりました．

Vim + Clojure

ujihisa さんずっと Minecraft と Civ 続けていてすごい… 「REPL とか要らなくて QuickRun だけで良い」というのは割とそうかもなと思いました（ただ，やはり REPL がほしい場面もあると思う）．僕の場合は tmux の pane を新しく開いてそっちで repl 起動するので，Vim 向けの repl プラグインは必要としていない感じです．

海外 vimmer のプラグイン紹介

deris さんが夜なべして調べたとのこと．Vim プラグインを試すのは結構たいへんなので，こういう survey 系の発表は助かる…個人的には vim-table-mode が刺さったので後で試します．

OmniSharp.vim の話

thinca さんの OmniSharp.vim の話．Vim からでもスムーズに VisualStudio ばりの補完ができていてすごい… 2000〜3000 行ほどの大きいファイルでどうかとか，Unity で使ったりとかが気になりました．メンテナになったということなので，定期的に進捗確認していきます． ロゴそろそろどうにかしたい感じだったのでその場でつくってみたりしました．

vim-gita の話

lambdalisue さんの vim-gita の話． 僕は vim-fugutive はちょっとなぁと思うところはあるものの，git add -p のために使い続けてます… 普段の git のユースケースをグラフィカルかつインタラクティブにする方向で実装されているみたいで，色々とこだわりが感じられました．1.0 になるのが楽しみ…

LT

guyon さんの Yokohama.vim の話を聞いて，そういえば Vim 関連で最初に参加したのは Yokohama.vim だったなぁと思い出しました．当時は Vim テクニックバイブルが発売した直後で，Shougo さんにサインをもらったり，席の前に座っていたのが basyura さんだったりした記憶があります． もくもく会が多い Vim の勉強会界隈では，Yokohama.vim みたいな参加型のイベントは珍しいので，毎回新鮮な気持ちで参加させていただいてます．

懇親会

今まで微妙に会う機会がありそうでなかった zchee さんと話したり，アメリカで maktaba の開発者と話してきた haya14busa さんと話したり，t9md さんと Atom の話をしたりしました．t9md さんは Atom の新しい vim-mode をつくっているらしく，色々こだわりとかを聞けました．特にオペレータを発動時にカーソルを動かすのではなく範囲を一瞬フラッシュさせてユーザにフィードバックするというのが良さそうだなと思いました． その他にも色々な方と話しましたが，まだまだウェブ上でしか知らない方がたくさんいるので時間が足りなかった感があります…

まとめ

vimconf への参加は今年が3回目で発表も3回目なので，11月は vimconf の発表準備で忙しいみたいなのがなんか板についてきている気がします‥（今回は東京Node学園祭の発表もありましたし） 今年も色々興味深い発表が聞けたり，ここでしか会わない人と会えたりしてとても楽しめました． スタッフの皆さん（特に今回の vimconf を仕切ってくれた @dictav さん）本当にありがとうございました．

devdocs.io が便利すぎたので Vim プラグインつくった

Vim document

devdocs.io

最近，GitHub Trending Repositories のページで devdocs.io という便利なサービスを知りました．

f:id:rhysd:20151111205826p:plain

devdocs.io は複数のドキュメントを素早く横断的に検索できるサービスです．多分使ってみると一瞬で分かるので詳細は省きますが，各言語や DOM，React などのフレームワークのドキュメントをサクッと検索できます．どのドキュメントを有効/無効にするかも選択でき，IndexDB を使ってローカルにドキュメントを置くことでローカルでも利用できます．いつでも devdocs.io を開くだけで使えますし，モバイル対応もしています．

また，Ruby 2.2 と Node.js が入っていればローカルでも簡単に立てられます．デフォルトでもウェブデベロッパーにとってうれしいドキュメントがたくさん入っていますが，さらに Scraper を使ってローカルの devdocs に新しいドキュメントを追加することもできるようです.

devdocs.vim とは

ここ数日試しに使ってみて，なかなか使い勝手が良かったので Vim 内から直接 devdocs.io を開けるようにプラグインを作りました．

rhysd/devdocs.vim

主な目的は下記の2つです．

  • Vim の既存の K マッピングを使って，カーソル下の単語をすぐに devdocs.io で検索したい
  • ファイルタイプに特定のドキュメントを紐付けたい

Vim の既存の K マッピングを使って，カーソル下の単語をすぐに devdocs.io で検索したい

Vim にはカーソル下の単語を直接ドキュメント検索できる K というマッピングがあり，デフォルトでは Vim のヘルプを開いたり man を開いたりできます．この K を下記のように特定のファイルタイプだけ devdocs.io で開くように設定できます．

augroup plugin-devdocs
  autocmd!
  autocmd FileType c,cpp,rust,haskell,python nmap <buffer>K <Plug>(devdocs-under-cursor)
augroup END

例えば上記では C, C++, Rust, Haskell, Python のコードを書いている時に K で直接 devdocs.io を開きます．

ファイルタイプに特定のドキュメントを紐付けたい

例えば，僕は JSX なコードには javascript.jsx というファイルタイプを割り当てていて，この時は React.js のドキュメントだけ見たいとします．また，devdocs.io には TypeScript のドキュメントはありませんが，TypeScript を書いている時は JavaScript のドキュメントが役に立つので，TypeScript を書いている時は JavaScript のドキュメントを開きたいとします．その場合は下記のように設定すると，各ファイルタイプでページを開いた時のデフォルトのドキュメントを指定できるようにしました．

let g:devdocs_filetype_map = {
    \   'typescript': 'javascript',
    \   'javascript.jsx': 'react',
    \ }

ローカルの devdocs.io を開きたい

変数で指定できるようにしました．

let g:devdocs_host = 'localhost:9292'

その他の devdocs.io クライアント

下記のようなツールがあります．便利そう…