DEV Community: Nick Vahalik

You may not need pg_vector, sqlite-vss, etc.

Nick Vahalik — Thu, 06 Nov 2025 02:10:06 +0000

I have a little side-project I've been working on for some time. What it does and how it does what it does isn't important. What is important is that it uses vector embeddings and it does use cosine similarity search.

One of the big stumbling blocks I kept running into over and over again was: how do I store these vectors? And, more importantly, how do I search these vectors to find matches?

I tried to get sqlite-vss and sqlite-vec both going, but I didn't like having to set the size of the embedding in the Schema definition. pg_vector forces you to have a single embedding size, but you can truncate the database and re-import and it will only complain about the data if the data you are trying to insert doesn't match the size of the existing vectors in the table.

Honestly, I spent a lot of time just fooling and fiddling around with the DB. It was truly a stumbling block: I couldn't really find the "right way" to do what I wanted to do. I am still toying with different embedding models.

This indecision kept me paralyzed. I just wanted to store my vectors and search them!

Then it hit me.

I don't need pg_vector. Actually, I don't need a vector-enabled database at all.

With about 10 minutes and Claude Code, I was able to build a very simple PHP solution that takes a key/value array like this:

$searchContext = [
   '01K9BDCMXB6SP745NS0C9W9XF9' => [ /* vector */ ],
   '01K9BDCJJHXWF8W5VYYD8DAHPS' => [ /* vector */ ],
   '01K9BDCE0BRZ51KEYM7WGN6EF2' => [ /* vector */ ],
   // More rows.
];

And I can search it like this.

$vss = new VSSSearch();
$vss->setSearchContext($searchContext);
$results = $vss->search([/* Vector to search */], k: 2);

foreach ($results as $result) {
    echo "{$result["id"]}: (score: {$result["score"]})\n";
}

The results are the same I'd get from a DB. But I don't need a DB to do any searching. I just load whatever set of vectors I need and search them. I'm already doing other stuff after I search anyway. The embedding search is just one step in the process.

This means I can go back to using MySQL. Storage doesn't complain if the vectors are the wrong size. They are just JSON or binary columns.

If I need speed I can just cache them.

Caveat: my search set is only a few hundred records (right now). 10K records is on the extreme high-end probably the most I'd see. For that index size, I don't need HNSW or FAISS or KNN or any of those fancy indexes. For a few hundred records and/or local development, this is 100% fine.

Dealing with Vim errors during Git operations

Nick Vahalik — Wed, 08 Oct 2025 15:07:45 +0000

I use a lot of git CLI tools and use vim as my editor. While doing a git rebase, I'll sometimes accidentally type :wQ into vim's command entry. However, this isn't a valid command:

E492: Not an editor command: wQ

This aggrieves vim and it doesn't take such mistakes lightly. It registers this as an error causing a non-zero status code to be emitted upon exit and now git rebase thinks something has gone horribly wrong:

$ git rebase -i master
(much editing and such, including an accidental :wQ!)                  
error: there was a problem with the editor 'vi'

I have been plagued by this for years and today finally found a solution.

The issue is one of mental model. Vim isn't just an editor. You can script it. And in some sense, you aren't using it as an editor, it's an editor with a REPL that you can use during editing. That is, your inputs after hitting ⎋ (Escape) will be treated as a live "script" and it's just as if you were running Vim with a script directly.

In other words, my input (the script) had an error.

Anyway, the result is that even after successfully :wq!, Vim still returns a status code of 1 and the rebase will fail. Because you screwed up, you have lost all possibility of getting a successful zero-status return code.

Thankfully, there is a way to work around this. Put this snippet into your ~/.vimrc:

command! WQ wq
command! Wq wq
command! W w
command! Q q
cnoreabbrev wQ wq

This way, accidentally typing WQ|Wq|W|Q|wQ will now map to a valid command and all scripting sins are forgiven.

Now, even if I type :wQ, vim sees the correct command (:wq) and saves and exits successfully. Now I can rebase once instead of 3 times. Yay.

Getting on the AI bandwagon

Nick Vahalik — Tue, 01 Jul 2025 23:27:49 +0000

If you've been putting off learning AI as a developer, you're behind the curve. There have been plenty of people who have groused about how they won't use AI. Honestly, it comes off as whiny. AI is here to stay whether you like it or not.

You don't have to know AI to use it

Honestly, you just need to jump in. Get a free account. Actually, get several. Just start playing around with it. It's really great at summarizing long bits of text. You can feed it docs and search them. It's kinda like an ice bath: you kinda just have to get in there and spend some time in it.

It doesn't have to write code

Even with something like Claude, it can do a lot of stuff for you without even writing code:

It can write tests to give you coverage over classes that don't already have it.
It can write documentation and generate diagrams in Mermaid.
You can have it write "plans" for how to do changes.
It can review plans and suggest changes and improvements.
You can ask it questions about the code base.
You can have it analyze the code base to look for areas of improvement.

All of these things can help give you better understanding of your existing code base, especially if it's big!

Clarity is key!

Unlike a human being, giving an AI a task like this:

Add a column to the user listing on the Coaching page in the admin

May not give you the results you are looking for. You have to be specific with AI. You'll need to tell it where you want the column, how to format it, if it's sortable, etc.

Which... really, you should be doing this already, right? If you were lazy before, you won't get the "bump" from AI that you're expecting because you'll need to take the time to be write better expectations and understandings of your work.

Different tools for different tasks

We use a number of different "AI tools":

CodeRabbit for PR reviews
ChatGPT for a little bit of everything
Claude Code for things like SQL, research, and agentic coding
JetBrains AI for commit messages and code suggestions
Junie for helping to "plan" work and doing some light documentation.
OpenAI for our user-facing Agentic functionality.
Ollama for local testing and experimentation.

I've experimented personally with half a dozen other ones. It pays to play test and try things out. It's amazing how the quality is so different between various platforms. Claude is excellent at Laravel stuff. ChatGPT is pretty good with SQL.

It still requires a human at the helm

AI is getting better. But it can't understand intent. It can't read your mind. It can't know that you did something one way because you found a bug in an upstream library. It doesn't "know" that this particular approach works because timeouts are issue. It'll change tests rather than fix the bugs. It'll outright ignore it what you tell it sometimes!

But like any tool, you must learn it. You must understand its strengths and its weaknesses.

There are strengths aplenty, but there are also nuanced drawbacks and differences and changes to your own workflows that will take some time to learn and adapt to.

Running Laravel Seeders before tests

Nick Vahalik — Wed, 07 May 2025 01:53:51 +0000

Photo by Christian Joudrey on Unsplash

Overview

In this post, we’ll break down a custom Laravel service provider I wrote to solve a common but tricky problem: ensuring a fixed, reliable seeding pattern across all test scenarios, especially with parallelization.

We all know that deploying database schema changes is a standard part of the deployment process. But one of the big debates we've had within our own team was how to deploy stuff that wasn't schema but also wasn't code.

The thing is, you could put data inside of the migration. In fact, there are people that do and it does work for them. But it has limitations:

If you're putting your data changes directly in the migration, then you've got data changes scattered in your migrations.
Those changes aren't applied if you run php artisan schema:dump (because it only writes out the schema). And they are gone if you tack on --prune.
You can write a seeder and centralize the data changes, but that, too, comes with its own problems:
- Seeders can run multiple times.
- Running schema:dump will remove calls to those seeders.

What we are looking for is a solution where:

Seeders will run before tests (e.g. the code can depend on the data in the seeders).
Seeders will run during our deployments.

Seeding for success

To us, a successful seeding strategy looks like this:

Seeds only code-dependent information. (e.g. Permissions and roles.)
Runs once before the tests. (Don't re-run the seeder before every test.)
Doesn't require additional setup. (Don't require devs to run the seeders manually before running tests.)

To accomplish this, we created a new Seeder that run 2 sets of seeders: the administrative permissions and our user-focused permissions:

class RequiredPermissionsSeeder extends Seeder
{
    public function run(): void
    {
        $this->call(AdminPermissionsAndRoles::class);
        $this->call(SeedUserSubscriptionPermissions::class);
    }
}

Getting this to run as part of our deployments was pretty straightforward. In our deploy.php, just add a task to run the seeder:

task('artisan:production-seed', artisan('db:seed --force --class=RequiredPermissionsSeeder', ['skipIfNoEnv']))->once();

And then just throw it into the deploy task:

task('deploy', [
    // <snip>
    'artisan:migrate',
    'artisan:production-seed',
    'deploy:publish',
]);

Now, we can ensure that our deployments will always deploy our permissions as long as they are in our seeders. We write pretty comprehensive tests so that's not going to be a problem: so long as the seeders run in the tests we'll know we added them because we're going to ensure that they are enforced.

Running seeders before tests

It's pretty easy to run a seeder before you run a test. Just add this to a setUp() method:

$this->seed(SomeSeederRequiredByYourTest::class);

The problem is that this seeder will run before every test method. Doing this before a handful of tests isn't a huge deal, but with over 2000 tests in our suite, running the seeders before each test added a substantial amount of time.

We need a way to just run the tests before all the tests.

What didn't work (for me)

I initially asked ChatGPT for help on this and it gave me a number of interesting paths:

PHPunit Extension: Apparently you can run code once before all tests. But... there is still the problem bootstrapping the application. I need something that sits between Laravel and PHPUnit.
PHPunit bootstap: Same issue. I'll still need to bootstrap the application.
Put it into the base class setUp(): Had this worked it would have been easy. But it didn't for reasons I'll get into in a moment.

The `letDown()` of `setUp()`

Our applications base TestCase looks like this:

abstract class TestCase extends BaseTestCase
{
    use DatabaseTransactions,
        MakesJsonApiRequests;

    protected function setUp(): void
    {
        parent::setUp();
        LaunchDarkly::fake();
        $this->withoutMix();

        // Other application specific setup.
    }

That parent::setUp() call must be first because it bootstraps the application. We can't Artisan::call(...) before it because there won't be a Facade root set.

However, putting the Artisan::call() after parent::setUp() will wrap the seeders in a transaction. That's not gonna work either because it'll run the seeders before every test.

Let's open up `setUp()`

protected function setUp(): void
{
    $this->setUpTheTestEnvironment();
}

Er, we gotta go deeper...

protected function setUpTheTestEnvironment(): void
{
    Facade::clearResolvedInstances();
    if (! $this->app) {
        $this->refreshApplication();
        ParallelTesting::callSetUpTestCaseCallbacks($this);
    }
    $this->setUpTraits();
    foreach ($this->afterApplicationCreatedCallbacks as $callback) {
        $callback();
    }
    Model::setEventDispatcher($this->app['events']);
    $this->setUpHasRun = true;
}

Much better. OK. That first line doesn't look that interesting but... refreshApplication() and ParallelTesting::callSetUpTestCaseCallbacks() are both interesting.

But what's setupTraits()?

Dig into setupTraits() and you'll find the real reason your seeders in setUp() run in a transaction. Everything after setupTraits() will be wrapped in a transaction:

protected function setUpTraits()
{
    $uses = array_flip(class_uses_recursive(static::class));
    // <snipped>
    if (isset($uses[DatabaseTransactions::class])) {
        $this->beginDatabaseTransaction();
    }

So now the question becomes: how do we get it to run during the application "refresh". Well, how do you do anything when the application boots? A Service Provider!

The Solution: `TestingServiceProvider`

Let’s walk through the code and see how we tackled this:

namespace App\Providers;

use Database\Seeders\RequiredPermissionsSeeder;
use Illuminate\Support\Facades\Artisan;
use Illuminate\Support\Facades\ParallelTesting;
use Illuminate\Support\ServiceProvider;

class TestingServiceProvider extends ServiceProvider
{
    protected static bool $hasRun = false;

    public function boot(): void
    {
        if (! app()->runningUnitTests()) {
            return;
        }

        if (static::$hasRun) {
            return;
        }

        static::$hasRun = true;

        if (env('LARAVEL_PARALLEL_TESTING') === '1') {
            ParallelTesting::setUpTestDatabase(function ($database, $token) {
                Artisan::call('db:seed', ['--class' => RequiredPermissionsSeeder::class]);
            });
        } else {
            Artisan::call('db:seed', ['--class' => RequiredPermissionsSeeder::class]);
        }
    }
}

Let's break this down:

if (! app()->runningUnitTests()) {
    return;
}

Don't do anything if we aren't in a unit test.

if (static::$hasRun) {
    return;
}

static::$hasRun = true;

Because the application will get reset between runs, our provider will get initialized multiple times. However, because we are running before the transactions, we only need to run once. This check just ensures that we only ever run the provider once.

if (env('LARAVEL_PARALLEL_TESTING') === '1') {
    ParallelTesting::setUpTestDatabase(function ($database, $token) {
        Artisan::call('db:seed', ['--class' => RequiredPermissionsSeeder::class]);
    });
} else {

Parallel Testing in Laravel uses a new database for each process. This database setup happens during bootstrapping. Thankfully, ParallelTesting gives us a callback that we can use to hook into its setup process. Using ParallelTesting::setUpTestDatabase() hooks into that so we can run the seeder once per parallel process!

The key part is this: env('LARAVEL_PARALLEL_TESTING') === '1'. You might think that, "Well, hey, if we can run the seeder once per process, then just running it in the service provider would be enough, right?" Well, it turns out the answer is "no". I cannot tell you why exactly but for some reason, the seeders would somehow manage to produce database errors and would throw odd exceptions.

Because the test helper sets this env variable, we can know if we are running in a parallel invocation. If we are, then we register our callback with the ParallelTesting facade. Otherwise... just run it regularly:

} else {
    // Make sure we run our required seeder once per test suite run.
    Artisan::call('db:seed', ['--class' => RequiredPermissionsSeeder::class]);
}

Now, the parallel test runner is happy and our regular invocations will also work properly.

In Summary

This was a real head scratcher. However, the cool part is that now our test suite now can have information we depend on in the seeder. The CI test suite runs as expected, and local devs can do their normal work without having to worry about making sure that they seed their single test DB or their parallel testing DBs. The Service Provider takes care of everything.

Comparing PHP's Null-safe operator with another null-safe operator can bite you

Nick Vahalik — Mon, 20 Jan 2025 19:36:41 +0000

PHP's Null-safe operator has been a God-send for cutting down long chains of Eloquent relationships. It can multi-line abominations and transform them into simple and elegant checks which are easier for developers to read and more consistent.

However, they do have dark sides. One problem is trying to figure out if a chain in the result is null or not. While following best practices in typing can help in this situation, there is one things that (as of yet) cannot help you.

Take the following example:

// Is the request $user the trainer of the current model's owner?
if ($report->owner->linked_trainer?->trainer_id === $user->trainer_record?->id) {
    return true;
}

return false;

At face value, the expression tests for something simple. The comment above is clear: Is the logged in user the trainer of the user who owns this particular model?

If the current user isn't a trainer, the first part of the right-hand expression ($user->trainer_record) will resolve to null. The left hand expression will be the ID of the user's current trainer. No problem!

Likewise if the owner doesn't have a trainer, the left-hand expression ($report->owner->linked_trainer) will return null. This is expected.

But! What if the owner doesn't have a trainer and the current user isn't a trainer:

if (null === null) {
    return true;
}

return false;

Our permission check fails because null === null. Ouch.

I'm currently not aware of a way to check for this, but it's one more thing I'm internally checking for when I do code reviews!

Do you know of a way to have PHPStan detect this and warn?

Comparing PHP's Null-safe operator with another null-safe operator can bite you

Nick Vahalik — Mon, 20 Jan 2025 19:36:41 +0000

Take the following example:

// Is the request $user the trainer of the current model's owner?
if ($report->owner->linked_trainer?->trainer_id === $user->trainer_record?->id) {
    return true;
}

return false;

At face value, the expression tests for something simple. The comment above is clear: Is the logged in user the trainer of the user who owns this particular model?

Likewise if the owner doesn't have a trainer, the left-hand expression ($report->owner->linked_trainer) will return null. This is expected.

But! What if the owner doesn't have a trainer and the current user isn't a trainer:

if (null === null) {
    return true;
}

return false;

Our permission check fails because null === null. Ouch.

I'm currently not aware of a way to check for this, but it's one more thing I'm internally checking for when I do code reviews!

Do you know of a way to have PHPStan detect this and warn?

Clarifying "Coding Convention"

Nick Vahalik — Wed, 18 Dec 2024 20:17:22 +0000

As a team lead, I often find myself, during code reviews, telling the people on my team to "follow convention" when reviewing their PRs. This tends to evoke groans and epithets (many hushed, some audible). What are these "unwritten rules" that I am asking (nay, insisting? demanding?) that they follow?

In some sense, what this looks like for me personally, is that if someone is looking at a project written by some person and myself, they shouldn't be able to tell which parts I wrote and which parts they wrote. What we both write ought to blend in such that everything is seen as a cohesive whole rather than individual parts mixed together.

So this post, for me, is an attempt to break down what it means to "follow convention" for myself, my team, and for you, dear reader. Because following convention is more than simply running a linter and exercising proper code formatting. It's about following the leader, being a good team mate, and focusing on what matters by playing by the rules.

I'm using PHP & TypeScript on a daily basis, so these examples are centered around these languages. The principles should be universally applicable (I think). Let's go.

Convention, like an ogre, has layers

Convention is hierarchical. Language designers, framework builders, development teams, and module/extension/plugin developers building atop each others' work refines and drives convention. We generally tend to see this form layers:

Local
Framework
Language

On larger projects, there may be some additional incursions between layers. There may be other external influences, too:

Local
Team
Project
Framework
Language

This list isn't authoritative. Projects of differing complexity will have different numbers of layers. If your project is using a language like Lua, you likely won't have a framework. This post and its examples are written considering Angular and Laravel.

The list above is from the outer-most layer to the inner-most, but in order to explain, let's look at them from the bottom up.

Language convention

Arguably this widest and foundational layer. Basically, this convention says:

use the language's features (core library and syntax) rather than some other way to accomplish the task at hand

TypeScript, for a long time, had the optional-chaining operator. It wasn't natively supported in JS until ES2020 (side note: I didn't know this was a thing until I wrote this.) If it wasn't in natively part of JS, and you are using TypeScript, then you should use TS's optional chaining (?.) because it saves you time and is easy to read.

Remember, before it was in ES2020, optional-chaining was this in TypeScript:

console.log(maybe?.it?.exists?.here)

And this in Javascript:

var _a, _b;
// You could think of it in three ways:
//
//  - A location to learn TypeScript where nothing can break
//  - A place to experiment with TypeScript syntax, and share the URLs with others
//  - A sandbox to experiment with different compiler features of TypeScript
console.log((_b = (_a = maybe === null || maybe === void 0 ? void 0 : maybe.it) === null || _a === void 0 ? void 0 : _a.exists) === null || _b === void 0 ? void 0 : _b.here);

PHP 8 introduced a number of str_* functions. Some of these (like str_starts_with()) were so needed that the framework themselves built their own and were eventually "pushed down" to the language. So you could still do this in PHP 8.0:

if (strpos($haystack, $needle) === 0) {
    ...
}

But you shouldn't. You should use:

if (str_starts_with($haystack, $needle)) {
    ...
}

Because that's what the language defined method for determining if a string starts with another string.

Framework convention

Borrowing from above, Framework convention says:

use the Framework's libraries (core library and syntax) rather than some other way and follow the framework's style and approach rather than your own to solve problems

Good frameworks are support structures and are designed to make you productive, safe, and able to build stuff that works. Like in the Language convention, Framework convention adds opinion to things. It also provides context. Some languages like PHP are "just backend web languages". But some languages like TypeScript or C# can be used anywhere.

So when you are in a Laravel application, don't write your own router. Use Laravel's. Don't use Symfony's DI. Use Laravel's.

But if you're working on a Drupal or a Symfony project, you'll want to use the routers, DI, and module/package systems that those frameworks provide.

Likewise, if a framework makes a preference for a particular decision, you should embrace that decision. For example, you may love Tailwind. I don't blame you. But if you're working on an Ionic project, you don't want to import and use Tailwind. You've made the decision to use Ionic. You'll want to use Ionic's utility and support classes for styling. Need more? Extend it!

Frameworks make certain decisions for you for a reason. You don't have to like it, but you should absolutely follow those conventions!

Team, Project conventions

In the draft of my original, it was pointed out by a colleague that even within our own project he saw another layer of decisions that our project that had were not "local" but rather drove the decisions of a number of submodules and other parts of the project. He was also directly pointing out that this layer happens to be the most cryptic and confusing because this layer is rarely documented.

We have a corpus of work which we tend to drive from, but we rarely stop to document it. In fact, it's probably this very layer which (unbeknownst to me at the time) which ultimately started the process of this article being written.

Here are some examples of Team and Project level conventions we've instituted in our own project:

App\Modules - Not perfect, but we stick new bits of functionality into this namespace. The code tends to be (almost) wholly partitioned off. Things like permissions and navigation don't have a formal hooking/integration... one day!
Use of Spatie's Laravel Permission package - We use this for permissions. Don't try to do any permission work without this!
MySQL - Some of the decisions we make are directly because of MySQL. So, where some projects may try to write stuff that is DBMS-agnostic, we've leaned into MySQL and don't sweat writing MySQL-specific bits where needed.
Livewire - We use Livewire for dynamic stuff now. Once over the learning curve, it has made building UIs for our admins simpler, faster, and they are far more usable!

Local convention

In larger applications, it's not uncommon to work on modules or sub-projects within the larger project. Sometimes, those parts of the project which are older and potentially follow a slightly different convention. Think about stuff that was maybe written 4 or 5 years ago and hasn't been touched. In those cases:

use the local code (or module) context's libraries, and approaches rather than some other way and follow the local (or module) style and approach rather than your own

If you find a bug in a piece of OSS software, you'll want the PR to conform to the contribution standards and guidelines. The same goes for stuff you write in a large code base. If you tried to add a second Markdown parser to a project that already had one because you happened to have a preference for it, you'll get your PR (rightfully) rejected.

Maybe a module you're working on supports PHP 5.6 for some unholy reason. Your work will need to reflect that reality (though, maybe you should consider finding an alternative, if one exists?).

There are exceptions to this. If the thing you are writing is broken, or is blocking a language or framework upgrade, then do what you have to make a decision. You probably shouldn't rewrite an entire 3-year old controller to add a single feature to it. But if you're writing tests and finding bugs and you find yourself doing a bunch of that work already—talk to a team member. Maybe changing the local convention to match the project convention is warranted.

Convention hierarchy

That's the model. Bottom to top. In general, the underlying convention will win. This is true when you write new features. It's true when you upgrade or update functionality.

Can there be times when a higher convention overrides something below it? I imagine there can be. But there'd need to be a solid reason for it. And those exceptions should be treated as such. In an ideal situation, you'd not so much override a foundational convention as improve upon it.

Note that much of this is about how to write code, but there is a separate piece of all this dealing with things that are more architectural or stylistic... which I'll create in a follow-up to this piece. More on that later.

By way of contrived example, consider a situation where, in a PHP/Laravel application, you need to parse a CSV:

Within the project, you need to take some input and generate an array.

The local piece of code doesn't seem to use a library.
Laravel itself doesn't have a preferred way of handling CSVs.
PHP has str_getcsv.

Minimally, this rules out trying to use some explode() or preg_match() to do this. You could use str_getcsv. Or... you could go check out a library that solves this for you: like league/csv.

Now, let's say you get tasked a few weeks later and you need to update a different Laravel project and you need to implement similar functionality. But let's say that this project uses laravel-excel.

By convention, you'd want to learn and use that library, since it's what's there.

Exceptions

There are always exceptions. Doing refactors and going back and adding tests may constitute a time to do partial or one-off rewrites of some things.

Regardless of the scope and effort required, the goal should always be to aim for uniformity of convention. If the code base is so large that there isn't a standard uniformity, then maybe you find other problems to solve.

But if the business needs a new feature and—for sake of argument—that feature is already partially done in a partially-implemented JSON:API endpoint, perhaps the better solution is to argue, for the sake of convention, that the new functionality will require the use of the updated API and you can (finally) deprecate the old API.

Next steps

Convention is one part of this. While convention tends to mean preferring some ways of doing things over others, standards or "best practices" would cover architectural or more overarching topics like listing and CI. Practices tend to live at the Framework level and up. For example, code formatting tends to be framework-dependent. This is totally OK! That's why conceptually it seems to belong in a separate category.

Feedback is welcome!

Use comments to figure out where you're going wrong

Nick Vahalik — Tue, 04 Aug 2020 03:36:21 +0000

One of the things that tends to happen to every developer is that you get get stuck with something you're working on. Your code isn't producing the result you are expecting it to.

What do you do?

Try this:

Go through every line of code and write a comment about exactly what it does. Get descriptive. What data is being used, what's the intended result.

Use a debugger, or just good old print statements to validate that's what is happening.

Sometimes the problem is in the expectations: The data that is really necessary is a few lines down, so reorganizing the code may help.

Sometimes the result you are getting doesn't match the result.

Walking through the code and adding comments will help clarify your thoughts and give you something solid to stand on. Try it the next time you're stuck.

Use PHP-Parser to test PHP before eval()

Nick Vahalik — Mon, 27 Jan 2020 17:04:05 +0000

I recently had an issue where I needed to comb through some logs and pull out some data. The data had been logged through Monolog and so it was valid PHP.

Except the logs were corrupt. The logs had been written under a period of heavy load and so some of the entries were corrupt. The file "comber" couldn't detect if the output was valid. But the only way I am aware to actually turn valid PHP into a real PHP structure is eval().

However, eval() presents a problem. If you pass in invalid PHP, you'll get a ParseError and execution will stop.

Enter https://github.com/nikic/PHP-Parser.

By adding this above my call to eval(), I could avoid any corrupt values getting passed through:

use PhpParser\ParserFactory;

$parser = (new ParserFactory)->create(ParserFactory::PREFER_PHP7)

// ...

try {
    $parser->parse($buffer);
} catch (Error $error) {
    echo "Parse error: {$error->getMessage()}\n";
    return;
}

eval("\$a = $buffer;");

// No more parse errors!

Worked as expected—no more ParseErrors were raised and the logfile combing efforts were successful.

Unpacking my head

Nick Vahalik — Fri, 24 Jan 2020 19:42:56 +0000

In a Cordova application it seems like pretty often our error reporting system is complaining about an HTTP Error 0. I've pretty much always seen now that HTTP 0 errors are usually related to some sort of CORS problem. Or perhaps the system couldn't connect. That is, maybe the application was trying to issue a request while there was a disconnection of the network and when it came back up, it decided to report the error that was cached.

But then I came across this answer on SE: https://stackoverflow.com/a/26451773/77209

That answer goes way more in depth into why CORS-related errors are technically status = 0. It's essentially because it's a problem before the request gets made.

So, I recently ran into a problem where I was still seeing these HTTP 0 errors. So I decided to check on the logs while some other stuff was running. That's when I noticed something.

Side note: I check New Relic APM regularly. It's open in a tab and I peruse through it and have alerts set up in case something wild happens. Nothing ever was showing in this tab. At least nothing too wild. A couple of DB issues and a handful of errors with a remote web service.

But back to the logs: so in the logs I checked the timestamp of the request in my reporting system with the log... and I see that the OPTIONS request for the resource responded with a 502 status code.

Hmmm. Why? Open up the error logs...

... [crit] 30081#30081: *4243516 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: #.#.#.#, server: redacted.server.name, request: "POST /api/v2/request-endpoint HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "redacted.server.name", referrer: "http://url/"

Whoa. So the webserver lost connection to FPM. Is FPM crashing?

[24-Jan-2020 13:48:57] WARNING: [pool www] child 13296 exited on signal 15 (SIGTERM) after 259.005807 seconds from start

Well, I'm not entirely sure why at this point but given that the application infrastructure has changed recently, I decided to go back over the config files.

php-fpm got bumped a little bit since some stuff was taken off this server. Also, it appears that I had been hitting the pool limits and so given the size of the box, it got a pretty sizeable bump.

So after deploying that change, I started getting errors again.

MySQL connection limit reached. Whoops. Upping the number of php-fpm processes means that now that number needs to go up some.

So after deploying that change, it really got me thinking about how easy it is to miss this stuff.

Even with something like New Relic and error reporting, I was getting these weird errors from the client which told me nothing.

Monitoring stuff is hard, especially if you're not even sure what you're looking for.

Anyway, things have died down considerably. The number of random status = 0 errors is practically 0 now.

I'm not sure if New Relic's infrastructure system would have caught this, but hey, they give you a 30-day free trial, so why not.

Reasons why you can get Error 0 during an HTTP Request

Nick Vahalik — Mon, 13 Jan 2020 16:15:46 +0000

One of the most frustrating things that can happen is you can start getting Unknown errors (Error status 0) on HTTP requests in your PWA/app.

Error 0 is a weird error since effectively what's happened is that the request has failed failed. Not just failed, but failed in a way that the system doesn't know how to handle. This can happen for a number of reasons, but this is my handy checklist for trying to figure things out:

CORS isn't set up properly. (check the browser logs, they will tell you this)
Preflight is failing. Is your server handling this properly? Is it returning an error?
The response is corrupt. Did you leave a debugging statement in there? Did something happen to cause HTML output when the browser is expecting JSON?
Did you exceed some sort of throttling? This can cause a problem, too.

git log --simplify-by-decoration is my new best friend

Nick Vahalik — Tue, 31 Dec 2019 01:43:45 +0000

In short, it's this: git log --decorate --graph --simplify-by-decoration --oneline [--all]

Let's break it down:

git log - Well, it shows you a historical log of commits.

--decorate - adds information about branches and tags to the log information. If a particular commit hash is tagged or is the latest in a branch, it will show you the name of the branch.

--graph - Git will show you some connecting information. For example, it will show you where commits end up and where the split from other branches. Really helpful if you're trying to figure out where one branch happens to split from another branch.

--simplify-by-decoration - Ah, this is the juicy one. Basically, adding this option only shows commits which have a decoration on them.

--oneline - Only show one line per commit. Essentially, show the SHA, the decorator, and the first line of the commit message.

--all - Adding this last option will show you not just the active branch, but all tags and branches that Git knows about.

* a471bb62 (HEAD -> sprint-7, tag: 2.0.0-9, origin/sprint-7) PROJ-1124 - Use the new widget.
* 39ad8aaf (PROJ-1125-no-boz-far) PROJ-1125 - Also handle no condition.
* 153feba4 (PROJ-1116-access-faz-boo) A couple of extra fixes.
| * 446ae0a4 (origin/PROJ-1125-no-boz-far) navigate to page
|/
| * a1716093 (origin/PROJ-1116-access-faz-boo) fixed access
|/
| * 1c0e6857 (origin/PROJ-1117-lorem-ipsum) fixed css
|/
| * 173131cf (refs/stash) WIP on PROJ-1117-baz-bar-foo: 266064d3 added icons
|/
| * bc7570bc (PROJ-880-bar-baz) PROJ-880 - Adding content.
|/
* bb5f437f (origin/staging, staging) PROJ-181 - Adjust spacing.
* 49f8dae4 (origin/master, origin/HEAD, master) 1.3.12
| * 8ec3b4f9 (tag: 2.0.0b3) Tagging 2.0.0-3.
| * d258e3c8 (tag: 2.0.0) 2.0.0
|/
| * 06f365ee (origin/PROJ-880-bar-baz) PROJ-880 - Adding content.
|/
* 24c6e2e0 (tag: 1.3.11) 1.3.11
<snip>

DEV Community: Nick Vahalik

You may not need pg_vector, sqlite-vss, etc.

Dealing with Vim errors during Git operations

Getting on the AI bandwagon

You don't have to know AI to use it

It doesn't have to write code

Clarity is key!

Different tools for different tasks

It still requires a human at the helm

Running Laravel Seeders before tests

Overview

Seeding for success

Running seeders before tests

What didn't work (for me)

The letDown() of setUp()

Let's open up setUp()

The Solution: TestingServiceProvider

In Summary

Comparing PHP's Null-safe operator with another null-safe operator can bite you

Comparing PHP's Null-safe operator with another null-safe operator can bite you

Clarifying "Coding Convention"

Convention, like an ogre, has layers

Language convention

Framework convention

Team, Project conventions

Local convention

Convention hierarchy

Exceptions

Next steps

Use comments to figure out where you're going wrong

Use PHP-Parser to test PHP before eval()

Unpacking my head

Reasons why you can get Error 0 during an HTTP Request

git log --simplify-by-decoration is my new best friend

The `letDown()` of `setUp()`

Let's open up `setUp()`

The Solution: `TestingServiceProvider`