トップ > Web

自分のための場所を作る。

Web 自サイト

少し前にMateChaが死んで、モバイルでTwitterを読み書きするには別の方法が必要になった。まぁオフィシャルなアプリを入れるなりウェブアクセスでやるなり方法は色々あるんだろうけど、そもそもTwitterアレだしなーと思ってなんか別のやつを使おうかな、という判断をした。
で、NostrやBlueskyみたいなのが色々出てきてはいるけどああいうのってiPhone限定でしょ?という雑な理解をしていたり、そもそも招待状要るらしいし……ってんで順当にMastodonのようなActivityPubを喋るやつにしよう、それも出来れば自分用のサーバを立てよう、という方針に決定。

実装の評価

方針が決まったので次は使用するサーバソフトウェアを決める必要がある。以下の観点で検討を行った。

  • 収容人数は数名で良い
  • フットプリントが小さいか
  • 一通りの機能が揃っているか
  • 運用コストが低いか

これらの条件に合致しそうな実装をいくつか評価した。

Wildebeest

  • Cloudflareによる実装だけあってCloudflareのプロダクトをふんだんに使ってスケールするように実装されている。大人数を収容できそうだが量によって伸び縮みするだろうから人数の問題はない。
  • 基本料金がかかるプロダクトを要求するため数ドル程度の固定費が掛かる
  • 標準的な機能を実装済み
  • マネージドサービスを使うためメンテナンス性は高い(はず)

GoToSocial

  • Golangで書かれた実装
  • 数名での使用を前提にしているように見える
    • オンラインサインアップが未実装になっている(adminがアカウントを発行する必要がある)など
  • 非常に軽量
  • 標準的な機能が実装されている

Honk

  • Golangで書かれた実装
  • 非常に軽量
  • 独特の世界観、"あえて実装しない"機能があるらしい


→ GoToSocialを選択。

インフラ

以下の構成でデプロイした。特に変わった点はない。

  • Compute Engine e2-micro
  • nginx
  • certbot
  • gotosocial
  • Litestream
    • ストレージはCloud Storageを使用

収容人数は最大でも数名の予定なのでRDBはSQLiteで十分と判断。LitestreamでCloud Storageへレプリケーションして最低限の冗長性を確保する。手癖でnginxを前段に置いてcertbotで証明書を取るようにしたけど、GoToSocialは組み込みの証明書取得機能があるのでそれを使ったほうが楽そう。


良かったらフォローしてみて下さい。
2023/10/21追記: Pleromaに移行しました↓
tl1.yumenosora.net

この手に雲をつかむ話。

Web 開発

創作物を一斉に一定期間匿名で公開し、期間終了後に作者名を公開するというイベントがあります。このイベント用のいわゆるアップローダに類するサービスを開発しました。

必要とする機能

  • 作者は
    • 制作物をアップロードできる
    • 説明文とあとがきを記載できる
  • イベント主催者は
    • 制作物のファイル実体・作者名を公開・非公開にできる
    • 各作者が投稿した説明文・あとがきを(別途作ったイベントページへ)転記できる

方針

イベント用なのでトラフィックのスパイクに耐えうる設計が必要で、トレーニングも兼ねてクラウドネイティブな手法を取ることとしました。

構成

  • Web UI
    • ReactでSPAとして実装
    • Firebase Hostingで配信
  • データベース
    • Firestoreを使用
    • イベント情報・投稿内容(ファイル除く)を格納
  • 投稿ファイル格納・配信
  • 補助用バックエンドAPI
    • Cloud Run上にSinatraで実装したバックエンドAPIを配備
    • アップロードの中継、配信用signed URLの生成及びバケットの権限操作を行う

実装

Projects · 殊海夕音 / bibai-event-uploader · GitLab

感想

従来の手法(IaaS上のLinux VMにRailsで構築したアプリケーションを走らせるやり方)と記述量はさほど変わらないという印象。バックエンドとしてFirestoreを使おうが、Postgresを読み書きするRails実装のバックエンドを置こうが、大部分の処理はブラウザ上のReact実装というのであれば、その差は微々たるものなのかもしれず。ただし許容トラフィック量を考えれば圧倒的に有利なはず。従来手法で同等の性能を出そうとするとかなりの追加作業と運用コストがかかるのではないかと。
リリースとロールバックが簡単なのは便利。小規模個人プロジェクトでは持て余すものの、A/Bテストやらcanary releaseなんかがコンソールから簡単に出来るのも便利そう。


どうぞご利用ください。*1

*1:イベントが開催されたら

監視をStackdriveで行う。

開発 Web

ログ管理やアラートメール送信って邪魔くさくないですか？ElasticSearchやKibanaなんかで作る今時のログサーバがあると便利だろうけど、小規模サービスにはオーバースペックだし、メールを使わないサービスなのにわざわざメールサーバ用意してアラートメール送信できるようにするのも本末転倒な気がする。単純な送信ロジックだと、似たようなアラートが大量に出るとメールボムになるから、案外気を使うところも多い。
そこでカケラの樹では、Stackdriverを使ってみることに。

前提

  • Railsアプリケーション
  • Compute Engine上のUbuntuで実行

導入方法

Railsアプリケーションの場合、最低限Gemfileでstackdriver gemを追加するだけで動作する。設定項目は次のドキュメントを参考に。
googleapis.dev

カケラの樹での変更は以下のコミットのとおり。
gitlab.com
config.google_cloud.logging.log_nameに日本語を入れるとログ収集が行われなくなったので、アルファベットにしておいたほうが良さそう。

できること

他にも色々機能があるが、とりあえず簡単に使えるものをいくつか。

ログ閲覧・検索

GCPのコンソールからLoggingを開くと、ログがブラウザから閲覧できる。検索も可能。

アラート通知

アラートが発生すると通知される。デフォルトではGCPのモバイルアプリへのプッシュ通知が送信される。メールを受信したい場合、コンソール右上の設定を開き、Stackdriver Error Reportingのメールアドレスの項目にチェックを入れる。
類似した例外が複数発生した場合、勝手にまとめてくれる。

デバッグ

画面上から指定した位置での呼び出し履歴を調べたり、変数の値のウォッチが出来る。本番環境で実行中のインスタンスを観察できるのでこれは便利。
ウォッチ式等の副作用でアプリケーションの動作が変わるのを防ぐ仕組みが入っていてかなり厳しいので、誤検知の場合は式全体をGoogle::Cloud::Debugger.allow_mutating_methods!で囲んでやるとよい。

GCEでライブパッチは使えなさそう。

開発 Web カケラの樹

手元の端末でcanonical-livepatchが動いてるのを見て、そういえば3台までいけるんだからサーバでも使おうか、と思った。

$ uname -a
Linux yumenosora 4.15.0-1024-gcp #25~16.04.2-Ubuntu SMP Tue Oct 30 14:14:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ sudo snap install canonical-livepatch
canonical-livepatch 8.0.6 from 'canonical' installed
$ sudo canonical-livepatch enable [トークン]
2018/11/19 14:20:31 cannot use livepatch: your kernel "4.15.0-1024-gcp" is not eligible for livepatch updates

にゃうーん。Compute Engine上では専用のカーネルが使われるけど、ソレにライブパッチは使えない、みたい。残念。

手軽にMaterial Designを使うには。

開発 Web

Material Design、いいですよね。
見るだけじゃなくて実際に自分のアプリケーションにも適用したかったので、いろいろ調べてみました。

  1. 自分でCSSやJSを書く。デザイナーならこれか一番早いかも。よく整備されたドキュメントがあるので、それを参考に。
  2. Polymer+Paper Elementsを使う。一番の正攻法？Web Componentsを使った新しい作り方をすることになるのでこれから発展が見込める反面、学習量は多くなる。学んて損はないだろうけど最初は時間がかかるかも。あと、まだプロダクションレベルではないですよね。
  3. Angular Material Designを使う。Angular JSを使って今時な感じで作ってるならすんなり適用できるのかな。別のフレームワーク使ってるとか、レガシーな作りしてるとかだとしんどそう。
  4. Leaf frameworkを使う。シンプルな作りのフレームワークで、マークアップの決まり事も少なく導入しやすい。エフェクトが実装途上だったり再現度は少し劣る？

最初の以外全部試しましたか、ウチでは最後のLeafを使うことにしようかと思ってます。新しく会得するべき内容が少なく済むし、できるだけお手軽に導入したいという場合にはぴったりなんじゃないでしょうか。

はじめてのPolymer。

自サイト Web

Web Components, Polymer, Material Designを使った習作として「雨上がりの青空を探して」サイトをリニューアルしてみました。
雨上がりの青空を探して
結構いい感じに動いてるのでどうぞお試しください。

限定公開はじめました。

開発 Web 雪華舞台

Welcome to nginx!

s
というわけで、限定公開ですが新サービスをリリースしました。(5/7追記: パスワードなしで公開にしました)
このサービス、どういうものなのかいまいち上手い紹介が思いつかないんですが、簡単に言うと、

  • 立ち絵付きのTwitter botのようなものが作れます。(あくまでも「のようなもの」です。Twitterとの連携機能などはありません。)
  • ユーザとしては、実行画面(舞台)を開きっぱなしにしておいて時々見る、もしくは適宜開いて読む。それだけです。
  • デスクトップマスコットをごく単純にしてブラウザに載せたような感じとも言えます。
  • キャラクター(出演者)のデータの作成は例のごとくブラウザ上で作れます。
    • 立ち絵(外観)と話の内容(脚本)の作成は分業もできるし、一人で両方作ることもできます


実行画面はこんな感じ。

表示されているのはデフォルトキャラ。まだたいしてネタの量がないので同じ話が繰り返されるのはご愛嬌。


しばらく限定公開でテストして、不具合など落ち着けば限定を外してリリースする予定です。
どうぞお試しください。