Welcome

This is my personal web space. Please forgive the broken articles, Markdown/Textile are not very forgiving after multiple blog software changes!

Debugging PHP applications on Ubuntu

Posted on: 2022-04-19 15:57:13

I'm cleaning out some notes and wanted to put this somewhere...

On Ubuntu

Crashes go to /var/crash.
Make sure ulimit -c unlimited is run. Restart php-fpm.

Or see: https://bugs.php.net/bugs-generating-backtrace.php

In order to “unpack them” you use apport-unpack <crash> ~/destination.

See: https://askubuntu.com/questions/434431/how-can-i-read-a-crash-file-from-var-crash

Then, you can use gdb cat ExecutablePath CoreDump within that directory to examine it.

You’ll need the debug symbols loaded for php-fpm. If you’re using the one from sury: https://github.com/oerdnj/deb.sury.org/issues/512

Basically, add the main/debug repos and then apt-get install the correct php7.4-fpm-dbgsym (or 8.0, whatever, you do you)

You also probably want the dbg helpers for zend: https://reverseengineering.stackexchange.com/questions/9558/how-to-get-current-php-function-name-in-gdb https://derickrethans.nl/what-is-php-doing.html

Get the current version of .gdbinit: https://github.com/php/php-src/blob/master/.gdbinit

Then you can review the stacktraces...

Strong like steel? What about the mighty oak?

Posted on: 2022-02-03 10:26:32

It's sleeting outside right now and while many people are having flashbacks to the event of last year. But one of the things that came to mind as I looked outside this morning was the trees in the front yard.

When people think about strength, we often think of steel. As in the "Man of Steel". And while steel has been used to create some of the biggest structures in existence, steel isn't perfect for everything.

While steel is strong, steel can form hidden cracks. When it finally does break, it can be catastrophic.

But oaks. Oaks may not be as strong as steel directly. But they are magnificent and mighty.

When it snowed and iced last year, our pin-oak's branches drooped nearly 9 feet until they basically touched the ground. Walking around outside after the snow, you could hear branches of the Juniper (Texas Cedar) trees snapping in the cold and the weight of of the snow.

I can't pull down a branch on my own, but the snow can weigh it down. But after the snow melts, the branches are restored and the oak is no worse for wear.

All that said, when we think about strength, we should consider the oak, which can bend and twist, be stripped naked of its leaves, be taken down nearly to the ground, but yet can withstand it all.

Hot code updates for Cordova applications

Posted on: 2022-01-23 21:18:27

A long time ago, I used and (mostly) loved Ionic's Live Update (iirc, I think it was called Deploy in the past) functionailty. The idea is really simple. Your "app" lives on-device in a www/ directory that gets served up by Cordova. There really isn't anything magical about it but why can't you just check to see if your application has updates files every time you start it up? And, if it does, update your files and then launch the app?

Well, that's what Live Update does.

There are some caveats, though.

Obviously, the updates can't add/remove/update Swift/Objective-C libraries or modules. Bugs or improvements in those modules can't managed through this method.

The only real "gotcha" here is that Ionic makes you pay for Deploy credits. By default you currently get 25k per month. This is probably enough if you want to update a small group of users a few times a day, but it isn't enough if you want to push out a large number of updates across the board.

In a way, this whole thing sort-of offends my sensibilities. Why would I pay per-device to deliver a www/ directory, when CDNs and other systems allow me to do this for pennies.

Well, if you're offended by this, like me, then you probably are wondering if there are other options.

Well, sort of.

Here's what I've found in my research.

https://github.com/mnill/cordova-app-updater - Seems like it allows you to make individual file updates available to your Cordova application. Probably not helpful for larger applications or ones that use generated code modules from webpack. Hasn't been updated in over 4 years. Dead-end.
https://github.com/nordnet/cordova-hot-code-push - Also deprecated. Updated about 3 years ago as of time of writing. There appears to be a handful of offshoots that have some recent updates. (This one in particular has been updated in the last few weeks.)
https://github.com/Microsoft/cordova-plugin-code-push - Marked as read-only, this system was effectively a competitor to Appflow Deploy (or at least, it seemed to be). So unless you're planning on using ~~CodePush (now App Center)~~ (nevermind, they killed off Cordova support completely). Looks like some folks are talking about writing a replacement for CodePush but it doesn't seem that much progress has been made. Dead-end.

Looks like there are 2 main options here:

Use the chcp (cordova-hot-code-push) module.
Set up Appflow Deploy.

Eloquent upsert() requires a UNIQUE index on MySQL

Posted on: 2021-10-29 16:19:48

tl;dr - upsert() acts different based on your DB. MySQL requires that a UNIQUE INDEX exist for the combination of column you are wanting upsert to work on.

Where I can, I've been using upsert() as a way to make many queries into (usually) a single query.

Recently, I had a situation where a function in our code base was essentially doing this:

$model->relation->delete();
foreach ($anArray as $newModels) {
   $model->relation()->create($anArray);
}

This operation was wrapped in a DB::beginTransaction() / DB::commit().

When I finally got around to re-writing it, it was much cleaner and of course looked something like this:

RelatedModel::upsert(
   $models,
   ['key_one', 'key_two', 'key_three'].
   ['col1', 'col2']
);

I ran the test suite (it passed), pushed and went to sleep.

When I woke up the next morning, I saw a number of errors and a large number of records being generated. Obviously, something was not right in the world of upsert.

After digging into things and exploring how MySQL "compiles" upserts, it turns out that this:

RelatedModel::upsert(
   $models,
   ['key_one', 'key_two', 'key_three'].
   ['col1', 'col2']
);

Also could be written like this:

RelatedModel::upsert(
   $models,
   [].
   ['col1', 'col2']
);

That second set of parameters is never used in the function:

public function compileUpsert(Builder $query, array $values, array $uniqueBy, array $update)
{
    $sql = $this->compileInsert($query, $values).' on duplicate key update ';

    $columns = collect($update)->map(function ($value, $key) {
        return is_numeric($key)
            ? $this->wrap($value).' = values('.$this->wrap($value).')'
            : $this->wrap($key).' = '.$this->parameter($value);
    })->implode(', ');

    return $sql.$columns;
}

$uniqueBy isn't used. It is in the SQLite version, but not here.

After cleaning up the DB and adding an index, the upsert will work as expected.

Notes on writing reproducable Laravel tests

Posted on: 2021-09-22 11:46:22

Just writing some notes down on things that have made my life easier:

Testing timestamps

This has kicked my butt so many times. Started using Carbon::setTestNow(now()) and Carbon::now() to test timestamps coming back from API calls. You may ask: why do you care? This is beacuse I want to know the format of what comes back. I suppose I could just write a custom assertion that lets me know if the timestamp is within, say, the last second or something like that and matches a valid format. This might work. But I like being precise.

Fully test the "shape" of responses

One of the big things that I've come to rely on tests for is to make sure that I don't accidentally break stuff when refactoring or making changes.

All of our new code is testing such that the entire structure of the response is tested to make sure it's good. We also then test some of the data points to make sure things are where they should be.

$this->actingAs($user, 'api')
    ->getJson(route('whatever'))
    ->assertJsonStructure([
        'data' => [
            'id',
            'created_at',
            'updated_at',
            ...
        ],
    ])
    ->assertJsonPath('data.id', $model->id)

A couple of times I refactored something and ended up accidentally forgetting (or renaming a value) because a test didn't cover it. APIs are contracts. They should always return the expected data.

Testing the DB, too.

I've also gotten into a habit of testing the DB after certain API calls, too. This is helpful for testing both what should be there and also for what shouldn't be there. Yes, the tests are longer. This isn't as necessary as much anymore as we've started pulling stuff out of controllers, but on older code this can be valuable, too.

Testing with no internet connection

Turns out we've accidentally had tests that reached out to production systems to pull data. Testing while offline finds these tests and allows you refactor/abstract them.

Knowing when to use fake/random values

This is actually a big one for me. For several weeks I fought with tests that would randomly fail.

Turns out the problem was that the models being tested had a flag on their factory that was choosing a random value. This random value determined if the user had an active subscription.

Now, we assume free and require paid using a factory state: User::factory()->paid()->create(). This ensures that the tests are clear and we've stopped running into this problem. However, here are some fields you likely shouldn't be using random data for:

status (paid_status, post status)
state (sending, processing, etc.)
type (public, private, shared posts, etc.)
flags (reported, archived, hidden)
tags (any tags, really)