thuringia

How is Bruno different from using REST-Client or similar tools? Looks like it can’t handle RAML or OpenAPI so it can only be an additional tool, never the primary one. I really like what they are doing, especially with the CLI client but it’s not really an API documentation. The documentation feature in Postman was very nice, as OpenAPI is not powerful enough here

The law never states that you are required to carry your ID. It states that you are required to own one. If you do not carry it with you, and have no why for them to identify you in a way that you can be looked up, e.g. because you have your ID number in your password manager, the police can summon you to the station, or escort you home or a variety of other protocols. The police like to convince you otherwise, because it makes their job easier. When children are taught about their ID in school, this is often accompanied by a police official. As you can see in the law itself, this is not true. However, this only applies to German citizens, and EU citizens, if you are in Germany on a visa or any other type of scheme, you are in fact required to carry you ID and documents with you at all times. In that case not carrying an ID is actually an offense with harsh punishments. In reality most of these situations are handled like with normal citizens though.

There is, if you click on a station, it starts to move to the next station automatically. Which station you click on next, determines if you’re doing the inner or outer loop, the site plays the correct melodies then as well as the in-train direction announcements.

I have used it in greater scale at the previous client. Working with multiple providers was much easier than with the Terraform setup the current client runs. The integrated secret handling feature is also something I miss, because it allowed for a very clean setup of GitHub configuration using Pulumi. I also prefer Pulumi‘s custom component abstraction to terraform modules, you don’t have to declare inputs and outputs manually, and don’t require complete teardown and recreation for every change. Also, you don’t even have to write custom components, you can simply write a function that create the resources you need, in that case you may have to handle unknown values a bit more manually, which wasn’t so bad, as it’s essentially Promise-based code.

Personally, I see the landscape like this: If you like CloudFormation templates, then Terraform is a better version of that. Especially as it’s workflows are very similar. If you like, or want, CDK then Pulumi will make you very happy, as it’s a much better version of that. Pulumi in particular makes some alternate patterns possible, e.g. using the integrated secret management, that give you more flexibility with how you approach your project.

As a side note, Pulumi is actively working with the community, accepting PRs, etc. and new provider APIs generally are available when they release. This may influence your decision, or not.

I don’t know about nomnoml but dot/graphviz works very well for this type of chart. Definitely another idea to try out.

PS: thanks for investing so much work into Tsukihime!

Do you plan on creating „real“ Github Actions actions to integrate with releases? All examples mentioned here use the github-script action, which, to me, feels like a workaround. Or some form of direct integration into Github Actions, e.g. configure a workflow as „pre-release“ and the tags and release notes are created automatically?

Given the currently documented automation features, I don’t see how this provides a tangible improvement to our team setups compared to current solutions like auto or semantic-release.