登る人のスペック

• 身長172.5cm、リーチ176cm、体重59kg(±1kgぐらい)

• ホームジム: B-PUMP TOKYO 秋葉原(2013～2016,7年ぐらい)から流浪の民を経て現在はロッキー新宿曙橋店

• 素足派を経て、現在は靴下履き派

• 外岩: RP二段、FL初段

• ジム: RP初段、OS1級

ジムのレンタルシューズ 11ヶ月ぐらい

秋葉原のB-PUMP、江戸川橋のT-wallで会社の部活動といった形で月1程度やってました。 この頃は履き心地はよくわかりませんでしたが、当時秋パンで5Qが登れるくらいまではレンタルでした。

Scarpa Force EU39

ボルダリングを始めてもうすぐ1年という頃、5Qが登れるようになったのでそろそろ自分もと思い、とにかく足に合うシューズを求めて購入しました。 ほとんど伸び縮みせず最初からジャストサイズで癖もないおかげで使いやすく、その後別のシューズを挟みながら合計三足買いました。

御岳にある「猫砂」という1Qを登り外岩のRPグレードを更新したり、 当時の秋パンで1級初段が登れたのもこのシューズだったので思い出深いシューズです。

このシューズさえあればよい、しいていえばトゥラバーがほしいかなと思ったりもしていました。 しかしポケットにつま先を突っ込むには丸みが邪魔をしていたり、傾斜でもうひと押し欲しいとき物足りなさを感じ別のシューズを探しはじめました。

LaSportiva Python EU37

2足目で買ったのがPythonです。Forceにも慣れ、そろそろダウントゥシューズにデビューしたいと思い購入。 定員さんの進められるままのサイズを選んだところ大後悔。 リンス付にして1サイズ(ハーフではない)伸ばしても激痛が走ってしまう始末。

(ここでリンス漬けとはぬるま湯のお湯にリンスを入れて、シューズを履いたままつける事で自分の足型に合わせていくことを指します。シューズを履いた状態で2、30分つけることで伸ばしていけます。)

痛すぎてつま先で乗り込めず、早々に2代目のForceを買い足しました。 サイズ選びは失敗しましたがトゥフックの性能は最高でした。 痛すぎてスリッパ履き(かかとは入れない)でもトゥフックがピタッと止まったのは衝撃でした。

LaSportiva Solution EU38

https://twitter.com/kashew_nuts/status/695047183649808384

Pythonの次に買ったForce以外のシューズがSolutionです。 当時は「忍者返し 1級」が目標で、シューズも思考錯誤していました。 フラットシューズだと傾斜のある壁で足が残りにくかったので、掻き込み性能が強いシューズがほしいと思い購入しました。

狙いとしていた掻き込み性能は抜群で、忍者返しもクラック取りまでは行けました。 しかしこのシューズで足が見えない状態での載せ替えに慣れてなかったり、 ジムはジムで足がぴったりすぎてスラブや垂壁で足が曲がらず使いこなせませんでした。 更に独特のヒールフックは人口壁でのツルツルしたホールドや小さいホールドにかけるのに慣れなかったこともあり、 基本的にはForceを履くようになってしまいました。

Tenaya Oasi UK5.5

現在もメインシューズであり、4足に渡って履いています。 PythonとSolutionの反省から、以下のようなシューズがほしいと思ってました。

https://twitter.com/kashew_nuts/status/743066639004897281

フラットシューズなら長時間履いていても快適なのですが、 傾斜のある壁も登りやさや小さな穴につま先を突っ込もうとすると多少ダウントゥしていたほうが都合がいいと思っていました。 結果これまで履いたことのあるダウントゥの中で一番自分にあってると思い、デザインが好みなこともあり愛用しています。

https://twitter.com/kashew_nuts/status/762523929747427328

「忍者返し 1級」を初めとする三大クラシック課題完登時や「デッドエンド横断 初段」、「水際カンテ 二段」などグレード更新時には常に履いていました。 シューズの力で勝手にホールドにかかることはないのですが、自分がやりたいことそのままに動いてくれるコントロール性能と長時間履いていても疲れない快適性は本当に気に入っています。

トゥラバーの面積が少ないのでシューズの力でトゥはかからないし、硬めにガッツリとヒールをかけたいときはソールが負けてしまうことがあったりしましたが、 トゥフックは練習したらある程度できるようになったのと、硬めのヒールもベルクロの調整の仕方を変えたら問題なくなったりと自分に足りないところをそのまま教えてくれるトレーニングシューズであり本気シューズになっています。

LaSportiva Miura Reboot EUR38.5

通販で購入したOasiがいつ届くのか不明になったときヒールに剛性があるのがほしかったのと、外岩にも使えるなーと思い荻パンで購入。 サイズは合っていたし足には馴染んだけど買ったばかりでソールの硬さに慣れず、買った翌日Oasiがすぐに届くことがわかってしまいその後履いてない… Oasiだとエッジングやヒールフックで負けてしまうときに使えるかもと、外岩に行くときはサブで持ち歩いています。(がいまのところ出番がない)

https://twitter.com/kashew_nuts/status/1011500153042132992

MadRock Remora UK6.5 EU40

これは御岳に行ったときシューズを忘れてしまったので、急遽現地のマウンガで調達したもの。 ベルクロなしの完全スリッパタイプで足のサイズもドンピシャだったので、使い心地は結構良かったです。 履いたのはこの1回のみで、Oasiが使えなくなったに履こうかと思ってます。

https://twitter.com/kashew_nuts/status/1109260441321037824

UNPARALLEL UP-RISE ZERO UK6.0 EU39.5

ジムでトゥフック課題ができるようになりたいと思い、練習用途に購入。 個人的に練習用にはダウントゥシューズよりフラットシューズの方が扱いやすいので、その中でトゥラバーが広めでヒールカップも剛性が高いものを選びました。

狙いはよくて良い練習になりましたが、左ふくらはぎが突っ張る感じがする上に足のフィット感が悪く感じ、ある程度練習したら履かなくなってきました。 購入時にハーフ攻めた結果でしたが、これは攻めないほうが良かったかもしれないです。 現在も左のトゥフックは右に比べると苦手なので、時が来たら引っ張り出すかもしれないです。(その時はハーフサイズ上げたものを購入して)

https://twitter.com/kashew_nuts/status/1285466940807368706

雑記

他のシューズを試したいときもありますがScarpaのINSTINCT VSRやLaSportivaのSKWAMAは履いてる人が多すぎるなと感じてるので購入に至ってないです。 Tenayaで新しいシューズが出るとOasiから買い換えられるシューズでてないかなーと見るときもありますが、なかなかピンときてないところ。 「もっとこれがほしい！」というときが来るときがでてきたら考えるのでよいかもしれません。

WSLについて

WSL1と2の違いや仕組みを把握するには以下を参照するとよさそう。

WSLのアーキテクチャ - roy-n-roy メモ

ターミナルアプリケーション

WSL2にふれるのに便利なターミナルアプリケーションがほしかったので、先日正式版になった Windows Terminal を使っている。 Powershell, cmd.exe, WSLとタブを切り替えながら作業できるのがよい。現在の設定は以下。

// To view the default settings, hold "alt" while clicking on the "Settings" button.
// For documentation on these settings, see: https://aka.ms/terminal-documentation

{
  "$schema": "https://aka.ms/terminal-profiles-schema",

  // 自分が使いたいprofileのguidを指定する
  "defaultProfile": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
  "initialCols": 120,
  "initialRows": 50,

  "profiles": {
    "defaults": {
      // Put settings here that you want to apply to all profiles
      "colorScheme": "Dracula",
      "cursorShape": "filledBox",
      "fontFace": "Ricty Diminished",
      "fontSize": 14,
      "hidden": false
    },
    "list": [
      {
        // Make changes here to the powershell.exe profile
        "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
        "name": "Windows PowerShell",
        "commandline": "powershell.exe"
      },
      {
        // Make changes here to the cmd.exe profile
        "guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
        "name": "cmd",
        "commandline": "cmd.exe"
      },
      {
        // Make changes here to the wsl.exe profile
        "guid": "{07b52e3e-de2c-5db4-bd2d-ba144ed6c273}",
        "name": "Ubuntu-20.04",
        "source": "Windows.Terminal.Wsl",
        // 起動時にHOMEディレクトリで開くようにする
        "commandline": "wsl.exe ~"
      },
      {
        // Make changes here to the azure profile
        "guid": "{b453ae62-4e3d-5e58-b989-0a998ec441b8}",
        "name": "Azure Cloud Shell",
        "source": "Windows.Terminal.Azure"
      }
    ]
  },

  // Add custom color schemes to this array
  "schemes": [
    {
      "name": "Dracula",
      "background": "#282A36",
      "black": "#21222C",
      "blue": "#BD93F9",
      "brightBlack": "#6272A4",
      "brightBlue": "#D6ACFF",
      "brightCyan": "#A4FFFF",
      "brightGreen": "#69FF94",
      "brightPurple": "#FF92DF",
      "brightRed": "#FF6E6E",
      "brightWhite": "#FFFFFF",
      "brightYellow": "#FFFFA5",
      "cyan": "#8BE9FD",
      "foreground": "#F8F8F2",
      "green": "#50FA7B",
      "purple": "#FF79C6",
      "red": "#FF5555",
      "white": "#F8F8F2",
      "yellow": "#F1FA8C"
    }
  ],

  // Add any keybinding overrides to this array.
  // To unbind a default keybinding, set the command to "unbound"
  "keybindings": [
    { "command": "copy", "keys": ["ctrl+shift+c"] },
    { "command": "paste", "keys": ["ctrl+shift+v"] }
  ]
}

以下のように日本語の扱いなどでまだ難ありなところはあるが、一旦許容して使っている。 この辺もクリアになるということなしかなー。

• IMEでインライン補完が効かない

• 少し古いVimを使っていたら記号や濁点付き文字の表示がおかしくなったりした

• tmuxの描画が乱れるように感じる

• tigで縦線が表示されない

https://twitter.com/kashew_nuts/status/1269494772349014016

WSL2のインストール

まず WSL 2 Linux カーネルの更新 を実施。 次に Windows Subsystem for Linux (WSL) を Windows 10 にインストールする に従って、Microsoft StoreからUbuntu 20.04 LTSをインストールした。 その後普段使うPythonやVim, Git関連のツールをインストール。

$ sudo apt update -y && sudo apt upgrade -y
$ sudo apt install python3-venv python3-dev nodejs npm zip unzip vim-gtk golang xsel hub tig
$ git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm
$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ python3 get-pip.py --user
$ go get github.com/x-motemen/ghq

あとは dotfiles を落として来て、展開すれば準備OK。

クリップボードどうする

VirtualBoxのようなVMを使っているときも悩みのタネだったが、今回はtmuxでclip.exeを使うようにした。 普段からターミナルでのコピペはキーボードで完結させていたので、同じようにしたかった。

調べると equalsraf/win32yank が良いという記事があったが、 自分の環境では動かなかったのでOS標準で入ってるのを使うことにしました。 clip.exeはコマンドプロンプトでもPowershellでも使えるので、考えることを減らせていいと思った。 以下のようにファイルを用意してWSL環境のときだけ読み込むように設定。

# ~/.tmux.conf
if-shell 'test "$(uname -a | grep Linux | grep microsoft)" != ""' "source-file ~/.tmux.conf.wsl" ""

# ~/.tmux.conf.wsl
bind-key -T copy-mode-vi Enter send-keys -X copy-pipe "cat | clip.exe"
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel 'cat | clip.exe'
bind-key -T copy-mode-vi Y send-keys -X copy-pipe 'cat | clip.exe'

ただこれだとVimでヤンクしたときにクリップボード連携ができていないのでvimrcに以下の設定を追加する。 +clipboard なVimである必要があるので、 sudo apt install vim-gtk などして有効にしておくこと。

" ~/.vimrc
if system('uname -a | grep microsoft') != ''
  augroup myYank
    autocmd!
    autocmd TextYankPost * :call system('clip.exe', @")
  augroup END
endif

Docker, docker-composeはどうか

以下の公式ドキュメントを参照しインストール。

• Install Docker Engine on Ubuntu | Docker Documentation

• Install Docker Compose | Docker Documentation

sudoなしでdockerコマンドが使えるように以下も設定。

# 現行ユーザをdockerグループに所属させる
sudo gpasswd -a $USER docker

# dockerデーモンを再起動する
sudo service docker restart

# exit後、再ログインして反映
exit

hello-worldは普通にできて、 Docker Desktop WSL 2 backend も問題なく動いたので正直驚いた。しかし WSL2によるホストのメモリ枯渇を防ぐための暫定対処 - Qiita のようにリソース管理から解放されたわけでないので、WSL2のメモリ上限は最低限設定しておいたほうがいいだろう。

Docker Desktop WSL backendは Docker Desktop for Windows をインストールして、WSL2のセットアップが完了してれば使える。

「DockerとWSL 2を使用して最高の開発エクスペリエンスを実現するには、デフォルトのLinuxディストリビューションにコードを含めることをお勧めします。」と公式ドキュメントにあったが、これに沿わない使い方をする場合、WSL2を選択すべきでないのだろう。

エディタやIDE

Vimが使えるので問題ない….のだが、一応かんたんに実行できるかは調べた。

雑感

凝った使い方をしてないので万人におすすめできるかはわからないが、ひとまずは好印象。Ubuntu DesktopだとAdobe, Kindleが使えないのと、Bluetoothやオーディオ周りで手こずることがあったが、Windowsではそのあたりを気にしなくていいというメリットも得ている。

WSL2に関連するところで感じたのは以下。いいところも気になるところもありつつ、しばらくは付き合ってみようかなと思ってる。

Ubuntu20.04LTSとは

2年に一度リリースされる長期サポート版です。サポート期間が5年間提供されます。 それまで使っていたUbuntu18.04LTSのあと、18.10, 19.04, 19.10を一気に飛ばしてのアップグレードでした。 ちょっとドキドキしながらでしたが無事アップグレードできました。

アップグレードの手順について

Upgrade Ubuntu desktop を参照して実施しました。

イントール時間

インターネットの回線速度が200Mbpsとかでている朝に実施したので、1時間足らずで完了しました。

アップグレード後実施したこと

必要なパッケージのインストール

デフォルトのPythonのバージョンが上がっていたり、nodejsまわりが消えていたので再インストールしました。

• sudo apt install python3-venv python3-pip nodejs npm

• deadsnakes から sudo apt install python3.7 python3.7-venv

Ubuntuでどうやってシステム側にpipをいれるかは毎回悩ましいのですが、今回はaptで入れました。

vimの再インストール

自前でビルドしているため、依存関係が変わったあとは再インストールが必要でした。今回はPython3の場所を指定するだけでOKでした。 vimのリポジトリーはgit clone済みなので、 vim/src ディレクトリーに移動して以下のコマンドを実行します。

$ make distclean
$ ./configure \
    --with-features=huge \
    --enable-gui=auto \
    --enable-python3interp \
    --with-python3-config-dir=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/ \
    --enable-fail-if-missing
$ make
$ sudo make install

ビルド方法については vim-jp » Linuxでのビルド方法 も参考にしてください。

xselの再インストール

ここまでで一応必要なパッケージは揃っていたのですが、以下の現象が再発しました。

https://twitter.com/kashew_nuts/status/1028169590965121024

Ubuntu18.04LTSのときにインストール済みだったのですが、下記手順でインストールし直したところ改善されました。

$ sudo apt remove xsel
$ sudo apt install xsel

最後に

アップデート自体はすんなり行えました。ひとまずまたUbuntuの民に戻ろうと思います。

ただUbuntu18.04LTS時代はオーディオ関連に悩まされていたので、使っていってどうなるかは気になっています。 有線でイヤホンを使っているときは問題なかったですが、AirPods Proとは接続がなかなかできなくてペアリングし直したりしてました。 さすがにmacOSほど親和性はないと思うので、うまく付き合っていけたらいいなー。

coc.nvimとは

いろんな記事で説明されてますが、Vim8/Neovim向けのインテリセンスエンジンでLSPのフルサポートを謳ったプラグインです。

移行理由

移行しようと思った理由は以下の3つです。「これなんてVSCode？」となったとかならなかったとか。

• 自動補完が「ちょうどいい」感じで補完してくれる

• 拡張が豊富で、LSPに限らずIDEとしての機能を提供してくれる

• Language Serverの設定でvimrcが膨れない

インストール要件

現在のインストール要件は以下となっています。

• Vim >= 8.0.1453

• node.js >= 8.10.0

• npm

当初2019年に試したときはVimの場合Python3インターフェイスや neoclide/vim-node-rpc 、yarnに依存していましたが、現在は依存が消えているので使いやすくなりました。(ソースからビルドするときはyarnが必要となります。

Vimの下限のバージョンはUbuntu 18.04LTSとかならデフォルトで満たしていますが、できればpopup-windowを活用するのに、8.2以上だとよりよいでしょう。 node.jsも現在のLTSの下限である10.x系にしたほうがよいと思います。

詳細は Install coc.nvim を参照のこと。

インストール方法

vim-plugを使ってる場合、 vimrcに以下のように記述します。 その後、Vimを再起動しコマンドラインモードで :PlugInstall すればOKです。

Plug 'neoclide/coc.nvim', {'branch': 'release'}

Quick Start の通りですね。

使い方

coc.nvimをインストールしたあとは拡張やLanguage Serverをインストールして使うだけ。 どんな設定ができるかや、Language Serverの設定をすればいいかは以下のWikiやヘルプを参照するとよいです。

• neoclide/coc.nvim Wiki

• coc.nvim/coc.txt

まずは自分の使うFileTypeの拡張を入れたり、設定ファイルの記述を便利にするために :CocInstall coc-json はしておくとよいでしょう。

popup-windowについて

coc.nvimに限らずVimのLSPクライアントを活用していくとき、popup-windowが有効になっていると便利です。 コマンドラインモードで :echo has('popupwin') を実行したとき、 1 が返ってくると有効になっています。

Vim8.2を使っていれば問題なくpopup-windowが使えると思いますが、colorschemeが追従しているかも確認しておくとよいかもしれません。 自分は昔から tomasr/molokai を使っていますが、popup-windowで使うハイライトの指定がされていません。

下記のドキュメントを参考に、ハイライトの指定を行いました。

• popup

• syntax

" 設定したハイライト
" ~/.vim/colors/molokai.vim
hi Pmenu guifg=#f8f6f2 ctermfg=15 guibg=#35322d ctermbg=236
hi PmenuSel guifg=#000000 ctermfg=16 gui=bold cterm=bold
hi PmenuSbar guibg=#35322d ctermbg=236
hi PmenuThumb guifg=#d9cec3 ctermfg=252

他のcolorschemeもいくつか見て、最終的に sjl/badwolf を参考にさせていただきました。 使ったときのイメージはこんな感じです。

https://twitter.com/kashew_nuts/status/1229781512050003968

気になるところ

良い点もあれば気になるところもあるということでかんたんに書きます。

• 設定ファイルがJSONのため、PATHの設定を書くと異なるOS間で共通化しにくい

• NeoVimでのみサポートとかあるので、coc及び拡張の機能が自分の「Vim」に対応しているか確認する必要がある

• トラブルシューティングにはJavaScript/TypeScriptまわりの知識が必要になる

現状なにか詰まったりしたときに「そういえばそうだったな」と思うぐらいなので、気に留めておくぐらいでいいかもしれません。

設定ファイル例

設定ファイルは README を参考に自分に必要な記述をすればと思いますが、自分のも一例としてリンクを載せておきます。 こだわりとしてはcoc.nvimを使わないFileTypeでは、キーマッピングなどを上書きしないようにしています。

• vimrc

• coc-settings.json

終わりに

使用感自体は快適です。vim-lspと比べるとnode.jsへの依存が増えていますが、Language Serverによっては関係なく必要なのであまり気にしていません。LSPひとつとっても、Vim界隈はこういった切磋琢磨が目に見えるので使っていても楽しいですね。

前提とする環境

• Vim: 8.0以上、かつコンパイルオプションで jobs, timer, channel, lambda が有効になっている

• Python: 2.7もしくは3.4以降 (pyenvやAnacondaでインストールしたPythonは考慮しない)

LSP(Language Server Protocol)とは

ざっくりいうと自動補完や定義ジャンプ、ドキュメントのホバー表示などエディタごとに実装していた機能を、言語Serverを用意して複数の開発ツールで使えるようにしましょうというものです。LSPを活用することでエディタのプラグインなどは最小限の労力で言語をサポートできるようになります。

各エディタ用にLSPを使うプラグインや機能を用意する必要がありますが、補完機能をサポートするサーバーが共通化できるのでそのServerが便利になると1つのエディタだけでなく複数のエディタで活用できるメリットがあります。

どのようなプロトコルでどのように通信しているのかは、 Microsoftが公開しているドキュメント が詳しいのでそちらを参照してください。 Software Design 2018年3月号 にも詳しく書いています。(残念ながら紙の書籍は2019/01/26現在在庫がないようです)

LSP導入

Python用のLanguage ServerとClientとなるVimプラグインを導入します。ServerとClientは以下になります。

• Language Server: palantir/python-language-server

• Client: prabirshrestha/vim-lsp

" vimrc
Plug 'prabirshrestha/vim-lsp'
Plug 'prabirshrestha/async.vim'

" vimrc
" デバッグ用設定
let g:lsp_log_verbose = 1  " デバッグ用ログを出力
let g:lsp_log_file = expand('~/.cache/tmp/vim-lsp.log')  " ログ出力のPATHを設定

" 言語用Serverの設定
augroup MyLsp
  autocmd!
  " pip install python-language-server
  if executable('pyls')
    " Python用の設定を記載
    " workspace_configで以下の設定を記載
    " - pycodestyleの設定はALEと重複するので無効にする
    " - jediの定義ジャンプで一部無効になっている設定を有効化
    autocmd User lsp_setup call lsp#register_server({
        \ 'name': 'pyls',
        \ 'cmd': { server_info -> ['pyls'] },
        \ 'whitelist': ['python'],
        \ 'workspace_config': {'pyls': {'plugins': {
        \   'pycodestyle': {'enabled': v:false},
        \   'jedi_definition': {'follow_imports': v:true, 'follow_builtin_imports': v:true},}}}
        \})
    autocmd FileType python call s:configure_lsp()
  endif
augroup END
" 言語ごとにServerが実行されたらする設定を関数化
function! s:configure_lsp() abort
  setlocal omnifunc=lsp#complete   " オムニ補完を有効化
  " LSP用にマッピング
  nnoremap <buffer> <C-]> :<C-u>LspDefinition<CR>
  nnoremap <buffer> gd :<C-u>LspDefinition<CR>
  nnoremap <buffer> gD :<C-u>LspReferences<CR>
  nnoremap <buffer> gs :<C-u>LspDocumentSymbol<CR>
  nnoremap <buffer> gS :<C-u>LspWorkspaceSymbol<CR>
  nnoremap <buffer> gQ :<C-u>LspDocumentFormat<CR>
  vnoremap <buffer> gQ :LspDocumentRangeFormat<CR>
  nnoremap <buffer> K :<C-u>LspHover<CR>
  nnoremap <buffer> <F1> :<C-u>LspImplementation<CR>
  nnoremap <buffer> <F2> :<C-u>LspRename<CR>
endfunction
let g:lsp_diagnostics_enabled = 0  " 警告やエラーの表示はALEに任せるのでOFFにする

使用感について

jedi-vimと比べたときのメリット/デメリットを書いていきます。

終わりに

自動補完(オムニ補完)や定義ジャンプの使い方は変わらないですし、仮想環境(venv/virtualenv)にも対応しています。 リネームに関してはropeよりjediに統一したほうがよいのでは？と思ったりしますが、現状リネームに関してはさほど気にしていない感じです。 今後LSPが進化していって、安定して高速な開発環境ができていくといいなぁと期待しています。

2018年の総括

https://twitter.com/kashew_nuts/status/1079732019314081792

だいたいこんな感じでしたが、せっかくなのでちょっと細かく見ていきたいと思います。

購入したものとか

買ってよかったなーと思うのを厳選するなら以下の5つ。

• Inspiron 13インチ 7000シリーズのフルスペック版: 現在はUbuntuデスクトップで運用

• Apple iPhone XR 128GB: 色はコーラルを選択。6sからの乗り換え。バッテリー持ちの良さは安心

• Amazon Kindle Paperwhite: 読書が捗るけど、PDFはA4が多いから向かないですね….

• Anker PowerCore Fusion 5000: プラグ搭載型なので移動時の持ち物が減って便利

• Cable Matters USB C to DisplayPort 変換アダプター: Ubuntuデスクトップでも4K対応

2019年の抱負

優先度が高いのは絞らないと10、20と並んでいくので3つ書きます。

終わりに

まずはじめて、それを習慣化していくしかないかなーと思うので2019年はそれを増やしていきたいですね。

前提とする環境

自分が普段使っている以下の環境が前提としています。

• OS: macOS (Sierra)、Ubuntu18.04LTS

• Vimのバージョン: 8.0以上

• Pythonのバージョン: 3.6.x

• Vimプラグインマネージャー: junegunn/vim-plug: Minimalist Vim Plugin Manager

junegunn/fzf.vim: Fuzzy Finder

インタラクティブ(対話的)にファイル・タグ・文字列を一覧に出力して、あいまい検索してくれるツールです。 他によく聞くツールだと ctrlpvim/ctrlp.vim やより汎用なツールを謳う Shougo/denite.nvim があります。

" Windowsの場合は別途手動インストール
Plug 'junegunn/fzf', has('win32') ? {} : {'dir': '~/.fzf', 'do': './install --all' }
Plug 'junegunn/fzf.vim'

よく使うコマンド

最初は Files を使うだけでも快適さの一片を味わえるかと思いますが、現在よく使うのは次の5つです。

• Files: カレントディレクトリ以下のファイル一覧を表示。一覧から選択したファイルを表示できる。

そのままでも便利ですがプレビュー画面を有効にするため、vimrcに以下の設定を記述しています。

" ファイル一覧を出すときにプレビュー表示
command! -bang -nargs=? -complete=dir Files
\ call fzf#vim#files(<q-args>, fzf#vim#with_preview(), <bang>0)

• Grep: 自分で定義したgrepコマンドの拡張。プレビューしながらインタラクティブにgrep検索できる。

ag は や Ag コマンド、 ripgrep は Rg コマンドをデフォルトで持っているのですが、 自分が普段使う pt はコマンドを持っていないので以下のように定義して使っています。

" https://blog.fakiyer.com/entry/2017/08/06/222936
function! s:find_git_root()
  return system('git rev-parse --show-toplevel 2> /dev/null')[:-2]
endfunction
" 外部コマンドptを使用してプレビューしながらgrep検索する
command! -bang -nargs=* Grep
\ call fzf#vim#grep(
\   'pt --column --ignore=.git --global-gitignore '.shellescape(<q-args>), 1,
\   <bang>0 ? fzf#vim#with_preview('up:60%')
\           : fzf#vim#with_preview({ 'dir': s:find_git_root() }),
\   <bang>0)

• History: 最近開いたファイルと現在開いているバッファを表示できる。

• Buffers: 現在開いているバッファを表示できる。

• Tags: プロジェクト内でタグ生成から検索までできる。

w0rp/ale: 非同期Linter/Fixerエンジン

ALE は Asynchronous Lint Engine の略です。Vimの快適な編集を邪魔することなく、コードチェックができます。 ALEは2018/12/01時点で110もの言語に対応しているので、Pythonに限らずBashやMarkdown、JSONなどにも使えます。

実際に使用しているイメージは以下の図のようになります。

CI実行時にFlake8やmypyのようなツールを使うよう環境は整えたりはよくすると思いますが、 CIの実行を待たずにVimで編集中に実行できるようにしたかったのでALEを導入しました。

Plug 'w0rp/ale'

$ python3.6 -m venv venv
$ source venv/bin/activate
(venv) $ pip install flake8 mypy
Collecting flake8

.... #  Flake8やmypyの関連パッケージがインストールされる

Installing collected packages: mccabe, pyflakes, pycodestyle, flake8, typed-ast, mypy-extensions, mypy
Successfully installed flake8-3.6.0 mccabe-0.6.1 mypy-0.641 mypy-extensions-0.4.1 pycodestyle-2.4.0 pyflakes-2.0.0 typed-ast-1.1.0

let g:ale_linters = {
\   'python': ['flake8', 'mypy'],
\}

" ファイル保存時にLinterを実行する
let g:ale_lint_on_save = 1
" テキスト変更時にはLinterを実行しない
let g:ale_lint_on_text_changed = 'never'
" Linter(コードチェックツール)の設定
let g:ale_linters = {
\   'python': ['flake8', 'mypy'],
\}
" ファイル保存時にはFixerを時刻しない
let g:ale_fix_on_save = 0
" テキスト変更時にはFixerを実行しない
let g:ale_fix_on_text_changed = 'never'
" Fixer(コード整形ツール)の設定
let b:ale_fixers = {
\   'python': ['autopep8', 'isort'],
\}
" 余分な空白があるときは警告表示
let b:ale_warn_about_trailing_whitespace = 0
" ALE実行時にでる目印行を常に表示
let g:ale_sign_column_always = 1

airblade/vim-gitgutter: 追加・変更・削除された箇所のマーカー表示

ALEでコードチェックができるようにしたら、Gitでバージョン管理してるコードに変更があったのかもできるようにしたくなりました。

以下はvim-gitgutter作者が公開している使用イメージ画面です。

15行目が変更され、21-24行目が新規に追加、25-26行目の間の行が削除されています。 vim-gitgutterを導入して自分がどこを変更をしたのか、意図していない変更はないかがすぐわかるようになりました。

Plug 'airblade/vim-gitgutter'
" 目印行を常に表示する
if exists('&signcolumn')  " Vim 7.4.2201
  set signcolumn=yes
else
  let g:gitgutter_sign_column_always = 1
endif

終わりに

fzf.vim, ALE, vim-gitgutterと3つのプラグインを紹介してきました。 今回は紹介しきれなかったプラグインも dotfiles/vimrc にあるので興味があれば見てみてください。

スケジュール感

書き出すときりがないのでざっくりと書くとこんな感じ。

• 10/19[Day0]: 移動

• 10/20-25[Day1-5]: クライミング

• 10/26[Day6]: 移動

初日と最終日の移動は本当に疲れたので、次回いくとしたらフレズノから行きたい…. 成田→サンフランシスコの直行便でいったが、渋滞にハマったおかげで初日宿についたのは0時を回ってた。

「レスト日どうする？」なんて会話もしていたけど、結局ヨセミテにいた5日中5日とも登ってた。 明確なレスト日はなかったけど毎日12-18時間ぐらいずつレストしてたのと、ワクワク感が尽きなくて今回は必要なかった。 だいたい10-12時から18時ぐらいしかエリアにいなかったり、移動も車で数十分かかることもあり登ってる時間もそこまで多くなかったのかな。

V7, V8以上の課題を完登しようと思ったら、 2週間ぐらいまとめていかないと足りない と感じた。

宿とか食事とか

今回止まったのはCamp4…じゃなくてヨセミテ園内にあるロッジ。 Airbnbで宿を取った。通信網は事前情報から諦めていたのでそれ以外の洗濯機や乾燥機、暖房もあるしすごいなーと思っていたら階段がヤバかった。

食事はDay0の行きがけに1週間分の食料を買ってから行ったのだけど、0時過ぎに着いて水やスーツケース、食べ物類を抱えて何往復もした。 「他の宿より安いのはこれが理由か….」とメンバー全員が思ったとか。

自炊力の高いメンバーが居てくれたおかげで食事に苦労することはなかった。感謝しかない。

移動とか

レンタカーを2台体制で行きました。自分が運転の経験値が浅いこともあり、ほとんどお任せする形になってしまったが、 ヨセミテ園内で海外で運転する実績は解除できた 。

日本から海外にいって運転するときは国際運転免許証が必要らしいのだが、今回はレンタカー会社がやっていた運転免許証翻訳フォームから発行できたのでそちらを使用した。必要な条件は満たしている上に、発行の手間も非常に少なかったので便利。

持ち物

宿に洗濯機があるのがわかっていたので服とかも3,4日分の荷物でいったけど十分足りた。

• 航空会社にANAを使ったので手荷物1つと預け荷物2つを持っていけた。

• 今回は手荷物をノースフェースのフューズボックスにして、預け荷物をスーツケースとクラッシュパッド(以下マット)にした。

• 現地で購入する手段もあったが、パモも持って行きたかったので自前で持っていった。

• パモのような細いものはマットの間に挟んでも抜けて紛失する恐れがあったので、行きは空港の バゲージラッピングサービス を活用していった。一緒に行ったメンバーは車用のラゲージネットで包んでいっていた。ラッピングしてもらうのもよかったが、空港である程度時間も使うので次回はこっちを検討しようと思う。

お財布事情

今回はカード1枚しかもっていかなかったけど、2,3枚+50~100ドルの現金があればベストかなと。 (1ヶ所なかなかカードの認証が通らなくて焦ったりしたのでバックアップ大事)

• 基本カード(クレジットなりデビット)があればそれで足りる、というかないと不便。

• しかし例外的に1グループごとに現金は50〜100ドルぐらいは持っていないと慌てる可能性がある。ただ100ドル札があっても断れることがあるらしいので、10ドル札とかを何枚か持っておく感じ。

• 以下は今回現金が必要だった場所

  • ヨセミテ園内にあるガソリンスタンド (日本のカードってアメリカのガソリンスタンドで通らないのを知った)

  • 通行料がある橋

通信網について

サンフランシスコあたりでは快適につながったが、ヨセミテ全体ではエリアによる感じでした。

• 今回はAT&TのMVNOであるMOST SIMをAmazonで購入して行った。

• Sprintだとヨセミテ園内では電波が入らなくないらしい(電波を掴んでもつながらなかったり)

• 空港から途中まではしっかりつながっていたが、ヨセミテ園内に入るとつながる場所はつながるが、つながらないところはどうしてもあった。

• 観光スポットになっていたり、Camp4やCurry Villageではつながりやすかったが、常にiPhoneのアンテナが4本立っているというわけではなかった。(これは予め知らないとわからないことだったので、ちゃんとSIMフリーiPhoneを持って、つながるSIMを選んで行けてよかった)

動画撮影とか

iPhone6sの空き容量を40GBぐらい空けて行ったけど、撮りっぱなしで撮影することもあったので全然足りなかった。 次の機種は128GBか256GBにするかな……それか、撮りっぱなし用途ならGoProみたいなのを持ち歩いたほうがよいのかも。

登った(トライした)課題

登れた課題も登れなかった課題もいくつもあって、思い出深いので今回使用したトポ SuperTopo Yosemite Valley Bouldering のエリア名、ページ数、課題番号とともにメモしておく。

Camp4 - West [P128-]

乗り込みにくかったり、ホールディングにコツが必要だったりとグレード関係なく試される感じがしたエリア。

1. Unnamed V3(★): 未完登。

   狭くて悪くて「これ本当にV3！？」って課題だった。

3. Unnamed V3(★): 未完登。

   これも保持感が悪くて木にぶつかりそうで1回で諦めてしまった。

4. Battle of the Bulge V6(★★★): 未完登。

   上部でマッチした後飛び出すのが確信らしいが、マッチできずに終了。 次回行くときは完登したい。

5. The Titanic V5(★★): 未完登。

   エリアの名前になってる看板課題。 初手取りが全然できなかったけど、コツ物かな。。。

35. Initial Friction V1(★★): 完登。

    V1だと思ってなめてかかるとスタートすらできない課題。 登れたときはテンション上がりました。

40. Marco’s Traverse V1(★): 完登

41. Unnamed VB(★★): 完登

53. Unnamed V0(★★): 完登

54. Unnamed VB(★★): 完登

Curry Village(Half Dome Village) [P76-81]

Camp4に比べると小さめな岩(とはいえ5〜6mくらいはある)が多く、取り付きやすい課題が多かった。

https://twitter.com/kashew_nuts/status/1054179629538304000

2. Circuit Breaker V2(★★★): たどり着けず。

   どうやらCurry Villageの他の課題と違うところから行く必要があるらしく、ふらっと探しに行ける場所ではなかったらしい。クラック課題なのでジャミングができるかできないかでレベル感も変わりそう。

4. Root Canal V7(★★★): 未完登。

   カチが多い課題だが、ムーブが選べて女性にも人気な課題らしい。実際セッションしてた強強女性クライマーが完登してた。左手のロックとかカチを耐えてしっかり持つところができないとつらそうなので次回行くときまでに鍛えたい。

8. Unnamed VB(★★): 完登

9. Unnamed V1(★★): 未完登

10. Unnamed V0(★★): 未完登

11. Unnamed V2(★★): 完登

12. Unnamed V2(★★): 完登

15. The Angler V3(★★★): 未完登

    カチ具合に気が引けて3回でやめてしまった….自分はロースタートxカチx横移動の組み合わせだと極端に弱いらしい…..

32. Zorro V4(★★★): 完登。

    「Yosemite’s Best」に選ばれているだけあって良い課題だった。飛び出しも初見だとすごく遠く感じるけど、右手人差し指と中指をしっかりホールドして、右足の置き場所を定めるとバチッとハマる課題。楽しかった。

    https://twitter.com/kashew_nuts/status/1054173983464075265

33. Unnamed V5(★★): 完登。

    Zorroの右横にある課題。スタートから右手を送るのが遠いが、左手の持ち感を変えたらあっさりできてしまった課題。個人的には好きなタイプの課題だったのでできて嬉しい。

    https://twitter.com/kashew_nuts/status/1054863324045692928

登った後のピザはおいしかった。

Sentinel Boulders [P62-66]

同行者も初めていったエリアだったが、駐車場からのアクセスもよく課題も見つけやすかった。

しかしリーチ感が非常に遠い課題があったり、ホールディングやムーブの質が求められている感じがした。 5. Flake Out V7(★★) にも目をつけていたのに、ここにあることを忘れていたのがもったいなかったので次回行くときは触りたい。

3. No Holds Bard V7(★★★): 未完登。

   一手一手が遠いとは聞いていたが、本当に遠かった。初手取りのムーブが起こせず消沈して終えてしまったが、動画ムーブに縛られなかったらまた別のやりようがあったのでは….とも思う。

19. Unnamed VB(★): 完登

20. Unnamed V1(★): 完登

21. Unnamed V0-(★): 完登

22. Door Knocker Traverse V3(★): 完登

28. Mr. Pink Eyes V0(★★★): 未完登。ひたすらスローパーで「これは本当にV0なのか！？」と衝撃を覚えたライン。

29. Unnamed V4(★★): 未完登。スタートの仕方がわからず….

30. Midget Traverse V3(★★): 未完登。

    トポに書いてあるラインだけ見ると「これV3？」と思うのですが、実は岩を半周するほど長いライン。最後のマントル時にはよれている上、足場もなく「なるほどこれはV3だ」というライン。

Cathedral Boulders [P42-48]

ここも同行者含めて初のエリア。途中迷ったが、偶然の出会いもあったりして印象的。Fish Headは次回いくときは落としたい。

7. Fish Head V7(★★): 未完登。

   撤収する30分くらい前に良さそうと思って手をつけたが、流石に厳しかった。 3手目出しをどうしたらいいかわからなかったけど、1手目ポケットと2手目の引けない向きについているカチからだと動けなかったからなー。 もうちょい格闘する時間ほしかった。

12. The Octagon V6(★★★): 未完登。一手一手がかなり遠かった。完敗。

13. Ladder Detail V5(★★): 完登。

    Youtubeでムーブを見てたから結局それで完登したけど、トポに書いてあるルートや記述とは違うので完登といって良いものか悩むけど、登れたものは登れたということにしておく。次はトポに書いてあるやり方で登りたいところ。

最後に

ヨセミテ最高だった！誘ってくれたTKBや一緒にいってくれたメンバーには感謝です。

次が来年再来年になるか、いつになるかわからないけどもまた行きたいなー。

おまけ

今のところアメリカいるときしかあたってない。(わかる人だけわかる)

https://twitter.com/kashew_nuts/status/1054113786506883072

自分の発表について

普段自分がPyCharmを使っている中で便利だなと感じるところや、どうゆうところで詰まったりしたかというところを紹介しました。

内容的には PyCon Kyushu - 2018 Fukuoka で話したことがベースになっています。始まる前は「裏番組も強力だし、まさか満員になることはないだろう」と思っていましたが、まさかの満員で、しかも立ち見NGなので別会場でライブストリーミングするという話が聞こえてきて「何が起きているんだ！？」とテンパっていました。

• 資料: https://gitpitch.com/kashewnuts/slides?p=20180917pyconjp#/

• Toggeterまとめ: https://togetter.com/li/1269343

登壇の機会をいただいたといっても、「聞きに来てくださった方の期待に応えられるかなー」と不安に思ったりもしましたが、概ね好評だったようでホッとしました。45分枠だったので質疑応答の時間も取れてよかったかなと思います。発表したことで自分が知らなかったことも知れたりしました。

チュートリアルについて

今回は「DjangoによるWebアプリケーション開発入門」の講師&TA担当でチュートリアルに初参加しました。 かなり反省点もある時間だったのですが、いい経験になりました。その経験が翌日の発表やその後の講師業にも活かせたかなーと。

いくつかやられたなーと思ったのがあったので今後の自分のためにいくつかメモ。

• Python3.7をサポートしているのはDjango2.0.7以降。Django1.11LTSはサポートしていない。

  • 考えてみたらそうだけど、Django1.11LTSの方がPython3.7より先にリリースされているからサポートされてる保証はなかった。サポートしているバージョンの確認は大事。

  • Python3.7互換の対応は https://code.djangoproject.com/ticket/28814 でされた様子。

• 忘れたことにやってきたShebang。

  • #!/usr/bin/python : フルパスで指定されているPythonインタプリタを実行する

  • #!/usr/bin/env python : PATH の中に含まれるPythonインタプリタを実行する

チュートリアル後に行われたWelcomeパーティは楽しかった！

https://twitter.com/kashew_nuts/status/1041284540264665088

PyConで拝聴したセッション

1日目は自分の発表もあり、他のセッションを聞いてる余裕があまりなかったのですが、2日目のキーノートである @ransui さんの 「Pythonでやってみた」：広がるプログラミングの愉しみ はわくわくしましたね。

他に会場で聞いたり、YouTubeで見てる中で良かったなーと思ったセッションはこんな感じ。現実と戦う話だったり、自分の興味を掘り下げていく話だったりと今回のテーマだった「ひろがるPython」にちなんだ発表だなーと感じました。

• あなたと私いますぐパッケージン Atsushi Odagiri

• Interactive Network Visualization using Python 〜 NetworkX + BokehでPEPの参照関係を可視化する Tomoko Furuki

• Migrating from Py2 application to Py3: first trial in MonotaRO / Python2 から Python3 への移植: MonotaRO での取り組み 増田泰

• Pythonでざっくり学ぶUnixプロセス tell-k

• Pythonで始めるウェブスクレイピング実践入門 田中 慎太郎

Tweet振り返り

雑多にいくつかピックアップして振り返り

https://twitter.com/kashew_nuts/status/1041526439923740673

ちょうどコラボイベントをやっていらしかったのでパシャリ。

https://twitter.com/kashew_nuts/status/1041933375882182658

@yattom さんのライブコーディング。

仕事で pytest は使っているのですが、 他の人がどうテストを書くんだろうと見れる機会は多くないので参考になりました。

コードは https://github.com/yattom/tddhome/tree/20180918_pyconjp2018_livedemo/python_pytest に上げていただいているので、見直したいときは役立ちそう。

https://twitter.com/kashew_nuts/status/1041978613514420224

スタッフの方々おつかれ様でした。参加者の人数が増えていたり、新しい会場だったり、いろいろ大変な役割だと思いますが、おかげで楽しめるました。

https://twitter.com/kashew_nuts/status/1041984074112413699

おわりに

https://twitter.com/kashew_nuts/status/1042038613893033984

有志の打ち上げも楽しかった。来年もトークできたらいいなと思うので、発表ネタをしたためておきたいですね。

前提

• 何かを貶めたりけなすような意図はありません。似たような問題に躓いたときに「そうゆうことだったのか」「こうすれば問題は回避できるんだな」みたいに思ってもらえたら嬉しいです。

• pyenvやAnacondaの話はしません。

結論

• VimのPython補完は davidhalter/jedi-vim: Using the jedi autocompletion library for VIM. で事足りる

• virtualenv/venvを使用していればVimのPython/Python3インターフェースを両方ONにする必要がない(jedi-vimに関しては)

• jedi-vimの補完で物足りなければPyCharm使うのも検討する

jediとは

最近LSP(Language Server Protocol)とかもでてきて気になったりしますが、Pythonの自動補完&静的解析ライブラリとして有名かつ定番なのが davidhalter/jedi: Awesome autocompletion and static analysis library for python. です。

これはJupyter NotebookやIPythonのインストール時にも一緒にインストールされますし、Vimに限らずEmacsやVSCode、AtomでもPythonの補完に使われています。 Vimではjedi-vimというプラグインを活用すると連携できますが、いくつか注意することがあるのでこの記事を書こうと思いました。

jedi-vimのインストール要件

VimのPythonインタフェースもしくはPython3インタフェースが有効になっていること と一点ですがこれが意外と曲者です。

PythonインタフェースもしくはPython3インタフェースを有効にするためには、以下の2つの条件を満たす必要があります。

• Vimで :version した際に +python もしくは +python3 になっている

• Vimが必要としているPython(3)のバージョンをマイクロバージョン単位で合わせる必要がある

マイクロバージョンとはPython3.6.5の場合、3がメジャーバージョン、6がマイナーバージョン、最後の5がマイクロバージョンです (参考: 一般 Python FAQ — Python 3.6.5 ドキュメント )

たとえばUbuntu18.04LTS サーバー版の場合、Vimを起動すると :version で -python/+python3 なのが確認できます。Ubuntu18.04LTSの場合はPython3.6.5がデフォルトでインストールされているため、 :python3 print('Hello') とコマンドラインモードで入力すると Hello と表示されるのが確認できます。大抵の場合 +python3 になっているVimを使っていれば問題ないでしょう。

しかしUbuntu18.04LTSのデスクトップ版の場合、最初に入っているVimは vim.tiny と呼ばれVimで使える様々なオプションがOFFになっているため、 -python/-python3 になっています。この場合ターミナルから sudo apt install vim のようにしてPythonインタフェースもしくはPython3インタフェースが有効になっているVimをインストールする必要があります。

OSが最初から用意しているVimとPythonを使えば問題ないこともあるのですが、次のように自分でVimやPythonを用意した際は問題になることがあります。

• WindowsでVimは香り屋版Vimを使い、Pythonは www.python.org で入手した「最新の」Pythonを使う

• macOSでVimはmacvim-kaoriyaを使い、PythonはHomebrewで入れている

つまりはVimが要求するPythonのバージョンを導入していないとVimが +python/+python3 になっていても、PythonがインストールされていてもPython/Python3インタフェースが有効にならない場合があります。これを避けるにはVimのリリースノートを見て、Vimが要求するPythonが導入されているか確認する必要があります。以下は一例です。

• Windows版の香り屋Vimの場合: Releases - koron/vim-kaoriya

• macvim-kaoriyaの場合: Releases - splhack/macvim-kaoriya

jedi-vimのインストール方法

長々とVimとPythonの組み合わせについて話してきましたが、jedi-vimのインストールはVimのプラグインマネージャーを使用していれば簡単です。この記事では覚えることが少なくて済み、そこそこ高速に使える junegunn/vim-plug: Minimalist Vim Plugin Manager を使います。vim-plugのインストール方法はURLを参照してください。プラグインは ~/.cache/plugged にインストールするものとします。

以下のようにvimrcでbeginとendの間に一行指定します。

call plug#begin('~/.cache/plugged')
Plug 'davidhalter/jedi-vim', {'for': 'python'}   " pythonファイルを編集するときだけ起動
call plug#end()

記述し終えたらVimを再起動して :PlugInstall すればjedi-vimがインストールされます。設定できるオプションはいくつかありますが、自分は以下のように設定しています。

set completeopt=menuone                        " 補完候補を呼び出すとき常にポップアップメニューを使う
autocmd! User jedi-vim call s:jedivim_hook()   " vim-plugの遅延ロード呼び出し
function! s:jedivim_hook()              " jedi-vimを使うときだけ呼び出す処理を関数化
  let g:jedi#auto_initialization    = 0 " 自動で実行される初期化処理を無効
  let g:jedi#auto_vim_configuration = 0 " 'completeopt' オプションを上書きしない
  let g:jedi#popup_on_dot           = 0 " ドット(.)を入力したとき自動で補完しない
  let g:jedi#popup_select_first     = 0 " 補完候補の1番目を選択しない
  let g:jedi#show_call_signatures   = 0 " 関数の引数表示を無効(ポップアップのバグを踏んだことがあるため)
  autocmd FileType python setlocal omnifunc=jedi#completions   " 補完エンジンはjediを使う
endfunction

補完を使うにしろなるべく入力時の邪魔にならないように、必要なときに自分で呼び出すように設定しました。詳しくは :h jedi を参照してください。

jedi-vimのvirtuelenv/venvサポートについて

jedi-vimを入れたVimはデフォルトで有効になっているPython (Ubuntu18.04LTSだとPython3.6.5) に対して補完を行いますが、virtualenv/venvのような仮想環境を使用していると、仮想環境下で使用しているPythonを使用できます。Pythonのバージョンを気にする場合、仮想環境を作成して使うことがほとんどだと思うのでjedi-vimのvirtualenv/venvサポートは嬉しい限りです。

数年前はPython/Python3インタフェースが有効なPythonのバージョンでしか動かなかったようですが、現在はその制限はなくなりました。Python2.7のコードを書くために +python と +python3 を両立した状態にしようとして自分でビルドする必要はないですし、vimrcに実行したいPythonのパスをPythonの2系と3系でそれぞれ指定する必要もありません。

どうしても +python と +python3 を両立したいケースがあるとしたら +python でしか動かない別のVimプラグインを使用したい場合や、すべてのVimのオプションをONにしたいような方だと思われます。普通にVimでPythonの補完を使いたい場合は +python3 になっているVimがあれば十分ですね。

jedi-vimの補完以外の機能

jedi-vimは補完機能以外にもさまざまな機能があります。気になる方はヘルプを見てみてください。

• 定義ジャンプ: <Leader>d

• 変数リネーム: <Leader>r

• 単語の使用箇所表示: <Leader>n

• pydoc表示: <K>

• モジュール表示: :Pyimport {モジュール名}

PyCharmと比較して

単純に比べられないのですがPyCharmの優位な部分は多いと個人的には思います。PyCharmがVimの補完と比べて使いにくいなと思うのがキーワード補完やファイル名の補完などVim自体の補完が使えない点です。しかしそれ以上に、Pythonの標準ライブラリにとどまらず、PyPIからインストールしたライブラリに対してもヌルヌルと補完候補を絞り込んでくれます。また「あれなんだったっけ？」と思うようなところでもなんでもインクリメンタルに絞り込めるので単純ミスが少なくなるのがいいですね。

とはいえ自分だけで最初から最後まで書くようなときや、さっと何かを書いて試したいときはPyCharmの環境を準備するのが煩わしいときがあるので、そうゆうときはやはりVimを使ってしまいます。

補完だけの話ではなかったり、向き不向きや慣れの部分もあると思うので適材適所で使い分けていきたいです。

まとめ

• VimのPython補完は davidhalter/jedi-vim: Using the jedi autocompletion library for VIM. で事足りる

• virtualenv/venvを使用していれば、自分でVimをビルドする必要はない

• jedi-vimの補完で物足りなければPyCharm使うのも検討する

最後に

この記事ではVimとPythonの補完について触れてきました。補完以外にも拡張したい項目があるかもしれませんが、それはひとまず他の記事に譲ることにします。また気が向いたらそのあたりの記事も描くかもしれません。