最近ブログで写真をたくさん使うので書いた。
#!/usr/bin/env ruby
dir = ARGV[0]
Dir.chdir(dir) do
system "mogrify -format jpg *.HEIC"
system "rm -f *.HEIC"
system "mogrify -path '#{dir}' -resize 1920x1920 -quality 90 -auto-level -normalize '#{dir}/*'"
end
本題のRuby Conf Taiwan 2023に行きました。
流石台湾、全員に本場のタピオカミルクティーがもらえるなんてすごい。
1日目
@hsbt さんの発表。
requireやPATHの仕組み、そしてdefault gem、bundled gemの問題とこれから。
合間のティータイムの様子。
@junk0612さんのRubyのParserのLramaのお話。
質疑応答ではLramaの作者の @spikeolaf からの回答もあったら大盛り上がり。
@hasumikinさんのPicoRubyの発表。
日本語の発表の時と同じ和やかな雰囲気で進みました。PicoRubyのIRBでの複数行コード編集を披露したときには最前列に座っていた @ima1zumi さんがIRB Teamとして大拍手😃
1日目のアフターパーティーはPicCollageさんのオフィスで開催。色々なITベンチャーが入っている素敵なビルとオフィスでした。
台湾ビールで乾杯！
美味しい料理はあっという間になくなりました。
2日目
@okuramasafumi さんの発表。
minitestをライブコーディングで作っていく発表。at_exitやmethod_added、class_evalなど、rubyならではのメタプログラミングで凄く短いコードで実現。どんどんできていく様子が楽しいですね。
最後の発表はhanamiやdry-rbのtimrileyさん。初代Ultima風のプレゼンはとっても情熱的でした。
終わった後にFBC関係者とオーガナイザーの@ryudoawaruさんなどでで集まって写真を撮ってもらいました。
台湾は初めてだったのでとっても楽しかったです。 何度も行っていて詳しい @hsbt さんや @cafedomancer さんにおすすめスポットやおすすめレストランなどをたくさん教えてもらいました。まだ全然行けてないので来年もぜひ行きたいですね。
台北で一番大きなナイトマーケット、士林夜市に行きました。
まずは有名なクソでかフライドチキンの豪大大鶏排を食べる。揚げたてなのでとにかく熱い。
そして牡蠣オムレツの忠誠號蚵仔煎の店内で食事。メニューは読めないので妻が雰囲気で注文。
と思ったらついでに臭豆腐を注文していた。
味は焼き厚揚げとほぼ同じだけど味とは別に臭い。俺は臭さは入らないので焼き厚揚げに生姜と醤油で食べたい・・・。
これは名物おじさんっぽい人がドラム缶改造型のタンドール窯みたいなので作るコショウ餅。これは安定して美味い。
面白かったのがエリンギを焼いてソースを塗ったやつ。アワビみたいな味と言われて怪しんだが本当に似てる。でも一回食べればいいかな。
最後は行きの飛行機で腰を痛めて以来ちょっと歩くとすぐ休むおっさんの図です。
台湾定番観光地の九份夜市に行きました。
千と千尋の神隠しの湯屋のモデルになったとかいうお茶屋さんでお茶とお菓子のセットをいただきました。
急坂で疲れて喉が渇くのでお茶がうまい。
夜市はクッソ混んでいましたが、これでも平常時の半分ぐらいだとか。
夜は幻想的な風景。
この日はアップダウンで疲れたので寄り道せずに帰宅しました。
ログ
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のインスタンスに接続できます。