Poem

背景 find コマンドというファイルを検索するコマンドがあります。 これはとても有名なコマンドであり、ネットで検索すれば大量の使い方の記事がヒットします。 大量のオプションが用意されており、様々な方法でファイルを検索できる便利なコマンドです。(まぁ、そんなに複雑な検索をしたいかという疑問はありますが…。) 対して、fd という rsut製のファイルを検索するツールが存在します。これは find よりも使いやすくて速いことを目指して作られています。 fing の設計思想は fd とは異なります。 fing は find コマンドとの互換を目指して設計しています。 そのため、find で作成されている script ファイルにおいても fing に置換するだけで動作することを目標としています。(オプションの全網羅は諦めていますが…) fd 並に速くて、find と同じ使用感を目指して作成しました。 インストール Go で作成したため以下のコマンドでインストールが行なえます。 go install github.com/komem3/fing@latest 使い方 基本的には find コマンドを fing に置き換えるといいです。 例えば　jpg ファイルの検索は以下のようになります。 fing -name *.jpg また、 fd の良いところである gitignore を反映してくれる機能もあります。 fd ではデフォルトでそのように動作しますが、fingでは -I オプションで指定します。 fing -I これは fing 特有ですが gitignore に書かれているが無視しないといこともできます。 エッジケースですが、僕が欲しかったため追加しました。-EI オプションをクエリとともに使用します。 以下のコマンドは　gitignore に .envrc が書かれていても、.envrc が検索結果に表示されます。 fing -I -name ....

まずは切り方。これを気になってこのブログを見た人がいるかもしれないので。 (global-font-lock-mode 0) こちらの設定で全てのシンタックスハイライトが無効になります。簡単ですね。 切ろうと思った理由 プログラムの中にはシンタックスハイライトを切っている人が一定数います。 不思議ですよね。僕も不思議でした。 そこでちょっと理由を調べてみました。そこで出会ったのがこのブログです。 こちらの内容は面白いので是非読んでみて欲しいのですが、要約すると 「シンタックスハイライトはプログラムを読みやすくするために開発されたはずだが、 開発者はコードの内容の理解よりもコードの形を見てしまい、コードの正しい理解から遠ざけてしまう。」 といった内容です。 好きな文を抜粋すると 色の付いたテキストは文章をつなぎ合わせるため、より脳を使う。 補助輪付きの自転車で練習しても自転車に乗れるようになるわけではない。 (コメントアウトを)色を変えて見えなくすることは、敷物の下に隠すようなものだ。 上記のようなものは過激ですが、成程なぁと思いました。 そんなこんなで感銘を受けて切ってみました。 使ってみて さすがに全てのシンタックスハイライトを切ると diff が見辛すぎたので以下のものだけ有効化しました。 (add-hook 'magit-mode-hook #'font-lock-mode) (add-hook 'diff-mode-hook #'font-lock-mode) 使用イメージ こんな感じになりました。 全然読めると思います。 感想 全然問題なく使える、というのが感想の一番です。むしろシンタックスハイライトを復活すると見辛く感じます。 個人的に良かったポイントは以下です。 コメントが読みやすいので読む習慣が付く。変なコメントに気付けるようになりました。 シンタックスハイライトの色で微妙な気持ちになることがなくなった。テーマで悩むこともなくなりました。 シンタックスハイライトが逆に付かなくなることによるイライラが失くなった。だって最初から付いてないんだから。 おわりに これを見てくれた人も試しに切ってみると世界が変わるかもしれません。 追記 ちなみに、flyspell を使う場合はコメントアウトにシンタックスを当てないと、flyspell が反応しません。 そのため、以下のように一回有効かしてからコメントアウト以外を無効にする必要があります。 (add-hook 'prog-mode-hook #'(lambda() (turn-on-font-lock) (setq-local font-lock-keywords nil)))

今まで、Vivalid を使用していたのですが、何か重いなぁとか、 何か微妙だなぁと思うことが多かったため、思い切って Opera GX というブラウザに乗り替えました。 今回はこのあまり有名でないブラウザの良さを紹介していきます。 Opera GX って？ 公式ホームページを見てもらえれば分かると思いますが、ゲーマーのためのブラウザです。 一応 opera の派生のため、ゲーマーのための opera と言った方がいいかもしれません。 ただ、ゲーマーのためのブラウザと聞いてピンと来る人は少ないと思います。なので、どんな機能があってどんな点が良いかを書いていきたいと思います。 機能 公式ホームページにも色々書いてありますが、特徴的な機能と言うと以下になると思います。 組み込みの広告&トラッキングブロッカー。(あんま強くはない) SNS 連携。サイドバーから SNS が見れます。 CPU・RAM・ビットレートの使用率を制限。 memory cleaner 標準搭載。 ダークモード強制。ウェブページを強制的にダークモードにする機能があります。 ゲーマーのためのブラウザ これを感じさせるポイントを上げていきます。僕はゲーマーじゃないので、ついでに僕が思う良い所も上げていきます。 見かけ もう何よりもこれです。こんなカッコイイ見た目のブラウザ見たことありません。 この見かけが一番ゲーマーらしいと思います。これだけで使う気になりました。 音 起動音がちゃんとあります。笑っちゃうので聞いてほしいです。 また、文字を入力するとカタカタ言います。何と無駄な音と思いますが、個人的にとても好きです。 SNS 連携 機能にも書きましたが、これがかなり強いです。一つのブラウザで完結することができるため、ポイント高いです。 正直ゲームしないので、ゲームよりの SNS よりも Slack とかも連携してくれればいいのにとは思っていますが、それでも便利なものは便利です。 特に Discord で便利に使っています。アプリの起動が必要ないのはとても便利です。 ワークスペース機能 複数のワークスペースを持つことができます。イメージは実際に見てもらう方が早いと思います。 chrome にラベル機能が付いたり vivaldi のようなスタック機能も出てきましたが、やっぱりワークスペースが一番便利なんじゃないかと個人的には思います。 個人的な使い方としては、仕事用 Slack 個人用 に分けて使用しています。 おすすめ拡張 拡張は opera の拡張を使う感じになります。軽くおすすめ拡張を列挙します。 translator google 翻訳の opera 版。chrome のやつより使いやすいです。 Install Chrome Extensions...

トップページのお知らせ欄を管理画面より変更できるようにしました。アーキテクチャはざっと以下のような感じになっています。今回はこの構成にした理由と、よかったポイントを書いていきたいと思います。 構成理由 フロントエンドを nuxt.js で作成したため、BFF でサービスにアクセスして、news サービス自体は非公開な構成にしたかったのが一番の理由です。 fronend 以外は非公開な構成のため、news サービスは news を操作することのみに集中できていているのがよく感じています。また、frontend の BFF サーバは更新エンドポイントを知らないため、一般ユーザがお知らせを更新してしまう心配もありません。 管理画面は認証を行なう必要があるため、今回は pomerium を使用して、cloud run に IAP を立てる方法で構築を行ないました。firebase などによる認証もありでしたが、開発環境などで既に pomeirum IAP はやっていたので、その知見を流用して行ないました。 よかったポイント nuxtjs の BFF は面倒でしたが、news サービス単体で御知らせの管理をできるようになったのが、やっぱり良いポイントです。処理がまとまっていて自分でも管理しやすいです。 また、今回は各通信を gRPC を用いて行ないました。これがすごいよかったです。導入やコネクション辺りはちょっと苦戦しましたが、コードの自動生成や分かりやすいスキーマ定義により、サービス間の通信はかなりスムーズに進みました。 swagger 書くよりも何倍も楽に書けて、その上自動生成のコードも swagger の何倍も分かりやすいとか、gRPC よすぎない…？ 感想 結構時間はかかりましたが、自分が自由に遊べる環境という名目でサイトを立てたので、その意義を十分に感じられる作業でした。 次は wysiwyg エディターを使ったブログスペースを作成したいなって思っていますがいつになるのかなぁ。 その前に問い合わせフォーム作りたいや。(いらないと思うけど…)

はじめに spacemacs を使い半年、限界を感じたので emacs の設定を 0 から行ないました。 その移植に思い立った理由を述べていきたいと思います。 嫌なとこたち master の更新が止まっている デフォルトのインストール先が master になっていましたが(現在は devleop になっていました)、最終更新は 2018 年であり、最新の機能が欲しい場合は devlop ブランチにする必要がありました。 spacemacs を使っている人はみなさん develop を使用していたようで、issueでも問題になっていました。 ですが、develop の問題もあります。 spacemacs の変更に振り回される 上記のことから、develop を使用していたのですが、いかんせん更新に振り回されます。develop を更新したらキーバインドが変わった、パッケージでエラーが出たなんてよくあります。 修正の PR がマージされるまで動かないので、しょうがないから PR の変更をローカルに反映したりしたりと、色々と更新時の面倒が多いです。 原因特定が面倒 どのレイヤーが原因なのか、どの設定値が原因なのか調べるのが難しいというのがあります。mac であまりにもフリーズするので調べてみたら、dotspacemacs-mode-line-unicode-symbols を nil にしたら直るという解決策だったことがあります。spacemacs 固有の問題なのか、それとも拡張側の問題なのか、これの線引きが難しく調べるのに難航するというのが結構しんどいです。 重い なんか重いです。結局原因は不明でしたが、特定のモードによってはフリーズすることがよくあり、issue でも似たような報告がちらほらあります。 spacemacs は所謂おらおら設定集なので、余計な設定も結構入っています。そのため、自分が必要なものだけ入れたときに比べ、余計な処理が走りやすいんだと重います。 ですが、滅茶ストレスです。 拡張性 spacemacs には様々なオプションが用意されており、自由に拡張することができます。 しかし、拡張するといっても spacemacs の範囲という感覚です。もう一歩先に行こうとするとかなりつまずきます。 せっかく設定しても spacemacs によって上書きされたりして反映されなかったり、オプションが効かなかったりと、できないことが多いです。 僕はこれが嫌で乗り替えました。オラオラ設定は楽しかったですが、何でもできるという emacs らしさが spacemacs の上でしか成り立たなかったので、嫌になりました。 よかった所 ファイルから自動で適した layer(簡単にいうと設定集)をダウンロードしてくるのには痺れました。これは本当に素晴らしいと重います。 新しい拡張子を開くたびに、拡張を調べてインストールするというのが面倒な人、初めて emacs を触る人、emacs の設定をするのが面倒な人は、spacemacs がとても刺さると思います。 また、オラオラ設定のため、いきなり emacs が vscode になったかのような錯覚を受けるぐらい初期設定が充実しています。 あまり、設定を凝ったことがない人は是非とも試してみてほしいです。...

検索機能が追加されました。右側のやつです。 実装方法 このブログページ自体は nuxt/contentで動いているため、nuxt/content の全文検索機能を用いて実装しました。全文検索自体はドキュメントを読めば簡単にできるので、content の良さを実感しています。 工夫点 もちろんタグ検索ですねー。元々ブログ記事にはタグを埋め込むようにしていたので、それで検索をかけています。タグの埋め込みイメージは下のような感じです。yml のため配列で格納するのも考えたのですが、こちらの形式の方が、全文検索のさいに扱いやすかったので、こちらで保存しています。 tags: Golang CloudRun 全てのタグ自体は、非同期に記事を全検索書けてマップでタグの値を数えて、DOM の値を更新するという風にしています。Vue では Map の変更が上手く反映されなかったので、このように最後に配列に push していくという形式を取っています。そんなに大量に記事が増えることもないと思うので、サーバーレンダリングでも良い気はしますが、一応非同期に行っています。手間がかかった割に地味な機能なんですよね。。。 const tags = reactive<TagCount[]>([]); onMounted(() => { context.root .$content(queryName) .only("tags") .fetch<Promise<{ tags: string }[]>>() .then((resps) => { const tagMap = new Map<string, number>(); resps.map((resp) => { _ = resp.tags?.split(" ").forEach((tag) => { tagMap.set(tag, (tagMap.get(tag) || 0) + 1); }); }); tagMap.forEach((num, tag) => { tags.push({ name: tag, count: num, }); }); }); }); はまったこと はまったことは、クエリが変わった際に発火するようにした asyncData の検索結果が、サーバーレンダリング時とクライント実行時で結果が変わったことです。...