Fugue Blog

Also this https://www.fugue.co/ I learned about this tool by interviewing with them. Nice guys.

Was it https://fugue.co ? I think they use Haskell for their DSL

Can anyone compare Fugue[0] with Terraform/Terraform Enterprise. I'm launching a venture that requires deploying and maintaining cloud infrastructure across the three major cloud providers (AWS, GCP, Azure) and am considering options. Most of our infrastructure is kubernetes but Fugue caught my eye for their AWS deployments. Curious if anyone has used both. [0] https://fugue.co/

In 2018 I ran across this: https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html - Recreates (Jef Raskin's) Archy-like philosophy and workflow in emacs, including some customizations: "Ace Jump Mode ... works a bit like Jef Raskin's Leap feature from days gone by." Explicitly references Archy's predecessor, the Canon Cat But now clicking on that URL brings up something completely different.

Fugue | Senior Software Engineer | Full time | Remote Fugue helps engineers build and operate secure cloud infrastructure. We continuously monitor infrastructure-as-code and cloud resources for our customers, report on vulnerabilities that we find, and help remediate the underlying issues. Our platform and open source tools are used in CI/CD pipelines to spot misconfigurations early and fix them before they are deployed to production environments. This position is primarily focused on backend development using Go, Python, and working with a serverless AWS architecture. Learn more about us and apply here: https://www.fugue.co/careers

Most people probably think of Terraform[0] or Fugue[1] here, but it also includes the more venerable likes of CloudFormation[2] and OpenStack Resources[3], both writeable in Troposphere[4]. It also includes any random mess of shell scripts and the like that manage the lifecycle of infrastructure. [0] https://www.terraform.io/ [1] https://www.fugue.co/ [2] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome… [3] https://docs.openstack.org/heat/latest/template_guide/openstack.html [4] https://github.com/cloudtools/troposphere

This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria. Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them…