スキップしてメイン コンテンツに移動

投稿

注目の投稿

Heroku を手動 deploy する

Heroku を手動 deploy する 先日、Heroku が やらかした 事件 があった。 このニュースを聞いて、すぐに github から heroku を切り離した。 その後、パスワードリセットが掛かる等、色々あったが、その辺は割愛。 実は、 つんでれ bot は heroku で稼働しているので、こいつの更新が出来ない状況になってしまった。 地味にちょくちょく更新していたので、どうにか deploy しなきゃなーと思ってたが、ようやく deploy 方法を見つけたので、ここに記録する。 heroku-cli を入れる まず、heroku-cli を導入する。 今は、npm 一発で入れられるので、 npm install -g heroku 自動アップデートされないから、他の方法をやれと書いてあったけれど、deploy する度に更新かければいいやという事で、折り合いをつける事にする。 次に、heroku にログインする heroku login をした後、Enter を叩くとブラウザが立ち上がるので、そこで認証する。 2段階認証もブラウザで出来る。 コマンドライン上でも出来るので、そこはお好みで。 その後、対象のレポジトリに移動し、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 が使えてお金が掛からないサービスあったらどなたか教えてください。
最近の投稿

puppeteer で、ほどほどの速度で自動スクロールさせるコード

puppeteer で、ほどほどの速度で自動スクロールさせるコード puppeteer で、ほどほどの速度で目的の要素の位置に自動スクロールさせるコードを書いた。 await page.evaluate(async () => { const targetClass = ".target_class"; const hh = document.querySelector(targetClass).offsetHeight; await new Promise((resolve, reject) => { const moved = 100; let _top = 0; let timer = setInterval(() => { window.scrollBy(0, moved); _top += moved; if (_top > hh) { clearInterval(timer); resolve(); } }, 100); }); }); targetClass に、適当なセレクタを指定の事。 最初は、 await page.evaluate(async () => { const targetClass = ".target_class"; const hh = document.querySelector(targetClass).offsetHeight; window.scrollTo(0, hh); }); というシンプルなコードを書いていたのだが、これだと Intersection Observer 的な奴の処理が上手く走らなかったので、少し面倒くさいコードを書くに至った。 これならば、ちょっとずつスクロールしてくれるので、Intersection Observer に何か仕込んでいるサイトでもちゃんと動いてくれる。

electronのリリース用ファイルサイズを半分以下にした

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回パッキングしていた可能性がある。 ひどい。 まあ、何も知らないで作るとこうなるという話なので、もし似たような件で悩んでいる人がいたら参考にしていただければと思う。

ワクチン接種3回目

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

きつねゆっくりリネーマーというツールを作った

きつねゆっくりリネーマーを作った きつねゆっくりリネーマーという名前のツールを作りました。 こちらからアクセスしてください 技術関連に関するあれやこれ 今回は、自分の主戦場でもあるJavaScriptをベースにツールを作ろうという事で、色々模索した結果 vite+TypeScript+electron という技術選定になった……が、実際にはTypeScriptはほぼ使っておらず、JavaScriptメインでの実装になってしまった。 これに関しては、今後のアップデートなどで更新出来たら良いなぁぐらいに思っている。 electronでfsなどを使うためには、色々工夫が必要で、preload.jsにcontextBridgeやらipcRendererを経由して、background.jsでデータをやりとりするみたいな感じになった。 レンダラーの所では、window.API名みたいな感じでアクセスするのだが、これの部分にはちょっと工夫が必要で、 App.tsx を見てもらえば分かるのだが、 declare global { interface Window { api?: any } } の設定と、関数内で、 if( window.api ) というチェック処理が必要になる。これをやらないとコンパイルが上手く通らない上、画面が真っ白になって動かないというバグがあった。 これは、デバッグモードでは見つけることが出来ないバグだったので、色々と辛かった。 まあ、いずれにせよ、このツールを作る事で、electronアプリの作り方を一通り体験出来たのは良かった。 nodejs周辺のライブラリを使うのにはかなり工夫が必要なのだが、一旦覚えてしまえばそこまで複雑な処理ではないので、勉強できて良かった(小並感)。 その他今後やっていきたい事 今回、ビルドしてみて改めて思ったのは、electronアプリのサイズがでかすぎるという事。 Hello,worldレベルのアプリに125Mは流石にでかすぎる。 サイズ的には30Mとか40Mくらいに抑えられるものだと思っているので、今後何かしら良い方法を知ることが出来たら、それで実装してみたいと思う。

ddu.vim introduction

ddu.vimへ移行する 昨日、重い腰を上げて、 denite.vim から、 ddu.vim への移行を行った。 基本的なセッティッグは、ddu.vimのREADME.mdを読めばある程度出来る。 とは言え、ddu.vimの理念を理解していないとそもそも使えないプラグインなので、理念を含めて説明していきたいと思う。 ddu.vimとは ddu.vimは、 Shougo さんによって開発されている、Vimプラグインである。 Unite.vimやdenite.vimの流れを組むプラグインであり、物凄く雑に説明すると、Vimで操作できる全てをコントロールしようというプラグインである。 雑すぎねーか。 Unite.vimからこのコンセプトは変わっていないが、Unite.vimは速度が遅いという欠点を抱えていた。 そこで、速度改善のために、pure Vim Scriptから脱却し、Python3を採用したのが、denite.vim。 しかし、denite.vimはPython回りのでトラブルが多かった。 そういう地獄のような状況で、 denops.vim というプラグインが登場する事で環境が一気に変わった。 denops.vimは、 Deno をVimで使えるようにするプラグインで、これがべらぼうにVimと相性が良かった。 早いし、色々なことが出来るなど、非常に柔軟な対応を出来るようになった。 Pythonちゃんは要らなかったんや……。 簡単にまとめると、 ddu.vimは全てを繋ぐ 環境依存性を著しく下げるdenpos.vimの登場により、環境構築が容易に Denoを採用することで高速性と柔軟性を担保 と言った、まさしく次世代のプラグインと呼ぶことが出来る。 ddu.vimの概念 ddu.vimには、 UI sources filters kinds という概念があり、これらも合わせてインストールが必要である。 それぞれ好きな物をインストールすれば良いと書いてしまえばそれで終わりなのだが、初めて導入する人にとっては何を言っているのか意味が分からないと思う。 UI は、文字通り、ユーザーインターフェースである。 とりあえず、ファジーファインダーに近い動きをしている、ddu-ui-ffを採用すれば良い。 sources は、

Netlifyでnode-gypのビルドが失敗したので、その対応

netlify で node-gyp のビルドが失敗した時 node-gyp という、nodejs回りを触っていたらなんか勝手にインストールされる奴がいるんだけれど、毎度毎度ビルド回りで、困らせてくる。 今回は、netlifyでビルドしようとした時にこいつのビルドが出来なくて、困ったので、その備忘録。 自分がビルドしようとしたnode-gypのバージョンは、8.4.1(2022年3月現在)。 こいつのビルドには、どうやらPython3.6以上が必要。 しかし、netlifyのデフォルトでは Python3.5.2が使われていたのでコケてしまった。 なんだこいつ。 https://docs.netlify.com/configure-builds/environment-variables/ と、 https://github.com/netlify/build-image/blob/xenial/included_software.md を見て、どうやらPYTHON_VERSIONに3.7を指定出来るようなので、Deploys > Deploy settings > Environmentを選び、PYTHON_VERSIONを追加した。 ついでに、NODE_VERSIONも今使っている16.14にアップデートしておいた。 これでビルドが上手く通った。 node-gypって何に使ってるん? node-gypって何に使ってるんでしょうね。 なんか色々入れていると気がついたら毎回入ってくる感じで、マジで捨てたい。 こいつのビルドエラーは頻繁に起こっている印象があり、開発体験を著しく悪くしているのでなるべくサクサクと倒せるようになりたい。