HN user

MorehouseJ09

33 karma

Founder, CEO nuon.co

Bring your own cloud, for everyone.

Posts9
Comments21
View on HN
[dead] 4 months ago

Early on, we decided to use the "uber go stack": temporal, zap, fx.

we wrote about how fx + fxtest has helped us do integration tests in a fairly large code base (200+ api endpoints, ~500k loc) with a small team

My keyboard obsession definitely turned into a rabbit hole. Once I got into the kinesis split, I immediately realized the world of wanting to customize it. This led me to figuring out soldering/desoldering, and over the past year figuring out how to do a DIY build.

I've been doing this kinesis mod https://github.com/dcpedit/pillzmod, and have a working solenoid wired up https://github.com/dcpedit/taptap. (I recommend checking out https://dcpedit.com/keyboards/ if you have time).

I'm pretty busy, but I've tried to find 2/3 hours a month to progress on it, and keyboards feel like the type of "investment in my craft" that is worth that kind of time for me.

You hit the nail on the head with the 2/3 thumb key bit. That is what was such a game changer for me with the kinesis. all the sudden you have real estate to take a layering approach that you just can't with normal keyboards.

Smart but unproductive is a class. We've all had experiences with those types of engineers. I think startups generally weed them out though. It's hard to survive at a startup without being productive. I probably should have put that as a disclaimer up front.

I forked https://github.com/yetone/avante.nvim and have been adding some additional features for claude-code (acp mode) into it.

I've found it to be the best workflow for me: I'm still editor first, but get the full power of an agent-based workflow.

Makes it easier and more natural to review changes in full-context.

s/o to the folks at Zed for making ACP happen. It's exactly the missing piece for this.

disclaimer: I'm the ceo of this company.

What started as a joke a few years ago has actually turned into really good signal. I've found that the engineers who care enough to invest in keyboards like this spend a lot of time investing in their tooling and are extremely productive.

Causation or correlation?

Hey I'm Jon, founder of Nuon.

We decided to open-source Nuon after almost 4 years of operating as a closed-source company. As BYOC has become a more standard way to deploy software, we realized that critical infrastructure like we're building belonged to the community.

Our hope is that by building in the open, we can help create standards for BYOC deployments. Some of the hardest challenges we've found are around security, day-2 operations and supporting different customer environments.

AMA

Every ORM needs to be extensible, and GORM really nailed this. Some thoughts from our team on how we're using plugins in our 100+ table data model

I will also add, part of the reason I'm most bullish on amp at this point is because their architecture allows interacting with amp from different contexts + threading is better than anything else I've seen so far.

I've been thinking more and more how modern coding agents are best when you can use them natively in your editor.

You as a developer have more context and in turn can give your agent more context. I think seeing developers not using editors anymore is going to turn out to be an antipattern.

I've been updating amp.nvim to let me drive it without ever leaving nvim and it's really good.

I wrote some thoughts on Bring Your Own Bucket, the evolution of S3 and why I think that blob storage is the default storage layer for any software deployed into customer environments.

We were using podman at our company, and it was great for a while but we recently migrated to orb.

The UX with orb is just much easier and the small gotchas between docker/podman started to add up. Especially with buildkit issues we had run into and things like using a remote buildkit instance (which we now use), was not supported well enough.

“If it takes longer to explain to the system all the things you want to do and all the details of what you want to do, then all you have is just programming by another name,”

I think this is going to make the difference between junior and senior engineers even more drastic than it is today. It's really hard to know what/how to even describe real problems to these tools, and the people who invest the most in their tooling now, are going to be most successful. It's hard for someone who hasn't designed a large codebase already to do this in an ai native way where they don't have the experience of abstracting at the right level and things like that.

Today's equivalent, I've often found some of the best engineers I know have insane setups with nvim or emacs. They invest in their tool chain, and are now bringing AI into.

Tom nails it, BYOC, by default is not more secure just because it's in the customer's cloud account. Just like self-hosted.

At worst, BYOC has a much bigger blast radius and can cause bigger vulnerabilities for customer workloads.

To offer BYOC, teams need to think beyond cross account permissions, and build tooling to dynamically push changes with toggleable, customer-controlled permissions and policy validation.

Disclaimer - I'm building Nuon, and we're building a security platform for BYOC deployments.

We have built a platform that enables any company to create a fully managed version of their app, that runs in the customer's cloud account in minutes.

Pretty much, you can build out a self-serve BYOC experience just like DataBricks, MongoDB or others in just a few minutes. We currently support AWS apps, but are planning to launch support for just about every cloud you can imagine in Q1 - from Azure, to DataBricks, Snowflake and others.

Take a look at our post, and let us know what you think!

You can also see our announcement on Twitter - https://twitter.com/nuonjon/status/1720116568032489640

I'm the author of this plugin, I'd love to hear what you all think.

For some background, I've been using this sort of work flow within vim for about a year now and finally decided to make the project more robust and easier to use. I find it helpful to be able to declaratively tell vim how I want to execute and validate my current working project.

Would love to hear suggestions and ways to make this better!