うならぼ

どうも。アフィリエイトとか広告とか解析とかは/about見てね。

あとがきのようなもの2018

今年の総まとめの体でなにか書きます。

コミュニティ活動

勉強会やっぱり楽しいですね。昨年に引き続き今年も何回か発表させてもらいました。スライドはたまにSpeakerDeckに上げてます。いいですよ、発表。なかなか難しくて。発表スキルが成長してるかと言うと正直微妙ですが、やっぱりそうか……そうかなとは思ったんだけど……を次につなげて改善していきたいですね。

コントリビュート的なものは今年はあんまりできてないですねえ。MDNのUserScriptはもうちょっと面倒見たい気もするけれど、翻訳もご無沙汰だし。Mastodonは手元で開発用にいじってたのをmasterに追従させるのが面倒で、ちょっとしたパッチも書きづらいのが悔しい。

そういえば「茜ちゃんの薄い本」に軽い?技術記事を寄稿したりしました。私は行けないのですが、12/31は東館に陳列されているらしいです。

おばけ

シールは皆様のご協力のおかげでまたバリエーションを増やし、OSC近辺で配布されているようです。私自身は普段ごく少量しか持ち歩いていませんが、言ってもらえれば束で持っていきます。素敵な活用例の情報もお待ちしています。

また今年もたくさんの素敵なイラストや二次創作をありがとうございました。見落としていそうなのがあればまた教えてください。星を投げに行きます。

私の方ではsuzuriのTシャツがラインナップに加わりました。イラストやアイコンも季節の変わり目などでたまに描いています。なんか2017年の方がたくさん描いていたと思いこんでいたんですが、今年も20枚ぐらい描いてたみたいです。

f:id:unarist:20181229204240p:plain
正月っぽいやつ

Vim

VimそのものではなくVSCodeIntelliJ IDEAのVImプラグインを使うようになって数年経ちました。バインドはかち合うわ、クリップボードやアンドゥ回りはエディタ本体の機能と絡みあってややこしくなるわ、Vimプラグインは使えないわ、ああもうっ!ってなることがちょいちょいあります。

Vim使えばいいじゃん、○○もVimプラグインでやれるよ、みたいな話は聞くんですが、うーん。プラグイン入れたらいい感じのキーバインドやメニューやUIが生えてくれて、それ選択するだけで使えるみたいな楽な拡張性とか、デフォルトでもそこそこ好みに合った設定になってるとか、そういうのがいいかなあ…。

じゃあそういうエディタをVimプラグインなしで使えば?というのは、Vim(行|単語|文字列リテラルの中|括弧の中|次のカンマまで)を(選択|削除|変更)みたいな操作を覚えてしまったので、カーソル位置を見ながらカーソルキーやBS/Delを連打するのがだるい…みたいなあれです。そういう意味では、別に具体的な操作体系がVimでなくとも、エディタのショートカットとかでも似たようなことはある程度できるかもしれませんが*1

SKK

これも似たような感じで、普通の連文節変換できるIMの方がいいのでは?と思うことも時々あるものの、普段はとても快適に過ごしています。もちろんこの文章もSKKで書いています。

「書いて」を「描いて」に変換ミスする、みたいなのはちょいちょいあって、結局修正は必要になるんですが、まあBSでちょいちょいと消して変換しなおすだけなのでそこまで大きな手戻りにはならなかったり。やっぱりカタカナとひらがな部分の入力が超絶に楽*2ですし、漢字も変換ミスの余地がないものは大丈夫なので、平均点はそこそこ出ている感じです。

周りを見ていると、abbrev変換*3とか再帰的なインライン辞書登録*4*5とかも好評のようです。わかる。あとこれは他のIMでもキーバインド変更すればいいんですが、全角半角キーがだいぶ遠く感じるようになりました*6

買ったもの

トラックボールを変えました。Marbleよかったんですが、ホイールの誘惑に耐えられなかった。左クリック押しにくい話は上のボタンにも割り当てて解決。割り当て変更は前から使ってた X-Mouse Button Control を使いたかったものの、ボタン数が足りなかったのでやむなく純正ツールに。でもホイール反転させるためにXMBCも併用してたりします。ちなみに余ったボタンをF5に割り当てたらブラウジングやブラウザ上での動作確認が捗るようになりました。

あと色々あって、同人音声作品を買うようになりました。いや、実際のところ耳かきボイスそのものはそんなに魅力を感じられておらず、癒し系ボイスドラマ的に聴いてたりするんですが。でも立体音響でシャンプーとかドライヤーとかはなかなか楽しかった。

そういえば買ったものとは関係ないんですが、デレステKawaii make MY day! とかmaimaiの悪戯を聞きながら、アイカツみを感じたりしました。単にMONACAが好きなだけ、というのはあるかもしれない。

SNS

「最近○○であまり見かけないよね」

○○の中には好きなSNSマイクロブログの名前を入れてください。まあ飽きが早いのはいつものことですが、色々変わってるので、何かに比べてこれは飽きが早かったねとか言うのもだからなんだという話です。以下も具体的なサービス名は出さずにいきます。

ただこないだふと自分のサービスAとサービスBのホームを見比べてみたら、サービスAの方がほっとする感じはあるなあと。ていうところからプラットフォームの差を語りたいわけではなくて、やっぱり結局は誰をフォローしているかに尽きるんじゃないかとか、自分の好みも変わるよなあって思ったわけです。以下ブレスト的なログ。

  • サービスB: 当時はこの人の投稿・シェアを読みたいと思ったけど、現状それほどでもないのにフォローしたままになっている
    • 自分の好みが変わった、環境の変化、相手の投稿傾向が変わった、etc.
    • シェアは人の数や投稿の数に対して情報量・コンテンツ量が増えてつらいみたいなとこはあるかもしれない(読む時間を食うか表示スペースを食うかみたいな)
    • やっぱりサービスによって拡散されるようなコンテンツや拡散度合いの違いがあるんだろうか。観測範囲内で少ないだけだろうか。
    • 流れてくる投稿の傾向の違いはまあユーザーの違いによるんだろうけど。ユーザーの違いはユーザーの違いやサービスの機能・特性の違いに寄る感じ。
  • サービスA: なんか、気ままに喋ってる人が多い、気がする。
    • なんと言ったらいいのか。別に他のサービスでも気ままに喋ってる人はいるだろうに。
      • 観測範囲だとシェアに埋もれがちというのはある
    • エアリプチャットみたいなのはまあそれとしても、ゆったりしている気がする
    • 各自好きなことを喋っているという感じというか、なんというか
  • まあ結局誰をフォローするかという話に尽きるところはあり、長年積み重なったフォローより、最近新しく作ったフォローの方が最近の好みに合ってるだけとかの可能性はある
    • 定期的にブートストラップし直すのはワンチャンある。新しい出会いも増える。

そういう感じでした。まあ別に別れを告げたわけでもないので気ままに現れています。

ブログテーマ

時々ちびちびいじっているんですが、今回もまた眺めていてリンク色が他のテキストと比べて読みにくい気がしたのと、配色におけるアクセシビリティの話*7を読んだりしたのとあって、少しいじりました。リンク下線、やっぱりわかりやすいのはその通りですね……。

  • 文字色 #c78B80 → #b57062 (ちょっと濃くした)
  • リンク下線 ホバー時のみ → 常にあり

ごそっと読みやすいテーマに変えてもいいんじゃないか、というのもちょいちょい思いはするんですが。

あとがきのようなもの

この記事は NelsonCoffeeRoaster Advent Calendarmstdn.maud .io Advent Calendar を眺めてたらなんか書きたくなったので書きました。前者はコーヒーの話が素敵だし、後者はなんかみんな好きなことやってる感じがして楽しそうです。

それではよいお年を。

*1:VimにせよEmacsにせよプリセットやプラグインが多くのエディタにある、というのは乗り換える時に楽ではある。

*2:ただ打てばひらがなのまま確定されるし、変換する流れでq押せばカタカナ確定される。いやカタカナ変換はF7とかあるけど、これを前提としてカタカナ語を辞書から排除できるし、そもそも単文節変換常用なのでこれを自然に使えることになる。

*3:英字列を読みとした変換で、標準の辞書集に英和辞書とかある。

*4:辞書にない言葉を変換すると辞書登録モードに入るので変換ついでに登録できる。辞書登録モード内でも辞書登録モードに入れるので、フルネームを登録しようとしたら名字だけでも変換できなかったから登録する、みたいなのが一連の流れでできる。

*5:実際のところこれは万能ではなくて、略称とか変換ショートカット的なものには超便利だけど、そもそも既存辞書での変換方法を悩むような字とか正しい綴りを忘れてるケースとかは検索してくるか…となるのであまり旨味はなかったり。そういうのはシステム辞書に追加しておくとかクラウド検索できる辞書サーバーを使うとかした方がいいかもしれない。

*6:Macは前から近くにキーがあるし、トグルじゃない、それはそう。

*7:一般色覚者にはほぼ分からない“小さくて大きな違い” JIS改訂で「日本社会における色のルール」はどう変わったのか (1/3) - ねとらぼ 「赤ペンはむしろ見にくい」「プレゼン本の『良い例』は良くない例」 色弱者に聞く“本当に見やすいデザイン”とは? (1/3) - ねとらぼ

Gitで不要なブランチを列挙する方法いろいろ

マージされたまま放置していたブランチとかその辺を掃除したかった。

不要なブランチを列挙できれば | xargs git branch -D でローカルブランチを削除したり、| xargs git push origin -d でリモートブランチを削除したりできるわけだ。

直接マージされたブランチ(=masterから辿れるコミット)

git branch にはちょうどマージ済みのものを抽出するオプションがある。

git branch --merged master

--format "%(refname:short)" をつければHEADであることを表す * を消せる。

upstreamが消滅しているブランチ

GitHubでPRを送ってマージされてその場でブランチを消した、とか。

そういったブランチは git branch -v だと [gone]git branch -vv だと [origin/hoge: gone] といった形で表示されるが、コミットメッセージにそういった文字列が含まれているかもわからない。

この [gone] は書式文字列では %(upstream:track) で表示できるので、自分で指定した方が安全になる。

git branch --format "%(refname:short) %(upstream:track)" | grep "\[gone\]" | cut -d" " -f1

ローカルでだけ消したブランチ

これを一括で消していいかどうかは運用によるが、ローカルでブランチ作ってPR投げておしまい、みたいなケースならいけると思う。

全てのブランチをpushしてよければ、--prune というオプションがある((まるごと同期というと --mirror なんてオプションもあるが、これはrefsをまるごとミラーする前提なので、リモートのrefをremotes以下に分離する普通のclone元に対して使うものではない。))。

git push --all --prune origin

削除だけしたい場合、そういったコマンドやオプションはなさそうなので、ローカルとリモートのブランチの差分を取ってみる。

comm -13 <(git branch | sed 's|*| |' | sort) <(git branch -r --list origin/* | sed -E 's#origin/|.+ -> .+##' | sort)

ローカルのブランチ一覧からは * 印を消し、リモートのブランチ一覧からは origin/ の部分を消してHEADを除外する。それ以外の symbolic-ref があることを考慮していないが、まあ大抵はないだろう…。

ところでリモートの HEAD が参照していたブランチを消してしまった場合、git remote set-head で変更することができる。手動でブランチを指定したり、-a でリモートの情報に合わせたりできるが、そもそもこれいるんだろうか。-d で消してちょっと様子を見てみよう。

squashマージされたブランチ

こいつが厄介。squashマージによるコミットはマージしたブランチのコミット群と履歴が連続していないので、履歴を辿ってもマージ済みかどうか判断することができない。

そこで見つけたのが、git cherry コマンドを使った方法。

not-an-aardvark/git-delete-squashed: Delete branches that have been squashed and merged into master

ちょっと短くしつつ、やっぱり長いのでここでは \ で行を分割して書く。

git branch --format="%(refname:short)" | \
while read branch; do
    mergeBase=$(git merge-base master $branch) && \
    [[ $(git cherry master $(git commit-tree $(git rev-parse $branch^{tree}) -p $mergeBase -m _)) == "-"* ]] && \
    echo $branch;
done

git cherry はブランチポイントからの各コミットについて、相手のブランチに既に取り込まれているかをファイルの中身で判定してくれるので、squash されていようと問題ない。ただコミット単位での判定になるため、例えば最終的に残らなかった変更のコミットについても評価されてしまうという git cherry-pick 同様の問題があり、これを防ぐために上の例では git commit-tree で squash コミットを作成している。結果が一行になるので判定が楽というのもある。

ただこれまでのパターンと比べるとやはり時間がかかるので、他の可能性を先に調べたり、判定除外を指定できるようにあれこれ足してシェルスクリプトにした。プレビューしてから再評価することなく本番を実行できるように、コピペ用のワンライナーも出力するようにした。

https://gist.github.com/unarist/2f6da154ddb30eb52993713e9d064a83