inconshreveable

hi y'all, ngrok creator/founder here.

we removed anonymous usage of our product many years ago because it was far and away the largest source of abuse on our entire platform.

i believe at this point that that anonymous, account-less tunneling services like this are net negative for the security of the internet

happy to answer any questions from the community

hi hn, i'm the creator of ngrok. here to answer any questions!

we're excited to continue bringing the magic of ngrok to production workloads. there's no networking to configure, just helm install it. and unlike other ingress controllers, it creates secure internet ingress no matter where your clusters are: EKS, GKE, k3s on your raspberry pi, minikube on your laptop, OpenShift, etc.

<3s to you all

hi all, i'm the creator of ngrok. we released a similar SDK for Go a couple weeks ago [1] and we're really excited to make it just as easy to listen on the internet as it is to listen on a local port for all the Rustaceans out there now too :)

happy to answer any questions!

[1] https://ngrok.com/blog-post/ngrok-go

hi all, i'm the author and creator of ngrok. we're really excited to make it just as easy to listen on the internet as it is to listen on a local port. happy to answer any questions

hi all, creator and founder of ngrok here!

we're super excited to share this release with the HN community. i'll try to answer any questions you have in the comments here.

we're making all of the functionality available for free until may so that you can try everything out. once you have an ngrok account visit https://dashboard.ngrok.com/launch-party to light up all the new features and give it a spin. we're eager to hear your feedback

also feel free to reach out over email, i'm inconshreveable at ngrok dot com

can you tell me a little bit more about what's tedious about it and/or the higher-layer problem you're trying to solve?

edit: feel free to email me as well at alan at ngrok dot com

happy to chat more about our future plans offline, feel free to send me a note. i’m alan at ngrok dot com. would be curious to see what project you’re incubating!

hi folks, i’m the founder/creator of ngrok. happy to answer any questions.

we’ve got some exciting improvements we’re looking to share with the community very soon here

<3 to you all

Thanks Kord! Founder of ngrok here, just a quick note of correction for others in this thread: ngrok is absolutely intended for production use cases. There are many customers both hobbyist and enterprise running thousands of production workloads over ngrok's service (including ourselves! we dogfood ngrok for our ingress). We're excited to be sharing more about that with the HN community really soon.

Really sorry about the frustrations! We're working on improving both of those pain points (as well as many other things). If you're still an ngrok user, send me an email at alan at ngrok dot com

It's missing my personal favorite:

ngrok http file:///Users/alan/share

ngrok | San Francisco, CA | Full Time | Remote OK | US Only | https://ngrok.com

ngrok is looking for networking and distributed systems engineers. ngrok has a rare combination of a small team with very deep technical challenges and a product that has massive adoption among software developers all around the world.

Do you like . . .

  - Hard technical problems in distributed systems / network engineering?

  - Small companies where you have a lot of autonomy and get to wear many hats?

  - Building tools loved by your fellow software developers?

  - An extroardinary high bar for software quality, software architecture and product user experience?

I'm the founder, email me directly: alan at ngrok com

ngrok | San Francisco, CA | Full Time | Remote OK | US Only | https://ngrok.com

ngrok is looking for networking and distributed systems engineers. ngrok has a rare combination of a small team with very deep technical challenges and a product that has massive adoption among software developers all around the world.

Do you like . . .

  - Hard technical problems in distributed systems / network engineering?

  - Small companies where you have a lot of autonomy and get to wear many hats?

  - Building tools loved by your fellow software developers?

  - An extraordinary high bar for software quality, software architecture and product user experience?

I'm the founder, email me directly: alan at ngrok com

Author here. After four years, I still stand by this advice/critique. As everyone likes to point out, there are a few presenters that are an exception to the rule. That's true! I'm certainly not one of them, though.

I would also love to see better tooling made for creating presentations from code. I usually end up painstakingly custom highlighting code so that it can be stepped through line-by-line on slides which is very ungrateful and frustrating work. I also haven't done this in a while, so if folks have found or made tools that make this easier, please send me recommendations!

ngrok | San Francisco, CA | Full Time | Remote OK | US Only | https://ngrok.com

ngrok is looking for senior backend networking and distributed systems engineers. ngrok is a rare combination of a very small company with really deep technical challenges and a product that has massive adoption among software developers all around the world.

Do you like . . .

  - Distributed systems / network engineering?

  - Small companies where you have a lot of autonomy and get to wear many hats?

  - Building tools loved by your fellow software developers?

  - An extroardinary high bar for software quality, software architecture and product design?

You should be comfortable with the Go (Golang) and GRPC/Protobuf, and digging into the weeds of networking protocols.

We're also looking for a frontend engineer with strong visual design and UX instincts and experience with Typescript.

I'm the founder, email me directly: alan at ngrok com

ngrok | San Francisco, CA | Full-Time | ONSITE or REMOTE | https://ngrok.com

ngrok is looking for senior backend distributed systems engineers! Your favorite developer tool is built by a very small company, so there's plenty opportunity to wear multiple hats and a lot of automony shaping the entire product. ngrok has many difficult challenges in distributed systems and networking that you won't find elsewhere in a company of similar size.

The stack is primarily Go (Golang), a little Python and React/Typescript. You should be comfortable with Go, GRPC/Protobuf, AWS and distsys design/architecture.

I'm the founder, email me directly: alan at ngrok com

please file a false positive bug report against windows defender. there's not much I can do about that if they're misclassifying ngrok

same idea, great project. folks pay for ngrok because it's 1) more reliable 2) more featureful

Certainly, although even with complete adoption of ipv6, i suspect we'll still see most networks locked down to prevent incoming connections

1) it depends on the network. the best way is simply to try it 2) yes 3) nope, they can use whatever standard tooling you already use

ngrok's value is for services that don't have public IP addresses (anything behind a NAT or firewall)

Yes that's correct, ngrok hosts servers around the world that serve as 'relays' which accept connections on your behalf and then copy the bytes through to a persistent connection initiated by the ngrok client. It's the same principle as a reverse SSH tunnel

Hiya there folks - I'm the creator of ngrok, happy to answer any questions

I love the idea of this: that there is a place you could go to get a pulse on the opinions of technology professionals regarding the tools they're working with.

So I apologize for the negativity that follows; it's a cool idea, and you've put work into it and made it look very pretty. That being said: unfortunately, without it being backed up by _data_, this is just one person's opinion and ultimately not very worthwhile as is.

Furthermore the presentation of the data along a single axis 'adoption' (or sometimes 'expectation') is even more confusing. Technology comparisons are not helpful plotted on a single variable as the comparator. It also leads to some very bizzare plots where somehow 'mariadb' has more 'adoption' than 'mysql' or 'postgres'

Cool. I'd love to see a section detailing the most important trade-offs that differentiate upspin from other projects, compare the approach to the alternatives and explain why upspin's approach is superior (for $TARGET_USE_CASE)

Seems to be very much in the space of kbfs and IPFS.

For the folks who are building this: can you compare and contrast this to both kbfs and IPFS? Why have you chosen to start another project in an already crowded space instead of contributing to either of those projects? They are both open source and much further along in development . . .

Yes it's possible. I've been doing it for nearly four years now running networking infrastructure software which has even stricter requirements than a typical SaaS business.

It's not easy though. Assuming you have product/market fit (i.e. something that sells):

Reliability is paramount. It is everything to you. If your system breaks, it will stop new development, marketing, support responses, sales calls. Because there is only one of you, you can't afford to spend time fighting fires and answering pages. It does not matter if your software is slow or fast or if it is pretty or ugly or if your userbase is growing or not if you are down.

Reliability is paramount. Invest your time into building systems that do not fail when one component or one machine breaks. Where you can, you should leverage primitives and services from cloud providers that provide the kind of failure guarantees you need. Then assume that your cloud providers will eventually fail on you, so design with that in mind. Take as few dependencies on them as you can handle or make sure you can failover between them.

Reliability is paramount. Every change you deploy could break your systems and cause downtime. You need good testing and monitoring. Run continuous end-to-end testing of all customer-facing functionality that pages you when it fails.

Reliability is a feature if your software is critical to your customer's business. Some will notice when your competitors are down and you aren't. For those that don't notice, educate them. Explain to your customers the investments you've made to keep your service up and running. You can sell it as a differentiator.

After that, support is the next time-sink you need to eliminate. Treat every support request as a bug that can be fixed so it doesn't happen again. Make it extraordinarily easy to contact you and then try to optimize so no one ever contacts you. Invest in your UX. Your UX should try to illuminate the inner workings of your software. Many support requests are simply failures of a customer to understand what your software is doing and why. Customers can't debug black boxes, but they are smart and motivated and if you invest in their understanding, many will solve their own problems before contacting you.

Design your error messages. Your error messages are a more important piece of design than any other messaging from your product. Finally, if you can't solve the support bug with UX, invest in your documentation. Documentation is your last resort because most users will not read it or they will only read portions of it. By the time they get to the docs they're already frustrated, so it needs to be fantastic.

good luck!

i've been impressed with how well the crawl dev team has maintained the velocity and consistent vision over the many years (5+) that i've followed the project. thank you, and well done! is dpeg the author of that section of the docs?

Unlike many other games, DCSS has an explicitly articulated design manifesto explaining the ethos of what is fun and why. It's _amazing_ and you should read it: https://github.com/crawl/crawl/blob/master/crawl-ref/docs/cr...

I've pulled a few highlights:

> Speaking about games in general, wherever there's a no-brainer, that means the development team put a lot of effort into providing a "choice" that's really not an interesting choice at all. And that's a horrible lost opportunity for fun.

> Another basic design principle is avoidance of grinding (also known as scumming). These are activities that have low risk, take a lot of time, and bring some reward. This is bad for a game's design because it encourages players to bore themselves.

> The interface is radically designed to make gameplay easy - this sounds trivial, but we mean it. All tedious, but necessary, chores should be automated. Examples are long-distance travel, exploration and taking notes.

> the joy of discovering something spoily is nice, once. (And disappears before it can start if you feel you need to read spoilers - a legitimate feeling.) The joy of dealing with ever-changing, unexpected and challenging strategic and tactical situations that arise out of transparent rules, on the other hand, is nice again and again.

<3