by Freek Van der Herten – 2 minute read – Edit
A few days ago Dylan Bridgman published a post on writing highly readable code. He cleaned up a truly horrible piece of code. The code was further improved the very same day by Ryan Winchester. I believe the code can be improved still. Read the mentioned blog posts to see which code we are going to…
– Edit
“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.The full article contains a nice code example to help you understand the theory:
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.
"I’ve been reading freeks newsletter for a while now, and it’s easily one of my favorite developer newsletters. Freek shares practical, no-nonsense insights from running Spatie, maintaining hundreds of open-source packages, and shipping real products. Every time I get useful Laravel tips, smart tooling advice, always high quality and immediately applicable."
– Edit
https://medium.com/@guypod/10-reasons-to-go-https-a2cba5734bb6Today, however, there are more reasons than ever to switch to HTTPS — even for a news site, corporate site, or any site that doesn’t consider itself at the top of the security food chain. HTTPS adoption grew 80% last year alone, much faster than previous years, but we’re still very far from encryption being the norm.
If you’re not convinced HTTPS is right for you, or need ammo to convince your peers and bosses, here are 10 good reasons to go HTTPS.
– Edit
A short and very enjoyable read by Uncle Bob on singletons:
Do you recognize this: ``` public class X { private static X instance = null;private X() {}
public static X instance() { if (instance == null) instance = new X(); return instance; }
// more methods... }
<em>Of course. That's the Singleton pattern from the GOF book. I've always heard we shouldn't use it.</em> Why shouldn't we use it? <em>Because it makes our systems hard to test.</em> It does? Why is that? ....</blockquote> You can read the whole conversation on <a href="http://blog.cleancoder.com/uncle-bob/2015/07/01/TheLittleSingleton.html">http://blog.cleancoder.com/uncle-bob/2015/07/01/TheLittleSingleton.html</a>
– Edit
Mitchell van Wijngaarden and Shawn McCool gave a talk at the Dutch PHP Conference 2015 uncon track about naming things. Shawn afterwards decided to make a video. It's must-see if you're interested in improving the readability of your code.
– Edit
If you're interested in some dark magic you should watch this talk by Marco Pivetta on Voodoo PHP. I really like these show-me-the-code type of talks.
We've often seen "magic" code, but how does it even work? Let's explore some arguably bad PHP coding techniques that are actually used in real world libraries to solve problems that would otherwise be a huge burden for all of us.
– Edit
Developers and their employers are often at odds over matters like clean or beautiful code and with good reason: neither ships a product or increases sales. Most end users don’t care what the code looks like, as long as the product works and meets their needs. That means that beautiful code goes out the window when the rubber meets the road and crunch time sets in.http://www.brandonsavage.net/the-case-for-maintainable-code/The fact of the matter is that framing code discussions in terms of beauty or attractiveness doesn’t help the case for getting code that’s clean. But there’s another way to frame the discussion that makes more sense, and achieves both the goal of writing clean code and meets the needs of most businesses: the concept of maintainable code.
– Edit
On using a factory versus just newing an object up:
In cases where an object has no dependencies, creating it locally is less of a concern. For example, a DateTime object has no object dependencies (unless you specify timezone, but that’s another matter entirely).http://www.brandonsavage.net/breaking-the-single-responsibility-principle/
– Edit
We've moved our logic into a trait, a trait can be shared between many controllers without inheritance and it's more reasonable to do things with views and redirects here (though still not ideal). This in my eyes is the best solution to the problem, it's what traits are good for and it's quite convenient.http://tech.graze.com/2015/04/14/sharing-controller-logic-with-traits-in-php/
The article provides a good overview of how the people at Graze came to this solution.
– Edit
... it’s important to remember that API design isn’t strictly about the practical implications on client and server software. The audience for an API is the developer who is going to consume it. Per the "principle of least astonishment," developers will have an easier time learning and understanding an API if it follows the same conventions as other APIs they’re familiar with.https://blogs.dropbox.com/developers/2015/04/how-many-http-status-codes-should-your-api-use/
– Edit
Is a million lines of code a lot? How many lines are there in Windows? Facebook? iPhone apps?http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
– Edit
Dimitrios Savvopoulos, the creator of the laravel-translatable package (which I use in almost every project), shared a very nice tip on how to develop a package while it is installed as a requirement.
If you have write access to a composer package repository, you have the possibility to continue its development while it is installed as requirement in another project. Let's see how we can accomplish this.http://dimsav.com/blog/9/git-repository-inside-composer-vendors
If you have another, possibly better, way to go about this, let me know in the comments.
– Edit
Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.http://semver.org/...
Given a version number MAJOR.MINOR.PATCH, increment the:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
– Edit
HTTP2 will mean a change in how we should build websites. The best practices of HTTP1 are harmful in a HTTP2 world.https://mattwilcox.net/web-development/http2-for-front-end-web-developers
– Edit
An old, but still relevant, blogpost by Derick Rethans (of Xdebug fame) about why the @-operator should be avoided.
http://derickrethans.nl/five-reasons-why-the-shutop-operator-should-be-avoided.html
by Freek Van der Herten – 1 minute read – Edit
My current hosting provider, DigitalOcean, has a great backup service. It takes frequent snapshots of entire droplets and it's very easy to restore the snapshot quickly. Unfortunately backups are only taken once every week. For our clients this is not acceptable. If you only rely solely on the DO…
– Edit
In this video Steven Salevan, a site reliability engineer (cool title) for Twitter, explains how they use Ansible to manage thousands of their servers.
https://www.youtube.com/watch?v=fwGrKXzocg4
– Edit
http://www.theguardian.com/info/developer-blog/2015/jan/05/delivering-continuous-delivery-continuouslyIn 2011 the Guardian deployed the software behind the website 25 times. It was a laborious and fairly manual process. In 2014 we made more than 24,000 highly automated production deployments. Why and how did we do it?
– Edit
There are many falsehoods programmers believe about geography, about addresses, about names and about time.
