All entries of my technical and business blog

Github is one of the most useful tools I have in my arsenal. With over 100 repositories (some of which are private), it’s the best $7/mo I spend. However, there are a couple things about Github you might not know.

Every mistake comes with a lesson or two…

I’ve made a horrible mistake…

For some API work in Laravel, I wanted to validate that the incoming request parameter was a boolean value. At first I tried using the built in boolean slug validator but it didn’t accept all of the ‘boolean’ values I wanted to use. (Also there were weird scenarios where string values of false were triggering as true - like what I wrote about here.

It’s such a cliche by now - “We need a rockstar programmer” or “only code ninjas should apply” - but this choice in your job want-ad is ruining your business. Let me tell you why.

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.)