Linux userfaultfd is fascinating and seems like a slam dunk when running a large fleet of mostly homogenous VMs. For a kernel feature that's been around for over a decade it's surprising how little content there is out there about how it's used in practice, so great to see this post.
This is great. I'm all for agents calling structured tools on sites instead of poking at DOM/screenshots.
But no MCP server today has tools that appear on page load, change with every SPA route, and die when you close the tab. Client support for this would have to be tightly coupled to whatever is controlling the browser.
What they really built is a browser-native tool API borrowing MCP's shape. If calling it "MCP" is what gets web developers to start exposing structured tools for agents, I'll take it.
The article assumes that AI coding is thoughtless, but prompting is writing, and writing is thinking. If you approach AI coding the same way as regular programming, your thinking phase involves crafting a prompt that describes your thoughts.
The closest thing I could compare it to would be services that make it easier to get data into Redshift or S3. E.g. segment.io's redshift product: https://segment.com/redshift.
Also, their messaging seems a little disingenuous. Otto talks about how important it is to support microservice development and deployment, but Nomad lists as a con that Kubernetes has too many separately deployed and composed services.
This is consistent with a (reasonable) belief that microservice architecture is an important design pattern to support, but may not be the best approach for all problems. From reading the docs, my sense is that Nomad takes the position that for a cluster scheduler, fewer moving parts leads to lower operational overhead, which outweighs any benefit that microservices may bring. E.g., it's more difficult to deploy a microservice platform like Nomad if the platform itself is deployed as a set of microservices.
Here's my understanding: if you use Wealthfront direct indexing, you mostly hold stocks, so you pay a minimal amount in ETF fees. This means your expense ratio is pretty close to the Wealthfront fee of 0.25%.
If you put everything in a Vanguard target retirement fund, your expense ratio is something like 0.18%. [1]
So as long as tax loss harvesting adds a tiny fraction of a percent (~0.07%) to your returns, it seems optimal to use Wealthfront, no?
The problem of keeping this kind of configuration up-to-date is an interesting one. I'm curious if anyone has tried encoding the local development configuration in how they run integration tests so that it never falls out of date.
I open-sourced a tool a few days ago that lets you do mass modification of git repos, including (but not limited to) adding license files: https://github.com/clever/gitbot. I've used it to add licenses to close to a hundred repositories at Clever. Would be great to see if others find it useful.
I had to learn how to use gulp and npm and browserify and and and ohmygodthelistgoeson,...
My point is that you shouldn't have to learn a long list of tools in order to learn the underlying framework the project is trying to introduce.
I can easily remove stuff I don't need, even when I don't know how it works. But adding JS tooling myself? What a disaster.
Really? I've walked in on quite a few existing gulp/grunt/insert-latest-hotness setups and found them incredibly hard to follow (let alone unwind) without a solid understanding of these tools.
As few tools as possible (no task runners, etc...)
:thumbsup: to this sentiment. Whenever I see a "skeleton" starter project that includes tooling that could easily be added at a later date, I usually close the tab.
I think people forget that skeleton projects need to serve an educational purpose to newcomers. Each additional framework/tool that you throw into the mix compromises the skeleton's ability to do that.
> What do you consider good feedback? How can you promote understanding and positive approaches in your criticism of the code? How can you help the submitter learn and grow from this scenario? Unfortunately these questions don't get asked enough, which creates a self-perpetuating cycle of cynics and aggressive discussion.
I'd be really interested to hear how teams codify this. To the extent that it's possible, I think feedback should be rooted in objective measures, e.g. styleguide/lint violations, test failures, etc. All too often, though, there are subjective things that come up: organization of code, interface design, using framework X instead of framework Y. These are the criticisms that most often lead to aggressive back and forths.
To some extent we knew that in-memory joins would eventually cause problems, but we were certainly surprised at how quickly Node memory usage became the bottleneck. Here's a little gist I used to test it a while ago https://gist.github.com/rgarcia/6170213.
As for your point about premature optimization, in my opinion a startup's first priority is getting something in front of users in order to start improving and iterating. The first version of the data pipeline discussed in the blog post was built when Clever was in 0 schools, so designing it to scale to some of the largest school districts in the country would have been fairly presumptuous.
Something to help teams rotate passwords on regular intervals. E.g. I want everyone to rotate their Heroku/Google Apps/Github/etc. passwords every 6 months, or maybe after a major security event (like Heartbleed). Right now it means sending out a Google Doc for everyone to check off.
Bonus points if it has some way of verifying that passwords were actually changed and the new password is strong.