At Spatie we do not only create a lot of Laravel packages, but we use also use a bunch of existing ones. In this post I'd like to give a quick hint to our fellow package developers. In the readme's of packages you'll often find an instruction like this to publish it's assets: php artisan…
Estimates are typically a necessary evil in software development. Unfortunately, people tend to assume that writing new software is like building a house or fixing a car, and that as such the contractor or mechanic involved should be perfectly capable of providing a reliable estimate for the work to be done in advance of the customer approving the work. This is pretty attainable by building contractors and auto mechanics, who generally are working with known materials building known things in known ways. ... With custom software, however, a great deal of the system is being built from scratch, and usually how it’s put together, how it ultimately works, and what exactly it’s supposed to do when it’s done are all moving targets.
https://medium.com/@ardalis/the-5-laws-of-software-estimates-fd13af46000b#.94s2f42fz
Join 9,500+ smart developers
Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
"Freek’s newsletter is one of the best ways to stay updated with the Laravel and PHP ecosystem. It consistently highlights useful packages, tools, and ideas from the community, especially the amazing work coming from Spatie. As a Laravel developer building SaaS and web platforms, I find it extremely helpful to discover practical tools and insights that improve my development workflow."
In a post on his blog Michael Stivala looks back on his own code written a year ago. Because he learned a lot of stuff in a year time, he seems a lot of room for improvement.
As I’m picking up the codebase ahead of this Summer’s updates, I can’t help but review and refactor the existing code. It’s interesting to dissect previous design decisions. Also, I’ve learnt so much in the last year that it’s only natural for me to want to bring the standard of an older project up a bit.https://michaelstivala.com/things-i-used-to-do-that-arent-cool-now/ If you look at your own code from a year (or longer ago) and think "this is allright, I can't improve on this", chances are you're not learning enough.
Evert Pot makes some sound arguments in favor of dropping the public keyword.
I think people should be using "var" instead of "public". I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discusssions), but hear me out!https://evertpot.com/drop-public-not-var/Over the last year I’ve been going through all my open source projects, and I’ve been removing all the public declarations where this was possible.
...
"public" is completely optional. "public" is the default, so adding it does nothing to your code.
Organizing code is a core skill for software developers and as with all skills the most effective way to improve is to reflect on your previous choices and the fallout from them. There are a wide array of different strategies for organizing code and learning to recognize both the useful and the dangerous ones is very important.https://medium.com/@msandin/strategies-for-organizing-code-2c9d690b6f33#.3fcr619nk
The last few months have been my first opportunity to do automated testing at my full-time job. As I’ve been trying to get the hang of it, my biggest question has been how many of each type to test to write: how many unit, integration, and acceptance tests. Turns out Folks Got Opinions™ on this! As I researched, I found at least four different approaches to testing, and they each provide different answers to a number of questions I had.http://codingitwrong.com/2016/02/08/approaches-to-testing-a-survey.html
Mattias Geniar posted an overview of how to take care of SEO from a technical standpoint:
If you're the owner or maintainer of a website, you know SEO matters. A lot. This guide is meant to be an accurate list of all technical aspects of search engine optimisation.https://ma.ttias.be/technical-guide-seo/There's a lot more to being "SEO friendly" than just the technical part. Content is, as always, still king. It doesn't matter how technically OK your site is, if the content isn't up to snuff, it won't do you much good.
But the technical parts do matter, after all.
Sebastian De Deyne on his blog:
Dynamic languages allow us to pass anything as a parameter without requiring a specific type. In turn, this means we often need to handle some extra validation for the data that comes in to our objects.https://sebastiandedeyne.com/posts/2016/normalize-your-values-on-inputThis is a lightweight post on handling your incoming values effectively by normalizing them as soon as possible. It's a simple guideline worth keeping in mind which will help you keep your code easier to reason about.
Tony Messias on the madewithlove-blog:
The other day I was listening to the FullStackRadio episode 34 which is about dealing with dependencies in Active Record models. This is a very interesting topic and they suggest a few solutions for it. I liked the suggestions and I tried to implement it differently (first try and second try).http://blog.madewithlove.be/post/commands-events-global-functions-and-testing/After that, I decided to talk to my colleagues about the design implementations. And they asked “why not implementing it as a command?”. At first sight I was a bit reluctant, because I’m starting to think applications are getting more complex then it really needs. Then I decided to implement it and the end result was the best one to us. Let’s discuss it a bit.
When starting out programming many developers are quite happy when their code just works. More seasoned programmers know that making working code is just a first step. Not improving your initial code will lead to professional suicide (not my phrasing, I'm sure I've read this in a book at some point).
In an article on his blog, Colin DeCarlo demonstrates how an initial solution can be vastly improved in just a few iterations.
From time to time a friend and I play a programming game that I consider to be a version of Code Golf. Typically, the goal of Code Golf is to solve some challenge using as little bytes as possible. In the version of the game we play however, the limitation is the use of certain language features. Specifically, we try to use as little variables, conditionals and explicit loops as possible.The focus in the article is on removing conditionals, and limiting the use of variables. Keep in mind that, in most cases, this shouldn't be your main goal. Maximizing the readabilty is what your should pursue. Don't try to be too clever or terse. In some cases limiting conditionals and variables goes hand in hand with improving readability, in other cases not. It all depends on context....
My method to accomplishing these challenges is to first write the algorithm in the simplest, most straight forward manner and then chip away at that solution until I’ve satisfied the challenge conditions.
Lorna Jane Mitchell explains on her blog which options you have when you see "lock file out of date" warning.
The `composer.lock` also includes a hash of the current `composer.json` when it updates, so you can always tell if you've added a requirement to the `composer.json` file and forgotten to install it.http://www.lornajane.net/posts/2016/handling-composer-lock-file-out-of-date-warningIn that case, you'll see an error message like:
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.You now have three options: upgrade everything, figure it out, or do nothing.
Matthias Noback continues his highly interesting series of posts with programming guidelines. Part four is about messages.
Besides having a type and a particular value, messages can also be categorized:https://www.ibuildings.nl/blog/2016/02/programming-guidelines-part-4-messages
- A command message is a request for change. One object wants to make the other object do something.
- A query message is a request for information. One object wants to get something from the other object.
- A document message is the response from the other object, based on the query that was sent to it.
JavaScript practically requires callback functions to do anything asynchronous. Unless you’re talking about generators, you really can’t get away from them. Callbacks are everywhere.http://derickbailey.com/2016/02/15/what-do-you-name-the-callback-function/...
I do use different names for the callback parameter, depending on the circumstance. I believe naming is important as it provides a set of expectations. If your code breaks the expectations of the name, people will be confused and it will cause problems.
Matthias Noback posted the third part of his "programming guidelines series".
In this article we'll zoom out a bit and look at how to properly organize the lifecycle of our objects, from creating them to changing them, letting them pass away and bringing them back from the dead.https://www.ibuildings.nl/blog/2016/02/programming-guidelines-part-3-the-life-and-death-objects
A few days ago Toon Verwerft gave an uncon talk at PHP Benelux Conference about a new code quality checking tool he has been developing. It's called GrumPHP. It can automatically perform various code quality checks when you try to commit some code.
Sick and tired of defending code quality over and over again? GrumPHP will do it for you! This composer plugin will register some git hooks in your package repository. When somebody commits changes, GrumPHP will run some tests on the committed code. If the tests fail, you won't be able to commit your changes. This handy tool will not only improve your codebase, it will also teach your co-workers to write better code following the best practices you've determined as a team.https://github.com/phpro/grumphp
The slides of Toon's talk can be found on speakerdeck.
Matthias Noback published the second article in his programming guidelines series. This time he explains why using null in a function isn't a good idea. In my opinion it's great advice that most devs can immediately apply in their projects.
It's certainly a good idea to get rid of the uncertainty and vagueness that null brings to your code. Besides, most of the time when you encounter an actual null value in your program, you probably weren't expecting it. You just call a method on it, thinking that it is an object and PHP will rightfully let your program crash.https://www.ibuildings.nl/blog/2016/01/programming-guidelines-php-developers-part-2-getting-rid-null...
Every particular null situation requires a different solution, but at least I'll list several common solutions for you.
Yesterday our local user group, PHP Antwerp, held it's third meetup. There were two excellent speakers and a bunch of familiar faces.
First up was Gabriel Somoza who talked about his project Baleen. It's goal is to provide an intuitive framework to migrate almost anything. You can view his slides on Speakerdeck.
The second speaker was Marco Pivetta, better known on the interwebs as Ocramius. He is a member of the Doctrine core team. His talk was about best practices when using Doctrine. His slides can be found on GitHub. Here's the video of the talk:
https://youtu.be/j4nS_dGxxs8?t=6m44s
Spatie, of which I'm a partner, sponsored the meetup. Before Marco's talk I got the opportunity to talk a bit myself about why my company is sponsoring the local user group. My short talk can be viewed on YouTube.
The organisers announced that the next meetup will be held at the end of March. If you're living in the vicinity of Antwerp, you should definitely attend.
Adam Wathan posted another excellent article on testing on his blog. This time he talks about creating test doubles. Adam demonstrates that creating your own fake can result in a much more readable test than using mocks or spies.
You'll learn to create an InMemoryMailer like this:
public function test_new_users_are_sent_a_welcome_email()
{
$mailer = new InMemoryMailer;
Mail::swap($mailer);
$this->post('register', [
'name' => 'John Doe',
'email' => 'john@example.com',
'password' => 'secret',
]);
$this->assertTrue($mailer->hasMessageFor('john@example.com'));
$this->assertTrue($mailer->hasMessageWithSubject('Welcome to my app!'));
}
That seems like a pretty readable test to me. Read (or view) the whole tutorial here: http://adamwathan.me/2016/01/25/writing-your-own-test-doubles/
Sandi Metz on her blog:
If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. It may have been right to begin with, but that day has passed. Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right. Although it occasionally makes sense to accumulate a few conditionals to gain insight into what's going on, you'll suffer less pain if you abandon the wrong abstraction sooner rather than later.http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
Matthias Noback, author of "Principles of Package Design", published the first article in a new series on programming best practices on the iBuildings blog. The subject of the first article is reducing complexity.
Inside your method or function bodies, reduce complexity as much as possible. A lower complexity leads to a lower mental burden for anyone who reads the code. Therefore, it will also reduce the number of misunderstandings about how the code works, how it can be modified, or how it should be fixed.https://www.ibuildings.nl/blog/2016/01/programming-guidelines-php-developers-part-1-reducing-complexity
