Readit NewsHypertune (https://www.hypertune.com) | ONSITE (London) | Senior Product Engineer
We're building the most flexible and developer-friendly platform for feature flags, A/B testing, analytics and app configuration. See https://docs.hypertune.com for more details.
At the core of Hypertune is a visual, functional, statically-typed programming language with first-class citizens for analytics, A/B testing and machine learning loops.
Our UI lets users define their configuration logic in this language and our SDKs act as interpreters, evaluating the logic locally with zero network latency.
As a senior product engineer, you'll work mainly in TypeScript and React.
If you're interested, please email miraan at hypertune dot com with your LinkedIn, CV or a link to a project you've built!
miraantabrez commented on Show HN: Dorkly – Open source feature flags github.com/dorklyorg/dork... · Posted by u/drichelson
If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening.
Open to missing something though, curious what others experience has been
Agreed that you lose the benefit of "instant updates" if it's always controlled by a PR.
But Git-style version control with history, diffs, branches and pull requests are pretty useful for feature flags and other "app configuration".
Version history and diffs are great for knowing what flag logic changed when + debugging what broke prod.
Branches let you test and preview flag logic changes in your own isolated branch (which you can point the SDK at) — this is a cleaner approach to having a few separate "environments" like development, staging, production which can drift from each other.
Branches are also great for refactoring the schema / structure of all your flags, e.g. deleting a bunch of flags in one go.
Pull requests and approvals are great for when you're making changes to sensitive flags. E.g. you can lock down specific flags.
Pull requests are also great for onboarding nontechnical team members like PMs or sales reps so they can safely make flag changes themselves but require approval from an engineer (at least while they learn to use the system). Empowering nontechnical people is also why a UI is important.
Branching and pull requests are also a great way to prevent conflicts / overwriting other team members flag changes.
So Git-style features are pretty useful, but you also want the UI and you only want to enforce pull requests for specific flags or team members — this is what we built at Hypertune.
miraantabrez commented on Show HN: Dorkly – Open source feature flags github.com/dorklyorg/dork... · Posted by u/drichelson
Feature flags are great for safely releasing features fast.
As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.
This is one of the reasons we built type-safe feature flags at Hypertune. When a developer deprecates a flag, they get type errors everywhere it's still used. This fails the build so they're forced to remove all the flag references, and they get a nice IDE / compiler driven workflow to do that. Otherwise it's easy to leave flag usages around.
Hypertune (https://www.hypertune.com) | ONSITE (London) | Senior Full Stack Engineer
We're building the most flexible and developer-friendly platform for feature flags, A/B testing, analytics and app configuration. See https://docs.hypertune.com for more details.
At the core of Hypertune is a visual, functional, statically-typed programming language with first-class citizens for analytics, A/B testing and machine learning “loops”.
Our UI lets users define their configuration logic in this language and our SDKs act as interpreters, evaluating the logic locally with zero network latency.
As a senior full stack engineer, you'll work mainly in TypeScript and React.
If you're interested, please email miraan at hypertune dot com with your LinkedIn, CV or a link to a project you've built!
Deleted Comment
Hypertune (https://www.hypertune.com) | ONSITE (London) | Senior Product Engineer
We're building the most flexible and developer-friendly platform for feature flags, A/B testing and "application configuration". See https://docs.hypertune.com for more details.
At the core of Hypertune is a visual, functional, statically-typed programming language with first-class citizens for analytics, A/B testing and machine learning.
Our UI lets users define their configuration logic in this language and our SDKs act as interpreters, evaluating the logic locally on clients with zero network latency.
As a senior product engineer, you'll work mainly in React and TypeScript to craft a beautiful product that delights our users.
If you're interested, please email miraan at hypertune dot com with your LinkedIn, CV or a link to a project you've built.
One problem with calendly is sending links politely without seeming like the other person should bend to your schedule / do the scheduling.
So I‘ve usually said something like: “what’s the best time for you? You can also pick a time here if easier:”
But maybe there’s a product experience that can solve / prevent this problem.
We're building the most flexible platform for feature flags, A/B testing, analytics and app configuration. See https://docs.hypertune.com for more details.
At the core of Hypertune is a visual, functional, statically-typed programming language with first-class citizens for analytics, A/B testing and AI “loops”.
Our UI lets users define their configuration logic in this language and our SDKs act as interpreters, evaluating the logic locally, synchronously, in memory.
As a senior product engineer, you'll work mainly in TypeScript and React.
If you're interested, please email miraan at hypertune dot com with your LinkedIn, CV or a link to a project you've built!