emilsoman

> In your case, positioning yourself as a cheap provider is inherently a bad idea.

Why is that a bad idea? When the providers have the same features, wouldn't the customers choose the cheaper alternative?

How does it compare to agent-vault and clawpatrol?

> I've tried (and failed)

Why did it fail?

Can you share something that you found nice?

Curious, what's the career path you'd chase? Can you give examples of some work that you think Claude will never be able to one-shot?

That's cool, but they say the code execution would wait till the tool call is done. Would they be just keeping the code execution process alive? That seems like a bad idea given tool calls can take an unknown amount of time to finish. I am guessing they would be putting the python orchestrator code to sleep when the tool call starts and restoring the state when the tool call is done.

> The script runs in the Code Execution tool (a sandboxed environment), pausing when it needs results from your tools. When you return tool results via the API, they're processed by the script rather than consumed by the model. The script continues executing, and Claude only sees the final output.

Anyone knows how they would have implemented the pause/resume functionality in the code execution sandbox? I can think of these: unikernels / Temporal / custom implementation of serializable continuations. Anything else?

> You may not have time for your actual responsibilities.

In your opinion, what are the actual responsibilities of a CTO?

From your point of view, what's the approach taken by someone who rose to the rank? Is it mostly people and process management and less to do with tech?

> do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"?

I liked your take and curious to know what you think a CTO should be doing here

> What kind of code “looks good” to you? What kind of code “looks ugly”? IMO this is not taste, it's your pattern recognition skill based on what you think is better in terms of correctness, performance and maintainability.

> Which design decisions you feel really good about, and which ones are just fine? It's not just a feeling, it comes from reasoning.

Good taste == good skill isn't it?

When someone chooses a functional lang over an object oriented one - is this because of better taste? They’ve learned, through experience, what kinds of problems map more cleanly to immutability and composition versus encapsulation and state. Their "taste" for one paradigm over another is just a reflection of the skills they’ve built up in recognizing tradeoffs, debugging pain points, and anticipating long-term maintainability. What looks like taste is really just expertise shaping intuition.

I get why the author feels a team member who doesn't align with the team's goals has bad taste. But it's really just this - the opinions they have formed from their experience don't match yours.

How does this compare to https://wasp-lang.dev/ ?

Which are some books focused on IRs you’d recommend?

Love the feature where creators can message their supporters. Congrats on the HN launch!

I have a directory named “mystuff” that’s gitignored globally, in every repository I work on. This is where I store commands, snippets, scripts, ideas, meeting notes etc. To organize things I find on the web, I simply use bookmark folders in the browser.

In our company we use both github wiki and google drive to share knowledge.

Update: we're listed on https://www.ycombinator.com/companies/?batch=w2019 now

Yes, every branch gets its own environment.

It looks like I need to host my prod environment completely on your tool to make use of the staging feature. I will look more into this though, thanks for sharing. One difference is that in Dockup, we can boot up databases instantly with obfuscated prod like data and we do this because Dockup deployments are accessible by the entire team.

Dockup does have support for this through a feature called "resource pools" which allows you to create external resources and use them in your dockup deployments. This is more involved than simply using the containers, but the support is there for those who think it's worth the effort. Thanks for asking!

Dockup is like Heroku review apps, but for the entire tech stack (each PR gets a dedicated environment with all the microservices in your stack). One benefit of using Dockup is that seeding DBs with prod-like data is easy and works super fast so you don't have to wait around for a long time until you do a pgdump/restore. We can do this in Dockup because we maintain a pool of single-use DBs for your deployments.

This looks neat! Thanks for sharing.

Yes, this is possible. By default Dockup would give a random subdomain to each deployment, but some of our customers wanted to use Dockup deployments for giving customer demos so we have added support for long lived deployments that use a specified subdomain.

That's exactly our goal - teams that don't have the time to invest in devops should be able to use Dockup and not have to think much about it. Thanks for the kind words, glad you see the value here!

That's awesome! We would love to interview you to understand your experience, can you please drop me a mail - emil@getdockup.com?

Thank you! We had no idea about Stream, yes the logo does look very similar haha

We would love to interview you to understand your experience, can you please drop me a mail here: emil@getdockup.com? Btw, we had the exact same requirement too - be able to test how a related change in multiple apps would affect the whole system. Check out our deployment form that helps us do this now: https://user-images.githubusercontent.com/1707078/53836663-6...

Dockup is like Jenkins X, but easy to setup for people who do not know Kubernetes or helm charts. Also we have features like single-use pre-seeded DBs and a deployment form for deploying a custom combination of branches, for example, development branches from two different repositories.

Step 3 in this flow is sometimes painful for big teams because developers have to wait in line if other developers are already using staging and may have to roll back databases after testing. Dockup gives the reviewer a chance to quickly test the feature without having to manually do deployments or start the app before merging the PR. Thanks for asking!

Glad you find it useful! If you want to give it a try, you can sign up for the "Free" plan by heading to https://getdockup.com/pricing . There's no setup documentation because we don't require you to run any scripts or maintain a config file. You can simply define your tech stack using our UI and get started immediately. We do have documentation for the self-hosted plan, and you'll see it once you sign up.

Thanks for sharing the list! We should show up there soon now that we've made a public launch.