ある OSS のプラグインにちょっと似ているがちょっと違うみたいなプラグインを作りたくなって、でもその OSS の内部構造とか全然知らないので、プラグインの実装を全部 GPT-4 に渡して「これを参考にこういうの書いて」って流したらパパッと出来た。まあでもその実装自体は不具合多数あるものだったんだけど、一旦シンプルな叩き台ができるとあとは話がはやい。QAプロセスまわして直して実装完了したしそのプロセスで知識も増えたのであとは自分でガシガシいける、ということになった。

最近 Hotwire をちまちま使っている 。 Rolling Icon くんも Hotwire でフロントエンド書き直してみた。 こんなかんじの SPA っぽいものならわりとすぐ作れる。 Rails のサーバーサイドの書きやすさもあってなんなら next.js とかで作るよりずっと速くできると思う。それから Rails のテストの書きやすさ(特に E2E テスト)もあって圧倒的に堅牢だと思う。 Tailwind が使えるのでスタイルはそれでやればいいと思う。ちょっと前まで MUI/Chakra UI とか使えないの辛いなあとか思ってたのが、 Tailwind に慣れるともうこれでいいやってなって next.js で書くときも twind ってやつ使うようになった。 とはいえ。 これが流行るとはとても思えない 「テスト書きやすい」ぐらいで next.js から人がこっちくるとは思えない(み

在宅勤務のために買ったけどいらなかったものまとめ 「在宅勤務環境整備しました」とかいって金持ち自慢するのがこの 2 年間ずっと流行ってた感じしますよね、最悪です。 本日は在宅勤務環境整備のために買ってみていらなかったもの、ゴミだったものについて紹介していきます。 マルチディスプレイまわり全般 ぼくは家での作業は主に 24 インチ iMac を使っているんですが、ディスプレイ増やしてみるか〜みたいな感じで浪費をしはじめることがたまにあります。 それで買ったものは ディスプレイアーム https://www.amazon.co.jp/dp/B00MIBN16O/ LG の USB Type-C でつながる 4K ディスプレイ https://www.amazon.co.jp/dp/B09CYBJ31X/ iPad スタンド(こういうやつ https://www.amazon.co.jp/dp/

今年買ってよかったもの 2022 こんばんわ。今年もいろいろ買っているので買ってよかったものをまとめていきます。 iPhone 13 mini 128GB docomo 版です。正月に東京中を徘徊して吉祥寺のヨドバシでようやく在庫確保して買いました。 MNP の弾はなかったので 2 年使って 2 万円です。 XR から買い替えました。 2 万円で買える携帯電話としては本当によいものだと思います。僕の手は面積としては手が小さい女性と比較してもかなり小さい、という感じなのでこのサイズは非常によいです。ただこうやって投げ売りされていることからあきらかな通り全然売れてないし今年からこのサイズなくなるらしいし悲しいことですね。 詳細は調べてほしいんですが 2 年後に没収されるかわりに 2 万で買える、という買い方をしていて実質的にはリースみたいなもんなので 2 年後に安い電話がないと結構面倒なことに

arm Mac と向き合う Web アプリケーション開発環境 しない話: Docker Desktop の課金回避 問題意識 Mac の CPU が arm になってしまった結果、以下のような問題がある JVM 系を中心に amd64 な Docker image が Mac で挙動が怪しい ネイティブ開発すっか!!となるとライブラリのバンドリングとかでおかしいことになりがち Ruby の nokogiri とか ネイティブだと古いものはわりと動かない そういう問題がなかったとして arm で開発したものを amd64 環境にデプロイするのはちょっと勇気がいる。 古い環境はアップデートせえやという話なのだが、リソース不足してるものはどうにもならず、結果として古い JVM 環境を延命させてたやつとかはまじでどうにもならなくなったりする。えてしてそういうものは皆さんの手元にあることでしょう。

近況 新型コロナウイルス感染症にかかりました 東京大学空間科学情報研究センターの柴崎先生のところで研究員になりました 副業でもすっかーということで大学ベンチャーに話を聞きにいったらその流れでなぜか大学のほうで働くことになった まあ技術補助員とかそんなロールでの採用だろうと思ってたが何故か研究員ということになった、高卒でもいいんですねこういうの 大学というところに行くのがはじめてなので万事勝手が分からずいろいろ周囲に迷惑をかけている気がする ユビレジ辞めてません コロナでリモート当たり前になったから無理なくこんな兼業ができるし、自分がコロナ感染して辛かったことを別にすればいまのところコロナがあってよかったなという気持ちがちょっとあります。

それでも Rails のアップデートをする Rails 5.0 あたりから DHH らが考える Web 開発と自分の手元にあるソフトウェアの設計の乖離が激しくなっていると感じていて、まあはっきり言えば Rails のアップデートでうれしい、と感じる機会は減っている。 Web アプリケーションフレームワークは Rails のようなフルスタックなものより Sinatra/express 風のシンプルな DSL 風のものが好まれるようになっていて、歴史に Rails が残した影響が何かといえば「assets pipeline を導入したことにより、 Web フロントエンドを別言語から JS/CSS にコンパイルするという習慣を広く普及させた」ということになるのではないか、と感じている(GWT とかまあいろいろあったけど Rails 3.1 によって決定的にこういう考え方は普及したでしょう)。 A

Rails の ActionMailer で正しく view の helper を使う Rails の ActionMailer では Rails ActionMailer helper とかで検索すると、「ActionMailer で helper メソッドを使用するには add_template_helper を使おう」というような記事が複数ヒットする 例 ActionMailerでhelperメソッドを使用する - Qiita How to use my view helpers in my ActionMailer views? 他にもたくさんこう書かれている記事がある。しかしなんとこれは実は間違ったやり方である。 ActionMailer::Base を継承したクラスで add_template_helper というメソッドが使えるのは ActionMailer::Base が

React アプリ構築するときのディレクトリ構成とかについて最近やっていること こんにちは。私は最近 React アプリを作る時以下のようなディレクトリ構成でやっていっています。 src/ ---> App.tsx |---> Components/ ---> Fuck/ ---> index.tsx | | |-> useSomething.ts | | |---> SubComponent/ ---> index.tsx | | | |-> Shit/ ---> index.tsx | |---> hooks/ ---> useGarbage.ts | |-> useShit.ts | |---> store/ ---> index.ts |-> modules/ ---> gomi.ts |-> unko.ts store 以下は redux を使う場合で Ducks っぽい奴がいま

next.js の SSG は糞 ぼくは next.js 結構好きでこのブログとかも next.js で作ってるんですが、最近の next.js の方向性にはちょっと危うさを感じています。 next.js は最近は静的サイトジェネレータ+αみたいな感じになっていて、サーバーサイドジェネレーションなる機能のサポートが入っています。 でもこれどう考えてもゴミでしょ。いや記事が 500 件とかならいいけど、 50 万件あったらデプロイのたびにどんだけ時間かかる？という話で。それからサイトが生きているかぎり結局のところ記事はどんどん増えていく以上トップページは動的生成にならざるを得ないわけで。あまりはっきりと言われているわけではありませんが、 next.js を開発している人たちは WordPress のテーマを PHP で書きたくない人というペルソナをもとに開発していて、その人たちは CDN を

認証自作、 Rails 、 Devise https://ockeghem.pageful.app/post/item/uQFX4oRNbnax82V これを読んで思ったことなんですけど、 Ruby On Rails 界隈では「認証は自作すべきではない、デファクトスタンダードの Devise を使うべき」という考え方が一般にあるように思います。 ではその Devise なんですけど、ドキュメントに以下のようにあります。 Starting with Rails? If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we ad

流行りのフロントエンド技術よりもサイト構築や SEO の基礎知識のほうが重要だ みたいな主張があり、 WordPress のカスタマイズをしている人たちがこれを言いがちであり、実際間違ってないと思います。 では我々(我々とは誰か？)がそれに対していえることが何かというと、 PHP と jQuery で頑張って WordPress をカスタマイズするよりも JSON API と nuxt.js/next.js でサイトを組んだほうが簡単だということです。 WordPress のカスタマイズをやってきた人たちは長年のノウハウを積み上げており、それを活用してバリューを出しているわけですが、 nuxt.js でやっていっている人たちが熟達したとき、すべてが破壊されます。 じゃあ実際僕が nuxt.js でかっこいいサイト作る仕事して WordPress の人たちの仕事を奪っていくぞ！！！という気持

ボケンミホドボが販売するコデマクロシのカヒシオ 僕は Amazon で安いロボット掃除機を適当に購入するという趣味を持っています。 Amazon には怪しい中華商品が大量に散乱しており、そのなかから良い商品を見抜くために以下のようなことに注意せよとよく言われています 商品名の先頭がブランド名になっていないものを避ける 商品一枚目の写真に余計なエフェクトがのっているものを避ける 上記 2 項目は規約違反なので レビューが不自然な商品を避ける 不自然に 5 が多いとか同じ時期に大量投稿されてるとか、その商品しかレビューしてない人がたくさんいるとか しかし少なくとも格安ロボット掃除機というカテゴリーにおいては、これらのノウハウはほぼ役に立たないものだと思います。理由としはいくつかあります。まず格安ロボット掃除機ではほぼすべてレビューは捏造されており、商品名や商品写真は規約を守っていません(という

Recoil どういうライブラリなのはか他所をみてくれ。簡単にさわってみた。設計の要点としては、 atom の key がグローバルユニークなんで、 src/states/session.ts src/states/posts.ts src/states/garbage.ts みたいな感じで Recoil の states はディレクトリ上で一箇所にまとめるのがよいと思う。各ファイルは ducks のモジュール + α のようなイメージ。具体的には以下のような感じ(型はめんどいのでつけてない)。 garbage.ts import { useSession } from './session'; import axios from 'axios'; import { atom, useRecoilState } from "recoil"; const garbagesState = at

PDF を Gyazo に展開して Scrapbox の記事にして全文検索する という試みについてです。 まず PDF を Gyazo に展開して Scrapbox の記事にするということですが、これについてブラウザ上で簡単に動くツールを実装しました。 https://ssig33.github.io/pdftoscrapbox/ おそろしく素朴な見た目ですがとりあえず動きます。Chrome や Edge に Tamper Monkey (試してないけど Firefox と Greasemonkey でも動くんじゃないかな)を入れて、 input に Scrapbox のプロジェクト名を入れて user.js をインストールした上で赤いところに PDFをドラッグ&ドロップすると、 PDF.js で PDF でレンダリングした上で全てのページを Gyazo にアップロードして Scrapbo

canvas を使って画像をトリミングする const img = document.querySelector('img'); const canvas = document.createElement('canvas'); canvas.width = width; canvas.height = height; const context = canvas.getContext("2d"); context.drawImage(img, x, y, width, height, 0, 0, width, height); というようなコードが紹介されることが多いですが、ダメです。これはディスプレイの解像度が伝統的な 96DPI になっていることに依存したコードで、現代的な HiDPI 環境では思った通りに動きません。 こうした問題に対応するためにwindow.devicePixelR

cookpad TechConf 2019 にいってきた 面白かった、参考になったトーク スライドとかは Qiita に cookpad がまとめを作っています。 藤井 謙士朗 - 新規サービス開発を加速させる技術とデザイン このサービスについて、エンジニア視点で書かれた紹介記事はあって Firebaseでバックエンドエンジニア不在のアプリ開発　クックパッドが体感した、メリットと課題 これは結構面白い記事で、レスとしてこんなものを書いたりした。 KomercoではReactでWebの管理画面やティザー画面を作っていて、デザイナーがコードを書いているので、フロントエンジニアもいないんです と何事もないかのように書かれているところに実際何があるかをデザイナーが何をしているかというのをデザイナー視点で話していた。紹介されているツールや技法は非常に興味深い一方で、 これ簡単にまとめると、プログラミ

デスクトップ Linux を 15 年ぐらい使っている のだが、あまりこの 15 年困ることはなかったと思う。 Vine Linux 2.6 あたりから常用する環境が Linux だったので、だいたい 15 年ぐらいそんなふうであると思う。 GUI にかんしてはいろいろとフラフラした結果、 2005 年ごろから JWM というのを使っていたが、最近いろいろめんどうになって LXDE に引っ越してしまった。 今日常的に起動している GUI なツールは Chrome と Franz と LXTerminal と Steam だけで、まあこれなら OS なんてなんでもいい。昔は Emacs でメールと原稿を読み書きしていた記憶があるのと Skype が必須の時代とかもありましたね。 別段 Linux だから辛いみたいなことはそんなに無かったような気するけど、記録をみると sid 常用してた時代と