vim-jp の好きな絵文字リアクション

有益な記事が続いてしまったので今日はゆるい記事です。

Slack といえば絵文字リアクション機能ですね。vim-jp Slack ワークスペースもご多分に漏れず、独自のリアクション文化が花開いているので、今回は個人的にヌクモリティを感じて好きなリアクションをいくつか紹介します。

:iinoyo:

誰しも間違いはあるもの。もしすれ違いがあっても「すみません」「いいのよ」でまーるく収めましょう。

:spin_keizai:

散財は罪ではなく、経済を回すという偉業なのです。

:nemawashi:

読んで字の如くです。

:+1smile:

+1 と smile を一挙に表すことができてとても便利ですね。大好きな絵文字です。

:bram:

Vim の創造神、Bram 氏の自画像です。

彼の名言「速い言語が欲しいなら、高いマシンを買えばいいじゃない」の意味でも使われます。

:iizo:

ほんの少し背中を後押ししてあげることで、人の行動は大きく変わるかもしれません。

:yonkaiyuushoo:

四回優勝したときに。

:vim-jp-dark:

ワークスペースのアイコンはいつぞやからこのクールなアイコンになりました。素敵。

:tips:

reacji-channeler によってこのリアクションをつけられたメッセージは自動的に #picked-tips チャンネルに転載されます。vim-jp には星の数ほどチャンネルがあり参加者もまちまちですが、このリアクションのお陰で気軽に知見共有ができるわけです。

:tabunikeru:

エンジニアには、確信がなくてもエイヤで行くしかないときもあります。

:wakarante:

必ずしも分かり手になれることばかりではない。

:siranai-siyou:

逆に考えるんだ、学ぶ楽しみが増えたと。

:otz:

労をねぎらう様子を全身で表した絵文字です。

:kankiwamattekimasita:

感極まってきた様子を全身で表した絵文字です。

:jisshitsumuryo:

質のよいものが相応の値段で手に入るすなわち実質無料ですね。

:blue-langue-de-chat:

「誰がうまいこと言えと」ってやつです。

:goodpoem:

いい話はなんぼあってもいいですからね。

:ese:

真の Vimmer への道は遠い。（誰かへのリアクションとしてつけるのではなく、自分に使うためのリアクションですね）

:bujishibou:

天高くエンジニア肥ゆるオールシーズンって感じです。でも出来ることならダイエットしてほしい。

:nuku:

ぬくもりの「ぬく」

:mo:

ぬくもりの「も」

:nri:

ぬくもりの「んり」

おしまい

おしまいです。

AIを不適切コメントフィルターとして活用してみる

小ネタです。ChatGPT のすごいところは自然言語をインターフェースとして使える点ですね。今まで人間にしか無理だと思われていた仕事が、機械で代用できるようになります。

そこで、プライベートの時間をほとんど受動的な YouTube の配信の垂れ流しで過ごす VTuber のオタクでもある私は、配信の不適切コメントを除去する役割 - YouTube でいうモデレーター - を AI に代替させられないかと試してみました。その様子がこちら！

かなり期待が持てそうだと感じました！（注：実際にモデレーターを実装したわけではありません。それは誰かの手に任せた…）

感じたこと

単純な単語によるフィルタリングでは除去できないコメントを不適切と判断できているのが特に印象的でした。理由も "繰り返し表現が冗長で意図が不明" と非常に妥当ですね。

「ここセーブしといた方がいいよ」のようないわゆるネタバレコメントはゲーム配信では忌避されるものですが、今回は不適切と判定されませんでした。この辺は文脈をより学習させる必要があるでしょう。

「炎上不可避」は逆に文脈次第で適切な場面もあるでしょうね。

適切度を数値で評価せよ、としか指示していないのに、理由付きで評価してくれたのは嬉しい誤算でした。空気を読んでくれる ChatGPT の面目躍如ですね。

展望

そもそも ChatGPT 自体が不適切な出力を行わないよう注意深くチューニングされたモデルであることも手伝って、このような不快な表現を除外する仕事は ChatGPT が真っ先に活躍できるシーンだと感じました。

ほとんど何も文脈を学習させていない現状ですら、古典的な単語によるフィルタリングより遥かに便利であるように思います。フィルタをかいくぐるのも、GPT の前では単純な検索避けでは敵わないですし。

さらに文脈やコメントの事例を学習させることでより性能の高いフィルタリングが出来そうで、将来にも期待できますね。whisper で文字起こししたものを GPT に食わせて、フィルタリングするなど。

おしまい

人間にしか出来なかった仕事をどんどんAIにやらせよう。

このアイデアに著作権は主張しないので、実用したい方はご自由にどうぞ！

ミニマリストに憧れて - 無彩色カラースキームを作った話

これは Vim 駅伝 4/5 の記事です。aomi-grayscale という Vim のカラースキームを作りました。

github.com

その名の通り、無彩色と見せかけてわずかに青みがかっているのが特徴です。カラーパレットは GitHub の default テーマを参考にさせていただきました。

お気に召した方は是非インストールして使ってみてください。以下はなぜこのカラースキームを自作したかの話をつらつらと書いていきます。

「読むための」カラースキームが欲しかった

プログラミングにおいて「読む」という行為は非常に重要です。私自身プログラムを読む機会は多いのですが、たびたび思っていたのは「ハイライトがノイズになるな」ということでした。

たとえば if や for, 文字列中のエスケープ文字など、読解したい内容に対して重要なときもあれば、そうではないときもありますよね。個人的には、それらよりも「同じ変数名」をハイライトした方が読みやすいと感じることの方が多かったです。

なので、注目したい箇所はハイライトに左右されるのではなく、自分の都合で決められる方が望ましいと考えたわけです。そこで無彩色カラースキームの世界に入門しました。

余談ですが、ハイライトがなくとも読みやすいことや、書くことより読むこと/読まれることを重視する態度は Go に影響を受けたものです。

なぜ自作したか

とはいえ無彩色カラースキーム自体は既存のものがいくつか出回っています。それらを使わなかったのは、純粋な無彩色だと少し色がくすんで見えるからでした。このくすみが気に入らなくて、無彩色カラースキームは一瞬だけ導入した後、一度元に戻してしまいました。

色彩には詳しくないので、いったいなぜだろうと首を傾げていたわけですが、あるときふと GitHub の文字色を確かめたところ、わずかに青みがかっているのに気づきました。なるほど、これかと。

というわけで青みがかった無彩色でカラースキームを作ってみたら、くすみもなく、かなりしっくりくる好きな色合いになりました。これが自作に至った理由です。

配色で気をつけたこと

前述の通り読むためのノイズを減らすのが第一目標でしたが、そうは言っても完全に一色では困るところも出てきますから、必要最小限の濃淡はつけてやる必要があります。ではどこに濃淡をつけるべきか。

aomi-grayscale では、文字列などの「行内に異なるコンテキストが混在するとき」の色をグレー寄りにしました。文字列はやはり区別できないとかなり不便ですね。他にも通常のテキストと異なるコンテキストとして、HTML のタグ部分などがあります。これで、大半の言語は自分にとって十分な可読性を得られるようになりました。

ただやはり、これでも厳しい場面はあります。様々なコンテキストが混在する Markdown だったり、HTML も場合によってはそう感じます。それらは仕方ないものと割り切っていますね。

無彩色にして気づいた、ハイライトの意義とLSP

こうして自作したカラースキームをしばらく実用していましたが、気づいたのは「書くときに少し困るな」ということでした。具体的にそう思ったのは、普段書かない Makefile を書くときに、「.PHONY の位置とか変数の記法ってこれで合ってるんだっけ…？」という出来事からでした。

目立つハイライトがあれば、記法があっていれば書いたときにいい感じに光るし、間違っていれば光らないですよね。なるほどハイライトが便利なのは書くときなんだな、と気づきました。

しかし、現代のプログラミングには強力な LSP という武器があります。言語サーバーさえあれば、ハイライトがなくとも構文をミスったとき理由付きで教えてくれます。というわけで、書くときの不便さは、言語サーバーでカバーするように割り切りました。文明の利器サイコーって感じですね。

無彩色という原始に回帰したような見た目とは裏腹に、現代の技術を前提としているのは、ちょっと面白いかも、と思ったりもしました。

で、実際読みやすいの？

自作してから一ヶ月くらい経ちますが、正直よくわからないですね…。読むときにノイズとなる情報が減ったのは確実なのですが、それを「読みやすい」と言っていいかどうかは、さらなる研究が待たれます。

その他のメリットとしては、ハイライトがないことで、なんとなくコードを眺めて気持ちよく読めた気分になることがないので、真に読みやすいコードを書くための矯正ギプスになる、などがあるかもしれません。これもまだ研究不足な分野ですが。

欠点をいろいろと挙げましたが、青みがかった色合い、それとミニマリスト感がクールで気に入ってるし、やはり自作しちゃった以上愛着が湧いてるので（欠点も含めて愛おしい的なところもある）、今後も使い続けると思います。

おしまい

自分で使う分は設定しましたが、ターミナルカラーも設定しないとだし、light テーマも追加したいですね…。

追記: light テーマ追加しました！（冒頭のスクショ参照）

ハイライトもいろいろと足りていないとは思います。ので、プルリク大歓迎です。スクショも添えて出していただけるととても助かります。

今後とも aomi-grayscale をよろしくお願いします。

github.com

ブログを開設しました

やるぞ～