drichelson
Joined 10 years ago
Karma
90
Submissions
15
Member since
Feb 12
Analog Nomad
View on Hacker NewsRecent submissions
Comment · 2 years ago
Author here. I'm paying more attention to GitHub than the comments here so please feel free to chime in there or ask any questions: https://github.com/dorklyorg/dorkly/discussions/40
Comment · 2 years ago
Well GitHub has a pretty simple UI for editing files + submitting pull requests, so let's say it's a different UI.
Comment · 2 years ago
The example files are put in place by Terraform, so they will get overwritten next time `terraform apply` is run. You can of course change the example flag files as you're kicking the tires or testing out your app, but to really use the system you'll want to create new flags as documented here: https://github.com/dorklyorg/dorkly/wiki/3.-Common-Tasks#add...
These new flags won't be managed by Terraform thus won't get reset to the default values.
This is good feedback. I'll clarify the comments
Comment · 2 years ago
Congrats on your success! The generally accepted definition of Feature Flags/Toggles seems to be this one: https://martinfowler.com/articles/feature-toggles.html
Comment · 2 years ago
It's worth noting that there is no architectural limitation preventing an HA topology: multiple Dorkly servers can be deployed behind one or more load balancers for HA + lower latency where it matters (ie web and mobile apps).
If this is a limitation for anyone I'm happy to work with you on modifying the terraform module to support HA.
Comment · 2 years ago
Fair point. I’m open to suggestions for a new name :)
Comment · 2 years ago
Correct: the flags live in a separate repo.
Comment · 2 years ago
The PR is optional, but governance often requires documented peer approval for all production changes.
Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.
>might as well just change the code at that point
If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.
Comment · 2 years ago
I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them).
Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.
Comment · 9 years ago
LaunchDarkly - ONSITE in Oakland, California.
Not currently hiring remotes workers
Unable to sponsor visas at the moment.
Posting as an engineer who has been working here one year. This is a fantastic team and product. The business is very healthy- not just good growth, but very satisfied customers who are sticking around.
https://jobs.lever.co/launchdarkly
Eng interview process: Offsite coding task that we discuss in person when you're here + other technical and cultural chats.
Comment · 10 years ago
Feature Flags FTW!
Comment · 10 years ago
Feature flags FTW!
Comment · 10 years ago
Did you encounter any performance problems during the 'Early Canary Read' phase? this seems like a lot of DB action.
Comment · 10 years ago
Great idea!