I can recommend dub techno for coding, works a treat for me at least. Nice and steady, relatively fast tempo but not too aggressive or intrusive. And crucially, no lyrics, which I find distracting when coding or writing.
throw "TODO" // <comment with some additional context to remember>
Substitute for your language's syntax of course.
I find this especially handy when writing test specs, but it's also handy when creating new functions etc. For tests I lay out the test descriptions with just this one line in the function body. For new functions/methods I can define the function and its return type (assuming a type-safe language) which makes the code using it compile, but leaves the implementation TBD.
The placeholders are then implicitly flagged in test runs and easily found. Basically my text search results for 'throw "TODO"' become my TODO list.
OP here, so I'm of course biased but I'm actually also a fan of the Tilt team :)
Overall, Garden has a broader focus, an added emphasis on testing, as well as capturing all the relationships between your services. The goal is for you to be able to use the same tools and workflows across development and testing/CI, and (as of our new release) the same environment as well.
For an apples-to-apples with Tilt, Garden does a lot of the same things when developing locally, but Garden additionally covers unit+integ testing and allows you to define all your bootstrapping workflows (e.g. migrations etc.). Tilt has a really good UI for local builds+deploys, but you wouldn't currently use it to run tests, or work with remote clusters.
The key thing we're adding in this release is not just an ability to work with remote clusters, but to do it _really fast_. Even faster than locally sometimes, because you can allocate more resources and share build+test caches with your team and your CI.
Plus—and this is more important for the long-run—Garden is designed to be pluggable to work with more platforms than Kubernetes. So you'll be able to use serverless, custom/legacy platforms etc. with the same tools when we release the plugin SDK later this summer.
I actually worked one summer doing exactly that, back when I was 15. Without any doubt, the absolute worst job I've had. I'd previously worked summers in my uncle's _fresh_ fish processing and that was totally fine. The stuff we were racking and drying at that other place though was anything but fresh. Ugh, the textures, the smells, it's all coming back to me... Kinda hard to reconcile that as a delicacy.
It sure was formative though. All uphill from there, haha.
Here's a fun fact to add to the mix: Aldi's gin is one of the best in the world, and cheap to boot. And they're pretty good at various other spirits and beverages too. Do they carry those in the US?
It's always a balancing act. Make the abstractions really stiff, and you can optimize heavily for that context. Too loose, and it becomes opaque and hard to reason about. And messy.
That's why we spent so much time working out the plugin mechanism, and figuring out what's native to the core framework. Terraform, for example, nails the infrastructure stuff quite well and strikes a good balance there, so we used that as a reference. But we added specific primitives for developing the application layer, and made that pluggable through a similar approach. Providers figure out the _how_, but the relationships in the graph are predictable.
Case in point, we now have a handful of different ways to deploy code. There's a Helm module type, which is very flexible but carries all the complexity and manual effort you need to make Helm charts. On the other side there's OpenFaaS, which is very constrained in features, but super easy to get going. So you can pick and choose depending on the level of abstraction you need.
Plus you'll soon be able to make your own, so you can tailor the abstractions to your needs, but keep the consistency of a single core dev tool.
I'm a fan of OpenFaaS. It's a simple, smart design, and Alex has done great work in building a community around it. We found it easy to adopt and support for garden.io, and it fits very neatly into the Kubernetes ecosystem.
I agree to some extent. One of the key value propositions of Kubernetes is indeed in its abstractions, which are mostly quite good. And I really like its declarative approach.
However, I've been dealing with its ins and outs for a while now, partly because I'm developing tooling around it, and I've found there are already a lot of idiosyncrasies in there. Some APIs have very frustrating flaws, and most annoying of all is how tightly some core functionality is coupled to kubectl. A remarkable amount of logic is embedded in the CLI, as opposed to the API layer, and if you really get in the weeds you're likely to start pulling your hair.
Which is to say, even once you get through the learning curve, you may still find yourself struggling with it as you use it. Sometimes when you declare your intent, you find that it just doesn't work, and it can take a while to figure out why. Before you know it, you're using various operators that are meant to mask some of the deficiencies in the core orchestrator, and by extension you're outside of the core abstractions. And don't get me started on Istio... (but that's a tangent).
Anyhow. If you're not trying to do anything unusual, it's a good orchestrator. Not perfect, and for sure heavy, but a good choice for a lot of use cases.
This phrase, slightly paraphrased, was part of what triggered me to found my startup. "I want my monolith back." It was even a slide in our first pitch deck.
So I empathize. I do get the motivation behind microservices (or other flavors of distributed system—I tend to use the microservice term a little loosely). Too many people/teams working on the same deployable eventually becomes a bottleneck for collaboration, builds and tests can take a long time for even small changes, governance and domain-separation becomes harder, and so forth. You'll also grow to have different SLOs and tolerances for different parts of your system. For example, logins should almost never fail, but background workers might slow down or fail without major fallout. Plus different services may have completely different scale/resource requirements.
Really, the question is: When do microservices become important for you (if ever)? When is it justifiable to do it presumptively, anticipating future growth? We all need to make those bets as best we can.
That said, I strongly believe that tooling can lower the baseline cost of splitting systems into microservices. That was one of our main motivations for starting garden.io—bringing the cost, complexity and experience of developing distributed backends to that level, and hopefully improving on it. We miss being able to build, test and run our service with a single command. We miss how easy it was to navigate our code in our IDE—it was all in the same graph! Our IDE could actually reason about our whole application. You didn’t have to read a README for every damn service to figure out how to build it, test it and run it—hoping that the doc was up to date. You could actually run the thing locally in most cases, and not have minikube et al. turning your laptop into a space heater.
I don’t want to plug too much here (we’ll do the Show HN thing before long), but we’re working on something relevant to the discussion. We want to provide a simple, modular way to get from a bunch of git repos to a running system, and build on that to improve the developer experience for distributed systems. With Garden, each part of your stack describes itself, and the tooling compiles those declarations into a stack graph, which is a validated DAG of all your build, test, bootstrap and deployment steps.
The lack of this sort of structure is imo a huge part of the problem with developing distributed systems. Relationships that, in monoliths, are implicit in the code itself, instead become scattered across READMEs, bash scripts, various disconnected tools, convoluted CI pipelines—and worse—people’s heads. We already know the benefits of declarative infrastructure, IaaC etc. Now it’s just a question of applying those ideas to development workflows.
With a stack graph in hand, you can really start chipping away at the cost and frustration of developing microservices, and distributed systems in general. Garden, for example, leverages the graph to act as a sort of incremental compiler for your whole system. You get a single high-level interface, a single command to build, deploy and test (in particular integration test), and it gets easier to reason about your whole stack.
Anyway. Sorry again about the plug, but I hope you find it relevant, if only at an abstract level. Garden itself is still a young project, and we’re just starting to capture some of the future possibilities of it, but I figure this is as good an opportunity as any to talk about what we’re thinking .)
I'm a pretty heavy TS user and I was pondering the same thing. I've not been able to find a motive for allowing numbers as interface keys, but Symbols actually do make sense since, turns out (I'm always learning something new), you can use them as object keys in ES6: https://www.keithcirkel.co.uk/metaprogramming-in-es6-symbols...
That post outlines a few use cases which are admittedly outside of everyday JS/TS usage but I can see them as quite powerful when, for example, building frameworks and libraries that expose an API. I'd offer real-world examples of my own but I'm still working it out for myself .)