Searching We.Love.Privacy.Club

Twts matching #meta
Sort by: Newest, Oldest, Most Relevant

** week notes **
I’ve been experimenting. I’ve been concocting a recipe for vegan kugel, and rediscovering little features and edges of my website I’d forgotten I baked in. Like chocolate chips hidden in an oatmeal raisin cookie.

One chip most recently re-discovered: support for per-page custom styles?! All I gotta do is include an optional bit of meta data, bespoke-css, that points to a style sheet. I may play with this feature more. I do love myself some css. I can tell exactly when in my life I added this feature because th 
 ⌘ Read more

​ Read More

Inscryption er Ärets bedste spil.

Det er et poleret og flot spil, som formÄr at flette plot ind i kortspils-formatet. Det er tÊmmelig spooky. Der er ogsÄ en rimelig omfattende og overraskende meta-fortÊlling igennem det hele.

Inscryption opleves bedst, hvis du gÄr ind i det uden at vide noget som helst - du vil helst ikke have overraskelserne spoleret.

(Ÿ) ⌘ Read more

​ Read More

“Para Portugal, [
] seria necessĂĄrio garantir uma redução de emissĂ”es de pelo menos 61% atĂ© 2030 relativamente aos nĂ­veis de 2005, em vez dos atuais 55% na Lei de bases do Clima, para alinhar o paĂ­s com a meta de 1,5°C”
“Para Portugal, [
] seria necessĂĄrio garantir uma redução de emissĂ”es de pelo menos 61% atĂ© 2030 relativamente aos nĂ­veis de 2005, em vez dos atuais 55% na Lei de bases do Clima, para alinhar o paĂ­s com a meta de 1,5°C”

[nitter.net/ZEROasts/status/1575415098352586760#m](https://nitter.n 
 ⌘ Read more

​ Read More
In-reply-to » Progress! so i have moved into working on aggregates. Which are a grouping of events that replayed on an object set the current state of the object. I came up with this little bit of generic wonder.

(cont.)

Just to give some context on some of the components around the code structure.. I wrote this up around an earlier version of aggregate code. This generic bit simplifies things by removing the need of the Crud functions for each aggregate.

Domain Objects

A domain object can be used as an aggregate by adding the event.AggregateRoot struct and finish implementing event.Aggregate. The AggregateRoot implements logic for adding events after they are either Raised by a command or Appended by the eventstore Load or service ApplyFn methods. It also tracks the uncommitted events that are saved using the eventstore Save method.

type User struct {
  Identity string ```json:"identity"`

  CreatedAt time.Time

  event.AggregateRoot
}

// StreamID for the aggregate when stored or loaded from ES.
func (a *User) StreamID() string {
	return "user-" + a.Identity
}
// ApplyEvent to the aggregate state.
func (a *User) ApplyEvent(lis ...event.Event) {
	for _, e := range lis {
		switch e := e.(type) {
		case *UserCreated:
			a.Identity = e.Identity
			a.CreatedAt = e.EventMeta().CreatedDate
        /* ... */
		}
	}
}
Events

Events are applied to the aggregate. They are defined by adding the event.Meta and implementing the getter/setters for event.Event

type UserCreated struct {
	eventMeta event.Meta

	Identity string
}

func (c *UserCreated) EventMeta() (m event.Meta) {
	if c != nil {
		m = c.eventMeta
	}
	return m
}
func (c *UserCreated) SetEventMeta(m event.Meta) {
	if c != nil {
		c.eventMeta = m
	}
}
Reading Events from EventStore

With a domain object that implements the event.Aggregate the event store client can load events and apply them using the Load(ctx, agg) method.

// GetUser populates an user from event store.
func (rw *User) GetUser(ctx context.Context, userID string) (*domain.User, error) {
	user := &domain.User{Identity: userID}

	err := rw.es.Load(ctx, user)
	if err != nil {
		if err != nil {
			if errors.Is(err, eventstore.ErrStreamNotFound) {
				return user, ErrNotFound
			}
			return user, err
		}
		return nil, err
	}
	return user, err
}
OnX Commands

An OnX command will validate the state of the domain object can have the command performed on it. If it can be applied it raises the event using event.Raise() Otherwise it returns an error.

// OnCreate raises an UserCreated event to create the user.
// Note: The handler will check that the user does not already exsist.
func (a *User) OnCreate(identity string) error {
    event.Raise(a, &UserCreated{Identity: identity})
    return nil
}

// OnScored will attempt to score a task.
// If the task is not in a Created state it will fail.
func (a *Task) OnScored(taskID string, score int64, attributes Attributes) error {
	if a.State != TaskStateCreated {
		return fmt.Errorf("task expected created, got %s", a.State)
	}
	event.Raise(a, &TaskScored{TaskID: taskID, Attributes: attributes, Score: score})
	return nil
}
Crud Operations for OnX Commands

The following functions in the aggregate service can be used to perform creation and updating of aggregates. The Update function will ensure the aggregate exists, where the Create is intended for non-existent aggregates. These can probably be combined into one function.

// Create is used when the stream does not yet exist.
func (rw *User) Create(
  ctx context.Context,
  identity string,
  fn func(*domain.User) error,
) (*domain.User, error) {
	session, err := rw.GetUser(ctx, identity)
	if err != nil && !errors.Is(err, ErrNotFound) {
		return nil, err
	}

	if err = fn(session); err != nil {
		return nil, err
	}

	_, err = rw.es.Save(ctx, session)

	return session, err
}

// Update is used when the stream already exists.
func (rw *User) Update(
  ctx context.Context,
  identity string,
  fn func(*domain.User) error,
) (*domain.User, error) {
	session, err := rw.GetUser(ctx, identity)
	if err != nil {
		return nil, err
	}

	if err = fn(session); err != nil {
		return nil, err
	}

	_, err = rw.es.Save(ctx, session)
	return session, err
}

​ Read More

Thanks for the feedback! This site was designed to look perfect on good old 800x600 monitors (I even left a comment next to the meta tag). Maybe I’ll add a mobile-friendly version someday :-) P.S. Nice try with SQL injection, haha. Do you have any plans for XSS attacks? :D

​ Read More

the right level for solving the hard problem of consciousness is within existing science/within philosophy/within meta- or pre-philosophy/needs a fully new paradigm of thought

​ Read More
In-reply-to » My thoughts about range requests

@movq@www.uninformativ.de

Don’t miss step 0 (I should have made this a separate point): having a meta header promising appending twts with strictly monotonically increasing timestamps.

(Also, I’d first like to see the pagination thingy implemented.)

In jenny I would like to see “don’t process previously fetched twts” AKA “Allow the user to archive/delete old twts” feature implemented ;-)

​ Read More

I think it is long due dropping Facebook (now Meta) from the S&P 500 index funds. As an owner of some, I really have a problem with it—and yes, I know there is little I can do but voice it everywhere I make noise online.

​ Read More

What about a meta header for setting charset?

I myself stumbled upon .txt files not being delivered with charset: utf-8 by default.

I had to set/modify .htaccess to correct that.

It would have been easier if there had been a charset header entry “overwriting” what http server is delivering.

What do you think?

​ Read More

My thoughts about range requests

Additionally to pagination also range request should be used to reduce traffic.

I understand that there are corner cases making this a complicated matter.

I would like to see a meta header saying that the given twtxt is append only with increasing timestamps so that a simple strategy can detect valid content fetched per range request.

  1. read meta part per range request
  2. read last fetched twt at expected range (as known from last fetch)
  3. if fetched content starts with expected twt then process rest of data
  4. if fetched content doesn’t start with expected twt discard all and fall back to fetching whole twtxt

Pagination (e.g. archiving old content in a different file) will lead to point 4.

Of course especially pods should support range requests, correct @prologic@twtxt.net?

​ Read More

My thoughts about pagination (paging)

Following the discussion about pagination (paging) I think that’s the right thing to do.

Fetching the same content again and again with only a marginal portion of actually new twts is unbearable and does not scale in any way. It’s not only a waste of bandwidth but with increasing number of fetchers it will also become a problem for pods to serve all requests.

Because it’s so easy to implement and simple to understand, splitting twtxt file in parts with next and prev pointers seems a really amazing solution.

As in RFC5005 there should also be a meta header pointing to the main URL, e.g. current or baseurl or something like that. This way hashes can calculated correctly even for archived twts.

​ Read More

@lucidiot@tilde.town “nuclear realtor” I like this twtxt. [meta: I guess I’ll often just reply with “I like this” or , although perhaps liking could be a primitive. I’ll do it rarely enough to not clutter my timeline tho]

​ Read More

added a !meta page. this proof of concept integrates with the weewiki !zettelkasten I am developing to produce something similar to this !feed.

​ Read More

weewiki uses a custom org markup parser written in ANSI C to render the HTML. No emacs needed! my hope is to introduce a user-defined callback that can process these to allow for custom meta-commands.

​ Read More