Loox Uと初音ミクで行こう！

コンパクト長財布 ブラックフライデーという名前の様々な通販商品買い叩き時期がやってきた。今年は色々と散在し、トータルで20万ぐらい使った。主に、ロードバイク系の商品にガッツリお金を掛けた形になる。前にもちらっと書いたが、手持ちのロードバイクを11速化+パワーメータを搭載というアホな事をする予定で、そのための出費＋スマートウォッチとサイコンを買ったみたいな感じでかなり散在してしまった。 そんな大量にロードバイク用品に偏った中で、ロードバイクにあまり関係なかった 長財布 の話を今日はする。 今まで使っていた財布 今までは、 ダンヒルの長財布 を使っていた。手触りと使い勝手が良く、かなり気に入っていた。しかし、形あるものはいつか壊れる。ジッパー部分の取っ手（？）がブチッと切れてしまった。かなり悲しかった。しばらくは、ジッパーを指でつまんで無理やり開けしめしていたが、段々とその行為にストレスを感じるようになった。 そこで腹を決めて、新たな財布探しに出たのが先月の頭ぐらいの話。 一応長財布を使っていて、こういうのが欲しいなーというおぼろげな輪郭を決めていた。 サイズは1万円サイズ ジッパー式はNG 予算は4万まで まず、1万円サイズというのは、長財布が取れるギリギリのサイズなので、これはマスト条件。 ジッパー式は、今回みたいに壊れたら嫌だなという思いがあり、なるべくジッパー式ではないタイプをチョイス。 予算は4万までという事にしたけれど、安ければ安いほど良いので、下限はそこまで設けなかった。 このような条件で探すと、以下の3つが候補として上がった。 usuha-long il modo loneo usuha-long まず、デザインに惚れた。ギボシで止めるタイプはめっちゃオシャレ。 設計思想も好みだった。最小＋最薄を目指すコンセプトは、自分の志向とも合っていた。 思考停止で買おうとしたのだが、なんとこれが超人気商品で、長期間待つ必要があった。 そのため、候補から外れることに。 il modo usuha-longと良く似たコンセプトの財布。これも、かなり好みなデザインである。 設計思想も似通っていて良い。Amazonですぐに買える。という事で、第一候補になった。 loneo こちらのloneoもusuha-longと似たコンセプト...

dpp.vimの設定でハマったアホな話 本記事は Vim駅伝 2024å¹´11月13日の記事です。 気がつけば11月も折り返しが近づいてきていて「2024年もあと1ヶ月半か～時間の流れが早すぎるってばよ……」と思っているArcCosineです。皆様いかがお過ごしでしょうか。 今日の記事は、 dpp.vim の設定をしていてハマったアホな話になります。 忙しい人のための要約 インストールパスを間違えない 便利な自動設定コードを活用 dpp.vimの導入をスムーズに もう少し詳しく知りたいと思った方は、続きをお読みください。 dpp.vimとは dpp.vimとは Dark Powered Plugin manager for Vim/NeoVim の事で、俗に言うshougowareにおける最新のVimプラグインマネージャーです。 この一つ前は、 dein.vim と呼ばれるプラグインマネージャーが活用さていました。dein.vimは中々画期的なプラグインマネージャーでした。dein.tomlやdein_lazy.tomlといった TOMLファイル を活用してプラグインの管理が色々出来るという事で、飛びついたのもありますし、何よりも 高速化 という言葉に弱い私にとっては大変魅力的なツールでした。しかし、dein.vimにも弱点が無かった訳ではありません。その辺の歴史に関しては、 プラグインマネージャーの歴史と新世代のプラグインマネージャー dpp.vim という記事が大変詳しいです。 この記事は実は非常に重要な 二次情報 で（一次情報はgithubに挙げられているソースコード。プログラマは黙ってソースコード読みなさいというストロングスタイル）、ここに書いてある設定を読み込むならば、誰でも（誰でもとは言っていない）dpp.vimを導入することが出来るようになっています。 記事の前段部分があまりにもボリューミーなため、本当に必要な設定に関しては一番最後の方に書いてある上に、これはどういう事をしますという説明が省かれているため、初見さんにはかなり厳しい内容となっています。 とは言え、そういう 思想 のプラグインなので、楽に導入したいという人は、もっと楽に導入出来るプラグインマネージャーを採用すれば良いのです。無理して苦労して導入している人...

外食産業へのお金の落とし方 僕は自炊が好きだが、外食も好きだ。父親が料理人であったため、実家にいた時も結構外食をしていた。そして、そこで食べた美味しい食べ物を真似して、アレンジして、家庭料理に落とし込むというのが僕の家における常であった。 そして、現在の自分も似たような感じで外食を利用している。 自分のレパートリーを増やす目的で外に食べに行く のだ。もちろん、作るのが面倒だという時に活用することもあるが、自分の手札が増えることに喜びを感じる人種なので、様々なお店に食べに行くことが多い。 とはいえ、自分にとって再現可能な店には基本的に1回ぐらいしか訪れない。自分が真似できない味や旨さを提供してくれるお店にはリピートして通うことがある。その代表例が ラーメン屋 である 1,000円の壁 ラーメンハゲの漫画 を読んでいる人は1,000円の壁と読んでいるものがある。ラーメンに関して1,000円以上出すのに抵抗があるという考え方だ。最近は700円～900円代の間が値段の主軸になっている気がする。それにトッピングを加えて1,000円超えを目指しているというが現状だろうか。 自分は、以前にラーメンに1,000円も出すのは惜しいと考えていたが、今は 1,000円以上を落としたい と考えるようになった。なぜなら、自分でラーメンを再現して作るようになり、そこにどれだけのコストが掛かっているかを理解出来るようになったからだ。昨今のインフレも考えると、一杯あたりのコストはどんどん上がっていて、 1,500円くらいが妥当な値付け だと考えている。もちろん、あまりにもアレなお店で食べるとがっかりする事があるが、一定水準のお店で食べるなら、それ相応のお金を落として、継続して営業し続けて欲しいと思っている。 しかし、ほとんどの人にとって、ラーメンに1,000円は高すぎる感覚だろうなと自分は思っているし、友人たちの感覚もそうである。とはいえ、そろそろ日本人の安いのが良いという考え方が変わって欲しいなと思う事しばしである。 ちゃんと良いものに、ちゃんとお金を落として、ちゃんとクリーンな経営を続けてもらう。それこそが、多くの人にとって幸福度が最大になる流れだと思う。しかし、実際には、粗悪なものに、ほどほどにお金が落ちて、ブラックな経営が生き残るというのが実情である。 この世界は、「 い...

サイクリスト向けワークマンコーデ 公式サイトより画像引用 だんだん寒い日が続いてるが、相変わらずロードバイクに乗って走っている。 ロードバイク乗りの中で、密かにコスパが良いと言われていたのがワークマンでサイクルウェアを買い揃えるという手法だった。しかし、昨今のワークマンは迷走が続いており、 サイクリスト向けの商品がほぼ店頭で売られなくなってしまった 。自分が年初あたりにサイクルジャージを購入できたのは運が良かったと言える。 現状、ワークマンで サイクルウェアを買い揃えるのは不可能 になっている。 特に サイクルジャージ サイクルパンツ サイクルグローブ の3点はほぼ手に入らないと言っても良い。これらの3パーツに関しては、大変残念だが別の会社から調達してくるしかない。Morethanやサンティックと言ったマイナーブランドから僕は調達していて、なんとか支出を抑えている。サイクルグローブだけは、モンベルの無駄に高くていい奴を買った。1年間ずっと使っているが、まだまだヘタれていないので、来年以降も使い潰すつもり。 2024年でもワークマンで揃えられるサイクリスト用コーディネート LOVE CYCLIST様のサイクルウェア＜春夏秋冬＞完全コーディネートガイドより画像引用 2024年現在でも、ワークマンで恒常的に発売されていて、代替が効きそうなコーディネートについて、ここからピックアップしていく。分かりやすく冬のコーディネートをLOVE CYCLIST様のサイトから引用した。この絵の中でワークマンでも揃えられる事が出来るのは ビーニー ウィンタージャケット 長袖ベースレイヤー ソックス の4点である。 ビーニー まず、ワークマンではビーニーというおしゃれな名前では売られていない。 ヘルメットインナー のような名前で売られていて、これが汗を吸収し、なおかつ風を通さないという中々のスグレモノである。ロードバイクで走る時、冬は頭が寒くなるのだが、これをつけてから寒さを感じなくなった。大体500円前後で手に入るので、見つけた際には確保をお勧めする。ちなみに、デザインに関しては、アレなものが多いが、そもそも、これを被ったまま町中を移動することはないから、気にする必要はない。大事なのは、 性能 。 ウィンタージャケット これも、ウィン...

Let's note を USB-Cで充電出来るようにする 先日の記事 に書いたように、Let's note CF-SZ6を衝動買いしたあと、疑似Chromebookとして運用している。 Let's noteは非常に軽くて使いやすいのだが、唯一難点を挙げるとしたら、 専用充電器 が必須という点である。 昨今は、USB-PDの登場により、 汎用充電器 にUSB-Cケーブルぶっ刺して電源供給するというのがスタンダードになっている。なっていない所もあるかもしれないが、なっているのだ。 当然、自分もなるべく荷物をごちゃごちゃと持ち歩くのはスマートではないので、USB-C経由で充電したいという欲求がある。 ちなみに、今CIOの NovaPort TRIO 65W 3C というPD充電器を持っていて、こいつにつないであれこれしたいなと考えてぐぐった所、どうやらそういうニッチな製品がある事に気がついた。 それがこれ。 パナソニック（Panasonic) レッツノート（Let's note） 対応 USB PD トリガーケーブル eMarker内蔵 15V 5A (PDE-15V-5525) なんとも胡散臭い商品名であるが、これがちゃんと動いた。素晴らしい。ネットの記事を見ると、65W以上の出力に対応している充電器＋トリガーケーブルがあれば充電出来ると書いてあった。 厳密には16V必要らしいのだが、実際に使ってみると問題なく充電出来ている。 BIOS画面から、「純正充電器使っていないよ」という警告は出るものの、今のところ爆発四散していないので、しばらくはこれを使っていく予定である。 安全面という事を考えると、付属で付いてきた充電器を使うのが望ましいのだが、人間、利便性には勝てなかった……。 編集後記 この記事を書いたあと、Amazonのリンク先を見てみたら、在庫切れになっていた。トリガーケーブルで、15V 5A対応の製品があれば、行けると思うので、 ネットの海を探せば 出てくるかもしれない。 記事内にも書いたが、安全面の保証は一切されないので、購入＆使用に関しては自己責任で。 あ、CIOの PD充電器 はめっちゃ安定してる＆ちょうどよいお値段なので、オススメします。

WSL2に立てたサーバに、外部端末からアクセスする 最近、絶賛WSL2で開発中なのだが、ちょくちょく外部端末からアクセスしたくなる事が多くなってきた。 wsl2 で立てたサーバーにローカルネットワーク内の他の端末からアクセスする 上記記事を 丸パクリ 参考にして、自分の環境用にカスタマイズしたスクリプトを公開する。 ポートを開放するスクリプト ポートを開放するスクリプトは下記の通り。 コピペで使えるはず。 コメント行の下に空行を入れないと、その下の文がコメント扱いされる という罠があったので、注意。 僕はこのスクリプトに、 server_conf.ps1 という適当な名前をつけて、 PowerShell で実行した。 実行すると、管理者権限のPowerShellが立ち上がって勝手に色々やってくれる。 $ports 変数の所を調整すれば、色々と好きなポートを開けることが出来るので、自分の環境に合わせて変えて欲しい。 # 管理者権限で実行 # コメントの下に空行を入れないと、その下の文はコメント扱いされるので、注意 if (!([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole("Administrators")) { Start-Process powershell.exe "-File `"$PSCommandPath`"" -Verb RunAs; exit } # WSL 2 の IP アドレスを取得 $ip = bash.exe -c "ip r |tail -n1|cut -d ' ' -f9" if( ! $ip ){ echo "The Script Exited, the ip address of WSL 2 cannot be found"; exit; } # 通信ポートを開く $ports=@(3000, 5173); $ports_a = $ports -join ","; # ファイアウォールの例外ルールを削除 iex ...

バグ発見から学ぶ：Cloudflare Workers+Hono で SESAME API を最適化 SESAME に関する記事はこれが 3 本目かもしれない。 今回、SESAME 関連の自前開発をしてて、Cloudflare Workers のバグを発見したので、その顛末を綴っていこう。 SESAME 操作環境遷移 以前の 記事 の通り、自分の SESAME 操作環境は下記のように遷移していった。 Google App Script + IFTTT Google App Script + MacroDroid Cloudflare Workers + MacroDroid(And ショートカット) まず、GAS+IFTTT の王道の組み合わせだが、以下の不満点があった。 IFTTT の反応がゴミ 自分が帰宅範囲内に入っても全然動作しないというやる気の無さっぷりにキレてしまった。 そうして、ネットの海を徘徊して見つけたのが、MacroDroid。 GAS+MacroDroid の組み合わせは、しばらくは不満がなかったのだが、これもまたイライラする要素があった。 それは GAS の起動がゴミ GAS を使ったことがある人なら分かるが、GAS は起動速度がとんでもなく遅い。 Cold start だと平均 9 秒～ 11 秒くらい掛かる。 そもそも、GAS をサーバレス・アーキテクチャとして使うなという話ではあるが、この起動の微妙な遅さのせいで、帰宅してから数秒のタイムラグがあり、キレてしまった。 Cloudflare Workers + Hono に出会う そんなさなか、ひょんな事から Cloudflare Workers + Hono の案件をもらい、実装する事でその汎用性の高さに気がついた。 まあ、この Cloudflare Workers を実装するきっかけになったのも GAS の案件で、死ぬほど GAS の起動が遅いからどうにかしてくれーという話に対応するためであった。 GAS はデータベース的に使うと便利（コンピュータにそこまで詳しくない人でもデータ入力ができる）なのだが、その分高速性は犠牲にされている。 1 分 1 秒が貴重な現代では、10 秒のコールドスタートははっきり言って時間の無駄。 Cloudflare Wo...

denops.vim を使って初めてプラグインを作った これは Vim 駅伝 7 月 28 日 の記事です。 次回は、7 月 31 日に投稿される予定です。 Markdown ファイルを HTML に変換して、クリップボードにコピーしたい こういう Vim プラグインをずっと探していた。だが、あまりにも需要がないので誰も作っていなかった。 denops-markdown2html だから、作った。 インストール方法 vim-plug の場合は、 Plug 'vim-denops/denops.vim' Plug 'ArcCosine/denops-markdown2html' dein.vim の場合は、 call dein#add('vim-denops/denops.vim') call dein#add('ArcCosine/denops-markdown2html') これでインストール出来る。 その他設定 set clipboard+=unnamed クリップボードを連携させる設定をしておく。 既に設定済みならば、この記述は要らない。 使い方 :DenopsMarkdown2Html このコマンドを実行する事で、カレントバッファの Markdown を HTML に変換してクリップボードにコピーしてくれる。 開発経緯 このブログの読者で、記憶の聡明な方ならば、10 年くらい前に markdown.pl を導入した話を覚えているだろう。当時は、perl の markdown 変換ツールが一番メジャーだった。 それから数年後には、nodejs の marked.js をベースに変換するツールを使っていた。 どちらのケースも、カレントバッファをツール（markdown.pl,marked.js）に渡して、出力結果をクリップボードにコピーするという動きをしていた。 これらの処理には幾つか不満点があった。 一時ファイルを生成していた vimrc に直接書いていてダサかった perl をインストールする必要があった nodejs をインストールした上で、npm install コマンドを最初に実行する必要があった。 一時ファイルを生成していた 一...

ssh config で複数の秘密鍵を切り分ける方法 ようやく、納得の行くやり方が出来たのでメモ。 まずは設定 ~/.ssh/config に、下記の設定をする。 # github プライベートアカウント Host github.com HostName github.com User git IdentityFile ~/.ssh/githubkey1 IdentitiesOnly yes # github 仕事用アカウント Host github.com.sub HostName github.com User git Port 22 IdentityFile ~/.ssh/githubkey2 TCPKeepAlive yes IdentitiesOnly yes 解説 ポイントは、Host 名に必ず、トップレベルドメインまで入れる事。 Host github ---> NG Host github.com ---> OK Host github.com.subdomain --->OK ちなみに、最近まで一番上のトップレベルドメイン省略で設定していたせいで、何にも参照していない状態だった（辛い）。 ~/.ssh/config に設定する際には、必ずトップレベルドメインまで指定しましょう。 さて、自分は仕事の関係上、プライベートアカウントと仕事用アカウントを２つに分けて運用している。 あとはこれを使い分けるために色々やってるのだが、仕事用アカウントのリモートレポジトリを下記のように設定している origin [email protected]:仕事用アカウント名/レポジトリ名.git ポイントは、 [email protected] で開始している所。 こうする事で、仕事用アカウントのレポジトリは、仕事用の秘密鍵を参照するようになる。 便利。 この設定は、クローン時に下記のコマンドを実行すれば良い git clone [email protected]:仕事用アカウント名/レポジトリ名.git その...

Next.js 13 以降で PWA を有効にする 2023/5/28追記： さらに良い設定を、新しい記事に書いたので、そちらを参照の事。 多分、その内 next-pwa が対応するので、待ってれば大丈夫だと思うが、どうしても今すぐに対応したい人用のパッチコード。 バージョンは、 next ^13.4.2 next-pwa ^5.6.0 となっている。 修正するファイルは、next.config.js next.config.js /** @type {import('next').NextConfig} */ const path = require("path"); const isDev = process.env.NODE_ENV !== "production"; const withPWA = require("next-pwa")({ dest: "public", disable: isDev, exclude: [ // add buildExcludes here ({ asset, compilation }) => { if ( asset.name.startsWith("server/") || asset.name.match( /^((app-|^)build-manifest\.json|react-loadable-manifest\.json)$/ ) ) { return true; } if (isDev && !asset.name.startsWith("static/runtime/")) { return true; } return false...

bluesky始めました 今話題の bluesky の招待コードをもらうことが出来たので、blueskyを始めました。 画面としてはこんな感じ。 見慣れたTwitterのUIで作られています。 これ、アカウントを作ると最初は、「ユーザ名.bsky.social」みたいになるのですが、独自ドメインを持っている人は、自分のドメインを設定することが出来ます。 以下、その設定方法のメモです。 Blueskyのスクリーンネームに独自ドメインを設定する方法 これから仕様が変わるかもしれませんが、2023å¹´4月現在、PCからも blueskyへのアクセスが出来ます 。このページに招待コードを入れて、アカウントを作った後の話です。 アカウント作成にアプリはなくても大丈夫です。 さて、スクリーンネームに独自ドメインを設定する方法ですが、「Settings→Change my handle→”I have my own domain"」とクリックすると下記の画面が表示されます。 Enter the domain want to use と書いてあるフィールドに、自分が持っているドメインを入力すると、下部にどういうDNS設定をすればいいかが表示されます。 TXTレコードのサブドメインとして_atprotoを設定して、did=did:plc:ほにゃららみたいな値を設定すればいいだけです。 Value-domainで設定する 自分は、Value-domainを使っているので、こういう感じで一番最後に設定しました。 他のDNSサーバでも同じだと思いますが、TXTレコードに txt _atproto did=did:plc:ほにゃらら と言った感じで、設定すれば良いです。 浸透したかどうかを whatsmydns で確認後、Blueskyの画面に戻り、Verify DNS RecordとすればOK。 ちゃんと浸透していればスクリーンネームが更新されます。 blueskyの感想 まだ始めてから数日なので、雰囲気を掴み取れてないのですが、mastodonと違って、TLは自分がフォローした人しか流れてこないので、相当に穏やかな流れになっています。 フォローしていない人の情報を眺めてカオスな感じのmastodonもありますし、まったりとしたローカルタイムライ...

Vim のテキストオブジェクトと surround.vim で効率よく入力 これは Vim 駅伝 の 13 本目の記事です。 テキストオブジェクトとは 皆さんは、テキストオブジェクトを活用しているでしょうか。 私は、特に HTML を書く時にテキストオブジェクトを活用しています。 テキストオブジェクトは、Vim7 から導入された新しい概念であり、記号などで囲まれたテキストをオブジェクトとして扱うことができる、Vim の機能です。 具体的には、カッコやダブルクオーテーションやタグ等で囲まれているテキストの削除、コピー、変更を簡単に行なう事が出来るようになります。 実際にテキストオブジェクトを使う場面 では、実例を考えてみましょう 例１）記号で囲われたテキストの中身を削除する 例えば、下記のようなコードがあったとします。 function (arg1,arg2,arg3) { } (arg1,arg2,arg3)と書かれた所を一気に削除したい事がありますよね。 通常の削除処理では dwdwdwdw と連打して消すとか、 5dw で消すというやり方が思い浮かぶかもしれませんが、テキストオブジェクトの場合、下記の操作で削除出来ます。 di( または di) 実際に、上記コードをコピペして、やってみてください。 ()内であればどこででもこの操作は有効です。 同じような例として const str = "Hello, World"; のように、ダブルクオーテーションで囲まれた文字列を削除したい場合は、 di" で削除する事が出来ます。 例２）記号で囲われたテキストの中身を変更する 例えば、下記のようなコードがあったとします。 function (arg1,arg2,arg3) { } (arg1,arg2,arg3)と書かれた所を一気に変更したい事がありますよね（デジャブかな？）。 そんな場合、下記の操作で変更出来ます。 ci( と入力すると、()の内側を消して、入力モードになります。 そのままタイプすれば、中身を変更することが出来ます。 同じような例として <h1>sample title</h1> のように、タグで囲まれた文字列を変更したい場合は、 cit と入力すると、...

Sesami4 を IFTTT で操作する 先日、スマートロックの Sesami4 を購入した 。 使い始めて 1 ヶ月ちょいになり、不満点が出てきた。 手ぶらで解錠がロクに効かない Android のウィジェットが常時表示はウザい オートロックを有効にしてると締め出される（当たり前だよなぁ！？） と言った感じ。 この中では特に手ぶらで解錠がロクに効かないのには相当不満があった。 原因はシンプルで、BLE（Bluetooth Low Energy）が上手く動作していなかった。 観察した結果だが、動作する時はちゃんと動作するが、ダメな時はとことんダメ。 Sesami の作り込みが甘いのか、純粋に Android の反応が悪いだけなのか、どちらなのか判断は付けられない。 その両方である可能性もあるが、いずれにせよこれでは快適な生活が送れない。 Sesami は API を公開しているので、それを使ってリモートコントロールする事にした。 あ、一応 Sesami の WiFi モジュール は導入している前提。 これがないと今回の Tips は使えないので、気をつけるように。 今回は スマートロックのセサミをさらに便利にする(アレクサからパスコードレスで解錠&オートロック化) の記事をそのままパクってるだけなので、その記事を読めば概ね同じことが出来る。 Sesami API キー取得 公式ページ にアクセスし、メールアドレスを入力する。 認証コードが送られてくるので、それを入力すると API 取得画面が表示される。 スマホアプリの「このセサミの鍵をシェア」から QR コードのスクリーンショットを撮って、API 取得画面にアップロードする。 そうする事で、デバイスの UUID と SecretKey が取得出来る。 API キー デバイスの UUID デバイスの SecretKey GAS のエンドポイント認証用のハッシュ値を用意する 下記のコマンドを実行して、認証用ハッシュ値を取得する。 任意のパスワードは、IFTTT との連携に使用するので、メモしておく事 $ echo -n '任意のパスワード' | shasum -a 512 自分は WSL2 上で実行して取得した。 SHA512 Onl...

WSL2にfishを導入した 最近、WSL2をカスタマイズするのにハマっている。 カスタマイズを始めると、色々とやりたくなるのは開発環境構築あるあるで、以前から気になっていた fish を導入することにした。 fish のインストール sudo apt install -y fish aptで入れるだけなので、簡単。 chsh which fishでパスを確認し、 chsh を実行する。 自分の場合は、「/usr/bin/fish」にインストールされていた。 fisher のインストール fishのプラグインマネージャーにはfisherを採用 curl -sL https://raw.githubusercontent.com/jorgebucaran/fisher/main/functions/fisher.fish | source && fisher install jorgebucaran/fisher これもワンライナーでインストール出来るので楽ちん。 fisherプラグインを入れる テーマ まず、テーマを入れる。 fisher install oh-my-fish/theme-bobthefish これで、いい感じのテーマが入る。 今使っているLightlineライクなテーマで個人的には気にいっている。 もし、文字化けするようであれば、weztermのフォントを変えればOK。 weztermの設定に関しては、 前の記事 に書いてある。 z 補完を色々とやってくれるzも入れた。 fisher install jethrokuan/z 「z ディレクトリ名」を入力した後、TABキーで補完してエンター押せば一発移動してくれるので超便利。 オススメ。 他にも何かオススメのプラグインがあったら教えてください。 環境変数を適用する このままだと、何故かdenoを認識してくれなかったので、環境変数を適用する。 ファイルの場所は、 ~/.config/fish/config.fish 。 if status is-interactive # Commands to run in interactive sessions can go here # deno set -x DENO_INSTALL...

Windows11 on WSL2 + wezterm + Neovim = 最強開発環境 これは、恥を忍んで書いている。 以下の点を守れば、Neovim使いにとって最強の開発環境を手に入れることができる。 開発用ディレクトリをWSL内に入れる Terminalをweztermにする wezterm内でNeovimを使う 開発用ディレクトリの位置 さて、まずは開発用ディレクトリの位置に関してだが、これはWSL内に入れると非常に快適に動作してくれる。 何を当たり前の事をと思われるかもしれないが、案外気が付かずに開発している人もいるかもしれないので、テキスト化する。 実は、自分は、 /mnt/d/hogehoge のようなディレクトリ下に開発用ディレクトリを置いていた（今もいくつか置いてある）。 これで問題なく開発できるプロジェクトもあるが、WSL経由でやろうとすると 死ぬほど遅い 開発体験になる。 もう既に識者の方は気がついていると思うが、/mnt/cや/mnt/d以下のアクセスはWindows経由でのアクセスになる。つまり、wsl→仮想ネットワーク→Windowsという遠回りをしてファイルにアクセスしているのと同義であった。 これは、非常に遅い開発体験になっても仕方がない。 自分は、開発ディレクトリを /home/ユーザ名/develop 以下に移動して、めちゃくちゃ快適な開発体験が出来るようになった。 yarn installがやけに遅かったり、yarn devでの起動が異様に遅かったのは、開発ディレクトリの位置が悪かったからという非常にお粗末な環境設定のせいだった。 もし、WSLで開発しようと思っている人は、ちゃんとWSL内にファイルを置いて開発する事。 試してないけれど、シンボリックリンクで/mnt/cとか/mnt/dに繋ぐと同じように遅延が発生すると思われるので、絶対辞めるように。 ちなみに、この情報は英語圏には大量に出回っており、既知の事実として知れ渡っている。 なんてこったい。 Weztermの設定 Cross Platformで使えるWeztermが非常に良い。 自分はとりあえず最小構成で使うようにしている。 local wezterm = require 'wezterm' local act = wez...

Next.js でのハマりどころ 自分用メモの羅列 firebase用の.envファイルのパラメータ命名 NEXT_PUBLIC_FIREBASE_API_KEY="" NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN="" NEXT_PUBLIC_FIREBASE_PROJECT_ID="" NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET="" NEXT_PUBLIC_FIREBASE_MESSAGE_SENDER_ID="" NEXT_PUBLIC_FIREBASE_APP_ID="" NEXT_PUBLIC_FIREBASE_MEASUREMENT_ID="" 先頭のprefixに必ず NEXT_PUBLIC_ をつける事。これをつけないと、Next.js内で参照する事ができない。 process.env.～でアクセスするコードを書くと分かるが、コマンド実行しているコンソール内にはきちんと設定した環境変数が出力されるが、ブラウザのコンソール内にはundefinedが出てくる。 こういう謎のprefixをつけなきゃ見えないみたいな処理が入ってるのは、フレームワークあるあるの罠である。 ロード時間に死ぬほど時間が掛かる プロジェクトに recharts を追加してからyarn devしたら、読み込みに死ぬほど時間が掛かるようになった。 具体的には、1.8Mのjsファイルを読み込むのに1分ちょい掛かるというありえない開発体験をする事に。 「nextjs development loading very slow」みたいなキーワードで検索すると、検索トップに Super slow page load times in development environment みたいなgithub discussionページが引っかかった。 これをばーっと眺めていると、どうやらGoogle ChromeのPWA用キャッシュをクリアすると早くなるらしい。 半信半疑で、Application→Application→Storage→Clear site dataをクリックしたら、見事にロード時間が改善...

API化したGASの高速化まとめ ひょんな事から、GAS経由でスプレッドシートの中身をAPI化する案件を頂き、ざっと構築したのは良いがあまりにも処理が遅すぎたので、高速化のためにやったあれやこれをまとめる。 全データ取得 まず、一番の高速化と言えば、データ取得。 for文で回してセルのデータを取るのではなく、 Sheets.Spreadsheets.Values.batchGet(sheetId, request).valueRanges みたいな感じで、ぐわっとデータを取るのが早い。 これは以前にやった事がある事だったので、基本中の基本なのだが、これだけだと高速化しなかった。 キャッシュ化 今回の案件は、複数のスプレッドシートからデータを取得して表示するという物であった。 故に、初回の実行時はどうしても何度かリクエストを飛ばす必要があった。 で、これが同じネットワーク（？）内だとある程度キャッシュが効くのだが、別のネットワークになると途端に起動が重くなるという クソ仕様 現象が生じた。 これを解決するために、色々調べた結果、 CacheService を使うと良い事が分かった。 const cache = CacheService.getUserCache(); みたいにして、後は let data = cache.get("keyName"); if( !data ){ //dataを色々処理 cache.put("keyName",JSON.stringify(data)); } と書いて対応する形にした。 今回は、APIを起動実行するユーザが一人しかいない前提なので、getUserCacheを採用したが、getDocumentCacheや、getScriptCacheとかでも全然構わない。 localStorageの採用 さらなる高速化として、localStorageを採用することにした。 これで、爆速化した。 一応、データ更新は3時間に1回という形にして、 let data = localStorage.getItem("keyName"); let dataObject; // キャッシュ時間は3時間くらい if( !data || data.expire ...

Heroku を手動 deploy する 先日、Heroku が やらかした 事件 があった。 このニュースを聞いて、すぐに github から heroku を切り離した。 その後、パスワードリセットが掛かる等、色々あったが、その辺は割愛。 実は、 つんでれ bot は heroku で稼働しているので、こいつの更新が出来ない状況になってしまった。 地味にちょくちょく更新していたので、どうにか deploy しなきゃなーと思ってたが、ようやく deploy 方法を見つけたので、ここに記録する。 heroku-cli を入れる まず、heroku-cli を導入する。 今は、npm 一発で入れられるので、 npm install -g heroku 自動アップデートされないから、他の方法をやれと書いてあったけれど、deploy する度に更新かければいいやという事で、折り合いをつける事にする。 次に、heroku にログインする heroku login をした後、Enter を叩くとブラウザが立ち上がるので、そこで認証する。 ２段階認証もブラウザで出来る。 コマンドライン上でも出来るので、そこはお好みで。 その後、対象のレポジトリに移動し、remote に heroku を追加する。 cd ~/hoge/fuga/ heroku git:remote -a [アプリ名] 自分のアプリの名前は、heroku の dashboard から確認出来る。 最後に、push する git push heroku master 自分のレポジトリでは master でやってるが、main で運用している人はそこを main にすれば良い。 heroku の方でもなんか設定が必要かもしれないけれど、それは 公式ドキュメント を読んで。 編集後記 これで無事に tundere_bot を更新する事が出来た。 地味に、Twitter API ver2 もリリースされたので、近々そのバージョンで組んでみるつもりである。 あと、色々とアレなので、heroku を使うのをどこかでやめた方が良いかもしれない。 現状は代替が無いので、しばらくは heroku を使う予定だが、node が使えてお金が掛からないサービスあったらどなたか教えてください。

electronのリリース用ファイルサイズを半分以下にした 本日、 きつねゆっくりリネーマーVer 0.0.2 をリリースした。 基本機能は変わっていないが、リリース用のファイルサイズを半分にした。 変更箇所 変更箇所は、package.jsonのbuild。 変更前 "files": [ "dist/**/*" ] 変更後 "files": [ "!.git", "!.dist", "dist/background.js", "dist/index.html", "dist/preload.js", "dist/assets/**/*", "node_modules", "package.json" ], 変更したのはここだけ。 以前のバージョンは、dist以下全部をビルドするようになっていたが、今回は、ビルド用のファイルを個別に指定するようにした。 node_modulesやpackage.jsonやら、色々書いているが、多分要らない。 今後、実験してこの辺はアップデートしていく予定。 推測 以前のビルド設定だと、dist以下を全部包含して作っていたため、同じファイルを2回パッキングしていた可能性がある。 ひどい。 まあ、何も知らないで作るとこうなるという話なので、もし似たような件で悩んでいる人がいたら参考にしていただければと思う。

ワクチン接種三回目 三回目のワクチン接種を木曜日に行ってきた。 そして、昨日は完全に死に体で過ごしていた。 こんな時間になってようやく復活という形。 一回目と二回目はファイザーだったが、三回目はモデルナを接種。 当日は、寝る時に謎の悪寒に襲われて、これやべーわとなったが、案の定翌日は完全死亡。 高熱（測れなかったが、恐らく３８度近く）と全身の倦怠感で色々ときつかった。 お医者さんには、少しでも痛みがあったら痛み止めガンガン飲めと言われてたので、痛み止め（自分はイブＡ錠が相性良いので、イブＡ錠を飲んだ）をガンガン飲んで、横になっていた。食事もろくに作れない状態だったので、事前に簡単に食べられる物やウィダインゼリー的な物を用意して、耐え忍んだ。 誤算だったのは、ポカリスエットを３L用意していたのだが、それが全く足りなかったという点だ。結局、合計で４．５L消費した。 もし、四回目があるなら、ポカリは３本用意しないと駄目だな……。 痛み止めの効果は抜群で、飲んだ後は大分楽になり、ちょっと買い物に行くくらいの元気は出た。 １回目と２回目は特に副反応が出なかったが、３回目はワクチンの本気を感じた。 しかしながら、諸説あるように副反応出たほうが強い抗体が出来るとかなんとかという話なので、これで大分強化されたと思い込むことにしている。 思ったよりも、キツい副反応が出たが、鎮痛解熱剤があれば人類は戦えるので、みんな鎮痛解熱剤をしっかり用意して戦おう。 バファリン、ロキソニン、イブのどれかで戦える。 ちなみに、ロキソニンのパチもん（？）も用意して飲んだが、それよりもイブの方が効いたのは多分体質的な物と思われる。僕はイブの方が相性良かった。