TokyoVim#18 に参加してきました。
TokyoVim#18 - connpass に参加してきました。
What's TokyoVim?
したこと
勉強会自体が1年ぶりくらいで内心緊張していたのですが、ほんの少しだけ遅刻して会場入りするといつもの TokyoVim な雰囲気でした *2
今日は長いこと更新をサボって陳腐化した vimrc をメンテしようと思っていたのですが、このところ JVM オペコードのリファレンスが欲しいと思っていたこともあり、vim-ref-jvmis を作ることにしました。
vim-ref-jvmis がそれなりに動くようになった後は、git でコミットメッセージを書く時になぜか 'c' が押された状態で Vim が起動してしまう謎現象を人力 bisect したりしていました *3
前回の KPT の Try で「中間成果発表しよう!」というのがあったようで、おやつタイムにプロジェクターを回しながら成果発表をしました。
残念ながら自分はほとんど成果がなかったのですが、周りの方々には大いに刺激を受け、そして学ぶものとても多かったです。
ぜひまた行きたいです。
JVM オペコードのリファレンスビューアが便利
使い方
" Vundle の場合 " vimrc に追記&再読込して :BundleInstall Bundle 'ebc-2in2crc/vim-ref-jvmis' " NeoBundle の場合 " vimrc に追記&再読込して :NeoBundleInstall NeoBundle 'ebc-2in2crc/vim-ref-jvmis'
Jvmis というコマンドが勝手に定義されるので、調べたいオペコードの上にカーソルを置いて :Jvmis を実行すると ref.vim インタフェースでリファレンスを閲覧出来ます。
リファレンスは The Java Virtual Machine Instruction Set から引いて来るので環境によっては一瞬もたつきますが、デフォルトでキャッシュを有効にしているので2回目以降は素早く引くことが出来ます *1
これでバイトコードリーディングがはかどりますね。
brew install mercurial で bin が入らない
現象
Homebrew で Mercurial をインストールしても /usr/local/Cellar/mercurial/<バージョン> に bin が入らない。
ログを見ても特にエラーや警告は出力されていないように見える。
手順
$ brew uninstall mercurial $ brew uninstall python $ brew install python $ brew install mercurial
補足
brew は依存関係を解決してくれるがユーザーが間違って依存関係を壊してしまうこともありえるので、上手くいかなかったら依存関係を疑ってみる、くらいはしてもいいかもしれない。
brew では deps コマンドで依存関係を確認でき、--tree オプションでツリー表示することも出来る。
使うとこんな感じ。
$ brew deps --tree mercurial mercurial |- :python $ brew deps --tree python python |- pkg-config |- openssl | |- makedepend | | |- pkg-config |- readline |- sqlite | |- readline |- gdbm
自分への小言
学び、教えろ。そして学べ。
勉強嫌いで苦労が嫌いな自分への小言を置いておく。
- 学べ。学び続けろ。
- 先後上下、別け隔てなく学べ。
- いつも効率的であろうとしろ。
- 汗をかくのを厭うな。
- 汗をかいて良しとするな。
- 汗をかかずに済むのを良しとしろ。
- 出来ない同僚には教えてやれ。
- 先後上下、別け隔てなく教えてやれ。
- 得意先、仕入先にも教えてやれ。
- 実を得たければ教えてやれ。
- 好んで苦労したければ教えるな。
- 教えるのは自分のためと思え。
chlordane カラースキーマが非常にかっこいいので浮気してみた。
chlordane.vim - GHOST IN THE SHELL like colorscheme : vim online
chlordane カラースキーマ
テキストエディターや IDE に始まり Twitter クライアントにも使うほど solarized を愛用しているのですが、最近見つけた chlordane という Vim 用カラースキーマが非常にかっこいいので、インストール方法兼ねて紹介してみようと思います。
chlordane カラースキーマのダウンロード
" Vundle の場合 " vimrc に追記&再読込して :BundleInstall Bundle 'vim-scripts/chlordane.vim' " NeoBundle の場合 " vimrc に追記&再読込して :NeoBundleInstall NeoBundle 'vim-scripts/chlordane.vim'
境界ワイルドカード型の指定方法が覚えられない
Java のジェネリックスで境界ワイルドカード型のパラメータを使用するときに、<? extends T> と <? super T> どちらを指定すればいいか迷っていた時期がありました。
今日はなぜか TL でジェネリックスの話題が多く *1 、当時のことを思い出したので懐古エントリを書いてみます。
PECS イディオム
Java で境界ワイルドカード型のパラメータを使用するときのイディオムは良く知られていて、Effective Java では以下のように述べられています。
どちらのワイルドカード型を使用すべきかを覚えるための略語は、次の通りです。
PECS は、プロデューサー (producer) -extends、コンシューマー (consumer) -super を表わしています。
プロデューサーの場合には <? extends T>、コンシューマーの場合には <? super T> を指定する、簡単です…なのですが、実際に使う段になると慣れないうちは「あれ? これは PECS の P と C どっちになるのかな?」といったことがありました。
Collections.copy
そんな時にふと見た Collections.copy のメソッドシグニチャー。
これがすごく分かりやすい。
パラメータ dest がコンシューマー (消費者)、src が プロデューサー (生産者) というのが一目瞭然です。
そう思わなくても境界ワイルドカード型の適用の仕方がまんま書いてあります。
public static <T> void copy(List<? super T> dest, List<? extends T> src) {
こういうのに頼るのはあまり良くないかもしれませんが、おかげで今では PECS を自然に扱えるようになりました。
ジェネリックス、まだまだ使いこなせていませんが便利ですねぇ。 *2
Effective Java 第2版 (The Java Series)
- 作者: Joshua Bloch,柴田芳樹
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2008/11/27
- メディア: 単行本(ソフトカバー)
- 購入: 77人 クリック: 936回
- この商品を含むブログ (267件) を見る