Posts tagged with best practices
In a new article on his blog Frank De Jonge demonstrates a lesser known feature/bug of PHP.
When two objects are of the same type, they can access the private properties of the other. This might seem like a bug, but it's actually a very valuable feature. For instance, it allows you to perform very efficient equality checks without the need to publicly expose your internals.http://blog.frankdejonge.nl/pipelines-immutability-and-privates/
A fun talk by Christin Gorman.
Join me for some ranting about how best practices from open source development and project management school is making your sustaining team miserable.https://vimeo.com/138774243
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.
Laravel ships with some good validation capabilities. Form request validation is a nice way to make sure http requests pass valid data. To validate stuff that enters the application in some other way validators can be created manually. Unfortunately this is kinda verbose: $validator =…
Some good tips by Matthieu Napoli on how and why to use a good coding style.
The main point of this article is:http://mnapoli.fr/approaching-coding-style-rationally/
- it’s possible to think about coding style logically
- sometimes doing so forces us to challenge our habits
- when unsure or dubious: just try
Jonathan Reinink made some very pretty slides with lots of good advice regarding templates.
Ross Tuck does not blog often, but when he does you probably are going to learn something useful. In his latest post he shares some techniques regarding exceptions.
Over the last couple years, I’ve started putting my Exception messages inside static methods on custom exception classes. This is hardly a new trick, Doctrine’s been doing it for the better part of a decade. Still, many folks are surprised by it, so this article explains the how and why.http://rosstuck.com/formatting-exception-messages/
A really great talk by Sandi Metz in which she refactors a nasty block of conditional code to a few small, understandable objects.
https://www.youtube.com/watch?v=8bZh5LMaSmE
If you have a form on your website where one of the fields is of the `type="password"`, the page will now be marked as insecure in your browser if it is served over a plain HTTP connection.https://ma.ttias.be/firefox-nightly-starts-marking-login-forms-in-http-as-insecure/
"Password must contain 1 uppercase letter, 1 lowercase letter, and 1 number."http://ryanwinchester.ca/post/stop-forcing-your-arbitrary-password-rules-on-meWith a rule like that, the password
Abcd1234would pass your validation, butmu-icac-of-jaz-doadwould not.
Ryan makes an excellent suggestion to replace password rules by an entropy estimator like Zxcvbn.
Matt Stauffer explains when and how you can leverage custom blade directives.
One of the greatest aspects of Laravel Blade is that it's incredibly easy to handle view partials and control logic. I find myself frequently extracting the contents of a loop out to a Blade partial and then passing just a bit of data into the partial.https://mattstauffer.co/blog/custom-conditionals-with-laravels-blade-directivesBut sometimes the repetitive code isn't the view itself, but the conditional logic I'm running.
In this excellent post Matthias explains why you can't put all your trust in cat when inspecting a file:
https://ma.ttias.be/terminal-escape-sequences-the-new-xss-for-linux-sysadmins/
Let's all agree to never trust anything that has been posted on the internet without very thorough inspection. And let's especially agree to never run an arbitrary command or script found on the internet, without really close inspection.
After giving excellent talks at both Laracons, contributing to Laravel's new ACL, putting out an interesting Full Stack Radio episode with Wes Bos, Adam Wathan today published a new screencast. He is now officially on a roll.
After my presentation at Laracon this year, a lot of people asked me how I'd take that same polymorphic approach when the objects would have to be retrieved from the database.http://adamwathan.me/2015/09/03/pushing-polymorphism-to-the-databaseThis screencast covers how I'd approach implementing the same idea in a real Laravel application with Eloquent, by using polymorphic relationships and delegation to accomplish the same thing without having to resort to any nasty conditionals.
When I first learned to program, I made many objects that were mutable. I made lots of getters and lots of setters. I could create objects using a constructor and mutate and morph the heck out of that object in all kinds of ways. Unfortunately, this led to many problems. My code was harder to test, it was harder to reason about, and my classes became chock full of checks to ensure that it was in a consistent state anytime anything changed.http://blog.joefallon.net/2015/08/immutable-objects-in-php/...
Now, I favor creating immutable objects.
The post clearly explains the benefits of using immutable objects and a nice example.
The venerable Uncle Bob wrote some thoughts on picking a framework:
Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?http://blog.8thlight.com/uncle-bob/2015/08/06/let-the-magic-die.html
I've quoted the end of the post, but you should read it in full, it's worth it. I agree with most things in the article. You should constantly learn stuff and try making the basic functionality yourself to get a better understanding of how things work.
Though there is certainly truth to it I don't fully agree with: "Before you commit to a framework, make sure you could write it." It's good advice when you're very experienced or if you have time enough to investigate lots of stuff. For most people this isn't that case.
When starting out writing PHP almost 10 years ago I made my own little framework because I didn't know any better. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.
Zend Framework 1 came out. It sped up my development because I didn't have to do every little thing myself. Did I understand everything ZF was doing behind the screens? Certainly not. Did ZF create value for me right from the start? Hell yes. While using the framework on various projects I read about how it worked and learned a lot about PHP. I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible.
A few years ago I read some positive articles about Laravel. I really liked the syntax and the feel of things. Sure, it was a gamble to choose a framework I didn't know but it worked out really well. While using Laravel I learned, thanks to some excellent learning resources, lots of things on design patterns and best practices.
It's certainly possible that, in the coming years, Laravel will be replaced by a new shiny framework. Maybe I'll then write a post on Laravel saying "I thought I was doing fine. Looking back at the projects I made with it, I'd say they're all horrible." .
Generally speaking I think the following applies to most frameworks and most programming languages:
Of course all of this depends on context. I would never pick a technology unknown to me when starting to work on a large and expensive task. Learn and experiment when working on small projects. Use what you have learned on the big ones.
Probably all PHP developers know how to concatenate strings. The most popular method is using the .-operator. For small concatenations using this operator works fine. When lots of strings or variables need to be combined it can become cumbersome. Here's an example: $logMessage = 'A…
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…
“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:
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.
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>
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.