本題のRuby Conf Taiwan 2023に行きました。

Image from Gyazo

流石台湾、全員に本場のタピオカミルクティーがもらえるなんてすごい。

Image from Gyazo

1日目

@hsbt さんの発表。

Image from Gyazo

requireやPATHの仕組み、そしてdefault gem、bundled gemの問題とこれから。

Image from Gyazo

合間のティータイムの様子。

Image from Gyazo

@junk0612さんのRubyのParserのLramaのお話。

質疑応答ではLramaの作者の @spikeolaf からの回答もあったら大盛り上がり。

Image from Gyazo

@hasumikinさんのPicoRubyの発表。

Image from Gyazo

日本語の発表の時と同じ和やかな雰囲気で進みました。PicoRubyのIRBでの複数行コード編集を披露したときには最前列に座っていた @ima1zumi さんがIRB Teamとして大拍手😃

Image from Gyazo

1日目のアフターパーティーはPicCollageさんのオフィスで開催。色々なITベンチャーが入っている素敵なビルとオフィスでした。

Image from Gyazo

台湾ビールで乾杯!

Image from Gyazo

美味しい料理はあっという間になくなりました。

Image from Gyazo

2日目 

@okuramasafumi さんの発表。

Image from Gyazo

minitestをライブコーディングで作っていく発表。at_exitmethod_addedclass_evalなど、rubyならではのメタプログラミングで凄く短いコードで実現。どんどんできていく様子が楽しいですね。

Image from Gyazo

最後の発表はhanamiやdry-rbのtimrileyさん。初代Ultima風のプレゼンはとっても情熱的でした。

終わった後にFBC関係者とオーガナイザーの@ryudoawaruさんなどでで集まって写真を撮ってもらいました。

Image from Gyazo

台湾は初めてだったのでとっても楽しかったです。 何度も行っていて詳しい @hsbt さんや @cafedomancer さんにおすすめスポットやおすすめレストランなどをたくさん教えてもらいました。まだ全然行けてないので来年もぜひ行きたいですね。

台北で一番大きなナイトマーケット、士林夜市に行きました。

Image from Gyazo

まずは有名なクソでかフライドチキンの豪大大鶏排を食べる。揚げたてなのでとにかく熱い。

Image from Gyazo

そして牡蠣オムレツの忠誠號蚵仔煎の店内で食事。メニューは読めないので妻が雰囲気で注文。

Image from Gyazo

と思ったらついでに臭豆腐を注文していた。

味は焼き厚揚げとほぼ同じだけど味とは別に臭い。俺は臭さは入らないので焼き厚揚げに生姜と醤油で食べたい・・・。

Image from Gyazo

これは名物おじさんっぽい人がドラム缶改造型のタンドール窯みたいなので作るコショウ餅。これは安定して美味い。

Image from Gyazo

面白かったのがエリンギを焼いてソースを塗ったやつ。アワビみたいな味と言われて怪しんだが本当に似てる。でも一回食べればいいかな。

Image from Gyazo

最後は行きの飛行機で腰を痛めて以来ちょっと歩くとすぐ休むおっさんの図です。

Image from Gyazo

台湾定番観光地の九份夜市に行きました。

千と千尋の神隠しの湯屋のモデルになったとかいうお茶屋さんでお茶とお菓子のセットをいただきました。

Image from Gyazo

急坂で疲れて喉が渇くのでお茶がうまい。

Image from Gyazo

夜市はクッソ混んでいましたが、これでも平常時の半分ぐらいだとか。

Image from Gyazo

夜は幻想的な風景。

Image from Gyazo

この日はアップダウンで疲れたので寄り道せずに帰宅しました。

ログ

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というパッケージになっているのでこれらを入れるようにしたら直りました。

白菜と角煮のアレで有名な台北故宮博物院に行きました。

Image from Gyazo

・・・と思ったらその二つは貸出中!マジかよ!

Image from Gyazo

残念ですが記念に @machida に角煮ペンをお土産に買いました。

hakusai pen

夕飯は阿城鵝肉というガチョウ料理のチェーン店で食べました。

Image from Gyazo

自分で好きな調味料を取ってきてガチョウの肉をつけて食べる。蛤のスープも美味しい。

Image from Gyazo

ただ、この冷蔵庫から勝手に取ってきて飲んだ冷たいお茶が一番美味しかった。茶葉がガッツリ入っていて、茶漉し的なパーツも付いているのでペットボトル感覚なのにめっちゃ爽やか。本格的な味なのにこのモバイル性よ・・・。コンビニで売ってればいいのになぁ。

Image from Gyazo

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で1回書いてるのになんでまた別の言語で書くの。

それを解消するソリューションはいろいろあるけど、要はアクセス制限をどんな言語で書くかって部分がまだこれは良いってのが見つかってない感じ。

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が出現するなんて嬉しい。

初回になる今回はもくもく会をしてその後飲み会という感じでした。もくもくも、まとまった時間あったらやりたいな〜と思ってたことを持っていったらすごくはかどったので充実度が高かったです。

飲み会も普段ご飯を食べにいってる場所っていうのが不思議な感じ。

Image from Gyazo

家が50mぐらいしか離れてない方がいてご飯屋さんの情報交換で盛り上がったり、いろんな方とお話しできて楽しかったです。 歩いて帰れる飲み会最高!ということで少し飲み過ぎたかもしれません🤭

主催してくださったたわらさんや参加者の皆さんありがとうございました。

2回目も行きたかったですが、RubyConf Taiwanの翌日なので移動中で参加できなさそう。

千歳烏山在住でなくても参加されている方はたくさんいたので、京王線沿線の方などは急行が止まるし、アクセスしやすくていいかもしれません。行ける方はぜひご参加を〜。

千歳烏山.rb #2 ぷちLTと年忘れ忘年会 - connpass