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.
Open source software is wonderful for many reasons. One of the best is we can see and inspect the software for vulnerabilities. But, far too many people actually do this. Let me demonstrate, using a Laravel package, how this lack of review might backfire and cause you grief.
This MySQL error isn’t as hard as you might think to solve. Let’s find out why it’s happening and what we can do to fix it.
I deal with a lot of start-up founders. One thing that I’ve noticed from a lot of them is that they feel like no one understands the struggles they’re going through. A lot have talked about being lonely or trying to find people to count on. Because of this, I had an idea - I wanted to help them with an online tool. I came up with the idea for StartUp Tribe.
2019 was a great year, learned a lot. Unfortunately, The Dev Manager and StartUp Tribe are no longer active.
It’s about halfway through 2019 and I think it’s time to reflect a little bit on my professional goals.
There are a lot of debates about trying to achieve test coverage of 100%. Some people swear you need to do this. Others say, get 80% or more… the rest doesn’t matter. Each side has strong arguments.
Sometimes it makes sense to filter user input before it goes to validation. If you’re using controller-based validation in Laravel, this is pretty easy. But, if you’re doing your validation in request classes, your approach needs to be different.
The average webpage seems to contain tons of bloat and increase in size - and this is no good. I decided that I wanted to create a proof-of-concept website that would act like a single page application that didn’t require a framework like Vue or React. I only need to support the latest evergreen browsers.
I’ve known a lot of programmers who give a lot of concern to making the best product they can. They follow best practices, create amazing programs and demonstrate both quality and accuracy. It’s quite amazing. But when you look at their internal tooling, it’s garbage. What gives?
There’s a struggle to balance the easy-to-use Laravel helpers and functions with very verbose, complicated methods in unit tests. As I’ve been relying on Laravel’s way of doing testing more, I’ve ran into a couple of gotchas that I should share.