Skip to content →

Jesper Jarlskov's blog Posts


Another month is coming to an end, and again that means I’ll try to summarize some of the most interesting articles I’ve read. Because of holidays, it’s been a pretty short month for me work-wise. That also means that this month’s list is pretty short, but the content is really high quality.

For a while, I’ve been considering how to prevent my controllers to get too bloated. Laravel 5.5 introduces the responsable interface, which I believe will help provide a nice convention for where to put the logic that often ends up in the controllers. Another option suggested by Jens Segers, is to turn the normal entity-based controllers into callable request handlers, narrowing their focus, which I also think is an interesting approach.

I first heard about Event Sourcing at last year’s Laracon EU at Mitchell van Wijngaarden’s talk Future is a thing of the past. Mitchell’s background was very theoretic, though, meaning that at the time he hadn’t built any large-scale applications using the approach. That’s why I found it really interesting when Barry O Sullivan wrote his article Event Sourcing: What it is and why it’s awesome, providing an introduction to the concept of event sourcing, from somebody who works with it in the trenches of every day development.

I also found this list of 5 interesting Vuex plugins, for the Vue state management plugin Vuex.

Leave a Comment


Once again a month is coming to an end and, as is becoming the habit, I’ve gathered a bunch of interesting tech articles that caught my eye during the last month.

First up, Matthias Noback has a 3-part series about his approach to application architecture and layered architecture. First part is a preface where he tells about his early experiences, and how he became interested in layered architecture. In the second part, he talks about layers and gives an outline of what a layered architecture is, and how he approaches the class structure in his applications. In the third and last article, he talks about ports and adapters, and he goes more into depth with how he handles communication between different layers of his applications.

Josh Justice from CodingItWrong has an interesting piece about his experiences with adding functional programming to his toolbox, on top of his existing knowledge on OO programming.

Christian Maioli writes about a project he took over. The people who had written it was really solid and experienced developers, but the project still ended up being a complete mess. This made him consider some of the barriers that can be set for developers, and some of the things that can cause terrible code to be written by perfectly sane people.

On a more curious note, Bruno Skvorc posted an article where he introduces bitwise operators, and whether they’re still relevant today. Bitwise operators, in my view, is a pretty core concept and knowing more about where the technology comes from helps make it easier to understand how stuff works, so I’d definitely recommend giving it a read, whether you’ll be needing bitwise operators or not.

Laracon US was held about a month ago, and now the videos are available. The page itself doesn’t provide a lot of info about the talk, besides the name or company of the speaker, and the website itself is not at all helpful in that regard, but luckily Sid K has done a Laracon US 2017 recap where he provides a short description of all of the talks, to give some hints to which might be of interest.

Laracon EU just ended, and as what seems to be becoming a habit, Taylor Otwell spent some of his conference time finishing up the new Laravel release. This means that Laravel 5.5 LTS has been released.

Leave a Comment


Even though July was a pretty quiet month online due to everybody being on vacation, I still came across some interesting articles.

Earlier in the year, there was a big discussion in the PHP community after some people suggested that pretty much everything in your code was cruft, and that code should be as concise as possible. One argument for being the opposite is to type-hint all the things which present an argument for how type hinting reduces the cognitive load of reading code.

In security training, Brute Logic presents The 7 main XSS cases everyone should know.

We’ve recently moved our entire front-end build process at work to WebPack. This has very much been a black box to me, so I was happy to see WebPack core contributor Sean Larkin announce his new online course WebPack the core concepts.

Of course, there’s also something Laravel related. First a tweet by Mohammed Said, subtlely announcing a nice new way for queue jobs in Laravel to determine whether they should actually go to the queue.

Matt Stauffer posed the question What packages do you install on every Laravel application you create?. The result is a list of interesting packages I’d recommend looking through. Most of them are not Laravel specific, so other PHP developers might find something interesting as well.

Leave a Comment


Summer is on, June is over, and it’s time for yet another summary of a month passed. This month’s focus will be on PHP and Laravel, with an emphasis on performance, but many of the tricks are also useful if you work with other technologies. There’s also a gem about database encryption.

I’ve had a hard time finding a proper plugin to provide proper syntax highlighting and folding capabilities when working with JavaScript, but Vim-vue seems to meet most of my needs when working with Vue components, finally!

The entire frontend was refactored. This provided a lot of useful insights that was documented in a post on refactoring the frontend. This process also formed the basis for the new Symfony frontend component, a Webpack wrapper and asset manager Webpack Encore which will be introduced in a coming version of Symfony.

StyleCI founder Graham Campbell has an interesting post on the architecture of a Laravel package. Besides the Laravel specifics it also contains some interesting points on advanced composer usage.

Performance is always an interesting topic. Chris Fidao from the awesome Servers for Hackers released a new section dedicated to Laravel Performance. The focus is on low-hanging fruits, and I believe most people will find something they can do right now to improve the performance of their application. Even though the emphasis is on Laravel, most of the tips are around object caching that can be used on any PHP projects, and different database optimisations, that can be used in any project where a database is in use.

Olav van Schie also has a performance focus in his Make your Laravel app fly with PHP OPCache. Again, even though the title says Laravel, OPCache optimisations can help improve performance on any PHP project, and the article gets a bit deeper into how to set up your OPCache settings.

The last article of the month focuses on security. Scott Arciszewski from the Paragon Initiative has a very interesting article about Building searchable encrypted databases. He both talks about the implementations of database encryption, both good and bad, and how to setup your database to make it possible to search your encrypted data in a performant way, without lowering your security.

Leave a Comment


The month of May is over, and as usual, it’s time for a summary of interesting tech related articles I’ve found during the month.

We start out with some numbers. Jordi Boggiano published a new updated version of his PHP version stats. A range of stats on the PHP version usage, based on the install stats on This does not comprise the full worldwide PHP usage, but provides some nice insights on the current trends.

On a meta-programming note, Robert Basic posted an article about how open source taught him to work with legacy code. It provides some nice points about working with legacy code and the thoughts of the people who came before you.

DHH posted an interesting view on his love of the implicit parts of programming. A nice piece about questioning common assumptions and defining best practices around your actual context, instead of expecting the same best practices to be the best in every circumstance.

On the geeky side, I really enjoyed a Stack Overflow response explaining the difference between language constructs and built-in functions. It is not knowledge that is useful in a programmer’s day-to-day life, but it’s always good to know more about how your tools actually work.

Leave a Comment


April is almost over, and it’s time for another monthly roundup of interesting articles and links.

During the month I’ve read some interesting articles providing a pretty good spread ranging from introductions to JavaScript tools over best practice for working developers to a deep dive into the PHP engine.

The world of JavaScript tooling and frameworks seems to be an ever moving target, even so, the purpose of these tools is to make the everyday life of developers easier. Npm seems to be something like a current de facto standard for JavaScript package management. Sitepoint posted a beginner’s guide to npm, which gives a bit more background info for people who wants to know a bit more than how to write npm install.

At our company we recently switched to the Webpack module bundler, it’s been working quite well, but it was interesting to read Tutorialzine’s learn Webpack in 15 minutes and gain a few more insights into how it all works.

JavaScript as a language is also a moving target. The latest version is ECMAScript 2015 (aka. ES2015, aka. ES6), if you want to know more about what’s new in this new version, you can Learn ES2015 with Babeljs.

On a more general development note, TechBeacon published an article called 35 bad programming habits that make your code smell. Despite the link batish title, the article contains some good points about bad programming habits worth keeping in mind when doing your development.

Developers often complain about having to maintain other peoples’ code, and sometimes you get the impressions that only greenfield projects are fun to work with. Tobias Schlitt from Quafoo has some very interesting points about the advantages of improving existing code bases in his Loving Legacy Code. I think the article presents some really interesting advantages that are often forgotten when we get too focused on the code itself.

I’ve written a few deployment scripts by myself, but it’s always interesting to learn about other peoples’ experiences, Tim MacDonals has some interesting points in his Writing a Zero Downtime Deployment Script article.

It’s always interesting to know how our tools actually work internally. Even though it’s a bit too low level for me I always find Nikita Popov‘s PHP internals articles interesting, the same goes for the new deep dive into the PHP 7 Virtual Machine.

As a last thing I’d like to share a PHP library that I’d like to play around with; Spatie’s Crawler a PHP library for crawling websites. I could imagine this would work well together with Fabian Potencier’s Goutte web scraper library. I currently use Goutte for a small “secret” side project I call Taplist, a web scraper that scrapes the websites of beer bars in Copenhagen, to collect the lists of what’s currently on tap in the bars in one place.

Leave a Comment


The month of march is ending, so it’s time for this month’s roundup of recommended reads. This month consists of 3 main topics: PHP, JavaScript and project management.

Even though I work a lot with PHP there’s always something new to learn. I’ve previously dived a bit into how Composer works. Earlier in the month my attention was called towards the Composer documentation, namely the part about autoloader optimization, which features hints on how to make the Composer autoloader work faster in your production environment.

I’m working a lot with JavaScript these days, especially with the Vue framework. A lot of stuff is currently happening in the JavaScript space, and I’m struggling to both get updated and keep at least partly on top about what’s going on in that space.

JavaScript ES6, aka. ECMAScript 2015 is the newest version of the ECMAScript standard and comes with a bunch of new features. Sitepoint has a nice article about 10 ES6 native features that you previously needed external libraries to get. They also have a quick rundown of 3 JavaScript libraries to keep your eyes on in 2017, including the before mentioned Vue.

“Awesome”-lists, curated lists of links somebody finds noteworthy, seems to be the big thing on Github these days. So much so that there is even awesome awesomeness meta listsa popping up. Any respectable (and all other) technology seems to have at least one dedicated awesome list, and of course, there is also an awesome Vue list.

When working with a Framework and a related template engine, there is usually a standard way of sharing data between the application and the frontend. But as the physical distance between the front- and the back-end of an application grows, with more functionality moving to the browser, sharing data gets a bit more complex. Jesse Schutt has a nice article about some different strategies for sharing data between Laravel and Vue applications, but despite the name, the strategies are applicable to any application where the back-end and front-end are separated and needs to share data.

On a less technology focused note PHPStan author Ondřej Mirtes wrote a nice article on How PHPStan got to 1000 stars on Github. Despite the rather click baitish title, the article has some really nice points on how to keep your focus on building, launching and growing an open source project and the community around it. Most of the points are very relevant in any development process, not only for open source projects, and they’re definitely worth being aware of.

On the same project building, I stumbled upon an article about the self-limiting habits of entrepreneurs, which is also worth a read for anybody trying to build a project, open source or otherwise.

Leave a Comment


February is coming to a close, and it’s time for a monthly round-up.

Even though February is the shortest month of the year I doubt it will be the least eventful. Especially the security scene has been on fire this month, and I doubt we’ve seen the final debris of this.

The month gave us two major security related findings from Google.

First, they announced the first practical way to create SHA-1 hash collisions, putting the final nail in the coffin for SHA-1 usage in any security relations.

Later in the month, Google’s security research team, Project Zero, announced how Cloudflare’s reverse proxies would, in certain cases return private data from memory, a bug which came to be known as Cloudbleed. The Google researchers worked with Cloudfare to stop the leak, but according to Cloudfare’s incident report, the issue had been open for a while.

On a slightly different note. Laravel is popular PHP framework. Articles online about the framework seems to be about equal amounts of hype, and belittlement. Earlier this month a critical analysis of Laravel were going its rounds in the Twittersphere. I believe it provides a nice description of the pros and cons of Laravel, without falling for neither the hype nor the hatred that is often displayed in framework discussions in general, and Laravel discussions in particular.

As a lead developer, I spend a lot of time thinking about and making decisions on software architecture. So it’s always nice with some inspiration and new ideas. Even though it’s a rather old article by now, I believe Uncle Bob has some nice points when discussion Screaming Architecture, when he points out that the architecture of a piece of software should make it obvious what the software does, rather than which framework it’s built upon.

Developers seem to find incredible performance gains when upgrading to PHP 7, all from Tumblr reporting more than 50% performance improvement to Badoo saving one million dollars per year in saved hosting and server costs. For the nerds out there, PHP core contributor Julien Pauli did a deep dive into the technical side of PHP 7’s performance improvement.

On the topic of performance, I found, a collection of open source performance testing/monitoring tools, that I’d like to look more into.

Want to know more about what’s going on in the PHP community? Here is a nice curated list of PHP podcasts.

Leave a Comment

Laravel file logging based on severity

Per default anything logged in a Laravel application will be logged to the file: storage/logs/laravel.log, this is fine for getting started, but as your application grows you might want something that’s a bit easier to work with.

Laravel comes with a couple of different loggers:

Everything it logged to the same file.
Everything is logged to the same file, but the file is rotated on a daily basis so you have a fresh file every day
Log to syslog, to allow the OS to handle the logging
Pass error handling to the web server

Having different handlers included provides some flexibility, but sometimes you need something more specific to your situation. Luckily Laravel has outsourced it’s logging needs to Monolog, which provides all the flexibility you could want.

In our case, logging to files was enough, but having all of our log entries in one file made it impossible to find anything. Monolog implements the Psr-3 specification which defines 8 severity levels, so we decided to split our logging into one dedicated file per severity level.

To add your own Monolog configuration, you just call Illuminate\Foundation\Application::configureMonologUsing() from your bootstrap/app.php.

To add a file destination for each severity level, we simply loop through all available severity levels and assign a StreamHandler to each level.

Simple as that.

Later we decided to also send all errors should also be sent to a Slack channel, so we could keep an eye on it, and react quickly if required. Luckily Monolog ships with a SlackHandler, so this is easy as well.

So with just a few registered handlers, we’ve tailored our error logging to a level that we feel suits our needs at the current time.

Notice how we only log to Slack when we’re not in debug mode, to filter out any errors thrown while developing.

Leave a Comment

HTTPS and HTTP/2 with letsencrypt on Debian and nginx


Most web servers today run HTTP/1.1, but HTTP2 support is growing. I’ve written more in-depth about the advantages of HTTP/2. Most browsers which support HTTP2 only supports it over encrypted HTTPS connections. In this article, I’ll go through setting up NGINX to serve pages over HTTPS and HTTP/2. I’ll also talk a bit about tightening your HTTPS setup, to prevent common exploits.


HTTPS security utilises public-key cryptography to provide end-to-end encryption and authentication to connections. The certificates are signed by a certificate authority, which can then verify that the certificate holder is who he claims to be.

Letsencrypt is a free and automated certificate authority who provides free certificate signing, which has historically been a costly affair.

Signing and renewing certificates from Letsencrypt is done using their certbot tool, this tool is available in most package managers which mean it’s easy to install. On Debian Jessie, just install the certbot like anything else from apt:

Using certbot you can start generating new signed certificates for the domains of your hosted websites:

For example

Letsencrypt certificates are valid for 90 days, after which they must be renewed by running

To automate this process, you can add this to your crontab, and make it run daily or weekly or whatever you prefer. In my setup it runs twice daily:

Note that Letsencrypt currently doesn’t support wildcard certificates, so if you’re serving your website from both and (you probably shouldn’t), you need to generate a certificate for each.


NGINX is a free open source asynchronous HTTP server and reverse proxy. It’s pretty easy to get up and running with Letsencrypt and HTTP/2, and it will be the focus of this guide.


To have NGINX serve encrypted date using our previously created Letsencrypt certificate we have to ask it to listen for HTTPS connections on port 443, and tell it where to find our certificates.

Open your site config, usually found in /etc/nginx/sites-available/<site>, here you’ll probably see that NGINX is currently listening for HTTP-connections on port 80:

So to start listening on port 443 as well, we just add another line:

The domain at the end would, of course, be the domain that your server is hosting.

Notice that we’ve added the ssl statement in there as well.

Next, we need to tell NGINX where to look for our new certificates, so it knows how to encrypt the data, we do this by adding

With the default Letsencrypt settings this would translate into something like:

And that’s really all there is to it.


Enabling HTTP/2 support in NGINX is even easier, just add an http2 statement to each listen line in your site config. So:

Turns into:

Now test out your new, slightly more secure, setup:

If all tests pass, restart NGINX to publish your changes.

Now your website should also be available using the https:// scheme… unless the port is blocked in your firewall (that could happen to anybody). If your browser supports HTTP2, your website should also be served over this new protocol.

Improving HTTPS security

With the current setup, we’re running over HTTPS, which is a good start, but a lot of exploits have been discovered in various parts of the implementation, so there are a few more things we can do to harden the security. We do this by adding some additional settings to our NGINX site config.

Firstly, old versions of TLS is insecure, so we should force the server to not revert:

If you need to support older browsers like IE10, you need to turn on older versions of TLS;

This in effect only turns off SSL encryption, it’s not optimal, but sometimes you need to strike a balance, and it’s better than the NGINX default settings. You can see which browsers supports which TLS versions on caniuse.

When establishing a connection over HTTPS the server and the client negotiates which encryption cypher to use. This has been exploited in some cases, like in the BEAST exploit. To lessen the risks, we disable certain old insecure ciphers:

Normally HTTPS certificates are verified by the client contacting the certificate authority. We can turn this up a bit by having the server download the authority’s response, and supply it to the client together with the certificate. This saves the client the roundtrip to the certificate authority, speeding up the process. This is called OCSP stapling and is easily enabled in NGINX:

Enabling HTTPS is all well and good, but if a man-in-the-middle (MitM) attack actually occurs, the perpetrator can decrypt the connection from the server, and relay it to the client over an unencrypted connection. This can’t really be prevented, but it is possible to instruct the client that it should only accept encrypted connections from the domain; this will mitigate the problem anytime the clients visits the domain after the first time. This is called Strict Transport Security:

BE CAREFUL! with adding this last setting, since it will prevent clients from connecting to your site for one full year if you decide to turn off HTTPS or have an error in your setup that causes HTTPS to fail.

Again, we test our setup:

If all tests pass, restart NGINX to publish your changes (again, consider if you’re actually ready to enable Strict Transport Security).

Now, to test the setup. First we run an SSL test, to test the security of our protocol and cipher choices, the changes mentioned here improved this domain to an A+ grade.

We can also check our HTTPS header security. Since I still havn’t set up Content Security Policies and HTTP Public Key Pinning I’m sadly stuck down on a B grade, leaving room for improvement.

Further reading

Leave a Comment