Posts tagged with best practices
Joe Ferguson shares a tip on how to make a version of PHPUnit's assertArraySubset where the order of the array does not matter.
The problem with this test is that `assertArraySubset()` will fail if the items in the array are out of order. And since we don’t have an `ORDER BY` on our query in our data source we cannot guarantee the order of the returned data.
In the beginning of the summer the Belgian company PHPro held a cool hacking contest. The persons the could hack a special site that they had set up could win a prize. Yesterday they published an interesting article on how that site could be hacked. The site was also hacked in ways that the developers of the company did not anticipate.
Since this contest started out as an internal project, we've put a lot of focus on the flow on how to hack the website. It was just a little side project to inform our colleagues that some small mistakes can end up in a big catastrophe. By focussing on the flow of the hackme contest, we forgot to secure the application for malicious contestants. Off course, this was something that fired back to us on the first days of the competition. Here is a little write-up of the problems we've encountered and how we fixed them.
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 publishes a super resourceful and practical newsletter. A must for anyone in the Laravel space"
A great story by DHH on his quest to find good names for some functions he was working on.
One of the real delights of programming is picking great variable, method, and class names. But an even greater treat is when you can name pairs, or even whole narratives, that fit just right. And the very best of those is when you’re forced to trade off multiple forces pulling in different directions.
https://m.signalvnoise.com/hunting-for-great-names-in-programming-16f624c8fc03
A couple of months ago Jason McCreary, creator of Laravel Shift, wrote down his opinion on the Laravel's LTS release. I couldn't agree more with this piece.
The more developers that get trapped by LTS, the more of a drag it creates on the Laravel community. Potentially having adverse affects on its growth. Using LTS as a minimum compatibility line for a Laravel package or other third-party code is understandable. But freezing your apps to an LTS version is not. Your apps should run the latest stable version of Laravel.
https://medium.com/@jasonmccreary/laravel-lts-is-a-trap-97b1d1103961
In the beginning of the year Wouter de Bres wrote this fantastic article on digital product design principles.
I wrote down twelve design principles for our team at Degreed to help us make design decisions. I tried to make them practical and clear and hopefully they are useful for anyone who is working on digital products.
https://medium.com/@WdeB/digital-product-design-principles-8bc9eb6c080c
In a new post on his blog Jason McCreary, creator of Laravel Shift, wrote down the summary of his Laracon US talk.
I consider myself a searcher. On a quest to find the Holy Grail of programming practices - that single practice which instantly levels up my skills. While I know this doesn’t exist, I do believe in a set of practices. Recently, I found one to be YAGNI.YAGNI is a principle of eXtreme Programming - something I practice daily at work. YAGNI is an acronym for You Aren’t Gonna Need It. It states a programmer should not add functionality until deemed necessary. In theory, this seems straightforward, but few programmers practice it.
I love those conversational posts written by Uncle Bob. This time he responds to an article by Luciano Mammino who is saying goodbye to OO programming. Uncle Bob's conclusion:
We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.
Amen to that! Read the entire article on the Cleancoder blog.
Gregory Brown wrote an excellent article on how you can grow as a programmer.
Do you know what the difference between competence and proficiency is? ... Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.
https://www.oreilly.com/ideas/the-traits-of-a-proficient-programmer
An older but still relevant post by Evert Pot on why and how you should also test your packages with the lowest versions of it's dependencies.
In some projects, there may be packages lying around that are not the latest version. This could be because it introduced some BC break, or introduced a bug.If other packages also use the package that’s being held back, they may get an older version as a dependency.
So for package maintainers, they will want to find out if their package correctly works with the oldest package they claim to support.
https://evertpot.com/testing-composer-prefer-lowest/
EDIT: Here's another old, but also still relevant, blogpost on the subject by Cees-Jan Kiewiet:
https://blog.wyrihaximus.net/2015/06/test-lowest-current-and-highest-possible-on-travis/
Fred Hébert on his blog:
... sooner or later, people start misinterpreting the original intent and thinking of technical debt the same way you could think about financial debt: a lever to use in order to get something now and then pay the accrued cost progressively over time. This is however not how things feel from the technical person's point of view. ... Rather than focusing on why that is wrong, I want to propose an alternative analogy to describe the reality behind technical debt.
Rob Allen, an active member of the Zend Framework community, makes the case for giving some love to API errors.
It's not hard to have great error responses; you just need to care. Poor error response cause developers to give up with an API and go elsewhere, so it's a competitive advantage to get this right.Developers integrating with your API will thank you.
Bill Sourour has some good tips on how to manage your time.
There’s no time for anything. At least that’s how it feels doesn’t it? No time to learn all the things you think you need to learn to stay ahead of the curve. No time to go back and refactor that ugly piece of code. It works (sort of) and there’s a deadline approaching. No time to write unit tests for everything. No time to write documentation or comments for the next guy who gets stuck maintaining what you wrote. No time to think. No time to breathe. No time!Well… if you take the time to read this article, I promise you’ll find yourself with more time for what’s important.
https://medium.freecodecamp.com/finding-time-to-become-a-better-developer-eebc154881b2
Stoimen Popov advises not to call __destruct() manually.
The important thing to note is that you shouldn’t call the destructor of an object explicitly! Not because it will throw an fatal error, but simply because it won’t destroy the object.
http://www.stoimen.com/blog/2011/11/14/php-dont-call-the-destructor-explicitly/
Bill Jordan wrote an absolutely amazing piece on the things he learned in the twenty-eight years he worked in the software industry. There are so many good insights that I can nearly quote the entire article.
Here are some of the things that resonated with me:
Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. These kinds of high performers are actually low performers when when TCO is factored in.
Encourage developers to improve the application while working on their projects. Examples of improvements are creating reusable objects out of copypasta code and breaking up large objects that are difficult to maintain into smaller objects that individually are easier to reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. With the benefit of hindsight update the user interface to improve user experience — sometimes even just changing a word or two makes a big difference.
When continual improvement is part of the DNA of your team you’ll be amazed with the results, but give those results some time to become apparent — it won’t happen overnight. It also means management will need to recognize that things will take more time since developers will be working on their primary project while simultaneously making incremental improvements.
Be sure to read the entire post: https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.1j7a7qos3
Sandi Metz solved the Roman numerals kata in a very interesting way. Along the way she makes the case for keeping code simple.
The desire for simplicity means that I abhor special cases. I am willing to trade CPU cycles to achieve sameness. I'll happily perform unnecessary operations on objects that are already perfectly okay if that lets me treat them interchangeably. Code is read many more times that it is written, and computers are fast. This trade is a bargain that I'll take every time.
http://www.sandimetz.com/blog/2016/6/9/make-everything-the-same
Amen to that. I did not know that additive Roman numerals are perfectly valid.
If you want to read more posts by Sandi, be sure to subscribe to her newsletter.
A few weeks ago the Frontend United Conference was held in Ghent, Belgium. The entire development team at Spatie attended the conference. Though it certainly was fun to go to a conference with the entire team we were left a bit underwhelmed. Some of the talks were very short and some speakers seemed a bit unprepared.
The organisers have begun posting video's of all sessions to YouTube. In my opinion the following three talks rose above the rest.
1: Harry Roberts gave a talk were he demonstrated that programming best practices apply to writing CSS as well.
2: Christian Heillman talked about web obesity and gave a few tips on how to optimize the size of images.
3: Mathias Bynens showed how unicode support in JavaScript is broken and what common pitfalls are when working with special characters. Rather than just complaining about it, he offered some kick ass self-made solutions.
(the video for this session hasn't been posted yet, this is a video of the same talk at another conference)
Jerome Dalbert on his blog:
Splitting your Rails controllers when they have a very specific scope, too much logic, or too many mixed concerns can have a lot of good side effects in your code.It doesn’t mean that you never abstract. It just comes later down the road. At some point some logic needs to be shared by several controllers. Sometimes even a splitted controller with only one public method gets too big. Et cetera. This is where concerns, model methods, possibly background jobs, and even sometimes service objects (hopefully not too many) come into play.
The more your app grows, the more time you will need to spend to understand it, no matter how clean the code is. But splitting your controllers makes things easier.
http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/
Some great coding tips written down by Joeri Timmermans on the Intracto blog.
As a developer it's your duty to take good care of your code. It's not enough for your code to work, you also have to make sure it's well written and readable. If we spend 10 times more time reading code versus actually writing it, this means the readability of your code is directly related to your output and the output of your co-workers. So providing cheaper reads will not only create happier co-workers, but also increase the productivity of your whole team.
http://blog.intracto.com/how-to-save-a-kitten-by-writing-clean-code
Frank de Jonge wrote an article on how to structure to your functions to avoid the duplication of cleanup code. Spoiler: use finally.
Cleaning up after yourself can be a tedious task. For example, closing file handlers after using them needs to be done. A programmer's life isn't all about the happy path. When things go pear-shaped you might end up duplicating cleanup code throughout your code. This is horrible, let's explore an alternative.
https://blog.frankdejonge.nl/finally-file-streams-and-deferred-execution-in-php/
That defer keyword from Go looks super nice.
Over at the CloudFlare blog John Graham-Cumming wrote an interesting article on SQL injection attacks via http request headers.
SQL injection is a perennial favorite of attackers and can happen anywhere input controlled by an attacker is processed by a web application. It's easy to imagine how an attacker might manipulate a web form or a URI, but even HTTP request headers are vulnerable. Literally any input the web browser sends to a web application should be considered hostile.https://blog.cloudflare.com/the-sleepy-user-agent/
