This is a good question, thank you! The flow of events into our system is somewhat different than GitHub Actions. We're trying to be a consumer of all sorts of events, including, say, data published to AWS SNS or via a Docker Hub webhook[0]. All of that isn't quite in place yet, but we want to act more like an event broker than a CI/CD solution alone.
One concept we're throwing around is supporting CloudEvents[1] and dispatching workflows based on event types. If anyone has experience with CloudEvents we'd love to hear if that would be something useful to you.
> 1) Please, please support some other config file other than just YAML.
Although we don't directly advertise it, you can in fact write a workflow in JSON and there's an underlying JSON interchange format that is authoritative in our system. We expect that any other languages we support would "compile" to this JSON format. What other languages are interesting to you? We've looked at CUE[0], HCL, and of course Puppet itself.
A good book in this space is Normal Accidents[0], which describes (among others) the impressive cumulative failure that caused the Three Mile Island incident. Fascinating read and applicable to software systems as well.
This article is about nurses, though. In the US many ER nurses work 12 hour shifts and they obviously don't have the option of personal downtime. It's likely that as "computer" people we're already reaping much of the benefit discussed.
This article is about nurses in care homes. They aren't under the same constraint as an ER nurse.
Reason why ER nurses work 12 is continuance of care. You're better off being looked after by 2 shifts who are familiar with your case rather than 3 or 4. More people just add complexity
That still doesn't work all the way down. The objects you get out of the collection remain as mutable as when they were inserted.
Also, unmodifiableCollection doesn't make the collection you pass in immutable; it creates a new object through which you can access it as long as you don't modify it. Anybody holding a reference to the original object can still change the object.
I think you can even somewhat break the collection by changing objects inside it if doing that changes their hashcode (for sets and dictionaries, such a change may have to reinsert the item in the collection to make sure that you can still retrieve it)
Right, but this project doesn't solve that problem, either. It wraps the underlying collection in a builder to make it less easy to access, but it doesn't appear that it places any additional restrictions on the types of members or collection elements (from the generated code on their site anyway).
If you weren't using this library, you could achieve something similar with, e.g.,
I think this library really is about making immutable objects accessible, i.e., taking away the boiler plate. Hand-writing immutable (and potentially mutable) implementations on top of interfaces for a whole set of DTOs is super annoying.
This is a good question, thank you! The flow of events into our system is somewhat different than GitHub Actions. We're trying to be a consumer of all sorts of events, including, say, data published to AWS SNS or via a Docker Hub webhook[0]. All of that isn't quite in place yet, but we want to act more like an event broker than a CI/CD solution alone.
One concept we're throwing around is supporting CloudEvents[1] and dispatching workflows based on event types. If anyone has experience with CloudEvents we'd love to hear if that would be something useful to you.
[0]: https://github.com/relay-integrations/relay-dockerhub/blob/m...
[1]: https://cloudevents.io/