peco芸: ファイルを検索して開いたりする

gfx.hatenablog.com

pecoめっちゃ便利ですよね. 僕も愛用しています. こちらの記事で紹介されているように, ghq + peco も便利ですが, 僕は ag + peco の組み合わせにハマっていて(?), その紹介をします.

ag

ag (The Silver Searcher)は, 一言で言えば｢めっちゃ早いgrep｣みたいなものです. 最近は, これよりも更に早いhw (Highway)とかも登場しているようですが, 手癖でずっと ag コマンドを使っています.

MacでHomebrewを使っていれば, こういう感じでインストールできます:

$ brew install the_silver_searcher

さて, ag コマンドは grep のように使えますが, -l オプションを使うと, カレントディレクトリ以下に存在するファイル(ag が検索対象とするファイル?)の一覧を出してくれます(例は, skajiさんのApp::cpmのGitリポジトリのルートで実行してみた様子です):

$ ag -l
author/copyrights-and-licenses.json
author/cpanfile.snapshot
author/fatpack.pl
Changes
Build.PL
cpanfile
lib/App/cpm/CircularDependency.pm
dist.ini
lib/App/cpm/Distribution.pm
lib/App/cpm/Job.pm
lib/App/cpm/Logger/File.pm
lib/App/cpm/Logger.pm

    ...

これを, peco と組み合わせてみましょう.

ag + peco

色々やり方はあると思いますが, 自分は .zshrc に次のように書いています.

function peco-file() {
    local filepath=$(ag -l | peco --prompt 'PATH >')
    if [ -n "$filepath" ]; then
        if [ -n "$BUFFER" ]; then
            BUFFER="$BUFFER $(echo $filepath | tr '\n' ' ')"
            CURSOR=$#BUFFER
        else
            if [ -f "$filepath" ]; then
                BUFFER="$EDITOR $filepath"
                zle accept-line
            fi
        fi
    fi
}
zle -N peco-file
bindkey '^f' peco-file

peco-file という関数を用意して, これを Ctrl + f で呼び出すようにしています. 更に, バッファ($BUFFER)の有無によって挙動が変わるようになっていて,

• バッファ($BUFFER)が空の時は, ag -l によって得られたファイルの一覧を peco で検索/選択して, それをそのまま vim で開く, という挙動をします:

• バッファ($BUFFER)に空ではない時, 例えば carton exec -- prove のような文字列が入力済みのときは, peco で検索/選択したファイルを入力済みの文字列の末尾にくっつける, という挙動をします:

このように, ｢vim でファイルを開く｣と｢コマンドの引数としてファイルを指定する｣が, 全て Ctrl + f で実現できて, これがなかなか非常に便利です.

まとめ

ghq+pecoとかいまさらすぎてあまり語られることもなくなってきた感があるけど、逆に若者が知らなかったりするので定期的に言及したほうがいいかなと思って書きました。

— FUJI Goro (@__gfx__) 2017年7月26日

このツイートを見て, 確かに! と思ったので, シュッと書きました. 皆さんもこの機会にオリジナルの peco ハック(?)について記事を書いてみると良いと思います!!!

YAPC::Fukuokaを終えて

YAPC::Fukuoka 2017 HAKATA, お疲れ様でした. スタッフの1人としては, とにかく当日右往左往していたら, アッという間に終わっていた... というのが正直な所でしたが, 当日ご参加頂けた皆様は楽しんで頂けたでしょうか.

今回のYAPC::Fukuokaは, 本当に素晴らしい会場と, 優秀なボランティアスタッフに恵まれたものの, それでも予期せぬ出来事が巻き起こるのが, イベント運営の怖いところです. 参加者の皆様にご迷惑をおかけした場面もあったかとは思いますが... それでも楽しかった, 得るものが多かった, 次のYAPC::Okinawa 2018 ONNNASONも是非行きたい! ...などと感じて頂けたのであれば, 本当に幸いです.

YAPC::Fukuokaの終了後, スタッフは会場を片付ける手はずになっていたのですが, とにかく1日動き続けて元気がなかったので, 先に懇親会に参加させてもらっておりました. 懇親会の会場を眺めると, とにかく皆さん笑顔, 笑顔で楽しそうに会話をされていて, 思わず自分も笑顔になりましたし, なんというか, ｢やってよかった...｣と実感しましたね. まあお陰でビールが美味しすぎて, とにかくひたすら飲みすぎて, ひどい状態になっていた件については... 大変申し訳ございませんでした...

あとはそうですね, 今回のYAPC::Fukuokaの個人的な裏目標(?)は, 毎回YAPC::Japanに対してスポンサーとしてご協力頂いている株式会社ネコトーストラボさんのノベルティのサイリウムを有効活用したい! というもので, クロージングでそれを果たすことが出来て大変満足しています. ネコトーストラボさん, 毎回ノベルティとしてサイリウムをご用意して下さっているにも関わらず, 毎回使われずに終わっているので, 今回は是非何かしらの形で活用するぞ! と思ったりしていたのでした.

YAPC::Fukuokaでの役割

今回は, Fukuoka.pmの id:debility さんを実行委員長に迎え, Japan Perl Association側の代表を私が務める形で準備をしていきました. 自分の役割には特に肩書はありませんが, まあ言うなれば｢実行副委員長｣といったポジションと言えそうです.

カレンダーを見ると, 打ち合わせの為に初めて福岡に行ったのが2016年9月末頃だったので, おおよそ9ヶ月ほどYAPC::Fukuokaの準備をしていたという感じでしょうか. とはいえ, 4月〜5月くらいまでは定期的に打ち合わせをしつつ, 手が空いた時にタスクを消化していく... 程度でかなり平和ではありました. 5月に入ってくると結構忙しくなってきて, 開催が近づいてきた6月末辺りは, 結構しっちゃかめっちゃかになっていた気がします.

詳しくは, 実行委員長である id:debility さんの振り返りエントリに, 開催までのタイムラインなどなどまとめられているので, そちらを見て頂けると良さそうです.

blog.yapcjapan.org

また, YAPC::Fukuoka当日の様子は, この記事でアレコレ余計に語るより, 参加者の感想エントリなどを見るのが良さそうです.

blog.yapcjapan.org

終わった時に思ったこと

クロージングが終わって, YAPC::Fukuokaが無事に完結して, その時に思ったのが, ｢あ, きっと今夢が叶ったな...｣ということでした. 折角なので, その辺の話をしようかと思います. 多少エモいかもしれませんが, そのへんはご了承下さい. そういうのが苦手/嫌いな人は, きっとこの先の文章を読まない方がいいでしょう.

夢の話, 或いはバトンを繋ぐということ

自分が"Yet Another Perl Conference"というイベントに参加したのは, 2011年のYAPC::Asia 2011のときでした. 当時は大学生で, Perlを勉強し始めたばかりの時期でしたが, たまたまスカイアークの遠方からの参加者支援制度という制度を知って応募したところ何故か採択頂き, 参加したのでした.

...余談ではありますが, 当時ご支援頂いたスカイアークとスカイアークの小林社長は, 今でもファームノートとして学生支援スポンサーを継続して頂いています. 個人的には, この｢学生支援スポンサー｣は地味かもしれなけれど, 未来ある若者にカンファレンスを体験して頂くという意味ではものすごく重要なスポンサーメニューだと思っていて, 本当に感謝の気持ちでいっぱいです.

で, YAPC::Asia 2011の話に戻ると, 当時はまだ本当にPerlを勉強し始めたという状態で, 右も左もわからない! という状態だったけれど, 技術について熱く語るエンジニアの姿を見て感銘を受けたり, 技術力の無駄遣いとしか言えないけれどもとにかく超絶な発表(特にPerlで8ビットゲームを作る話とかは本当にエキサイティングでしたね...)に感動したり, とにかく最初から最後まで興奮しっぱなしだったことを, 今でもずっと憶えています. そしてその時に, ｢この人達と, 肩を並べて働けるエンジニアになるぞ!｣という夢を持ったのでした.

今は2017年, あれから6年が経ちました. 思えばその間, いろいろなことをやってきた気がします. 全国各地のPerlコミュニティに足を運んだり, Perl入学式を始めてみたり, ブログに技術ネタを書いたり, 勉強会で発表したり, Webサービスを作ってみたり... その途中で, 明らかに遠回りしていた所もあったりしましたが, 今思えばその遠回りもきっと必要な糧だったのでしょう.

いろいろな積み重ねを経て, お陰様で就活もうまく進めることができて, そこから更にいろいろなことがあり, 今ではなんと, はてなという会社で最高の仲間と最高のサービスの開発に携わることができている(もし5年くらい前の自分に, ｢5年後の君は, はてなに入って id:hitode909 さん達と一緒に仕事をしているんだヨ!｣と言ったら, 間違いなく｢冗談を言うなら, もっと面白い冗談を言ってくれヨ!!!｣と笑って返していたことでしょう)訳で, そこだけ見れば, とっくに｢あの日の夢は叶っていた｣と言えそうです.

ではなぜ, YAPC::Fukuokaが終わった時になって, ようやく｢夢が叶った｣と実感できたのか? なんとなくですが, きっとあのYAPC::Asia 2011で夢を抱くと同時に受け取っていた"バトン"を, ようやく次に渡しきれたということに, 実感が持てたから... かもしれません.

...そういえば, ｢バトンを渡す｣という話は, id:tomcha0079 さんの感想ブログにも書かれていましたね.

tomcha.hatenablog.jp

懇親会ではPerl入学式の @papix 校長と、今回の自分のトークは若い人たちにバトンが繋がるトークを心がけた事と、自分は @papix さんから5年前にPerl入学式に参加してバトンを受け取ったからこそ、今この場に居るといった事を話しました。 @papix さん自身も、ファームノートさんからYAPC参加の旅費支援というバトンを受けたから今があると言ってられたので、Perlのコミュニティは次から次へとバトンを繋げていく素晴らしいコミュニティだなぁと、参加する機会があって良かったと改めて感じました。

まさにこの通りなのかなー, と思っていて, 自分がYAPC::Asia 2011で受け取ったバトンを, いろいろな形で手渡していって, その結果として, 今回YAPC::FukuokaではPerl入学式卒業生として初めて id:tomcha0079 さんのトークが採択されて登壇されたり, Okinawa.pmの id:codehex や id:shimitakax といった, 勢いのある若者が登場してきたり, その他いろいろなイベントが起きていったのかも? と思っています. ...まあ, 沖縄の若者たちについては, 僕がバトンを渡そうが渡すまいが, 今のように勢いある活躍をしていたのは, 間違いないと思いますが.

その集大成として, 自分がバトンを受け取った場所である"Yet Another Perl Conference"というカンファレンスを, 今度は自分たちの手で作り上げて, YAPC::Fukuokaとして開催して, 次のYAPC::Okinawaに繋げることができました. ｢あの日憧れた場所を自分たちの手で作り上げ, それを次に繋げる｣, それがYAPC::Asia 2011で受け取ったバトンの中で, 最後まで残っていたものだったのかもしれません. だからこそ, YAPC::Fukuokaが終わった時に, ｢夢が叶った｣というか, ｢夢を叶えきった｣と思ったのでしょう.

...このバトンが, これからも繋がり続けると良いですね.

これからのこと

...まあ, アニメで言えば最終回的な展開を迎えた訳ですが, とはいえまだまだやることはたくさんあります. はてなで働くということはとにかくエキサイティングで, まだまだやりたい事は尽きないし, Perl入学式はもちろん, JPAのスタッフとしてやっていかないといけないこともたくさんあります(まずは, YAPC::Okinawaが成功するように尽力するところですね...!).

最近沼に片足を突っ込んでいる(?)アイドルマスターシンデレラガールズの楽曲に, EVERMOREという曲があり, その中にこのような歌詞があります:

先へ先へ 夢の先へ 進んでゆくと誓うよ

今まさに, そういう状態なんだろうなーと思っていて, あの日憧れた夢にようやく追いつくことができた! という所で満足せず, 更にその夢の先を目指して, これからも引き続きやっていくぞ!!! という感じです.

いろいろあるかとは思いますが, 引き続き, ご指導ご鞭撻の程, よろしくお願いいたします.

まとめ

EVERMOREめちゃくちゃ良い曲なので皆さん聞いて下さい.

www.youtube.com

購入する時はコチラ!!!

THE IDOLM@STER CINDERELLA MASTER EVERMORE

direnvは環境変数の上書きもよしなにやってくれる!

direnv, 常日頃から愛用していて, これまでは｢新しい環境変数のセット(export TEST=test)｣しかできないと思っていたんですけど, 今日試していたらなんと

export PATH=/path/to/tool:$PATH

みたいな, 環境変数の上書きもいい感じにやってくれる事が判明したので, 忘備録的にメモしておきます.

解説

こういうディレクトリ構成があるとして,

parent
|-- child
    |-- .envrc

childディレクトリの.envrcの中身は次のようになっているとします.

export TEST=this_is_$TEST

このとき, parentディレクトリで, 次のようにして環境変数TESTをセットします.

$ export TEST=test
$ echo $TEST
test

この状態で, cdでchildディレクトリに移動すると…

$ cd child
direnv: loading .envrc
direnv: export ~TEST

こうなり, echoコマンドで環境変数TESTの中身を表示すると…

$ echo $TEST
this_is_test

.envrcで指定したように, this_is_が先頭に付くように上書きされます. さらにここから, cd .. でchildディレクトリを抜け…

$ cd ..
direnv: unloading

echoコマンドで環境変数TESTの中身を確認すると, なんと環境変数TESTの中身は元通りに戻っています.

$ echo $TEST
test

ユースケース

諸事情あって, 複数のバージョンのMySQLをHomebrewで管理して使い分けている時, 例えばあるアプリケーションではMySQL 5.6を使うようにしたいのであれば, そのアプリケーションのルートに.envrcを置いて,

export PATH=/usr/local/opt/mysql@5.6/bin:$PATH

と書いておけば良さそうで, こうすればこのアプリケーションの開発環境ではmysqlコマンドなどで5.6のものを優先して使ってくれるようになります. brew linkやbrew unlinkを駆使して, Homebrewで利用するMySQLのバージョンを切り替える必要がなくなって, 楽そうな感じがします.

加えて, MySQLのサーバはDockerを利用して立ち上げるようにすれば, ミドルウェアの管理がかなり楽に, かつ柔軟に(アプリケーションごとに最適なものを選べるように)なりそうです.

chrome-GitHub-Issue-BadgesにPull Request送った話

chrome-GitHub-Issue-Badgesという最高のChrome拡張があります.

github.com

これはとにかく最高のChrome拡張で, GitHubに#1のようにイシューやPull Requestの番号を書いたり, 或いはhttps://github.com/motemen/chrome-GitHub-Issue-Badges/pull/9のようにIssueやPull RequestのURLを書くと, こういう感じで展開してくれてめちゃくちゃ便利, というやつです.

最近幾つかPull Requestを送ったので, そのへんの紹介をします.

エスケープする

github.com

そのまんまで, IssueやPull RequestのタイトルにHTMLが含まれていたらそのまま表示される, ということでなんとかしてみた.

function escapeHTML(str: string) {
    return str.replace(/&/g, '&')
              .replace(/</g, '&lt;')
              .replace(/>/g, '&gt;')
              .replace(/"/g, '&quot;')
              .replace(/'/g, '&#039;');
}

素朴にこういうの実装してやっつけたのだけれど, もっと良い方法あったりするのだろうか…

Assignees全員のアイコンを出す

github.com

最近GitHubが複数人をアサインできるようになったけれど, それに対応していなかった(アサインされた人のGitHub IDを辞書順にしたときに, 先頭になる人が表示されていたっぽい. …多分)ので, ｢できないかなー?｣と試行錯誤していたら, なんかいい感じに出来たのでPull Requestを送ってみました.

無事マージされて(途中でPull Request出した事忘れてレビューコメントを放置してた… 本当にすいませんでした…), 多分使えるようになっているはずです. 個人的にはめっちゃ便利! と思っているので, 是非体験してみてください.

まとめ

とにかく言いたいのは, chrome-GitHub-Issue-Badges, めっちゃ便利なので皆さん是非使ってみて下さい…

このエクステンションはTypeScriptで作られているので, ｢オオッTypeScript… なんか難しそう…｣と最初は感じてしまうかもしれませんが(自分も最初そう思っていた), ｢俺はJavaScriptを雰囲気でやっている｣という感じの自分でも, 試行錯誤しながらやっていたらPull Request送れる程度には素朴だし, 規模も大きくないので, ｢こういうのあったら便利では?｣というアイデアがあれば, 是非実装してPull Requestを送ってみると良いと思います!!!

｢オブジェクト指向のこころ｣読んでた

最近, ｢アプリケーションの設計｣というところへの興味が湧いていて, その領域の学習をちょっとずつ取り組んでいます.

きっかけとしては, はてなに入社して, はてなブログの開発チームに配属されたというのがあり, 6年近く開発が続く, そこそこの規模のサービスを素早く進化させ続けていく為には, 良い設計を取り入れていくのは非常に重要だなあ, と痛感したというのがあります.

はてなブログというサービスを, 素早く進化させる為の施策については, 既に先達の方々がいろいろな取り組みをしていて, 例えば id:hitode909 さんのYAPC::Asia 2015の資料, ｢Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜｣などから, その様子を感じることができます:

speakerdeck.com

その結果として, はてなブログというサービスは｢オブジェクト指向やDDD気にしなくてもシンプルに書ける｣ようになっています. この辺り, 入社するまでは｢本当に…?｣と思っていたりもしましたが, 実際に開発に携わってみると｢その通りだった…!｣と実感しています.

だからといって, ｢アプリケーションの設計｣についての学習は後回しで… という訳ではなく, チームメンバーとサービスの開発について相談する際, この辺りの知識を増やしておくのは間違いなく役に立ちますし, 何より"特定の言語に依存しない"知識なので, (即効性はないかもしれませんが)エンジニアとしての一つの武器に成り得るのではないか, と思っています(思えば, これまでは即効性はあるけれど, 特定の技術領域に依存している学習ばっかりやってきたような気がする…).

まあ, そういう経緯があり, その第一歩として｢オブジェクト指向のこころ｣を読んでいました:

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

半分くらいは知っていたり, 過去に経験したりしていて(｢あれってこういうパターンの名前があったのか…｣みたいな)理解が進んだけれど, 残り半分くらいは結構ゆるふわな理解という感じでした.

｢アプリケーションの設計｣, その中にもいろいろな領域があり, それぞれの領域にまたいろいろな本があるので, 1冊の本をじっくり読むより, 幾つかの本をハシゴして, その中で理解が深まったら, 一度読んだ本をもう一度読んでゆるふわに理解していたところを固めていく, みたいな進め方の方が良さそうという気持ちがあって, 今回はいつも以上にサクサク読み進めていくことを意識してみた… ものの, 350ページくらいあって, 結局2〜3週間くらいかかってしまいました…

ゆるふわ理解ではあるものの, アプリケーションの設計に関するいろいろなキーワードがインデックス化(?)できたので, これをスタート地点に理解を深めていきたいですね.

これからの方針

とりあえず, 手元にあって薄そうだったので(理由が酷い), 次はさっくりとこれを読んでみようという気持ちです:

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

デザインパターン周りも, もう少ししっかり抑えておきたい気持ちがあって, GoFの本を買おうか… と思ったのですが, 結構難しいぞ! という意見もあり, まずは｢増補改訂番Java言語で学ぶデザインパターン入門｣から入るか…? みたいな気持ちがあります.

オブジェクト指向における再利用のためのデザインパターン

増補改訂版Java言語で学ぶデザインパターン入門

｢実践ドメイン駆動設計｣も, 本棚で眠っているのでちゃんと読みたい…

実践ドメイン駆動設計 (Object Oriented SELECTION)

最終的には｢オブジェクト指向入門｣とか行けたら良さそう…

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング)

他, オススメの本などあれば是非情報を下さい. よろしくお願いします.