3 ms·

What I was pointing out that hitting save and getting a result on the live server was achievable in the 90s, there is nothing new about it. The reason we stopp

by voidr 7y ago

What I was pointing out that hitting save and getting a result on the live server was achievable in the 90s, there is nothing new about it. The reason we stopped doing that is because we wanted version control, we wanted to work in teams and we wanted unit and integration tests, which I doubt that you could run within 50ms. > the feature flags, function versioning I can easily replicate that with at least early 2000s PHP(would probably work with 90s PHP as well). > DB migrations We do have DB migrations in all web frameworks that are worth using.

pbiggar 7y ago
> The reason we stopped doing that is because we wanted version control, we wanted to work in teams and we wanted unit and integration tests, which I doubt that you could run within 50ms. A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. > I can easily replicate that with at least early 2000s PHP(would probably work with 90s PHP as well). If you could replicate it, you'd do it. Except you need version control, unit tests, etc, etc. So you need tooling that has those things to make the feature flags work.
- thecatspaw 7y ago
  > A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. You found a way to run multiple selenium tests in less than 50ms?
  - necovek 7y ago
    You seem to be married to a particular technology and approach: I would imagine Dark deploys a versioned/feature-flagged alternative in 50ms, allows you to run tests on it, and once you are satisfied, you switch to it in "production" (even if it's already "deployed", it was not "activated: — we could argue that they are using deployed in a slightly different sense than usual). Tests wouldn't be Selenium, and Dark can probably deduce which tests are affected by a particular code change (if it's close to purely functional/no side effects), so it does not need all of them ran. I generally like the idea and approach technically, but wouldn't be using them because of lock-in nature. I also worry about feature flags: for longer lived "features" (they happen!), code ends up being more complex and hard to maintain, and when the time finally comes to drop them, it's a mess.
  - necovek 7y ago
    Note that I am also guessing they are transpiling Dark to JS for the frontend, thus allowing them to use a common infrastructure for everything.

by voidr 7y ago

pbiggar 7y ago

> The reason we stopped doing that is because we wanted version control, we wanted to work in teams and we wanted unit and integration tests, which I doubt that you could run within 50ms. A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. > I can easily replicate that with at least early 2000s PHP(would probably work with 90s PHP as well). If you could replicate it, you'd do it. Except you need version control, unit tests, etc, etc. So you need tooling that has those things to make the feature flags work.

thecatspaw 7y ago
> A good way of thinking about Dark is to suppose that instead of stopping doing that, we found a way to make it work. You found a way to run multiple selenium tests in less than 50ms?
- necovek 7y ago
  You seem to be married to a particular technology and approach: I would imagine Dark deploys a versioned/feature-flagged alternative in 50ms, allows you to run tests on it, and once you are satisfied, you switch to it in "production" (even if it's already "deployed", it was not "activated: — we could argue that they are using deployed in a slightly different sense than usual). Tests wouldn't be Selenium, and Dark can probably deduce which tests are affected by a particular code change (if it's close to purely functional/no side effects), so it does not need all of them ran. I generally like the idea and approach technically, but wouldn't be using them because of lock-in nature. I also worry about feature flags: for longer lived "features" (they happen!), code ends up being more complex and hard to maintain, and when the time finally comes to drop them, it's a mess.
- necovek 7y ago
  Note that I am also guessing they are transpiling Dark to JS for the frontend, thus allowing them to use a common infrastructure for everything.