I’d like to share my experience of encountering Hotwire from the team at Basecamp which was extracted from the tooling used to build their Hey product. I was so pleased to see DHH tweet about it and took some time over my end-of-year vacation to delve into it.
[Thanks to Joachim, Michael & Stefan from INNOQ, and Tudor and the speakerconf cohort for feedback. Also thanks to Oliver for the interest from the Spring Boot team, and special thanks to Bruno for inspiring the Thymeleaf configuration.]
I first encountered Pulumi a few years ago when I was getting a little frustrated at the lack of some expressibility in Terraform. I’ve been using Terraform from almost day 1 and it really does the job well — providing you really grok its declarative nature, are very good at modularisation, and never need an escape hatch to non-declarative instructions. At the time, though, Pulumi wasn’t ready for me to use, so I watched from a distance.
When developing software, particularly with larger cloud-based distributed systems, there are often a few secrets that need to be disseminated in a secure manner amongst the developers and to the services that use them to unlock credentials.
In systems with many credentials, services, and instances, storage of these secrets is often delegated to a “vault” like AWS Key Management Service or HashiCorp Vault. But you still need a credential to open the vault to pull out a credential for the specific principal and scope you want.
In the past I’ve seen people deposit secrets into source code files and include…
Having RESTful components programmatically traverse links in hypermedia — much like you just did when you clicked on a link to get here — is an appealing capability. A format like HAL is useful for a resource to dynamically augment itself at run time with links to other resources. But what about something to describe the top-level resources / resource types? How about some sort of well-known entry point that a HATEOAS consumer can start from, like the home page for a web site? …
Around July last year, with the introduction of some new components in the systems we build at mPort, we also introduced some new CI/CD tooling. I’m experienced with the tools built by previous companies I’ve worked for (particularly ThoughtWorks and Atlassian), so GoCD and Bamboo were good candidates. Jenkins was not (at the time). This article does not dwell on the specific pros and cons of those products in the specific mPort context. Suffice it to say, they are all fine products and the evaluation criteria for mPort are not the same for other teams.
For the past year or…
Here at mPort, we have a multi-platform technology team (Windows, macOS, Linux). This brings interesting challenges when collaborating on the same components. Docker is an obvious choice to mitigate those challenges, but it introduces a few more corkers along the way.
This post is about the journey of us trying to fix a problem with file permissions on the CI server leading to having to solve problems with line-endings in text files.
Here’s a quick snapshot of the relevant tools involved: