Brollyが表とASCIIチャートで構築された天気サイトを公開

Why it matters

Brolly shows how a solo developer can use AI to ship a differentiated consumer utility while keeping the product's defining interface decisions human-designed.

Jacob（ヨーク拠点の開発者で、ファーストネームのみを公表している）は、表をスキャンするほうを好む人向けの天気サイトとして、7月25日にBrollyを公開した。ローンチ投稿で彼は、UK Met Officeの刷新で余白、スクロール、アニメーションが増え、一望できる予報が失われたと述べている。

Brollyは7日間の予報をモバイル幅の単一のテキスト列に変換する。York forecastは現在の気温、風、紫外線（ultraviolet radiation）と大気質を冒頭に示し、日別の天候、時間ごとの降水、花粉、過去との比較へと進む。主流の天気アプリにあるチャート、アイコン、地図の代わりに、ハッシュ記号とダッシュで作られたバーが使われている。

Jacobは「主に自分のためにこのサイトを作った」と言う。その制約が多くの消費者向け天気インターフェイスよりもBrollyに鋭いプロダクト仮説を与えた：有用な情報を一度の下方向スクロール内に最大限収め、時間と日を比較できる能力を保ち、すべてのビューをブックマーク可能にすること。

文書として設計された予報

Brollyの特異な点は、予報をダッシュボードではなく文書として扱っていることだ。7日間の表は気温、平均風速、突風、降水を固定列に保つ。日を選択すると、下の時間別セクションが別画面に遷移することなく変わる。Brollyはまた前日の天気を保持し、今日が実際に昨日より暑いのか寒いのか、あるいはより湿っているのかといった一般的な疑問に応えている。

Jacobは見た目のインスピレーションをPlain Text Sportsから得ており、同様に余分を削いだインターフェイスでライブスコアとスケジュールを圧縮している。彼はBrollyの技術とデザインのノートによれば、文字ベースのビジュアライゼーションの手作業に多くの時間を費やした。彼の好例は花粉のヒートマップで、句読点を使って時間ごとの強度を表示し、日ごとのピークをアスタリスクで示している。

Brollyは選択した場所、日、展開されたセクションをURLに保存する。したがってユーザーは一般的な都市のランディングページではなく、他の人に正確な予報ビューを送ることができる。この設計は、ページが共有されたり再度開かれたりしたときにアプリケーションの状態が消えるという、対話型ウェブ製品で増えている弱点を回避している。

Met OfficeはJacobのプロジェクトを引き起こしたトレードオフを認めている。リフレッシュされたアプリのFAQは、以前のレイアウトは特に小さなデバイスで煩雑に感じられることがあり、新デザインは一画面に表示する情報を減らしていると説明している。同機関はその後レイアウトをよりコンパクトにし、不必要なスクロールを減らす方法を模索していると言う。Brollyは逆のインターフェイス賭けをしている：情報が一貫して構造化されている限り、より密な画面を受け入れるユーザーもいる、というものだ。

小さなウェブスタックにおけるプレーンテキスト風スタイリング

Brollyのインターフェイスは端末の出力のように見えるが、従来のウェブアプリケーションである。JacobはGoで書き、HTML、JavaScript、CSSを用い、サーバーサイドのルートと集計統計や予報キャッシュのためのデータベースにPocketBaseのSQLiteを使っている。ユーザーが日を切り替えると、軽めのJavaScriptがサーバー描画されたセクションをリロードする。

天候と位置データはOpen-Meteoから来ており、そのサービスは30以上の気象モデルを参照している。Brollyは上流APIへの呼び出しを減らすために場所ごとの予報を5分間キャッシュする。Jacobによれば、フルサービスはロンドンの512MBのDigitalOceanインスタンス上で1つのコンテナとして動作しているという。

実装はまた、現在のAIコーディングツールで作られたソロのサイドプロジェクトの経済性を反映している。Jacobは、アーキテクチャ、構造、インターフェイスを手作業で定義しつつ、AIを使って重要な部分の実装を行ったと述べている。「AIがなければこのサイトを作る時間はなかっただろう」と彼は書き、いくつかのビジュアライゼーションとデザインの問題は自分で保持したと付け加えた。

その役割分担は完成品にとって重要だ。Brollyの価値は予報を取得してレンダリングするために必要なコード量ではなく、情報階層と細かなインタラクションの決定にある。AIは実装負担を減らし、一方でJacobはサイトを差別化するプロダクト上の選択を保持した。

ミニマリストなインフラは初期トラフィックで試された

Brollyの公開統計ページは、7月25日夜までに37,187ページビュー、24,064の予報ビュー、推定12,678のユニーク訪問者を示していた。これらはBrolly自身の集計数値であり、サイトはユニーク訪問者の算出方法を推定値と説明する以外には開示していない。確認時点で予報と大気質のキャッシュヒット率は90%以上だった。

注目の急増は小さなデプロイメントの限界も露呈した。初期のユーザーの一部は数秒単位の読み込み時間を報告し、Jacobはキャッシュとページレンダリングの経路を調査した。別のユーザーは遅延の一部がBrollyのカスタムフォントに起因すると突き止めた。スピードと視覚的抑制を中心にする製品にとって不都合な依存性だ。

ユーザーは「プレーンテキスト」という語にも異議を唱えた。Brollyはプレーンテキスト風にスタイリングされたHTMLを送っており、コマンドラインクライアントで予報を要求してもマークアップが返る。Jacobは真のテキスト専用モードを検討すると述べた。

その違いがBrollyと確立されたコンソール指向の天気サービスであるwttr.inを分けている。wttr.inは端末テキスト、ブラウザ用HTML、PNG、JSON、Prometheus出力をサポートし、シェルから直接問い合わせ可能な人間可読の位置パスを持つ。Brollyはより狭いブラウザ体験を提供し、モバイルでのナビゲーション、前日比較、花粉、紫外線、そして大気質のための詳細な文字ベースの表示を強化している。

初期のcurlサポート要求はBrollyの最も明確な拡張経路を示している。本物のtext/plainレスポンスは同じコンパクトな予報を開発者が端末、スクリプト、ステータスバーに置けるものに変えるだろう。またそれはJacobに製品の最も特徴的な制約を守らせることになる：すべての装飾的要素を取り除いても予報が読みやすいことがBrollyの成り立ちだからだ。