I’ve been discussing Mastodon UX want lists with some new acquaintances there. This excerpt from A Bloomberg terminal for Mastodon concludes with a part of my very own want checklist.
In a Mastodon timeline, a chatty particular person can dominate what you see at a look. Once we take part in social media we’re all the time making bids for each other’s consideration. As publishers of feeds it’s smart to think about how a flurry of things can overwhelm a reader’s expertise. But it surely’s additionally helpful to think about ways in which feed readers can filter a chatty supply. Steampipe’s SQL basis affords a straightforward and pure manner to do this. Right here’s a part of the question that drives the checklist view.
choose distinct on (checklist, particular person, hour) -- just one per checklist/person/hour particular person, url, hour, toot from information order by hour desc, checklist, particular personIt was simple to implement a rule that limits every particular person to at most one toot per hour. Subsequent steps right here will probably be to use this rule to different views, present the variety of collapsed toots, and allow such guidelines on a per-person foundation.
As a warmup train, I made a decision to first add a easy management for boosts that permits me to see my residence timeline with or with out boosts. To present technically-inclined readers a way of what’s concerned in doing this sort of factor with Steampipe, I’ll describe the modifications right here. I’m clearly biased however I discover this programming atmosphere to be accessible and productive. If plainly option to you as properly, you would possibly need to check out a number of the gadgets by yourself UX wishlist. And should you do, let me know the way it goes!
Listed here are the unique variations of the 2 information that I modified so as to add the brand new characteristic. First there’s residence.sp which defines the dashboard for the house timeline.
dashboard "House" {
tags = {
service = "Mastodon"
}
container {
// a textual content widget with the HTML hyperlinks that outline the menu of dashboards
}
container {
textual content {
// a block that shows the HTML hyperlinks that type a menu of dashboards
}
card {
// a block that experiences the identify of my server
}
enter "restrict" {
width = 2
title = "restrict"
sql = <<EOQ
with limits(label) as (
values
( '50' ),
( '100' ),
( '200' ),
( '500' )
)
choose
label,
label::int as worth
from
limits
EOQ
}
}
container {
desk {
title = "residence: current toots"
question = question.timeline
args = [ "home", self.input.limit ]
column "particular person" {
wrap = "all"
}
column "toot" {
wrap = "all"
}
column "url" {
wrap = "all"
}
}
}
}
And right here’s the brand new model. It provides an enter block known as boosts, and passes its worth to the referenced question.
dashboard "House" {
tags = {
service = "Mastodon"
}
container {
// a textual content widget with the HTML hyperlinks that outline the menu of dashboards
}
container {
textual content {
// a block that shows the HTML hyperlinks that type a menu of dashboards
}
card {
// a block that experiences the identify of my server
}
enter "restrict" {
// as above
}
enter "boosts" {
width = 2
title = "boosts"
sql = <<EOQ
with boosts(label, worth) as (
values
( 'embrace', 'embrace' ),
( 'disguise', ' ' ),
( 'solely', ' 🢁 ' )
)
choose
label,
worth
from
boosts
EOQ
}
}
container {
desk {
// as above
args = [ "home", self.input.limit, self.input.boosts ]
}
}
}
Steampipe dashboards are constructed with two languages. HCL (HashiCorp configuration language) defines the UX widgets, and SQL fills them with information. On this case we’re choosing static values for the boosts enter. However any Steampipe question can run there! For instance, right here is the enter block I take advantage of on the dashboard that filters the timeline by the checklist to which I’ve assigned individuals.
enter "checklist" {
sort = "choose"
width = 2
title = "search residence timeline"
sql = <<EOQ
choose
title as label,
title as worth
from
mastodon_list
order by
title
EOQ
}
Now right here is the referenced question, question.timeline, from the file question.sp which accommodates queries utilized by all of the dashboards.
question "timeline" {
sql = <<EOQ
with toots as (
choose
account_url as account,
case
when display_name="" then user_name
else display_name
finish as particular person,
case
when reblog -> 'url' is null then
content material
else
reblog_content
finish as toot,
to_char(created_at, 'MM-DD HH24:MI') as created_at,
case
when reblog -> 'url' shouldn't be null then '🢁'
else ''
finish as boosted,
case
when in_reply_to_account_id shouldn't be null then ' 🢂 ' || ( choose acct from mastodon_account the place id = in_reply_to_account_id )
else ''
finish as in_reply_to,
case
when reblog -> 'url' shouldn't be null then reblog ->> 'url'
else url
finish as url
from
mastodon_toot
the place
timeline = $1
restrict $2
)
choose
account,
particular person ||
case
when in_reply_to is null then ''
else in_reply_to
finish as particular person,
boosted || ' ' || toot as toot,
url
from
toots
order by
created_at desc
EOQ
param "timeline" {}
param "restrict" {}
}
And right here is the brand new model of that question.
question "timeline" {
sql = <<EOQ
with toots as (
// as above
),
boosted as (
choose
$3 as enhance,
boosted,
account,
in_reply_to,
particular person,
toot,
url
from
toots
order by
created_at desc
)
choose
account,
particular person ||
case
when in_reply_to is null then ''
else in_reply_to
finish as particular person,
boosted || ' ' || toot as toot,
url
from
boosted
the place
enhance = boosted
or enhance="embrace"
or enhance="n/a"
EOQ
param "timeline" {}
param "restrict" {}
param "enhance" {}
}
The unique model makes use of a single CTE (aka frequent desk expression aka WITH clause), toots, to marshall information for the concluding SELECT. The brand new model inserts one other CTE, boosts, into the pipeline. It makes use of $3 to reference param "enhance" {} which maps to the self.enter.boosts handed from residence.sp
The SQL code is all normal. Postgres is the engine inside Steampipe, and I typically use Postgres-specific idioms, however I don’t assume any of these are occurring right here.
The HCL code could also be unfamiliar. Steampipe makes use of HCL as a result of its core viewers are DevSecOps professionals who’re acquainted with Terraform, which is HCL-based. However its a reasonably easy language that can be utilized to explain all types of assets. Right here the assets are widgets that seem on dashboards.
The opposite factor to know, if you wish to roll up your sleeves and check out constructing your personal dashboards, is that the developer expertise is—once more in my biased opinion!—fairly nice as a result of should you’re utilizing an autosaving editor you’ll see your modifications (to each HCL and SQL code) mirrored in actual time.
For example that, right here’s the screencast we included in our weblog submit introducing the dashboard system.
Not proven there, as a result of we needed to concentrate on the blissful path, is real-time suggestions when your SQL queries provoke Postgres errors. The expertise feels very very like the one Bret Victor champions in Inventing on Precept. The core precept: “Creators want an instantaneous connection to what they’re creating.”
Right here’s the fallacious manner that too typically constrains us.
If there’s something fallacious with the scene, or if I am going and make modifications, or if I’ve additional concepts, I’ve to return to the code, and I edit the code, compile and run, see what it appears like. Something fallacious, I am going again to the code. Most of my time is spent working within the code, working in a textual content editor blindly, with out an instantaneous connection to this factor, which is what I’m truly attempting to make.
And right here is the correct manner.
I’ve received this image on the aspect, and the code on the aspect, and this half attracts the sky and this attracts the mountains and this attracts the tree, and after I make any change to the code, the image modifications instantly. So the code and the image are all the time in sync; there isn’t a compile and run. I simply change issues within the code and I see issues change within the image.
Bret VictorWe need to work the correct manner wherever we will. The expertise isn’t accessible in every single place, but, however it’s accessible in Steampipe the place it powerfully permits the experimentation and prototyping that many people are impressed to do as we delve into Mastodon.
If you wish to do that for your self, please take a look at the setup directions for the plugin that maps Mastodon APIs to Postgres tables, and the dashboards that use these tables, and ping me (on Mastodon should you like!) with any questions you might have.
See additionally:
Copyright © 2023 IDG Communications, Inc.
