One thing I like about Laravel is the amount of built-in functionality that is available. But when this functionality is left in default configuration (much like many default configuration items getting hacked), there can be consequences.
For our agile workflow, it’s important to provide a check-in each day. What did you do yesterday, what do you plan on doing today, do you have any blockers? My biggest challenge is actually remembering what I did “yesterday” - especially after the weekend.
I tend to use either the web interface for Slack or I use Franz to manage my open connections. When this is not focused, however, it tends to mark you automatically inactive/away after 30 minutes. If you’re hard-core programming, you might not have slack focused for hours - and this is really confusing for your teammates as you might look non-active or even out for the day.
In an earlier entry here, I described the need for a case-sensitive disk in my development set up. I’ve enjoyed using my SD-based drive, but I wanted to change to using my own drive for two reasons: a) I have 1TB drive, so I have plenty of space and b) the SD is slower than the SSD - at least last time I tested it was.
I’ve written a few helpful methods and systems that help out my unit testing. There are many arguments for and against these tools (don’t test protected methods, don’t introduce global namespace methods, etc) - and those are discussions for another day - but perhaps these might help you out in the mean time.
When PHP errors happen, often times there is an error log. This might be in the PHP error log itself or in a log file. For example, in one of my Laravel projects, I have two log files, one for errors and one for info or debug level information.
In my Laravel application, I have an end point that will retrieve a collection of Client models. I have many other unit tests that validate that my repository returns the proper clients when requested, that my client model is sound. My last test is a feature test checks that if I retrieve a list of clients from the end point there is proper pagination and client models exist. I don’t really need to test the exact values because I know this will work - from all my other tests.
If you deal with integers, you validate them, right? You make sure they’re a valid integer? Well, what about the value 9223372036854775808? That’s right, that’s one more than the PHP_INT_MAX on a 64 bit system.
When you have a more complex assertion you need to make on the parameters of a mocked object, you might use the Mockery::on() method. It can be hard to tell how this fails, though, because if the assertion fails somewhere, the message is confusing - it basically says that there was no matching call to that method, which is technically correct.
A nice feature of Laravel is the ability to add a listener to the DB object’s events (or SQL queries). I’ve seen some people add this, then comment it out when it’s done, then un-comment it if they need it again. I don’t like that - I don’t want commented code in my files (also that’s why we have version control).