dkarlovi

Invest time in GH actions, they are actually really good once you get over the initial hump.

I love puns and this one was excellent, thanks for the chuckle.

Enforce by code style tools.

> It took an hour to read, I thought it would take an hour to write.

Backup codes on a paper in your wallet. Multiple devices.

That's fair, I guess.

You're right, Symfony 1 -> Symfony 2 was definitely a rewrite, but from then on, the general design was kept almost intact (again, not counting the evolution and streamlining of the framework).

I guess the first attempt is always tricky, let's see if Go 2 can find a smooth upgrade path.

Can't say for the rest, but Symfony 2 was a resounding success. Current Symfony 5 is very similar to Symfony 2, with just a ton of refinements and facelifts.

Of course, that's why the list is sorted, he might never make it pass 1 :)

PHPStan and Psalm support what they call "array shapes", basically you can treat the array keys as a type, similar to how TypeScript does it.

Roughly in the order you should do it. Hopefully it's at least PHP 5.3 code:

1. Definitely get a PHP IDE: https://www.jetbrains.com/phpstorm/

2. Get a step debugger and hook it in: https://xdebug.org/

3. Fix the code style: https://github.com/FriendsOfPHP/PHP-CS-Fixer

4. Run the code through some static analysis tools https://phpstan.org/ https://psalm.dev/

5. Upgrade the code with an AST fixer (might help you update to newer PHP version): https://github.com/rectorphp/rector

6. Add tests to it: https://phpunit.de/

7. Run mutation tests: https://infection.github.io/

The "0 budget" is rough, though.

As I understand it, you pass your current span ID to the remote RPC endpoint, it continues adding to it from there, creating their own nested spans etc.

When it gets back to you and all spans are merged, you can see the whole picture, but don't need to provide all the details all the way down.

They could claim OP pushed for MIT specifically for this reason, to be able to take advantage of it after the employment is terminated.

You shouldn't rely on any "just like X" systems for tests, you should use X exactly, including correct config and version as production.

What you want is having a Postgres server, but optimized for tests. What I've done is 1. One instance per pipeline 2. Parallelize by having separate databases per process 3. Build schema once 4. Before each test, purge the database (or run tests in transactions so you can just rollback in the end) 5. Run in Docker, use tmpfs volumes for writes (no disk writes)

It runs fairly quickly.

IIRC it was Azure pipelines.

Did you build it around OpenAPI? I'm interested to try that approach.

It could just be the market they were interested in.

What's the rough scale of "disgusting" here?

Having APIs designed for public consumption probably helped.

GitLab has been great for a while and actually had some features before GH.

If you think about it, this comment could be made in reply to itself.

A lot of businesses use Excel as their means of storing and exchanging any sort of structured data.

This PHP library allows you to define a PHP class and a mapping (using column names or header labels) how you'd like to transform the said Excel into the PHP value object. Then you iterate the Excel sheet one row at a time and get a PHP object for each row, which you can for example store to the DB via an ORM.

Since it's using Symfony Serializer, you can also create custom denormalizers, like converting a random date-ish string into an instance of \DateTime.

More features (like validation, proper streaming serializers for very large data sets, etc) are planned.