A deep look at Laravel’s AssertableJsonString for testing JSON assertions cleanly, showing how to wrap data for more expressive and reliable PHPUnit tests.
A candid take for developers on overly demanding technical exam requests from recruiters, why they don’t reflect real work and how to interpret them wisely.
A thoughtful exploration of coding principles like DRY, KISS, and YAGNI versus strict coding standards, and why simplicity often wins in real projects.
As a developer, we often times deal with massive amount of nested relations and multi-dimensional arrays. Which also means from time to time we get hounded by some unexpected `Undefined index` or `Trying to get property of a non-object` errors. For me, I often times experience this when I'm working on generating excel reports. So let me give you some real world (almost) examples.. ## Situation... Let's say we are creating an export excel report functionality for a helpdesk ticketing app. We have a `$ticket` model that has an `id` field. It belongs to an `$approver` model that has a `full_name` field. So when we plot on excel sheet we want to know who is the approver of the ticket. Somewhere in our code we will have something like: ``` // Assume that the array keys are the excel headings.. return [ 'ticket_id' => $ticket->id, 'approver' => $ticket->approver->full_name, ]; ``` At first this looks all good. However, if the **ticket has not yet been approved** `$ticket->approver` will result to `null`. And since you are basically doing `null->full_name` you'll get the really nasty error of `Trying to get property 'full_name' of non-object`. In reality, if `$ticket->approver` is null, we want it to just return `null` so the excel cell can be empty and not worry about any error. ## optional(...) to the rescue!? Yes! The magical `optional(...)` helper function can help here. So we can just say: ``` return [ 'ticket_id' => $ticket->id, 'approver' => optional($ticket->approver)->full_name, ]; ``` This looks quite okay already. You submit a PR and what a productive day it is, right? But then your client decided to add another caveat. Now `$approver` model belongs to a `$company` model that has a `name` field in it, and your client wants that added on the excel sheet too. No problem! ``` return [ 'ticket_id' => $ticket->id, 'approver' => optional($ticket->approver)->full_name, 'approver_company' => optional($ticket->approver)->company->name, ]; ``` However, if for some reason `$company` is not present from the approver model then we'd be back to that nasty error again. Okay so we can just wrap it in another `optional(...)` right? Well, we can do that... but it does not look clean... and there is a better solution. ## Arr::get(...) If you are not yet familiar with what this helper does, take a look at the [official documentation here!](https://laravel.com/docs/8.x/helpers#method-array-get). Let's go ahead and change our implementation: ``` use Illuminate\Support\Arr; ... return [ 'ticket_id' => Arr::get($ticket, 'id'), // Apply here as well so it looks uniform :) 'approver' => Arr::get($ticket, 'approver.full_name'), 'approver_company' => Arr::get($ticket, 'approver.company.name'), ]; ``` Now if either `$approver` or `$company` model is not set, we do not have to worry about the nasty error. And it works seamlessly on multi-level nesting too. Note: Obviously, the implementation will not work if the inner relation is a `Collection`. That's a totally different approach when plotting on an excel cell.
A detailed look at Laravel’s parallel testing backport in 8.x, resolving a version mismatch with nunomaduro/collision packages and improving test performance.
Laravel team has recently announced that they are moving from a 6 month major release cycle to 12 month major release cycle. This is due to many users feeling that versions were being released frequently since adopting the *"semantic versioning"* standard even though the cycle speed stayed the same. And because of this decision, the team decided to backport parallel testing to Laravel 8, which was supposed to be a major feature of the Laravel 9 release. Developers like us can now enjoy the benefits of faster running tests as of Laravel 8.25! We can read the full announcement here: [Laravel: New Release Schedule](https://blog.laravel.com/updates-to-laravels-versioning-policy) Here's a preview of tests in one of my major projects before and after implementing parallel test.  As you can see, that's about 50% increase in time it took to complete the entire test suite and more than 80% reduction on memory usage. I don't know about you but that is insane! You can read full details of the new feature here [Laravel: Parallel Testing Is Now Available](https://blog.laravel.com/laravel-parallel-testing-is-now-available)
I recently updated my dev machine (Macbook Pro) to macOS Big Sur version 11.1. After upgrading, I encountered this error after running `npm run dev` on one of my projects.  Here's a quick fix that worked for me.. Make sure you are using the LTS version of node. You can get it from [nodejs.org](https://nodejs.org/) (version 14.15.4 as of this writing). Run `npm rebuild node-sass --force` command. And you should be good to go!