Skip to content →

Category: PHP

June-2017.php

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 symfony.com frontend was refactored. This provided a lot of useful insights that was documented in a post on refactoring the symfony.com 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

May-2017.php

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 packagist.org. 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-2017.php

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

March-2017.php

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-2017.php

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 Sitespeed.io, 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:

single
Everything it logged to the same file.
daily
Everything is logged to the same file, but the file is rotated on a daily basis so you have a fresh file every day
syslog
Log to syslog, to allow the OS to handle the logging
errorlog
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

Lazy loading, eager loading and the n+1 problem

In this article I’ll look into a few data loading strategies, namely:

I’ll talk a bit about the pros and cons of each strategy, and common issues developers might run into. Especially the n+1 problem, and how to mitigate it.

The examples in the post are written using PHP and Laravel syntax, but the idea is the same for any language.

Lazy Loading

The first loading strategy is probably the most basic one. Lazy loading means postponing loading data until the time where you actually need it.

Lazy loading has the advantage that you will only load the data you actually need.

The n+1 problem

The problem is with lazy loading is what is known as the n+1 problem. Because the data is loaded for each user independently, n+1 database queries is required, where n is the number of users. If you only have a few users this will likely not be a problem, but this means that performance will degrade quickly when the number of users grows.

Eager Loading

In the eager loading strategy, data loading is moved to an earlier part of the code.

This will solve the n+1 problem. Since all data is fetched using a single query, the number of queries is independent of the number of items fetched.

One problem with eager loading is that you might end up loading more data than you actually need.

Often data is fetched in a controller and used in a view, in this case, the two will become very tightly coupled, and every time the data requirements of the view changes, the controller needs to change as well requiring maintenance in several different places.

Lazy-eager loading

The lazy-eager loading combines both of the strategies above; loading of data is postponed until it is required, but it is still being prepared beforehand. Let’s see an example.

As usual, a simple example like this only shows part of the story, but the $users list would usually be loaded in a controller, away from the iterator.

In this case, we’re keeping related code close together which means you’ll likely have fewer places to go to handle maintenance, but since the data is often required in templates we might be introducing logic into our templates giving the template more responsibilities. This can both make maintenance and performance testing harder.

Which strategy to choose?

This article has introduced three different data loading strategies, namely; lazy loading, eager loading and lazy-eager loading.

I’ve tried to outline som pros and cons of each strategy, as well as some of the issues related to each of them.

Which strategy to choose depends on the problem you’re trying to solve, since each strategy might make sense in their own cases.

As with most other problems I’d usually start by implementing whichever strategy is simplest and fastest to implement, to create a PoC of a solution to my problem. Afterwards I’d go through a range of performance tests, to see where the bottlenecks in my solution appears, and then look into which alternate strategy will solve that bottleneck.

Leave a Comment

PHP regular expression functions causing segmentation fault

We recently had an issue where generating large exports for users to download would suddenly just stop for no apparent reason. Because of the size of the exports the first thought was that the process would time out, but the server didn’t return a timeout error to the browser, and the process didn’t really run for long enough to hit the time limit set on the server.

Looking through the Laravel and Apache vhost logs where the errors would normally be logged didn’t provide any hints as to what the issue was. Nothing was logged. After some more digging I found out that I could provoke an error in the general Apache log file.

It wasn’t a lot to go on, but at least I had a reproducible error message. A segmentation fault (or segfault) means that a process tries to access a memory location that it isn’t allowed to access, and for that reason it’s killed by the operating system.

After following along the code to try to identify when the segfault actually happened, I concluded it was caused by a call too preg_match().

Finally I had something concrete to start debugging (aka Googling) for, and I finally found out which Stackoverflow question contained the answer.

In short the problem happens because the preg_* functions in PHP builds upon the PCRE library. In PCRE certain regular expressions are matched by using a lot of recursive calls, which uses up a lot of stack space. It is possible to set a limit on the amount of recursions allowed, but in PHP this limit defaults to 100.000 which is more than fits in the stack. Setting a more realistic limit for pcre.recursion_limit as suggested in the Stackoverflow thread solved my current issue, and if the limit should prove to be too low for my system’s requirements, at least I will now get a proper error message to work from.

The Stackoverflow answer contains a more in-depth about the problem, the solution and other related issues. Definitely worth a read.

Leave a Comment

OOP Cheatsheet

This is a small OOP (Object oriented programming) cheatsheet, to give a quick introduction to some of the commonly used OOP terminology.

Line Concept Definition
1 Function A function is defined in the global namespace and can be called from anywhere.
2 Variable The variable is enclosed in the function definition, so it can only be used by that function.
4 Variable access Here the value contained in the variable is accessed.
7 Function call This executes the function.
9 Class definition A class is a blueprint that you can generate objects from. All new objects based on a class will start out with everything that has been defined in the class definition.
10 Property A property is like a variable, but is accessible from the entire object it is defined in. Objects can have different visibilities.
12 Method A method is a function defined inside a class. It is always accessible to all objects of the class, and depending on it’s visibility it might, or might not, be accessible from outside the class.
13 Property usage An object can reach it’s own properties using the $this-> syntax.
17 Object instantiation This is an object is created based on a class definition.
19 Method call The method Something::returnSomethingElse() is called on the newly created object. The method has it’s visibility set to “public”, hence it can be called from outside the object itself.
21 Property access This is how the property Something::$somethingElse is accessed from outside the object. But in this case the property has the visibility protected which means it can’t be accessed from outside the object itself, hence this will cause PHP to fail.
Leave a Comment

Wrapping up Laracon EU 2016

Last week I spend some days in Amsterdam attending Laracon EU 2016. It was two very interesting days, and I think the general level of the talks was very high compared to other conferences I’ve attended. The location and the catering was also really good, and I was impressed with how smooth it all seemed to go, at least for us as participants. Good job!

Here I’ve tried to gather up some of my notes from the talks I saw. It’s mainly meant to serve as my personal notes, but I also try to give some recommendations as to which talks are worth watching when the videos are released.

The event can be found at joind.in. The videos havn’t been released yet, but you can find the Laracon US videos.

Taylor Otwell – Keynote / Laravel 5.3

Taylor continued his Laracon US keynote, and highlighted some of the other new features Laravel 5.3 will bring.

The emphasis on his talk was on:

  • Echo – Which makes it easy to provide real-time push notifications to online users of your app, for example straight to the website, or through notifications on your phone. One major advantage in this update is the easy of setting up private notification channels.
  • Notifications – An easier interface for pushing user notifications to various service like Slack and email. The interface makes it easy to create integrations to new services.

Hannes van de Vreken – IoC Container Beyond Constructor Injection

Hannes did an interesting talk on IoC containers. The first part of the talk was a general introduction to dependency injection and IoC containers and the purpose of both concepts. Afterwards he dove into some more advances subjects like contextually binding interfaces to implementations and container events which can be used to lazy load services or changing the settings of a service before injection.

He also talked about lazy loading services by using method injection and using closures for lazy loading services, not only when the requiring service is instantiated, but all the way to the point where the injected service is actually being used, like it’s done in Illuminate\Events\Dispatcher::setQueueResolver().

The talk definitely gave me some takeaways I want to look more into.

Mitchell van Wijngaarden – The past is the future

Mitchell did a talk on event sourcing, a topic I had only recently heard about for the first time. It was an interesting talk with a lot of bad jokes and puns to keep you awake (or whatever the purpose was) which gave a nice introduction to the subject, how it could be utilized and some of the pros of using it.

I think event sourcing is a pretty interesting concept, and I’d like to see it used in a larger project to see how it holds up. To me it sounds like overkill in many situations, but I’ve definitely done projects where knowing about it would have helped simplify both the architecture and the logic a great deal.

An interesting talk for developers working with transaction-based domains or who just wants some new inspiration.

Lily Dart – No excuses user research

Lily talked about the importance of user research and the importance of knowing what your users actually want, instead of just guessing. It would have been nice with some actual examples of projects where it had been used, how and the results of the research, but I’m already pretty convinced that data as proof is better than anyones best guess so this talk only served to make this belief stronger.

She provided some easy ways to start collection data about your customers wants and behaviour that I think could be interesting to look into:

  • Bug reports – Bug reports contain a wealth of knowledge about what your users are struggling with. Often we as developers can have a tendency to push aside reports, big or small, as simply being because the user didn’t understand how something works, but this is often caused by usability issues in the system they’re using. Lily suggested started tagging all bug reports, to provide an overview of which parts of your system that maybe should be easier to understand.
  • Transactional audits – Transactional audits are the small feedback forms we sometimes meet after completing a transaction. Many help systems, for instance, include a small form at the bottom of each help section asking the simple question “Did this page answer your question?”, where if we answer no, we’re asked what was missing, or what we were actually looking for.
  • Search logs – If your website has a search engine, logging all searches can also provide some interesting knowledge, both about what your users actually want to know more about, but also about what they are struggling to find out more about. This can give you an idea about things like features that are hard for the user to understand, or issues in your site architecture that makes it hard to find certain information in your website, or maybe even tell you more about what subjects people would like your website to expand more about.

A really interesting talk I’d recommend to anyone working with websites (developers, marketing, managers etc).

Evan You – Modern frontend development with vue.js

Evan gave an introduction to the vuejs framework, where it came from and some of the architecture decisions it’s based on. It was a very theoretical talk that provided some good background knowledge, but I had hoped for a more hands-on approach, and some more code, but I believe he did that at his Laracon US talk so I should probably watch that as well. Even so the talk still provided some good insights that I’m sure will help me when I’ll start looking into using Vue, which will hopefully happen soon.

It was an interesting talk if you’d like some background for Vue and it’s structure, but if you just want to learn how to get started using it, there’s probably better talks out there, like the ones from Laracon US.

Matthias Noback – Please understand me

Matthias gave a talk to remind us all that working as a developer isn’t only about developing software. On the personal side it’s important to work in a place where you feel appreciated and respected, and that you have access to the tools you need to do your work.

On the other hand you also need to do your part to make the job meaningful. Try to figure out who the customers are, and what they think about and want. Knowing who you’re doing the job for, and why they need it, will help you understand what actually needs to be done, and will help you make better decisions about your product. In the same way it’s useful to get to know your manager, that will make communication easier when the deadlines draw closer.

If you really want to be taken serious you also need to take yourself and your job serious. Take responsibility for your job. Show up, set deadlines and meet them, and deliver high quality work. Take your colleagues, managers and customers seriously, don’t be a ‘developer on a throne’.

There was nothing particularly new in the talk, but I believe it serves as a good reminder of some things that many either ignore or take for granted. A good talk to watch for any developer or people managing developers.

Abed Halawi – The lucid architecture for buiding scalable applications

Abed talked about what he described as lucid architecture and the general thoughts about the problem him and his team were building. He described an architecture as a an expression of a view point that is used to communicate structure and should hopefully help eradicate homeless code by providing every piece of code with one obvious unquestionable place to reside.

The requirements for Abed’s team’s architecture was that it should kill legacy code, define terminology, be comprehensive without limitations, complement their framework’s design and perform at scale.

The lucid architecture consists of 3 parts

  • Features – Each feature fulfills one business requirement. Features are grouped into domains, and a feature works by running a range of jobs in order. CreateArticleFeature could be a feature name.
  • Jobs – Each job handles one step required to fulfill a feature ie. validation. SaveArticleJob could be a job name. Each job can be used by several different features.
  • Service – A service is a collection of features. Features are net reused between services. The website service and the API service would each have their own CreateArticleFeature. Jobs can be reused, though.

In lucid architecture controllers are VERY slim, each controller serves one feature, and does nothing else, everything from validation to domain object creation/updating and response preparation are handled by different jobs launched by the feature.

I found the idea pretty interesting, especially since it removes some of the overlap of different concepts by providing a specific use case for each domain level. I also like how all logic is handled in specific and clearly separated jobs making it easy to move jobs to queues if necessary. It looks a bit like the direction that we’re currently taking our code base at my job, though we’re not quite so radical in our approach.

An interesting talk to watch if you want some new inspiration regarding architecture.

Gabriela D’Avila

Gabriela talked about some of the changes coming to MySQL in version 5.7. A lot of the talk went a bit over my head since I’m not a database specialist, but it was interesting and gave some good pointers for things to look more into.

MySQL 5.7 enables the NO_ZERO_DATE option by default, which might have implications for our application since we actually use zero dates.

MySQL has a concept of virtual columns, that can calculate values based on the value of other columns, like concatenating a first_name and a last_name column into a full_name. Iirc it can also get attribute values from the new JSON type columns, which would be pretty cool.

Jeroen V.D. Gulik – How to effectively grow a development team

Jeroen gave a talk about developer culture in teams, and how he had built his developer team at Schiphol airport. He talked a lot about what culture is, what developer culture is and how to foster a positive culture, and how that culture is related to developer happiness. He had a lot of good points, too many to note here, and I’d recommend anyone interested in company culture to watch this talk, it’s relevant to anyone from developers through developer managers to higher level managers in technology focused companies.

Adam Wathan – Curing the common loop

The last talk I saw was Adam Wathan’s talk about using loops when programming, versus using higher order functions, which is functions that takes other functions as parameters and/or returns functions. The base of the talk was the 3 things Adam claims to hate:

  • Loops
  • Conditionals
  • Temporary variables

I can see the point about the code getting a lot more readable and I like how the approach requires a radically different thought process compared to how I’d normally do things, I’d definitely recommend any developer to watch this talk.

Leave a Comment