HappyGoLucky

Web系サーバーサイド寄りの自動化大好きエンジニアの徒然なるブログ

hub で Issue や PullRequest を修正できるようになった

↓がマージされてできるようになった。

github.com

個人的に、あればいいな(なかったら別の手段でやるけど...)と思っていた機能が hub に入った。

hub issue update 16 --edit

などと実行すれば、id: 16 の Issue もしくは Pull Request の既存の title と body がエディターに展開される。

f:id:yasuhiroki:20200202150602p:plain

あとはそれを好きなように更新すればOK。

プルリクを見ると分かるけど、最初は hub issue edit というサブコマンドだった。
だけど hub issue edit --edit というのちょっと分かりづらいよね、という意見から hub issue update という名前に変わった。
他にもラベルを付けたり消したりするオプションの仕様と名前をどうしようかー、という議論もされてて、こういうの普段自分たちが業務でやってることと同じなので、OSSだからって何かすごいやり方とか想像もつかないコミュニケーションがされているというわけではないんだなー、と勝手に親近感を持ったり安心したりした。

hub を install するだけの orb を作った

hub を CircleCI で使うための orb を作った。

github.com

こんな感じで使える。

version: 2.1

orbs:
  hub: yasuhiroki/hub@v0.0.1

jobs:
 install:
    docker:
      - image: circleci/node:latest
    steps:
      - hub/install
      - run: hub --version

workflows:
  test:
    jobs:
      - install

当初は hub/release とか hub/create-pr とか作って、 hub を使った command をいくつか用意しようと思ったんだけど、私はシェルでゴリゴリした結果をもとに release を作ったり pull request を作ったりしたいのだと気づいて、ただ hub をインストールするだけの orb になった。
結果、 circleci/aws-cli orb と似たような感じになった。

ちなみに hub を使いたい理由は、私がふだんから hub を使っているから。
CircleCI で GitHub のあれこれを自動化するために GitHubAPI を調べてスクリプトを書くのも手間だし 1 hub の使い方を知っていればCIで何してるのかも分かる、という統一感があって嬉しい。


  1. 作ろうとした けど hub でいいじゃん…という気持ちになって止まってる

2019年を振り返って

2019年も振り返っていくぞ。

2019年の習慣

2019年はEvernoteに個人的な週報をつけてみた。
仕事のことも家庭のことも思いつきもイベント事もつらつらと書き続けた。

f:id:yasuhiroki:20200101154848p:plain
週報の一覧

我ながらよく続いたなと思う。
毎週必ず書くのしんどいかなーと思ったけど、仕事では 1週間区切りの sprint なので weekly scrum で何かしら書くことあるし、育児ネタも湧いてくるのであまり苦労しなかった。もし毎日書いてたらしんどかっただろうけど。
あと自分のことをあまり書きすぎないようにしたのも良かった。
昔、4行日記を書いてたことがあるんだけど、ほぼ自分の失敗と反省ばかりで辛くなって続かなかった。まあ社会人2年目~3年目の頃なので、そういう時期だっただけかもしれない。

ちなみにペン字も始めたんだけど、こちらは続かなかった。
成果を実感しづらいと習慣化は難しいなーと思いましたまる。


では月別振り返り。

1月

家族全員インフルエンザ。きつかった。
朝活をしようと思って早起きしてたんだけど、私が早起きすると物音のせいか子どもも早起きするので結局時間が取れなくてやめた。

1/30の 第1回CircleCI ユーザーコミュニティミートアップ 後に CircleCI Japan User Group の Community Leader になった。

業務では OKR を試し始めた。タスクの優先順位が明確になって良い仕組みだと思う。

2月

背中の痛みに悩み始めた。後日病院にも行ったけど改善されず、今もたまにジリジリした痛みを感じる。
同僚に筋トレのせいではと言われて背筋の筋トレをやめて少し楽になったけど、根本的な痛みの原因だろう我が子は日に日に体重が増えるので、これはもうずっと付き合う痛みと思うことにした。

OKRの自信度を0~100%だと尺度が広すぎてこまかい数値の上下が気になっちゃうから5段階くらいで良いのでは〜という意見を持った。

3月

大きな新機能をリリースして、それなりに結果も出たのでホッとした月だった。
新機能にどれほどの効果があるのか未知数な上にかなり工数がかかっている状態だとストレスだった。個人的にもストレスだったけど、それ以上にチームとしてもストレスがある...ように感じてしまうのがしんどかった。

イチローの引退会見を何度も見てた。

4月

担当大臣制というものを試し始めた。
OKR で決めた KR 達成を目指して各施策を打つんだけど、その施策の取りまとめ役を担当大臣と呼んだ。仕様決め・施策内容の検討・優先度の決定などの実行権限を与えられて、自分がすべきことに集中できるのは良くて当初はいい仕組みだと思ったんだけど、自分の担当外への関心が下がってしまう弊害もあった。アイデア段階で意見しなくなったせいか、ほぼ実装が終わった後に「これで良いのかなー」という反応をしたりされたりして手戻り作業を増やしてしまう。
たぶん、チーム内の相互理解が相当進んでないと効率的に進まないシステムのような気がする。それこそ公安9課みたいな。

この時期はMTGが泥沼化する傾向があって頭痛の種だった。他の文章にしづらいイベントや育児ストレスも相まって、2019年で一番体調が優れない時期だったと思う。悪夢を見て叫びながら目が覚めるという初めての経験をした。

5月

文章にしづらいイベントをきっかけに MISSION / VISION / VALUE / CREDO / HABIT を決め直したり新しく決めたり。
とても時間がかかったけど、自社を自分の言葉で説明できるようになって良かった。自社サービスしか説明できなかったもんなー。

体調が回復した。今思うと、やっぱ私のストレスの原因はアレだったんじゃないかと思う。そう思うと、次また似たようなストレスを感じたり、その予兆があったらすぐに対処しようと思う。具体的には自分のストレスを言葉にすること。

あと副業の検討を始めた。

6月

育児サポートのためリモートワークが増え始めた。
ただ、リモートワークを前提とした開発フローではないので、リアルタイムにオフィス内で決まったことが伝わらずに効率がよくない。特に、何をするのか決まったことは書いてても、なぜそうなったかが分からなくて、すでに議論済みのことをコメントして聞き返したり、違う解釈をしてズレた実装をしたりして効率が悪い(という感覚を持っていた)。
とはいえリモートワーク前提の組織にするのもコストだし、今はあくまでもリモートワークはオプションだと思っているので、この辺はリモートワーク側が自分の作業効率のために努力する部分だと思っている。議論済みかもしれなくても自分の解釈が正しいか確認すべきだし、ツールは何でも良いので電話して直接会話することを積極的にすべき。

妻と子どもが1週間半帰省した結果、私の顔を忘れられてしまってめっちゃショックだった。
だからリモートワークを増やしたのは内緒。

7月

Androidの開発タスクが増えてきたんだけど、AACとかKotlinとかRetrofitとか自分の知らない技術への勉強時間が足りてなくて追いつかない。
同僚がどんどん新しいのを取り入れるのでプルリクベースで追いかけるのがやっとという感じ。業務中に勉強できないと時間が取れない生活をして片手間で開発してると、まー時間が確保できない。RubyAWSのキャッチアップも続けたいので、結局、薄く広くな知識になっていく。本気で勉強したいなら絞ったほうが良いんだろうけど、どうするかはまだ悩み中。

もっと仕様を整理した開発をするにはどうしたらいいんだろ、と思ってエリック・エヴァンスのドメイン駆動設計を読み始める(まだ読み終わってない)

8月

体調が芳しくなく熱を出した。
2018年の8月も同じような感じだったらしい。周期的なものなのか...。

circleci.vim を作った。

9月

情報共有不足(する側もされる側も不足している)から手戻りが発生してかなりもやっとした気持ちになった。
計画的にそうしてるんだと思ってたので口を挟まなかったんだけど、蓋を開いてみたらただの認識違いだった。オフィス内で決まったことを共有しきれてないせいなんだけど、GitHubへの記述が間に合ってなかったり、そもそも当初から開発の進め方の足並みが揃ってなかったり、工数と実際の成果物が出る日数にズレがあったりと、マネージャーが存在しないことによるデメリットが噴出した月だった。
今でもマネジメントは必要だと思っているけど、デメリットが見えてるならある程度は仕組みで解決できるんじゃないかとも思っている。気をつけるとか注意するとか、そういうのは嫌いなので、自然と情報共有するしキャッチアップするような仕組みを考えたい。まだ考え中。というかこれ習慣の話なので、何とかできないと何のサービスやってんだという感じもする。

10月

テスト漏れの不具合があって、CIの仕組みにまだまだ改善の余地があると実感した。実装した箇所のカバレッジがなかったら怒られるような仕組みが欲しい。そういうのSaaSでありそうだけど。

実家に1週間くらい帰って完全に技術から遠のいて、いざ仕事に戻ると辛いのなんの。毎日少しでもエンジニアモードにはなった方がいいなーと思った。

11月

個々人の開発の進め方の違いに悶々とした出来事があった。後日この辺の話をすると、経験してきた開発フローが違いすぎるのがベースにあるようだった。この辺は整備しないと、いつまで経っても噛み合わないので考えたいところ。

私の作業ミスがチラホラ増えてしまって気を引き締め直した。ミスのうちいくつかはCIで自動検出できるようにしたり、レビュー漏れがないか確認するためのチェックリストを用意した。また、 # TODO: あとで直す はあとで直さないので、わざと落ちる実装にしておいてエラーを起こすようなスタイルに変えた。

12月

入社後最大のビッグイベントを経験し、やはり私はデバッグ作業が好きなのだと改めて自覚した。
最終日に社員エンジニア飲み会が開かれて、かなり話し込んだ上にまだ話し足りないので、もっとこういう時間が必要なのではと思えた。
副業募集を公言した。


まとめ

2019年は、個人の課題というよりチームの課題を意識した年だった。
そのチームの課題の文言化と解決策の実施・振り返りができる 2020年にしたい。
個人の課題はたぶん副業の方でボロボロと出てくるので粛々とやっていく。

相変わらずアウトプットは少ないので(勉強会でLTしないとまずアウトプットしない)このブログをもうちょい使おう。

副業はじめます

TL;DR

  • 副業を探しています
  • ライフスタイルを崩したくはないので月10~20時間程度の副業を探しています
  • Jenkins認定エンジニアを持っていたり CircleCI User Community Leader をしていたりと CI/CD に強いです
  • 開発チームはビジネス要件に集中して開発効率化は誰かに任せたい、先人が残したCIが死んでて困っている、といったニッチでスポット的なお仕事が最適です
  • AWS / Rails / Android の開発をお手伝いすることもできます
  • 何かお手伝いできることがあればご連絡ください

あなたは誰?

@yasuhiroki (twitter@duck_yasuhiroki) というアカウントで活動しているエンジニア歴8年目の男です。
現在は恵比寿にあるベンチャー企業AWS : Rails : Android を 5 : 3 : 2 くらいの割合で触ってるエンジニアをしています。最近 Android 率が高まりつつあります。

Jenkins認定エンジニアという資格を持っていたり CircleCI User Community の運営に関わっていたりと CI/CD まわりが好きです。
前職では新規事業開発、現職はベンチャーということから 1人N役な開発経験が多く、0→1 や 1->10 くらいのフェーズに馴染み深いです。

できること

  • CI / CD の構築・メンテナンス
    • CI/CD の導入
      • 初期設定, Test, Deploy, Release 一通り何度もやってきたので得意なところです
    • Jenkinsに困っている(=使いこなせていない)という状況ならお力になれると思います
      • 死にかけのJenkinsさんの介護に困っているならご相談ください
      • とはいうものの、ここ2年は知識を更新していないので、たとえば Jenkins X についてのノウハウはないです
    • CircleCI
      • 現職では CircleCI をメインに使ってるのでノウハウが溜まっています
    • GitHub Actions
      • 趣味程度ですが enjoy しているので程度知見があります
    • Google Apps Script
      • CI/CD とは少し逸れますが、業務改善というくくりだと GAS は中々便利で優秀なツールだと感じています
      • 現職では CS 対応の管理用ツールを GAS で作って GitHub と連携して自動化したりしています
  • AWS 開発
    • 5年くらい経験があり、現職での本業はここです
    • VPC設計 / Security設計 / システム設計 は一通りできます
    • CloudFormation チョットできます -> Qiita
  • Rails 開発
    • 2年ほどの開発経験があります
    • Rails 4.2 から 5.0 へのアップグレードをしたり Fat Controller な実装を Model に移したりとリファクタしたり
    • 最近は RuboCop のカスタム Cop を作ってコードレビュー効率化図ったりしています
  • Android 開発
    • トータルで1年ちょいくらいの開発経験があるので多少はできますが AWSRails に比べるとレベルが落ちます
    • 具体的には AAC を勉強中で使いこなせていない、という感じです

できないこと

  • Windows / iOS アプリ開発の経験はありません
  • JavaScript は GAS や AWS Lambda + Node.js の経験がほとんどなのでフロントエンドのお手伝いは難しいです

趣向や性質

ストレングスファインダー によると↓の性質を持っているようです。

  1. 最上思考
  2. 学習欲
  3. 達成欲
  4. 調和性
  5. 収集心

バグは絶好の学習材料という認識を持っているので楽しく調査します。
解決できた時は最高に嬉しいですが、時間の都合で取り急ぎワークアラウンドで回避する時もそれはそれで楽しいと感じます。
結局は、目の前に分かりやすい問題があると何かしら解決したくなる性分なのだと思います。

連絡先

TwitterのDMが一番繋がりやすいです。
何かお手伝いできることがあればご連絡いただけると嬉しいです。

Ebisu.rb #26 に参加しました

ebisurb.connpass.com

Ebisu.rb はこれで5回目くらいで、前回の参加が #23 の 5月なので 半年ぶりになる。

今回は参加者の層が Rubyガチ勢と ゆるふわRuby勢と 未経験者勢 とで何となく分かれていた気がする。Rubyガチ勢とゆるふわRuby勢の境界は自分でも良くわからない。少なくとも私はゆるふわRuby勢。
そんな中で GitHub Actions について喋ったんだけど、気になる層とそうでない層が真っ二つに分かれるのは予想していたので、もう少し広い範囲で興味を持ってもらえそうな git の alias を使ったライフハックも紹介した。懇親会では GitHub Actions の話もライフハックの話もできて楽しかった。

他の方の発表も多種多様で、そうそう Ebisu.rb ってこんなだったわー、という気持ちになった。GitHub Actinos の話をしてる私が浮いていないくらいなのですごい。

個人的には、書き捨てコードの話とRspec高速化の話が刺さった。

書き捨てコードを見たり解読するのが好きだということもあるけど、書き捨てコードがあるということはプログラムで何かを解決しようとしているわけで、それがプログラマーの仕事の仕方だよねーというのを実践してる人が目の前にいることが刺激になった。そういうの最近できてないなー。VimIDE開いて愚直に手作業してた面倒な繰り返し作業も、もうちょっとスクリプト組んで効率的にできたんじゃないかと思えてやる気出てきた。

Rspec の高速化の話は、こりゃもう知ったからにはやらなきゃと思ってスライド見ながら手を動かしてたら、そもそもうちの factories たちが trait で余計な関連レコードたくさん作ってるのを整理しなきゃいけないと気付かされて、でもまあやるっきゃ無いかとふんばってる。そのやる気が出てきたのはあの LT のおかげなので、いやもーありがとうございます。

RSpecの実行時間を1/5にした話 - Speaker Deck

帰宅してからは reline の rvm の CI が落ちる問題を調べてた。目の前にバグがあったらちょっかいかけたくなるよね。
rvm がメソッド追加してる Bundler と実際に動いてる Bundler が別なので動かないというのが分かったものの、どう解決するのが適切なのか分からず寝たら、次の日に bundle exec して直してるのを見て、その発想が出なかったのがちょっと悔しかった。bundle install してるんだからそりゃそうじゃんか...。でもスッキリしたので良かった。

Fix to failed CI. by osyo-manga · Pull Request #71 · ruby/reline · GitHub

今年もアドベントカレンダー書く予定なので、文章を書くリハビリがてら久々にブログ書いた。

2018年を振り返って

なんで振り返るのか

2017/09 に SIer から ベンチャー企業のエンジニアになり、2018年はそのベンチャー企業で過ごした1年だった。
大きくまとめると楽しくハッピーな1年だったが、なにかを成し遂げられたかというと、そうでもない1年でもあった。
また消化不良な感覚があって、その感覚を具体化したくてこの記事を書こうと思った。

1月

娘が生まれた。前日は大雪だった。里帰りしている妻と電話で、こんな雪の日に出産になったら大変だね、と話していた翌朝に娘が生まれた。フラグにも程がある。

あれこれと相談した結果、妻が娘を連れて戻るのはゴールデンウィーク前となった。
言い換えると、私が私のために時間を自由に使えるのは4月末までということだと思った。

2月

いずれ自分の時間が制限されるなら、限られた時間を最大限に活用する必要がある。なので生産性にこだわって仕事をすることにした。
当時、タスクはすべて見積もりポーカーでポイントをつけていたので、Sprintごとに消化できたポイント数を増やすことに拘った。

先に書くと、これは失敗だった。
消化したポイント数を意識すると、ポイント効率をどうしても考えてしまう。つまり、同じポイントなら(自分なら)短時間で完了できるものを優先してしまった。もちろん、Sprintごとにやるべきタスクと優先度は決まっているのだけど、そのタスクが終わって空き時間ができると、ポイントを効率よく稼げるタスクを進めてしまいがちになった。
結果、自分にとってチャレンジングなタスクには手を出さなかったので、何の勉強にもならなかった。経験を食いつぶしているだけなので、消化できたポイント数がいくら増えたところで、自分の成長を実感することはなかった。
この結論に気づいたのが4月で、以降は消化ポイント数を意識するのをやめた。

3月

作業効率性を上げるために hub コマンドを活用し始めた。具体的には プルリクエストの作成は hub コマンドで行うようになった。今でもそう。他の機能は使ってない。

社内勉強会を開催した。Ruby on Rails 製の OSSソースコードを読んで「なんだコレ」する会。題材はGitLabにした。新規メンバーが増えたこともあり、コミュニケーションを取ることも兼ねて数回行った。
今では自然消滅したが、またきっかけがあれば開催しようと思っている。

この月はまだポイント消化数に拘っていたので、結果、ベストスコアを叩き出した。

4月

esa に日報をつけていたのだが、日に日に内容が薄れていることを自覚してもやもやしていた。
仕様の検討や実装で分かった点・気になった点などをメモしたいけど、いちいち esa を開いてまとめながら作業するのも面倒だし、後から思い出しながらまとめるのはもっと面倒だったので、Slackに times-yasuhiroki チャンネルを作って分報を始めることにした。分報で雑にメモして、そのメモを日報にまとめるスタイルにした。 分報で悩みをボヤくとアドバイスをもらえたり、なんでもないような呟きにツッコミがもらえたりと有益だった。
分報は今でも、当時ほどの量はないが続けている。

4月末に妻と娘が戻ってきた。
生活が一変した。

5月

生産量が目に見えて減った。そもそも出社時間が短くなったし、自宅で仕事する時間も激減した。勉強する時間はほぼゼロになった。 ただ、自分の時間が減ったのは確かだが、それでも時間が全くないわけじゃなかった。平日は夜にアニメを観る時間はあったし、休日は昼寝をする時間があった。要するに時間の使い方の問題なのだけど、アニメも昼寝も削る気にはなれなかった。

この頃、システムの小規模なリアーキを行った。それまで Rails の SuckerPunch で行っていた非同期を AWS SQS で Message にして ElasticBeanstalk の Worker で処理するように変更した。非同期処理は SQS 経由で行うシステム構成へ変更する足がかりとなった。この実装は少々時間がかかったが楽しかった。
現状の問題を解決する新しい仕組みを検討・導入するのは楽しい。

また、サービスの使われ方の調査やKPI測定のために Jupyter を使い始めた。pandas はすごく便利。

6月

AWS Summit の Startup 向けコーナーで 15分の発表をした。内容はAWSリソースの構成管理をテーマに、CloudFormation の CI/CD を考えるもの。 CIで使えるツールの例として cfn-lint を紹介したのだけど、発表した後に聞いたセッションで cfn-python-lint の存在を知り「マジかよ...」と悲しい思いをした。すぐにインストールして、やがて vimale.vim で動くように対応して Qiitaに記事 も書いた。

この頃から、たまにリモートワークをするようになった。仕事に集中できるかどうかは、タスクと家庭状況によってまちまち。少なくとも仕事の方は、仕様が決まっていると作業が捗りやすく、一方で、相談が必要な作業は滞りがちだった。
もともと、口頭のやり取りで仕様を相談しその結論が文章化されるのはプルリクになってから、という傾向が強かったので、リモートに対応するには情報共有の文化の面で課題があった。

このリモートワークにおける情報共有の課題は少しずつ改善されている。特に GitHub で仕様を議論するルールになったことで情報共有漏れは解消された。
一方で、リモートワークしている人がどういう状況か見えない問題もあって、私はなるべくSlackで発言したりリアクションすることで「オンラインですよ」アピールをしているのだけど、そのせいで作業に集中できていない面もある。ビデオチャットを垂れ流すのが良いのかなーとは思うけど、自主的にならともかく、ルール化すると女性がノーメイクでラフにリモートワークしづらくなるのでは、などと余計なことを心配したりしている。余計なお世話な自覚はある。

7月

ebisu.rb に参加し、RubyRailsのキャッチアップが全くできていないことを思い知り、週刊Railsウォッチを読むことにした。

Androidのタスクを少しずつ進めることにした。業務経験はあったがほとんど忘れているので、簡単な機能やバグ修正だけ手伝う感じ。今でも同じ距離感で開発に参加していて、GCMからFCMに乗り換えなど、サービスの機能とは少し離れた部分にコミットしている。

また、リモートワークにて情報共有漏れによる時間ロスが発生し、対策として毎朝 slack でその日の作業予定を報告する運用を始めた。これは今も続いているが、若干、形骸化しているので、有効活用する仕組みを考えるか、廃止を含めて考え直すかしたい。

8月

体調が芳しくなく、長期休暇もあって生産量が大きく減った。開発以外のタスクばかり進めて何も生み出していないような気分になっていたが、後半は持ち直したような気もする。

9月

8月と打って変わって生産的だった。CSの仕組みを変更して自動化したり、 go でごにょごにょしたり、Ruby正規表現を調べてLTしたりした。

久々に飲みすぎて視界が真っ白になった。なんとか帰宅できたが、いろいろとギリギリだった。

10月

かなりレジェンドな感じだったある実装がいよいよ限界なのでリファクタを始めた。このリファクタは気に入っていて、リファクタの規模を抑えつつ、スケールしやすくエラー時の検知も分かりやすくリトライ可能な実装になったので嬉しい。ただし妥協点もあって、この妥協点がいずれ負債になる未来も見えている。

NHK筋肉体操を始めた。今も続けている。二期があるとのことで楽しみにしている。

11月

サービスの課題や新機能の効果測定のためにデータを調べる機会が増えた。別に依頼されたわけじゃなくて、自分が気になるから調べていたのだけど、もっと早くからこの習慣を身に着けておけば良かったと思っている。

Ebisu.rb で rb コマンドについて発表してきた。スライド無しで README に書いておいたコマンドを実行しながら説明する実演スタイルで発表したが、そこそこ良い反応が得られてよかった。個人的にも楽しかったので、実演スタイルの発表は今後も挑戦してみたい。

VimConf2018 に行ってきた。最高だった。最高に最高だった。

12月

AWSのキャッチアップがまるでできていないと気づいたので、 AWS Black Belt Online Seminar を聞くことにした。1時間でたっぷり情報が得られてとても良い。継続的に視聴していきたい。
CircleCI のハッカソンに参加して reviewdog 用の orb を作った。こういう成果物が残るのは良い。

年末に体調を崩した。もともと私は年に一度、冬の季節に高熱を出す習慣があるんだけど、今年は吐き気もして最悪だった。結局年明けまで回復しきらず、散々な年末年始だった。

まとめ

月ごとに振り返りながら思ったことをリスト化

  • インプットが足りていない
    • 年末に意識し始めたけど、インプットが足りてない
    • 時間というよりインプットの質の問題な気もする
  • アウトプットが足りていない
    • せっかく読んだ本・スライドの内容をアウトプットしていないので自分の血肉なった感覚がない
    • コンテンツのように消化しておしまいな傾向があるので改めたい
  • 短い期間でふりかえりしたい
    • 意外とやってたり、やってなかったりすることに気づける

VimConf2018 に行ってきた

行ってきました。最高でした。来年も行きたい。 スタッフの皆様お疲れ様でした。VimConfをたっぷり満喫できたと思います。

以下、感想メインでつらつらと。

LINK

VimConf2018 Official: VimConf 2018
スライドのリスト: VimConf 2018 – VimConf official blog

チケット

販売開始時刻にリマインダーセットして速攻買った。個人スポンサーも買った。
もともとmattnさんの発表が聞けるなら買わねば...と思っていたが、Bramさんが来日するとなればそりゃリマインダーセットするよね。
個人スポンサーも買ったのは、応援の意を込めて。

予習

vimconf2018.swp で、Bramさんのvim25周年時の動画があると知ったので見ておいた。

Vim 25 presentation by Bram Moolenaar on 2016 November 2 - YouTube

この動画は Vimの 25年の歴史を振り返る内容で、同時に Bramさんの歴史を振り返るものでもあって、私の中で、今まで雲の上の未確認な存在だったBramさんが、雲の上だけど存在ははっきり分かった存在に変わって、すごく良かった。
また、動画にはBramさん本人は映ってなくて、これがかえって、VimConf2018で本人に会える楽しみを増幅させてた。あの声の主に会える、みたいな。

Keynote 1

まずは mattn さんのキーノート。

vim-jp の話とNew Featureの話。
vim-jp によって日本の vimmer の知見が蓄積されていくのは本当に良い話。
New Feature の話では、VimScriptでNUL文字を扱えないことを説明するために、実際に Vim を開いてコマンドを入力して見せてもらえたのが最高だった。このライブ感がたまらない。

Keynote 2

そして Bramさんのキーノート。
最高だった。

Plugin のために今までどういうことをしてきて、これからどういうことをしようと思っているかの話。
Autocommand を追加し (Vim 4.0) Vim script を追加し (Vim 5.0) Plugin の概念を追加し (Vim 6.0) パフォーマンスに懸念が出たので autoload を追加し (Vim 7.0) 将来的にはマルチスレッドやpycのような中間言語コンパイルするのが良いかもしれない、という感じ。
そして Plugin Manager の提案。個人的には、プラグイン管理はvim本体で持たなくても良いのではという気持ち。
あとはアンケートを取ってみたら、popup window と store properties with text の要望が多かったとのこと。properties は plugin 作ってる人たちからするとめちゃめちゃ欲しいだろうな、と聞いてて思った。
LSP は Bramさん的にはあんまりな感じだったけど、Vim が LSP に対応したらアツイ。LSP がプログラミング言語界隈でどれくらい浸透しているのかよく知らないけど、考え方は好きなので広まって欲しい。Vimが対応することでよりLSPの輪が広がると思う。

いやー。最高だった。

お昼

すきやき弁当がうまかった。
すきを見てBramさんと握手した。Vimが好きだとひたすら言った。幸せだ...。

午後

ほぼぶっ通しで発表を聞き続ける。スライド見続けるのでめちゃめちゃ目がしょぼしょぼした。目薬持ってくれば良かった。 発表の中では、 :Termdebug がインパクトあった。GDB使ったことなかったので使い方のデモとしても面白かったし、それが vim の中で完結されていたのが良かった。まさに vim を開発するための vim という感じ。
今どきのプラグインの作り方も良かった。スライドも発表も分かりやすい。Vital.vim で job/channel を Promise ぽく扱えるようになるのは良い。使ってみたい。
あとは vim の標準の補完機能もうちょっと使い込んでみたくなったなあー。<C-n> しか使ってないからなぁ。とりあえず dict は有効にした。
来年はLT出てみたい。何がいいかなぁ。

懇親会

英語で話す機会があった。これが国際カンファレンス...!
なんでVimを使ってるんだ、という話だったんだけど、私がVimを使うきっかけはEmacs使いの先輩への対抗心で、それを英語で伝えられたかというと伝えられていない。まず先輩を英語で何ていうか分からなかったのでFriendって言った時点でもう間違ってる。むずかしいなー。
というか、Vim自身に理由がないので説明しても面白くなくて、代わりにVimを使い続けている理由を話せば良かったのではと帰宅中に思った。
ちなみに相手の方は左手の小指が内側に曲がっていて、この指じゃEmacsは使えないだろ? みたいな話だった。まさかそんなパターンがあるとは...。
あと、Vim を tmux のように attach/detach したいという方もいた。それができれば tmux がいらなくなる、と。私は tmux + vim で満足してるのでそんな発想はなく、新鮮だった。これができるならログインシェルを /bin/sh から /usr/bin/vim にできたりするんだろうか。ちょっと違うか。
VimConf参加者のブログを読み漁ってたら、この話をしてたのってもしかして江添さんだろうか?もしそうなら、ばったり著名人と同じ輪の中で話すことがある。これが国際カンファレンス...!

家の事情があって途中で帰宅したのが残念。お酒も飲みそこねた。SAKE飲みたかった。やむなし。
また来年も参加したい。