kboyd @kboyd@phpc.social

Ported project to symfony, but now I need to work out the new way of deploying it ... symfony has a few differences that might be stumbling blocks. Anyone know of a good ansistrano+symfony guide, particularly with Apache as the server? And mod_php instead of phpfpm?

Muahaha, email MX records all ported to fastmail ... today's the day I hit the big red delete button for google workspace.

Hobby project framework port: nearly complete. All tests pass, and bugs found in the first round of manual testing have been addressed. Next up: digging into Ansible and similar to get it deployed.

Anyone know of a good Capistrano replacement? I'm considering Ansistrano, but open to suggestions.

Fixed it by splitting it into smaller tests. 257 of 257 passing! woo!

And despite all my thinking that the test was failing due to the nasty internal wiring of the ported test class ... nope! The test was failing because the feature was broken, which is exactly when the test should fail. Excellent!

(Technically the two failing tests are the same test, just different data provider values...)

Apparently I added some tests as I went along, now at 253 passing out of 255

I've been spending the summer porting a hobby project from a dead framework (Silex) to Symfony 5.4, and last night I got to the point where only 1 test (out of 255) is failing.

It's still a shambles, of course, and the reason for the test failure is internal to the integration test configuration, but aside from that: it's almost done! woo!

Now I just have to run through a bunch of manual testing to find edge cases & update/add tests accordingly.

Tests on hobby projects: Great idea.

Total tests: 244
Tests passing/ignored: 109
Tests failing: 135

That means I'm 45% done porting this hobby project. It's nice having tests. (Some are unit tests, some are functional / webtestcase tests)

Running psalm on a codebase ... 89% done (thousands of files) and it's been stuck on a single file for about ten minutes. Must be a monster file. And this is with 8 threads.

Note: When implementing "offsetGet", it is vitally important that your method should have a "return" statement.

Ask me how I know.

Well, so far porting to Symfony is going faster than rolling my own microframework, but it's not one iota less frustrating. And I'm anticipating many headaches down the road, due to the app being ported working in ways that are orthogonal to how SF likes to do things.

But it needs to be done. Otherwise the code can't be upgraded at all.

Um. Some people would consider this the textbook definition of fragile, no?

https://symfony.com/doc/current/service_container.html#manually-wiring-arguments

Lessons:

1. Remember to write tests

2. Tests will lie to you if you're not careful

3. Code can look correct yet still be silently wrong

4. Silently-wrong code can be live for months or years with no one noticing

5. Computers were a mistake. I need a sailboat and a long break from everything.

Peak "how did this ever work" today in PHP land. I was debugging a method that was improperly returning an empty array. Dig into the code ... and found that it was hard-coded to do so.

But oh! Polymorphism meant a subclass had a non-empty-returning implementation.

Yet that was still improperly returning an empty array.

Ultimately, the very innermost method was returning an array with the wrong schema, which caused subsequent lookups to be blank.

A one-line fix got it working.

Ooh, this might be useful. "A new OAuth2 client for Javascript" https://evertpot.com/oauth2-javascript-client/

Answer: array_udiff() plus the spaceship operator.

Apparently array_diff doesn't like to compare arrays of arrays. Hmm. Wonder what I should be using instead.

... and while the internal jax library might be able to support cpu-bound rendering using the 'iree' variant rather than the 'cuda' one, it's refusing to install jaxlib, so I can't even try that out ...