I tried it several times and the one thing that got it to stick for me was having a structure to the markdown. I have an AST parser for markdown body grammar and validate the frontmatter. The structure helps me keep things sane and organized because my brain is all over the place. Beyond that, unlike OP I attach these schemas to folders in my vault per schema.
I actually got MacWhisper originally for speech to text so I could talk to my machine like a crazy person. I realized I didn't like doing that but the actual killer feature for buying it that I really enjoy is the fully local transcription of meetings, with a nice little button to start recording that pops up when you launch zoom, teams, etc. It means I can safely record meetings and encrypt them locally and keep internal notes without handing off all of that to some nebulous cloud platform.
I had previously used Hyprnote to record meetings in this way - and indeed I still use that as a backup, it's a great free option - but the meeting prompting to record and better transcription offered by Macwhisper is a much better experience.
I initially built Talkie to talk to it like a crazy person when I was on long runs and ideas would pop into my head haha
Been a power user of SuperWhisper and Wispr Flow for a long time and eventually decided to unify those flows - memos & dictations, everything is a file and local first, BYOK
I'm kind of curious why language specializations matter much to all but the most hardcore of hardcore performance firms. People have demonstrated now that you can pick up even Rust with an LLM and be productive with it in a few days if you know what you are doing: https://github.com/humanlayer/advanced-context-engineering-f...
I just like my stack, which includes Go. That stack is of course ever changing, but why would I make a drastic change if I’m already both happy and somewhat good?
I’ve been recruiting people and had exposure to small sample of generalists as an interviewer, but also in a team. Not too long ago, I’ve been briefly exposed to „staff” level Go developers who, I kid you not, would not follow ANY known and widely accepted as best practice Go convention (that I could identify). Obviously these were Java, C#, Python developers bringing habits from their last language to that project and boy was it bad. I suppose that was an extreme end of the spectrum (they were also incredibly toxic), but not once before were I in a team where new code was that bad. Of course, best practices are there to serve you and not the other way around, but each time I’d ask, they couldn’t explain why in a coherent way.
I suppose once you know programming it’s kinda easy to change the syntax, but imo code is just significantly better if people know what they are doing.
100% agree! But how many organizations actually need an expert vs someone productive? Goes back to the "only the most hardcore performance-based orgs" point as an example
Nearly every time I've held out and not given a number I've gotten a much higher salary than the number I would have given.
It is true, of course, that when they give you the number that they leave money on the table for negotiation, that is standard practice. It's even factored into the offer amount at bigcorps, and chances are they have an amount they cannot go over and it's set. So you should always ask for more after they lay the money out.
My experience has been about 50/50 with that. Twice when I haven't given the number first, they've pleasantly surprised me with significantly higher offers than I would have expected. Twice when I did give a number, they said "oh no that's way too low, we want you to be extremely happy with comp" and bumped me up. In all other circumstances I don't think it mattered, and I suspect that giving the number or not was moot in all 4 of those cases.
In the second example, it's likely that you still left money on the table. They almost certainly gave you the lower/midrange of your projected band which was likely significantly above the number you gave.
Hard to say from a blurb whether the situation is an outlier, just generalizing here based on on basically every salary discussion I see on the hiring side.
ECS Fargate is basically this on AWS. It’s just not cloud agnostic. But Swarm itself while being cloud agnostic is a proprietary product as well, so you still get the lock in, just at a different layer
This is the thing about kubernetes that these short sighted takes always seem to miss. Kubernetes is complicated because deployment is complicated. For every little knob in k8s there is a pretty good standard path. Need certs? Cert manager. Autoscaling? Cluster autoscaler or KEDA. Load balancing? Handled. All wheels you will need to reinvent yourself otherwise.
I’m currently experimenting with something similar on a smaller scale using continue.dev’s code indexing implementation to expose a context mcp server for both semantic and code search. Tricky part is of course context management.
There is a text based file format for models. It's called OpenSCAD. It's also much more information compacted than a mesh model file like STL - e.g. in OpenSCAD you describe the curve, in the mesh file like STL you explicitly state all elements of it.
It's just gimped to the point that you can basically only use it for hobbyist projects, anything reasonably professional looking is using STEP compatible files and that is much more complex to try to emulate and get right. STEP is a bit different - it's more like a mesh in that it contains the final geometry, but in BRep which is pretty close to the machining grade, while OpenSCAD is more like what you're asking about - a textual recipe to generate curves that you pass into an engine that turns it into the actual geometry. It's just that OpenSCAD is so wholly insufficient to express what professional designs need it never gets used in the professional world.
reply