Freek.dev

Everywhere that I go, conference, the supermarket, the dentist, building sites, people always ask me about the Composer lock file. It's a mystery that seems to cause confusion all across the globe. Well, boys and girls, I'm here today to de-mystify the lock file once and for all.

http://daylerees.com/the-composer-lock-file/

Read more

In my company, we use Twig instead of Blade for our Laravel projects. I know there are a lot of developers that also prefer Twig over Blade. So the question ‘Why choose Twig over Blade?’ often pops up. The reason is usually just a matter of preference, but in this post we’re going to compare the Blade and Twig templating engines side-by-side.

http://barryvdh.nl/laravel/twig/2015/08/22/comparing-blade-and-twig-templates-in-laravel/

If you want to try out Twig in a Laravel project, you can use this bridge package.

Read more

I present you with the taxonomy of terrible software developers, the ecosystem of software critters and creatures who add a whole new meaning to the concept of “defensive programming.”

At one point or another, every programmer exists as at least one of these archetypes – the good ones see these bad habits in themselves and work to fix them over time. The bad ones… simply are.

http://www.aaronstannard.com/the-taxonomy-of-terrible-programmers/

Read more

There is always value in learning about the internals of the frameworks and libraries we use. It allows for a deeper understanding of the problem being solved and appreciation of the work that has gone into these projects.

So today I will be building a basic router to explore this fundamental part of even the smallest framework. The idea is not to create something complete or production-ready but rather the minimum set of features needed to be considered a router.

https://medium.com/@dylanbr/building-a-basic-router-b43c17361f8b

Read more

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:

1. When you see a framework / language that feels good to you, read a bit a about it.
2. If you still feel good about it, use it on a small project
3. If after that project you still feel good about it, use it again, maybe on a bigger project. Learn a bit more how framework and language works.
4. Repeat steps 2 and 3 until you find yourself at step 1 again.

The most important part is the learning in step 3. If you don't do this you'll be a programming cowboy forever.

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.

Read more

The project I'm currently working on will have to send out mails to all its users on a regular basis. It's not a newsletter: the contents of each mail will be very specific to each user. The mail also should contain a link to unsubscribe the user from simular future mails.

The link could look like this: https://myapp.com/unsubscribe. Clicking on the link would direct the user to a login page. After the user has logged in the unsubscribe can be automatically performed. In my mind requiring the user to login first in order to unsubscribe from something isn't very user friendly.

This can be improved by adding the id of the user to the link. Here's what that could look like: https://myapp.com/user/1/unsubscribe. With this link you the app can unsubscribe the user with id 1 in one go. That'll work, but it's not very secure. Unsubscribe links for all other users can be easily guessed. Such links can be made more secure by adding a signature and an expiry date on them.

My colleague Sebastian coded up a Laravel package to create signed url's with a limited lifetime. Here's example where the url gets signed and made valid for only one day:

echo UrlSigner::sign('https://myapp.com/user/1/unsubscribe', 1);

This outputs an url that looks like: https://myapp.com/user/1/unsubscribe?expires=1123690544&signature=93e02326d75

The validate-method can be used the determine if a signed url is (still) valid:

$isValidUrl = UrlSigner::validate($theSignedUrlInTheExampleAbove);

The signature is calculated using the original url itself, the expiration date and a secret string that's specific to your project. When a malicious user tries to change any part of the url the signature won't match up.

I'm assuming that the most common use case of signing url's is to protect routes. The package supplies a middleware that protects routes from invalid signed url's. In the following example only requests with a valid signed url will hit the controller:

Route::get('unsubscribe', ['middleware' => 'signedurl', 'uses => 'UserController@unsubscribe']);

If you're interested in using the package, take a look at it on GitHub: https://github.com/spatie/laravel-url-signer

There's also a framework agnostic version: https://github.com/spatie/url-signer

E-mails can be intercepted and are never 100% secure. Bearing that fact in mind you should never use this kind of link for any destructive action.

EDIT: Some fellow developers pointed out that I could also obfuscate the id in the url. Here are two good libraries to do that:

• http://hashids.org/
• https://github.com/jenssegers/optimus

When using obfuscation of the id this url `https://myapp.com/user/1/unsub `would become something like: `https://myapp.com/user/kwxgqu5w/unsub`

And sure enough, the unsubscribe links of other users cannot be easily guessed. A small downside however is that the url becomes less readable. The big disadvantage is that the url will remain valid forever. As these links through an unsafe medium I think it's a good idea to give them a limited lifetime. Signing an url will do that.

Read more

Though the generators look cool, I've never used them much because I didn't find a good use case. Evert Pot demonstrates on his blog how they can help conserve memory.

Since the release of PHP 5.5, we now have access to generators. Generators are a pretty cool language feature, and can allow you to save quite a bit of memory if they are used in the right places.

http://evertpot.com/switching-to-generators/

Read more

“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:

http://verraes.net/2014/08/dry-is-about-knowledge/

Read more

As software developers we tend to look at things from our own perspective. Assuming everyone else will see it the same way. I’ve spent all this time developing but I didn’t take those extra few minutes to really polish the marketing text. This is the big mistake. I know you are thinking it’s open source, do I really need marketing? Without a doubt yes you do!

http://ericlbarnes.com/open-source-marketing-tips/

Read more

A curated list of amazingly awesome PHP libraries, resources and shiny things.

http://getawesomeness.com/get/php

An epic list indeed!

Read more

Coolblue is a company that sells customer electronics. They are located in The Netherlands. Matthias Noback visited the company earlier this week and wrote an interesting article on the developer culture at the company. There are too many good bits to give you a single quote. Read the entire article on Matthias' blog:

http://php-and-symfony.matthiasnoback.nl/2015/07/behind-the-scenes-at-coolblue/

Read more

Davey Shafik cleary explains the new exception hierarchy in PHP 7.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with `try... catch`.

http://daveyshafik.com/archives/69237-an-exceptional-change-in-php-7-0.html

Read more