Mastodon UX のウィッシュ リストについて、新しい知人たちと話し合っています。 このマストドンのブルームバーグ端末からの抜粋は、私自身のウィッシュ リストの一部で締めくくられています。
Mastodon のタイムラインでは、おしゃべりな人が一目であなたの目に映るものを支配できます。 ソーシャル メディアに参加するとき、私たちは常にお互いの注目を集めています。 フィードのパブリッシャーとして、商品が殺到すると読者のエクスペリエンスがどのように圧倒されるかを考慮するのが賢明です。 しかし、フィード リーダーがおしゃべりなソースをフィルター処理する方法を検討することも役立ちます。 Steampipe の SQL 基盤は、それを行うための簡単で自然な方法を提供します。 リスト ビューを操作するクエリの一部を次に示します。
select distinct on (list, person, hour) -- only one per list/user/hour person, url, hour, toot from data order by hour desc, list, person1 人につき 1 時間に 1 歯までに制限するルールを実装するのは簡単でした。 ここでの次のステップは、このルールを他のビューに適用し、折りたたまれたトゥースの数を表示し、そのようなルールを人ごとに有効にすることです。
準備運動として、ブーストの有無にかかわらず自宅のタイムラインを確認できるブースト用のシンプルなコントロールを最初に追加することにしました。 技術に敏感な読者に、Steampipe でこの種のことを行うことに何が関係しているかを理解してもらうために、ここで変更点について説明します。 私は明らかに偏見を持っていますが、このプログラミング環境はアクセスしやすく、生産的だと思います。 自分もそう思うなら、自分の UX ウィッシュリストにある項目をいくつか試してみるのもいいかもしれません。 もしそうなら、それがどうなるか教えてください！
新機能を追加するために変更した 2 つのファイルの元のバージョンを次に示します。 まず、 home.sp ホーム タイムラインのダッシュボードを定義します。
dashboard "Home" {
tags = {
service = "Mastodon"
}
container {
// a text widget with the HTML links that define the menu of dashboards
}
container {
text {
// a block that displays the HTML links that form a menu of dashboards
}
card {
// a block that reports the name of my server
}
input "limit" {
width = 2
title = "limit"
sql = <そしてこちらが新バージョン。 と呼ばれる入力ブロックを追加します boosts、その値を参照されたクエリに渡します。
dashboard "Home" {
tags = {
service = "Mastodon"
}
container {
// a text widget with the HTML links that define the menu of dashboards
}
container {
text {
// a block that displays the HTML links that form a menu of dashboards
}
card {
// a block that reports the name of my server
}
input "limit" {
// as above
}
input "boosts" {
width = 2
title = "boosts"
sql = <Steampipe ダッシュボードは 2 つの言語で構築されています。 HCL (HashiCorp 構成言語) は UX ウィジェットを定義し、SQL はそれらにデータを入力します。 この場合、静的な値を選択しています boosts 入力。 しかし、どんな Steampipe クエリもそこで実行できます! たとえば、ダッシュボードで使用している入力ブロックを次に示します。これは、ユーザーを割り当てたリストでタイムラインをフィルター処理します。
input "list" {
type = "select"
width = 2
title = "search home timeline"
sql = <参照されたクエリは次のとおりです。 query.timeline、ファイルから query.sp これには、すべてのダッシュボードで使用されるクエリが含まれています。
query "timeline" {
sql = < 'url' is null then
content
else
reblog_content
end as toot,
to_char(created_at, 'MM-DD HH24:MI') as created_at,
case
when reblog -> 'url' is not null then '🢁'
else ''
end as boosted,
case
when in_reply_to_account_id is not null then ' 🢂 ' || ( select acct from mastodon_account where id = in_reply_to_account_id )
else ''
end as in_reply_to,
case
when reblog -> 'url' is not null then reblog ->> 'url'
else url
end as url
from
mastodon_toot
where
timeline = $1
limit $2
)
select
account,
person ||
case
when in_reply_to is null then ''
else in_reply_to
end as person,
boosted || ' ' || toot as toot,
url
from
toots
order by
created_at desc
EOQ
param "timeline" {}
param "limit" {}
}
そして、これがそのクエリの新しいバージョンです。
query "timeline" {
sql = <元のバージョンでは、単一の CTE (別名共通テーブル式) を使用します。 WITH 句）、 toots、結論のデータをマーシャリングする SELECT. 新しいバージョンは別の CTE を挿入します。 ブースト、パイプラインに。 それは使用しています $3 参照する param "boost" {} にマップする self.input.boosts から渡された home.sp
SQL コードはすべて標準です。 Postgres は Steampipe 内のエンジンであり、Postgres 固有のイディオムを使用することもありますが、ここではそれらのいずれも行われていないと思います。
HCL コードは見慣れないかもしれません。 Steampipe が HCL を使用する理由は、主な対象者が HCL ベースの Terraform に精通している DevSecOps の専門家であるためです。 しかし、あらゆる種類のリソースを記述するために使用できる非常に単純な言語です。 ここでのリソースは、ダッシュボードに表示されるウィジェットです。
袖をまくり上げて独自のダッシュボードを構築してみたい場合に知っておくべきもう 1 つのことは、開発者のエクスペリエンスが非常に優れているということです。 (HCL コードと SQL コードの両方に対する) 変更がリアルタイムで反映されます。
それを説明するために、ダッシュボード システムを紹介するブログ投稿に含めたスクリーンキャストを次に示します。
SQL クエリが Postgres エラーを引き起こしたときのリアルタイム フィードバックは、ハッピー パスに焦点を当てたかったため、ここには示されていません。 この経験は、Inventing on Principle で Bret Victor が擁護した 1 人のように感じられます。 核となる原則: 「クリエイターは、自分が作成しているものとすぐにつながる必要があります。」
これは、あまりにも頻繁に私たちを制約する間違った方法です。
シーンに何か問題がある場合、変更を加える場合、またはさらにアイデアがある場合は、コードに戻ってコードを編集し、コンパイルして実行し、どのように見えるかを確認する必要があります。 何か問題があれば、コードに戻ります。 私の時間のほとんどはコードでの作業に費やされ、盲目的にテキスト エディターで作業しており、実際に作成しようとしているものとは直接関係がありません。
そして、これが正しい方法です。
横にこの絵があり、横にコードがあります。この部分は空を描き、これは山を描き、これは木を描きます。コードを変更すると、絵がすぐに変わります。 したがって、コードと画像は常に同期しています。 コンパイルして実行する必要はありません。 コードを変更するだけで、状況が変化するのがわかります。
ブレット・ビクター私たちは、できる限り正しい方法で働きたいと考えています。 この体験はまだどこでも利用できるわけではありませんが、Steampipe では利用できます。そこでは、Mastodon を掘り下げるときに私たちの多くがインスピレーションを得て行う実験とプロトタイピングを強力に可能にします.
これを自分で試してみたい場合は、Mastodon API を Postgres テーブルにマップするプラグインのセットアップ手順と、それらのテーブルを使用するダッシュボードを確認し、質問があれば (必要に応じて Mastodon で) 私に連絡してください。持ってる。
以下も参照してください。
- フェディバースへの希望
- Steampipe で Mastodon ダッシュボードを構築する
- フェディバースの閲覧
- マストドンのブルームバーグ端末にて
- 独自のマストドン UX を作成する
- マストドンのリストと人
著作権 © 2023 IDG Communications, Inc.