Posts tagged with best practices
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
Join 9,500+ smart developers
Every month I share 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.
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/
The venerable Uncle Bob makes the case for dynamic typing and TDD. Be sure to read the entire article to get a quick history lesson in computer languages.
The pendulum is quickly swinging towards dynamic typing. Programmers are leaving the statically typed languages like C++, Java, and C# in favor of the dynamically typed languages like Ruby and Python. And yet, the new languages that are appearing, languages like go and swift appear to be reasserting static typing? So is the stage for the next battle being set?http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.htmlHow will this all end?
My own prediction is that TDD is the deciding factor. You don't need static type checking if you have 100% unit test coverage. And, as we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. What's more, the benefits of that achievement are enormous.
In our framework agnostic packages we sometimes pull in illuminate/support. This package that's part of the core of Laravel provides some nice string and collection functions. But unfortunately a lot of other stuff gets pulled in as well. In a post on his blog Matthew Allen explains the downsides of requiring illuminate/support.
A lot of framework agnostic Composer packages (PHP) pull in illuminate/support, which contains helper functions and general purpose code used by the Laravel framework. Usually it’s because the support package has nice helper functions like array_get, or because of the nice collection class.The helpers functions are nice, but I don’t think developers appreciate the ramifications of choosing to pull that package in. Everyone is afraid to get criticized for reinventing the wheel, so packages are pulling in 6000+ lines of code to avoid writing isset($arr[$k]) ? $arr[$k] : null themselves.
http://mattallan.org/2016/dont-use-illuminate-support/
One of the most useful functions of illuminate/support is the Collection class. In a thread on Reddit Taylor Otwell, the creator of Laravel, seems to agree that requiring illuminate/support isn't a good idea and that the Collection class could be extracted to it's own package. Let's hope that'll happen in the near future.
In the new major versions of our framework agnostic packages we'll swap out illuminate/support in favor of packages like the ones mentioned at the end of Matthew's post.
EDIT: Meanwhile Tighten has released a Collections-only split from Laravel's Illuminate Support.
Yesterday, after a winter sleep, PHPGent awoke and held a meetup at the offices of In The Pocket. It was nice to see some familiar and some new faces.
I had the honor of being the first speaker. My talk was titled "Backing up with Laravel". I started off with some best practices regarding backups and demonstrated the laravel-backup package which was released a few weeks ago.
Here are my slides:
https://speakerdeck.com/freekmurze/backing-up-with-laravel
Next up was Wouter Sioen of SumoCoders. He talked about building maintainable software. He showed how using the solid principles help to clean up the code of his home brew json to html converter. Then he continued with explaining object calisthenics: a few simple rules to greatly improve the readability of your code. Wouter's slides can found on github.io.
These two very beautiful graphic summaries of the talks were made by Peter Decuyper:
https://twitter.com/sgrame/status/720674134041235456
https://twitter.com/sgrame/status/720690758265778176
If you attended the meetup be sure to leave Wouter and me some feedback on joind.in so we can improve our speaking skills.
Visiting your local PHP user group is one of the best ways to learn new stuff and to getting to know the community. If you've never visited a user group, use this site to lookup the closest one to your home. If there isn't one close by, start one yourself.
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
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.