Stop Using Assert Database Has in Laravel
Please stop using assertDatabaseHas in Laravel. There are many reasons why this is bad, and there are better options available. Let’s find out why.
Please stop using assertDatabaseHas in Laravel. There are many reasons why this is bad, and there are better options available. Let’s find out why.
Terms like web developer, web programmer, webapp developer, and software engineer get thrown around a lot. But, what’s the difference?
A big challenge when setting up a new Zabbix installation is “how do I test my media+action+notification+trigger” setup? I’ve come up with a pretty easy way to do this that doesn’t require butchering your server or messing with it’s historical data.
For the most part, I’ve containerized all of my dependencies inside of my Laravel projects. But, one thing was missing: npm.
Currently, there are two pretty common packages for interacting with your database: Eloquent and Doctrine. Eloquent is part of Laravel and Doctrine, while used often on its own, is usually referenced with Symfony. If you’ve come to read this article, you’re probably versed in Doctrine and wondering why you can’t just - or shouldn’t just - use it with your new Laravel project.
tldr; Using Sqlite in Laravel (or most PHP apps) for unit testing causes false positives in unit tests. Things that work will not work when you move to production and use a different db like MySQL. Instead, spin up a test database that is the same tech and engine as your application will be.
When it comes to Open Source Software, you have a number of choices to make for licensing your software. When you provide a license for your software, you, as the copyright holder, are giving various types of permissions and warranties for the use of this software. You might even define the way it can be used and if modifications have to be submitted back to you. But, what do you “license” software that is closed, paid or private software that you don’t want anyone else to use?
Before I begin a security audit, I try to make sure that the client owns their website. Normally, this is pretty easy and obvious. However, sometimes it takes a little bit more work. That’s why I had thought of launching the tool called Possessor.
When you’re trying to demo your work in progress to a client, it can be difficult to know where to draw the line between working and non-working features. On one hand, you want to show them some context so they can understand the current feature. But, then what happens when they invariably try to explore the context (which may not be done)? Let me put that in a more concrete example.