You can make use of guarded or fillable attributes in Eloquent models in Laravel to help control what values you might allow to be updated via your API. But, I wanted to go a step further and actually stop certain values from being passed in. You could go pretty wild with this and try to block everything, but that’s not what I did. I made this validator.
If you check out array_filter without a callback, you’ll notice that it will basically check each array key to make sure it doesn’t equal false. If you have an object, you get call of the properties as an array using get_object_vars. This quick snippet will allow you to look at an object and verify each property is non-false (or non-empty).
You’ve heard the phrase “The customer is always right” before. I think you’ll find an equal amount of articles online saying that that sentiment is still and always true vs the fact that the customer doesn’t know what’s best for them and they’re not right. (You’ll even hear stories about how some “great” companies like Apple ignore the customer desire and that’s how they became successful.) But they’re not really digging further into the customer relationship.
You’ve heard the saying before: “Fake it till you make it.” I agree with this philosophy - especially when it comes to getting a great programming job. But, I think the way you ‘fake’ it is important. It’s important to fake it ethically. Let’s discuss.
This isn’t a one-size-fits-all suggestion, but it’s a start to help you think about how you actually interact with factories in Laravel. They are used for test data, and are ran very often, multiple times in a row. You don’t need as much random information as you need. (In fact, a lot of times I see people overusing Faker even.)
I wrote instructions in 2011 to add a PHPUnit Listener to Watch for Long Running Tests which seem to be a bit out of date now. But, here’s a quick refresher:
What’s the difference between pitching for new programmers to join the team vs investors to fund it? Nothing. If you’ve not been pitching both of them with equal detail and vigor, you’re missing out.
I’ve used the anonymous self-executing paradigm a few times in JavaScript over the years. Something like this:
I’m a huge fan of code review and code walkthroughs. I’ve been asked before what I look for while reviewing code but I don’t know if I’ve ever addressed ways to pick out what code to actually review.
For testing, I tend to use Postman - which gives you the option to view your API JSON responses in a preview mode (interactive), pretty and raw. But, the other day I heard someone saying sometimes they just want to invoke pretty print in their JSON responses without having to use an external tool and set up a whole environment.