台湾定番観光地の九份夜市に行きました。
千と千尋の神隠しの湯屋のモデルになったとかいうお茶屋さんでお茶とお菓子のセットをいただきました。
急坂で疲れて喉が渇くのでお茶がうまい。
夜市はクッソ混んでいましたが、これでも平常時の半分ぐらいだとか。
夜は幻想的な風景。
この日はアップダウンで疲れたので寄り道せずに帰宅しました。
ログ
ActionView::Template::Error (`magick convert /tmp/ActiveStorage-216461-20231214-1-1ekdlk.jpg[0] -auto-orient -resize 88x88> /tmp/image_processing20231214-1-x899tq.jpg` failed with status: 1 and error:
convert: no decode delegate for this image format `JPEG' @ error/constitute.c/ReadImage/746.
convert: no images defined `/tmp/image_processing20231214-1-x899tq.jpg' @ error/convert.c/ConvertImageCommand/3362.
):
3: .page-content-header__user
4: = link_to user, class: 'page-content-header__user-link' do
5: span class="a-user-role is-#{user.primary_role}"
6: = image_tag user.avatar_url, title: user.icon_title, class: 'user-profile__user-icon-image a-user-icon'
7: .page-content-header__end
8: .page-content-header__row
9: .page-content-header__before-title
app/models/user.rb:587:in `avatar_url'
app/views/users/_profile.html.slim:6
app/views/users/_profile.html.slim:4
app/views/users/show.html.slim:39
ActiveStorageでconvertして表示するときにJPEGがconvertできてない。
Cannot convert pdf files · Issue #6935 · ImageMagick/ImageMagick
this is because in alpine:18 there was basically one imagemagick package, and in alpine:19 the packages have been split up
see also https://pkgs.alpinelinux.org/packages?page=1&name=imagemagick%2d%2a&branch=v3%2e19
どうやらalpine18まではimagemagickというパッケージに色々入ってたのが、alpine19からは各種モジュールは別パッケージになった模様。
Dockerfile:
RUN apk add --no-cache imagemagick imagemagick-heic imagemagick-jpeg imagemagick-pdf imagemagick-svg imagemagick-webp
各種モジュールはimagemagick-xxxxというパッケージになっているのでこれらを入れるようにしたら直りました。
白菜と角煮のアレで有名な台北故宮博物院に行きました。
・・・と思ったらその二つは貸出中！マジかよ！
残念ですが記念に @machida に角煮ペンをお土産に買いました。
夕飯は阿城鵝肉というガチョウ料理のチェーン店で食べました。
自分で好きな調味料を取ってきてガチョウの肉をつけて食べる。蛤のスープも美味しい。
ただ、この冷蔵庫から勝手に取ってきて飲んだ冷たいお茶が一番美味しかった。茶葉がガッツリ入っていて、茶漉し的なパーツも付いているのでペットボトル感覚なのにめっちゃ爽やか。本格的な味なのにこのモバイル性よ・・・。コンビニで売ってればいいのになぁ。
12日からRuby Conf Taiwan 2023のために台湾に行ってきます。
台湾初めてだから楽しみ。
こちらもまとまってない考えをモニョモニョ書きます。
サーバーとクライアントどっちがいらない？
前提として、俺個人としては、Webアプリ作成の省力化のターゲットは1人〜数人程度のエンジニアで作れるもの。大規模になったら簡単に作るというより、スケールしやすさと信頼性が大事だから別の話。
サーバーサイドの人は「なるべくサーバーでやりたい。クライアント最小限」
クライアントサイドの人は「なるべくクライアントでやりたい。サーバーは最小限」
Hotwireは前者。サーバレスとかは後者。 俺がハマってるSuperbase + Nextみたいなのは後者。
どっちが楽かって観点だと、ある程度頑張れば両者とも同じぐらい楽になるんじゃないかと思う。 それよりも、パフォーマンスの観点、コストの観点が重要視されてると思う。
ユーザーのアプリ体験のリッチさって面では現状クライアント重視派に軍配。
また、CO2排出量的にエコかどうかって観点も今後ありそう。 同じ処理をするのに共通部分をなるべくサーバーで処理して、クライアントに配信した方がエコではありそう。
俺みたいなとにかく楽したい野郎にとっては本質的なところよりも、どんだけ便利なSaaSがあるかに依存してるからこれはもうどうなるかわからない。
現状の面倒なところ1 - Web API
下記にも書いたけど、まずAPIを作るのはめんどい。
Web APIを手作りする時代は終わった | FJORD BOOT CAMP（フィヨルドブートキャンプ）
ライブラリとかで、APIの定義を書けばクライアントとテストが自動化できますよってみた時にまず、
「APIの実装は書かなきゃいけないんかい。」
って思ったよね。
アプリの提供する中心的な価値とは関係ないDBのラッパーごときに面倒すぎる。データの定義だってDBのDDLで１回書いてるのになんでまた別の言語で書くの。
それを解消するソリューションはいろいろあるけど、要はアクセス制限をどんな言語で書くかって部分がまだこれは良いってのが見つかってない感じ。
Firebaseのセキュリティールールは複雑でキツい。RLSはみんなが大喜びするほど書きやすくはない。あとMySQLが対応してない。 Punditみたいにアプリの言語で書くってのも独自っぽくてちょっと嫌。ただrubyで書けてものすごく書き味が良いのがあれば良いかも。
現状の面倒なところ2 - 通知
Web APIを書かないとすると、プロジェクのコードの中で地味に大きいのが通知。
Facebookみたいなサイト内の通知やメール通知やアプリ通知。
送る対象と中身の文章、未読・既読程度管理ぐらいしかやってないのにコード量とか手間がかかりすぎてると思う。アプリの提供する中心的な価値とは関係ないのにこれはだるい。 （アプリの提供する中心的な価値の部分は独自のコードたくさん書いても良い）
定番のSaaSとかgemが欲しい。もしくは作りたい。
考えがまとまってないことについてブログに書いていこうと思った次第です。
新規プロジェクトについては、下記のどっちかでいいと思った。
- Railsデフォ(Hotwire)
- Rails APIモード + Next
前者は少人数に向いてて、後者はバックエンドとフロントエンドでチームが分かれる以上の人数の場合。 そして、Reactと組み合わせるんだったら絶対Routerが必要なのでNextでいいじゃん。
何が言いたいかというと、Rails非APIモード + Reactは既存案件の改修とかで使われるだけと想定して、スクールで教える必要は無いってこと。
そして、バックエンドコースとするならHotwireを使って、フロントエンドコースでTypescriptとNextをやる。 これでバックエンドコースと言いつつフルスタックやっていて卒業まで年単位でかかる問題を解決する。フルスタック勉強したい人はフロントエンドコースも両方受講すれば良しというようにする。
辛いのはチーム開発（スクラム）のカリキュラムで取り組むFBCのEラーニングツールがまさにRails非APIモード + Reactになっているってこと😭 （まさに既存案件だからね）
どうやら最近Cloud SQL Auth Proxyのプログラムが新しくなったらしい。
スネークケース(cloud_sql_proxy)からハイフン(cloud-sql-proxy)のプログラムに変わってました。しれっとオプションとかも全然違うのでちょっとハマりました。
Apple Silicon版を入れる
Cloud SQL Auth Proxy について | Cloud SQL for PostgreSQL | Google Cloud
$ curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.7.1/cloud-sql-proxy.darwin.arm64
$ chmod +x cloud-sql-proxy
TCP接続用に起動する。プロジェクト名とリージョン名とインスタンス名をコロン区切りで指定します。
$ ./cloud-sql-proxy --port 5433 プロジェクト名:リージョン名:インスタンス名
今までのcloud_sql_proxyだとこれでよかったんですが、新しいやつはそのままだと認証が通りません。
gcloud CLIの認証情報を使う
Cloud SQL Auth Proxy を使用して接続する | Cloud SQL for PostgreSQL | Google Cloud
gcloud auth loginで認証している情報をcloud-sql-proxyで使うには下記をやります。
$ gcloud auth application-default login
これでlocalhostの5433番ポートに接続するとCloud SQLのインスタンスに接続できます。
千歳烏山.rb #01 - connpassに参加してきました。
地元に地域rbが出現するなんて嬉しい。
初回になる今回はもくもく会をしてその後飲み会という感じでした。もくもくも、まとまった時間あったらやりたいな〜と思ってたことを持っていったらすごくはかどったので充実度が高かったです。
飲み会も普段ご飯を食べにいってる場所っていうのが不思議な感じ。
家が50mぐらいしか離れてない方がいてご飯屋さんの情報交換で盛り上がったり、いろんな方とお話しできて楽しかったです。 歩いて帰れる飲み会最高！ということで少し飲み過ぎたかもしれません🤭
主催してくださったたわらさんや参加者の皆さんありがとうございました。
２回目も行きたかったですが、RubyConf Taiwanの翌日なので移動中で参加できなさそう。
千歳烏山在住でなくても参加されている方はたくさんいたので、京王線沿線の方などは急行が止まるし、アクセスしやすくていいかもしれません。行ける方はぜひご参加を〜。
bundle2.2からか対応platformが細かくなった。
arm64-darwin-22
arm64-darwin-23
x86_64-darwin-21
x86_64-darwin-22
x86_64-linux
こんな感じでosのバージョン毎に追加してくのは辛い。みんなどうやってるのかなと思ってSlackのruby-jpのsupportチャンネルで質問させてもらいました。
gohさん、kojix2さんに教えていただきました。ありがとうございます。
結論から言うとこう言う感じで良さそう。
PLATFORMS
universal-darwin
x86_64-linux
mac関連は全部universal-darwinでOK。CIや本番環境、WSL2の人用にはx86_64-linuxでOK。
Stripe & Supabase Tokyo Meetup - connpassに行ってきました。
原宿の竹下通りの出口横のでかいビルにあるおしゃれなStripe Japanのオフィスで行われました。
僕はStripeは基本的な機能しか使ってないし、Supabaseもまだ本番で使えてないのでイベントとか行っちゃってついていけるかな？と心配だったんですが発表などとても勉強になりました。
FultterからStripeをバリバリ使ってる事例やSupabase WrapperというStripeのデータがSupabaseのテーブルとして使えるすごい機能の発表など気になる点が多かったです。SupabaseでAuthのProduct Ownerをしてらっしゃる@stojaaanさんの発表でのGuestログイン的な機能も気になりました。
（テーブルへSELECTはともかくINSERTなども対応してるのはびっくり。どうやってるんだろう？）
僕は去年こういうエントリーを書いたように、SupabaseのREST APIを用意してくれる機能がとんでもなく好きなんですが、他にもたくさんの便利そうな機能があるのでそういうのも使ってアプリをリリースしていきたいですね。
Web APIを手作りする時代は終わった | FJORD BOOT CAMP（フィヨルドブートキャンプ）
日本のSupabaseコミュニティがもっと発展していくといいなと思うので今後も参加したいと思ったイベントでした。