Searching txt.sour.is

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

Realmente, custa muito a entender. Dissecar esta notícia dava uma tese, mas não tentar expandir-me muito sobre isto só me daria cabo dos nervos. Fico-me pelo início: (½)
Realmente, custa muito a entender. Dissecar esta notícia dava uma tese, mas não tentar expandir-me muito sobre isto só me daria cabo dos nervos. Fico-me pelo início: (½)

nitter.net/paulasimoes/status/1560221281198432256#mRead more

⤋ Read More
In-reply-to » Hi, I am playing with making an event sourcing database. Its super alpha but I thought I would share since others are talking about databases and such.

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.

type PA[T any] interface {
	event.Aggregate
	*T
}

// Create uses fn to create a new aggregate and store in db.
func Create[A any, T PA[A]](ctx context.Context, es *EventStore, streamID string, fn func(context.Context, T) error) (agg T, err error) {
	ctx, span := logz.Span(ctx)
	defer span.End()

	agg = new(A)
	agg.SetStreamID(streamID)

	if err = es.Load(ctx, agg); err != nil {
		return
	}

	if err = event.NotExists(agg); err != nil {
		return
	}

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

	var i uint64
	if i, err = es.Save(ctx, agg); err != nil {
		return
	}

	span.AddEvent(fmt.Sprint("wrote events = ", i))

	return
}

fig. 1

This lets me do something like this:

a, err := es.Create(ctx, r.es, streamID, func(ctx context.Context, agg *domain.SaltyUser) error {
		return agg.OnUserRegister(nick, key)
})

fig. 2

I can tell the function the type being modified and returned using the function argument that is passed in. pretty cray cray.

⤋ Read More
In-reply-to » Hi, I am playing with making an event sourcing database. Its super alpha but I thought I would share since others are talking about databases and such.

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.

type PA[T any] interface {
	event.Aggregate
	*T
}

// Create uses fn to create a new aggregate and store in db.
func Create[A any, T PA[A]](ctx context.Context, es *EventStore, streamID string, fn func(context.Context, T) error) (agg T, err error) {
	ctx, span := logz.Span(ctx)
	defer span.End()

	agg = new(A)
	agg.SetStreamID(streamID)

	if err = es.Load(ctx, agg); err != nil {
		return
	}

	if err = event.NotExists(agg); err != nil {
		return
	}

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

	var i uint64
	if i, err = es.Save(ctx, agg); err != nil {
		return
	}

	span.AddEvent(fmt.Sprint("wrote events = ", i))

	return
}

fig. 1

This lets me do something like this:

a, err := es.Create(ctx, r.es, streamID, func(ctx context.Context, agg *domain.SaltyUser) error {
		return agg.OnUserRegister(nick, key)
})

fig. 2

I can tell the function the type being modified and returned using the function argument that is passed in. pretty cray cray.

⤋ Read More
In-reply-to » @prologic Error handling especially in Go is very tricky I think. Even though the idea is simple, it's fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn't feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

+1

⤋ Read More
In-reply-to » @prologic Error handling especially in Go is very tricky I think. Even though the idea is simple, it's fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn't feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

+1

⤋ Read More

**RT by @mind_booster: [¼]
Terminou ontem a consulta pública do projeto Aproveitamento Hidráulico de Fins Múltiplos do Crato (Barragem do Crato) a que a ZERO dá parecer negativo

❌Dinheiro do PRR vai ser usado p/ projeto sem sentido e promotor de impactes ambientais e sociais negativos

👇(continua)**
[¼]

Terminou ontem a consulta pública do projeto Aproveitamento Hidráulico de Fins Múltiplos do Crato (Barragem do Crato) a que a ZERO dá parecer negativo

❌Dinheiro do PRR vai ser usado p/ projeto sem sentido e p … ⌘ Read more

⤋ Read More
In-reply-to » I did a take home software engineering test for a company recently, unfortunately I was really sick (have finally recovered) at the time 😢 I was also at the same time interviewing for an SRE position (as well as Software Engineering).

@prologic@twtxt.net Error handling especially in Go is very tricky I think. Even though the idea is simple, it’s fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn’t feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

We tried several things but haven’t found the holy grail. Currently, we have a mix of different styles, but nothing feels really right. And having plenty of different approaches also doesn’t help, that’s right. I agree, error messages often end up getting wrapped way too much with useless information. We haven’t found a solution yet. We just noticed that it kind of depends on the exact circumstances, sometimes the caller should add more information, sometimes it’s better if the callee already includes what it was supposed to do.

To experiment and get a feel for yesterday’s research results I tried myself on the combined log parser and how to signal three different errors. I’m not happy with it. Any feedback is highly appreciated. The idea is to let the caller check (not implemented yet) whether a specific error occurred. That means I have to define some dedicated errors upfront (ErrInvalidFormat, ErrInvalidStatusCode, ErrInvalidSentBytes) that can be used in the err == ErrInvalidFormat or probably more correct errors.Is(err, ErrInvalidFormat) check at the caller.

All three errors define separate error categories and are created using errors.New(…). But for the invalid status code and invalid sent bytes cases I want to include more detail, the actual invalid number that is. Since these errors are already predefined, I cannot add this dynamic information to them. So I would need to wrap them à la fmt.Errorf("invalid sent bytes '%s': %w", sentBytes, ErrInvalidSentBytes"). Yet, the ErrInvalidSentBytes is wrapped and can be asserted later on using errors.Is(err, ErrInvalidSentBytes), but the big problem is that the message is repeated. I don’t want that!

Having a Python and Java background, exception hierarchies are a well understood concept I’m trying to use here. While typing this long message it occurs to me that this is probably the issue here. Anyways, I thought, I just create a ParseError type, that can hold a custom message and some causing error (one of the three ErrInvalid* above). The custom message is then returned at Error() and the wrapped cause will be matched in Is(…). I then just return a ParseError{fmt.Sprintf("invalid sent bytes '%s'", sentBytes), ErrInvalidSentBytes}, but that looks super weird.

I probably need to scrap the “parent error” ParseError and make all three “suberrors” three dedicated error types implementing Error() string methods where I create a useful error messages. Then the caller probably could just errors.Is(err, InvalidSentBytesError{}). But creating an instance of the InvalidSentBytesError type only to check for such an error category just does feel wrong to me. However, it might be the way to do this. I don’t know. To be tried. Opinions, anyone? Implementing a whole new type is some effort, that I want to avoid.

Alternatively just one ParseError containing an error kind enumeration for InvalidFormat and friends could be used. Also seen that pattern before. But that would then require the much more verbose var parseError ParseError; if errors.As(err, &parseError) && parseError.Kind == InvalidSentBytes { … } or something like that. Far from elegant in my eyes.

⤋ Read More

**RT by @mind_booster: [¼]
✈️Novo passo na expansão ilegal do Aeroporto da Portela prejudicará severamente milhares de cidadãos.

⚠️Foi iniciado processo de consulta pública sobre portaria que passará a permitir voos noturnos sem limites.

(Continua 👇)**
[¼]

✈️Novo passo na expansão ilegal do Aeroporto da Portela prejudicará severamente milhares de cidadãos.

⚠️Foi iniciado processo de consulta pública sobre portaria que passará a permitir voos noturnos sem limites.

(Continua 👇)

![](https://nitter.net/pic/me … ⌘ Read more

⤋ Read More

“Com a apresentação do Simplex na área ambiental, o Governo prepara-se para retroceder décadas na política ambiental, fazendo tábua rasa dos valores fundamentais que a política ambiental e o instrumento da avaliação de impacte ambiental visam proteger.” 1/7
“Com a apresentação do Simplex na área ambiental, o Governo prepara-se para retroceder décadas na política ambiental, fazendo tábua rasa dos valores fundamentais que a política ambiental e o instrumento da avaliação de impacte ambiental visam proteger.” … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: REST API Openfire plugin 1.9.0 released!
We have released version 1.9.0 of the Openfire REST API plugin! This version adds functionality and provides some bug fixes that relates to multi-user chat rooms.

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from [the plugin’s archive page](https://www.igniterealtime.org/projects/openfire/pl … ⌘ Read more

⤋ Read More

R to @mind_booster: So? “Anything above 1.5C will see a world plagued by intense summer heat, extreme drought, devastating floods, reduced crop yields, rapidly melting ice sheets and surging sea levels. A rise of 2C and above will seriously threaten the stability of global society, McGuire argues.”
So? “Anything above 1.5C will see a world plagued by intense summer heat, extreme drought, devastating floods, reduced crop yields, rapidly melting ice sheets and surging sea levels. A rise of 2C and above will s … ⌘ Read more

⤋ Read More

“to limit that rise to 1.5C […] global carbon emissions will have to be reduced by 45% by 2030.
[…]
Instead, we are on course for close to a 14% rise in emissions by that date – which will almost certainly see us shatter the 1.5C guardrail in less than a decade.”

“to limit that rise to 1.5C […] global carbon emissions will have to be reduced by 45% by 2030.

[…]

Instead, we are on course for close to a 14% rise in emissions by that date – which will almost certainly see us shatter the 1.5C guardrai … ⌘ Read more

⤋ Read More

Gajim: Gajim 1.4.7
Gajim 1.4.7 brings performance improvements, better file previews, and many bug fixes. Thanks for all your reports!

What’s New

Multiple issues with Gajim’s file preview have been fixed. If you want to disable file previews entirely, there is now a setting in Gajim’s preferences.

For people with many contacts in their contact list, this release will bring a significant performance improvement 🚀

Furthermore, notifications on Windows should not appear in the taskbar anymore.

Fixes … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: REST API Openfire plugin 1.8.3 released!
We recently release version 1.8.3 of the Openfire REST API plugin. This version extends the MUC search capability to include the natural name of the MUC (instead of just the name). It also updates a number of library dependencies.

The updated plugin should be available for download in your Openfire admin console already. Alternatively, you can download the plugin directly, from [the plugin’s archive page](https://www.ign … ⌘ Read more

⤋ Read More

I’m trying to switch from Konversation to irssi. Let’s see how that goes. Any irssiers out there who can recommend specific settings or scripts? I already got myself trackbar.pl and nickcolor.pl as super-essentials. Also trying window_switcher.pl. Somehow my custom binds for Ctrl+1/2/3/etc. to switch to window 1/2/3/etc. doesn’t do anything: { key = "^1"; id = "change_window"; data = "1"; } (I cannot use the default with Alt as this is handled by my window manager). Currently, I’m just cycling with Ctrl+N/P. Other things to solve in the near future:

  • better, more colorful and compact theme (just removed clock from statusbar so far)
  • getting bell/urgency hints working on arriving messages
  • nicer tabs in status bar, maybe even just channel names and no indexes
  • decluster status bar with user and channel modes (I never cared about those in the last decade)

⤋ Read More

Erlang Solutions: Updates to the MIM Inbox in version 5.1

User interfaces in open protocols

When a messaging client starts, it typically presents the user with:

  • an inbox
  • a summary of chats (in chronological order)
  • unread messages in their conversation
  • a snippet of the most recent message in the conversation
  • information on if a conversation is muted (and if so how long a conversation is muted for)
  • other information that users may find useful on their welcome screen

Mongoos … ⌘ Read more

⤋ Read More

Gajim: Gajim 1.4.6
Gajim 1.4.6 fixes some bugs with the status icon and notifications. Emoji short code detection has been improved.

Fixes and improvements

Several issues have been fixed in this release.

  • Improved detection of emoji short codes
  • Tray icon withlibappindicator has been fixed
  • Groups are now preserved when changing a contact’s name
  • Windows: Notifications shouldn’t appear in the taskbar anymore

Have a look at the [chan … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: Push Notification Openfire plugin 0.9.1 released
The Ignite Realtime community is happy to announce the immediate availability of a bugfix release for the Push Notification plugin for Openfire!

This plugin adds support for sending push notifications to client software, as described in XEP-0357: “Push Notifications”.

[This update](https://www.igniterealtime.org/projects/openfire/plugins/0.9.1/pushnotificatio … ⌘ Read more

⤋ Read More

**RT by @mind_booster: My latest @locusmag column is “The Swerve,” a short essay about the shape that hope takes when happy endings are off the table:

https://locusmag.com/2022/07/cory-doctorow-the-swerve/ 1/**
My latest @locusmag column is “The Swerve,” a short essay about the shape that hope takes when happy endings are off the table:

locusmag.com/2022/07/cory-do… 1/

![](https://nitter.net/pic/media%2FFW6b … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: REST API Openfire plugin 1.8.1 released!
Earlier today, version 1.8.1 of the Openfire REST API plugin was released. This version removes the need to authenticate for status endpoints, adds new endpoints for bulk modifications of affiliations on MUC rooms, as well as a healthy number of other bugfixes.

The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the pl … ⌘ Read more

⤋ Read More

Erlang Solutions: Contract Programming an Elixir approach – Part 1
This series explores the concepts found in Contract Programming and adapts them to the Elixir language. Erlang and BEAM languages, in general, are surrounded by philosophies like “fail fast”, “defensive programming”, and “offensive programming”, and contract programming can be a nice addition. The series is also available on Github.

You will find a lot … ⌘ Read more

⤋ Read More