pierstoval

pierstoval, 19 hours ago

@Hariboas @shochdoerfer @heiglandreas @gmazzap @naderman @Schrank

I've seen projects where even the dockerfiles, docker-compose, etc., are in an entirely different repo, and you could run the project in dev with anything (your own docker images, symfony cli, frankenphp, etc.).

However, there is still something about the tests that is very specific:

pierstoval, 19 hours ago

@Hariboas @shochdoerfer @heiglandreas @gmazzap @naderman @Schrank

Do you have a CI? Do you deploy your project to production if the test suite fails, locally or in the CI?

If you do, tests are just information, metadata about the "current estimated safety" of the project.

If you need tests/CI to be green before deploying, this means that your tests ARE a necessary part of your project, same for the testing framework the tests use.

pierstoval, 5 hours ago

@heiglandreas @Hariboas @shochdoerfer @gmazzap @naderman @Schrank

Sure part of the dev chain, indeed, however if you change your deployment systems, the tests won't change. If you change your DBMS, it will. There are different part in your entire project architecture that are all bound together and some of them are harder to replace, and tests are harder to replace anyway, and moreover tests define the expected behavior of your app, so it's definitely part of it.

pierstoval, 5 hours ago

@heiglandreas @Hariboas @shochdoerfer @gmazzap @naderman @Schrank

You seem to have a strong belief that production and development must be separated, could it be code, architecture, or tooling.
However, all of it is part of the project.
That's why we talk about "project" and not "source code": the source code by itself can't do much without the specs, the CI (hopefully), the production infrastructure, etc.
The tooling in this case will definitely be part of the project.

pierstoval, 5 hours ago

@heiglandreas @Hariboas @shochdoerfer @gmazzap @naderman @Schrank

And I'd even say that the IDE is also part of it sometimes: a few years ago I was using IntelliJ (like I do since 2014) and a new coworker was using VSCode. He struggled in defining some testing rules, and whenever he had to execute the tests, he had to do it in CLI only, and it came with a few productivity issues that a properly configured IDE won't face.

(Even though most modern IDEs shouldn't make a difference in that part)

pierstoval, 5 hours ago

@herndlm Read the alt 😇

pierstoval, 2 days ago

To be clear, my final code is this diff:

return new Promise((resolve) => {
this._callback(data, operation, requestParameters);

• return resolve;

• resolve();
  });

That's stupid, I know.

I even don't have any idea why I couldn't see that before. Everything worked super well, but it's only when unit-testing this particular piece of code that I realized the promise actually takes super long time, therefore is never resolved ("never resolved" should have given me a hint, by the way)

pierstoval, 2 days ago

(No blame, I wrote this code years ago)

pierstoval, 4 days ago (edited 4 days ago)

@olafurw I'm sorry, I just dropped an issue. I may take a look at it if I find more time, but overall it could be solved quickly with db migrations 👍

EDIT: nevermind, I fixed that in a PR: https://github.com/olafurw/rust-sudoku/pull/2

pierstoval, 4 days ago

@emilweth I guess Laravel always took example on node.js, at this point

pierstoval, 4 days ago

@dantleech I already answered that: https://mastodon.social/@pierstoval/112477851928010090

pierstoval, 4 days ago

@dantleech Nope, Symfony CLI is open-source: https://github.com/symfony-cli/symfony-cli

It was first made to ease local development and integration with SymfonyCloud, but now that SymfonyCloud has abandoned its white mark and moved back to Platform.sh, the Platform.sh integration in Symfony CLI is just a wrapper around the Platform.sh CLI tool (which is also open source: https://github.com/platformsh/cli)

The "installer" part is still a wrapper around "composer create" though.

pierstoval, 4 days ago

@dantleech To be clear: I was at first pretty fine with the Symfony installer because back then it gave some "hope" to see different Symfony "distributions" (like the "demo", "skeleton", and "full" we first have), but no work has ever been done to promote other distributions.

Before the CLI tool, promoting a distribution was just about promoting another repo for "composer create", but now it's more about Github templates (like for API Platform's distribution, or Monofony, for instance).

pierstoval, 4 days ago

@dantleech I had so many fights when I was working at SL with the maintainers of Symfony CLI, I really insisted to open-source the CLI tool and they didn't want it.

They only did it once SymfonyCloud "moved" (or more specifically "came back") to Platform.sh 🤷‍♂️

pierstoval, 4 days ago

@herndlm I KNEW IT

pierstoval, 4 days ago

@herndlm What saddens me the most is that it's the same with the React hype. I hate that, but somehow I will end up being forced to join the hype train if I want to keep a job.

And I really hate that monopolizing-hype every framework has.

pierstoval, 4 days ago

@ojrask That's the capitalist version of Open Source.

Not Free Libre open source.

They want to bring you in and keep you there as much as possible, and make you dependent of them.

Standards > monopoly.

pierstoval, 4 days ago

@rolfdenhartog @ocramius Do you also stick to "PHPUnit" instead of "Pest"? 😉

pierstoval, 4 days ago

@rolfdenhartog That's some serious coding! Did you drop usage of Facade and embraced Dependency Injection too? 😱

pierstoval, 4 days ago

@ArnaudStrill That's a known thing: Youtube enforced Firefox users to have a longer buffering time than anyone else, for no real reason.