Programming for your Future Self
If you are anything like me, you may find yourself hacking on a variety of different applications during a given week. Occasionally I get the luxury of working on a single app, which gives my brain the freedom to immerse itself into the details of the program. However, inevitably at some point I have to set the project aside and fire up a different one… perhaps one that was written months, or even years ago.
Several thoughts have repeatedly surfaced as I re-familiarize myself with an old project. Instead of having to collect them each time, I thought I’d write them down here, to serve as a reminder.
Sorting Parent Eloquent Models by a Child Relationship
Recently I had a situation in a Laravel app where I needed to sort a collection of parent models by a particular value in a
It’s fairly simple to sort the opposite direction, meaning, to sort all the related models that belong to a parent model.
Simplifying Conditional Expressions
As I’ve been reading through Refactoring by Martin Fowler, I’ve found it helpful to rewrite some of the examples from the book in PHP in order to cement the concepts into my mind. While Martin’s examples are primarily in Java, I’ve found an overwhelming majority of the concepts apply to PHP, which is where I spend most of my programming time.
In today’s article, I will attempt to rework the Simplifying Conditional Expressions (pp. 237-270) section into a handful of PHP-based examples.
Diving Into a Laravel Audit
Recently the Zaengle team was asked to look over an existing Laravel application and give a review of the overall state of the code. We were to act as an independent third party, between a new studio who had inherited the codebase, and the client, who was anticipating launching the product. The studio had some concerns about the quality of the code and wanted an independent review prior to picking up development on the project. Here are a few thoughts on the process I followed and several takeaways I had from the experience!
Testing 101: Escape Testing Paralysis!
Learning to write good tests is critical to being a programmer. We write tests to make sure the work is solid and doing what it's supposed to, while exerting as little effort as possible (we're not lazy; we're effective...). When I understood that, I determined that I was going to get great at testing. So naturally I started internet research: "Dear Google, show me 'best code testing practices.'"
I quickly gathered that there are a multitude of testing solutions with numerous opinions on each one. In the same way that children can choose blue LEGO bricks, red ones, or two green ones and then argue loudly about which choice is superior, I heard terms like unit testing, functional testing, integration testing, acceptance testing, etc., and all the debates on what should and shouldn’t be tested in our applications.
I soon found myself in testing-paralysis. My overloaded brain said I had to thoroughly understand each of these paradigms before I could begin implementing any kind of testing on my apps. (Which color LEGO is best?) I didn’t feel confident enough to implement any test, for fear of choosing the wrong test, so I resorted to saying, “Let’s just build the app, and I’ll circle back and test it later.”
Little did I know that even though I thought avoiding the tests was making my life easier, I was actually digging myself into a hole.
Page 2 of 2 (15 total entries)