I had to convert one set of data to another… and it produced some very gnarly code. So what should we do with code like this? The Dets I have a Model called “Customization” which stores details that users provide in order to customize a product. Once that product is paid for and ready to …
cause I sure has hell just made a kickass logging trait. Alone I don’t think I could have wrote this straight up as quickly as I did with TDD. Plus, now it is testable for the life of the project. Why the hell haven’t I been doing this all along?!
Here’s a bit of code fo yo ass. Here’s the migration for the logs table:
And here the model. Nothing special.
Here is the trait that evolved thanks to TDD
And here is the implementation of that trait
Pretty neat, huh? Here is the test class that brought this Logging feature about.
Am I doing this right? I have no idea. What I do know is that I started out needing the ability to log and now I have a trait I can slap on any model to store logs on. Back in the day I would have extended a class to take on this functionality but this is so much better.
Imma keep at it. This was a great start.
is a silly thing to do. Your Laravel app will throw errors, likely a key won’t be generated, and everything will have a bad time. Just delete the composer.lock file and run another update. You’ll be good to go.
And I’m about to rebuild it for the 3rd time. I’ve been listening to Full Stack Radio and packing my brain full of idea thanks to Laracast. When I look at the current code base, I just can’t deal with it. So I’m going to start from scratch… again.
This time I’ll write tests for practice and for peace of mind. Enough trying to rush. Imma try to build this one with best practices in mind. Let’s see what happens.