Hannes Van De Vreken

Switching companies

Thu, 14 Sep 2017 00:00:00 +0000

After precisely 3 years (since 8 September 2014) at madewithlove, I’ve decided it was time to move on. A little while ago, I agreed to join the team at Stream as a PHP Software Engineer and Developer Advocate. Next Monday I will join them in their office in TQ in Amsterdam.

My task will be to represent them, and the product, in the PHP community. Many people know Algolia, Sendgrid, Twilio, etc. and soon Stream will be as well known as those names. I’ll be creating demo applications, tutorials and workshops in PHP. Also I’ll be a point of contact (account manager if you will) for customers doing integrations with our product in PHP applications. Next to that I will keep doing my best to create PHP related talks, that help other people learn new things.

I’m really looking forward to this new chapter and I’d like to thank my colleagues at madewithlove for the epic ride! Keep rocking.

On PSR-7 middlewares

Wed, 01 Jun 2016 00:00:00 +0000

PSR-7 got released May 4, 2015. There is a discussion about middlewares based on PSR-7 messages, and it is awfully overdue. The most common middlewares in use since June 2015 are callables with this interface:

They just work. I’ve been using them since June 2015. You can stack a number of middlewares with tools like relay/relay or mindplay/middleman. I prefer the latter because it plays well with container-interop containers to resolve middlewares when you need them.

Granted, you can use them wrong by fiddling with the Response before passing it on to the next middleware. Just don’t do that. But I’d rather educate newbies than to remodel the whole thing and to make it overly complex. I’ve been giving this PSR-7 talk for 12! months now. Please just spread the word and stop discussing something that has been in use for over a year now.

Thanks.

PSR-7 middlewares discussion links:

Some links might be missing here. Feel free to send a PR.

Airbnb tricks

Wed, 24 Feb 2016 00:00:00 +0000

Hi there! It’s been a while since my last blog post. Sorry for that. Let’s break the silence with a post on travelling with Airbnb.

I like visiting cities, both for work (conferences) and pleasure. Hotels are often quite expensive in cities, and the value you get from them is often disappointing. Over the past few years I’ve been using Airbnb a lot, so that I can stay in a calming environment, away from the hustle from the city and hotel personnel.

An Airbnb can be anything. It can be a castle or a villa for 16 people. Or as small as a private room with a bed from wall to wall in a 3 bedroom student apartment. I’ve been there, I’ve done that.

Building trust

All places on Airbnb are made available by their owners. Every time a stranger contacts an owner (host) to rent a place, the owner can decide whether they trust a stranger to use their property or not. Owners rent their places for a price per night, a handling fee for Airbnb, and optionally a cleaning fee.

After staying at a place, both hosts and guests get to post a review about each other. If both the host and you (as a guest) send in a review, the host’s review of you will become visible on your profile and vice versa. Future hosts read these reviews as part of their decision process to host you or not. It is thus very important to be kind, stick to the house rules of the owner, and leave the place as clean as you found it. Don’t leave trails of dirt, trash or dirty dishes. It’s obvious that if you’re paying a cleaning fee, you don’t have to wipe the floor. General rule: use common sense, show some empathy with the owner. How would you like to find your place after it has been used by strangers?

Host yourself

Obviously when you host yourself you will learn about the logistics, communication and emotions that come with letting strangers inside your home or property. This is valuable when dealing with other hosts.

I haven’t hosted people myself. I live in a fancy, well located, 2 bedroom apartment with my girlfriend. If it were up to me we’d have guests over regularly, but when you are in a relationship you decide these sorts of things together. Sorry to all the Airbnb guests that I have let down ;-)

Contact host beforehand

On Airbnb, on every page to view a place, there is a button that says “contact host”. Use it. I get in touch with hosts before sending a booking request with my credit card details. I do this to send a little introduction about myself, and the reason why I am looking to rent their place. Don’t tell your bad habits or your life story. Just the information they need. For example: I’m a passionate runner since 2014 and I’m planning on making a weekend trip to Valencia to run the Valencia marathon with X friends from day Y till day Z.

The second reason I contact hosts without a booking request is because hosts have the option to send special offers. After one or two messages I usually ask hosts if they want to make me an offer for a cheaper price. Sometimes they do if you’re trustworthy, if you book well in advance, and even better: if the owner can relate to you because you have something in common. You’re essentially bargaining. A common sentence to use is: “I’ve seen this cheaper place nearby (include link). I’m having doubts if I should book that place or yours. If the price would be the same I would book today.” One time I got the price for a seaside villa in Valencia for 6 nights down from 3500 euro to 2000!

It’s still people you’re dealing with, so if they don’t buy it: stay friendly, be honest and don’t waste their time.

If you’re looking for a place for 2 weeks or longer you can ask to only book the first week via Airbnb with an option to stay longer. After one week the trust level between host and guest should be high enough to decide on a fixed price for the rest of the stay without going through Airbnb. Be careful though. Airbnb offers refunds, insurance to the owner that the host can pay the amount, and other legal stuff. If you’re going to shortcut Airbnb, all responsibility is on you, both the host and the guest.

Getting there

A few days in advance I usually text the host to let him/her know when I’ll arrive. This is to make sure the host is still alive and aware you’re coming over. If the owner responds quickly, you know you can reach him/her when you’re in an emergency situation. When you arrive you can pick up the key, get to know the host and start navigating around the city. Make sure your phone has an internet connection and a fully charged battery and you’ll be good.

Book your own AirBnb place

If you want to try AirBnb for one of your upcoming trips, get 30 euro off of your first booking.

That’s it. Happy travelling!

PS: This was a blog post on travelling. It is not my intention to start making this a travel blog. Though, we’ll see where this goes.

NYC marathon preparation started

Mon, 20 Jul 2015 00:00:00 +0000

Hi all! Here’s an update on my latest leisure time activities.

In April this year I ran my very first marathon: the Rotterdam marathon.

3:29:21 #mr15. The crowd was amazing! #marathon #rotterdam

Een foto die is geplaatst door Hannes Van De Vreken (@hannesvdvreken) op 12 Apr 2015 om 11:15 PDT

It was until that day (12th of April) that I kept telling others and myself that this was a one time thing. Though, after the race I was so happy with my result, that I just stopped saying whether or not I would do it again. Some time was needed to reflect on my result, wether I wanted to go faster, wether I could push my body even further, and whether I could afford the time needed to improve.

After my first marathon

Four days after the Rotterdam marathon I was able to run (painless) again. The weeks after that I ran a lot: 6 or 7 times a week. No fast running, no workouts, no more than 20 km per day, no more than 150 beats per minute heart rate. In the mean time I talked to a few people on marathon running, ultramarathon running (42+ km) and trail running. The more I talked to people, the more I wanted to have a goal again. So I started to assemble a calendar of all kinds of races that will take place in late 2015.

Picking a race

On May 28th I registered for, not one, but two marathons. I applied with a good cause initiative which had 50 bib numbers for the TCS New York City marathon. I believed my odds were little, so I didn’t wait for this.

A few people told me the Eindhoven marathon is a great race, has good atmosphere, and it’s just a short drive by car. It’s a great race to run, so I registered for this one as well.

On June 23th I received an email I didn’t expect to receive.

It's official now: I will run the @nycmarathon on the first of November! 🗽 #tcsnycmarathon

Een foto die is geplaatst door Hannes Van De Vreken (@hannesvdvreken) op 23 Jun 2015 om 3:19 PDT

Yes, that’s right! I got into the TCS New York City marathon! This means I will raise money for a good cause (more about that later). I already planned every training for the next 16 weeks leading up to the race. My goal is to run the marathon in less than 3 hours, which is 29 minutes faster than my last one. This might be too optimistic, but I feel very strong already after the first week of training. If I don’t make it, I would be happy with anything faster than 3 hours and 10 minutes still.

On the good cause

The initiative I will be raising money for is called Mediclowns. Mediclowns is an organisation of about 10 artists who brighten up ill children. They visit children that stay home months on end, waiting to see if the treatments they receive have a positive effect on their horrible illnesses. I really admire people that are so strong and positive that can even entertain even the sickest and weakest. People living in Belgium might recognise the name Cliniclowns. Mediclowns is similar, with the big difference that they do home visits.

The money I will raise will all go to Mediclowns, who will pay for my entire 5 day trip to New York. In Belgium you (as a tax payer) can deduct gifts from your taxes, and as a business the amount is 100% deductible from your revenue. Please, if this sounds appealing to you, or you can connect me to a company to which this might sound appealing, let me know and we’ll talk more on the details. Every single backer will get a personal souvenir, a thank you letter and a mention in a future blog post. It may not be worth much, but it’s a gesture of gratitude ;)

The fund raising page is on gofundme.com/tcsnycmarathon.

</embed>

Take care!

Displaying stream progress in PHP

Tue, 12 May 2015 00:00:00 +0000

With PHP you can, next to handling HTTP requests, invoke scripts from the command line. For a typical web application this could be used to run database migrations, insert data into the database from fixtures or seeders, repetitive tasks run by cron, clear the cache (cache:clear), general admin stuff… basically anything that can be automated.

The Symfony console component is a very useful tool to define and invoke these kind of CLI tasks. You can view the console application as the command line alternative of your index.php front controller and request/response objects for HTTP requests. It handles calling the right commands, parsing and validating arguments and options, displaying usage help, … All you need to do is to create a Command class per task and define its name, description, arguments and options.

You command’s execute method will be called using an InputInterface object and an OutputInterface object. The $input object can be used to retrieve the arguments and options required to run the specific task. The $output object is used for displaying what the task is doing or has done. What is actually printed on the console is very important for the issuer of the task. Think of it as the command’s usability. Too little runtime information, the less usable the task.

Opposite to HTTP requests, tasks run from the command line aren’t supposed to return instantly. They can take a very long time. Imagine a task that loops an entire database table or a task that references an external source repetitively, or maybe a taks that performs a large file transfer. It’s very important to show the issuer what is actually going on, or he/she will be left in the dark for minutes/hours. “Is this task still running?”, “How long has this thing been running yet?”, “Is it almost done?”, “Is it running out of memory?”

Enter the ProgressBar. The ProgressBar is an output helper that wraps the OutputInterface object. Initiate a ProgressBar object with the OutputInterface object, and a number that represents the maximum iterations to be executed, for example number of table rows, number of bytes to be transferred, … For example, do a quick count query first on your database to check the amount of rows that will need to be iterated over. Then while iterating call the ProgressBar::advance or ProgressBar::setProgress method to indicate progress.

15214/455642 [=========>------------------]  33%  21 sec/58 sec  2.1 MB

When you call any Symfony console application you can indicate the verbosity you want from the output (use -vvv option). When adding 3 v’s the ProgressBar will also display the elapsed time, the estimated time left and the memory the process is currently consuming.

When transferring a file it’s a bit harder to show the progress of the transfer, but possible. When opening resources (also called “streams”) in PHP one can add a “stream context”. The context defines options and parameters. One parameter is the optional stream_notification_callback.

A resource can be a FTP, SFTP, HTTP, HTTPS source, or anything else that can be streamed over TCP sockets.

The notification callback will be called to notify you of certain events. See of it as an event dispatching mechanism with a single callable event listener. For example: one can get notified how many bytes are available on the readable stream. After every chunk of data transfer the callback is called with the number of bytes that have been transferred up till then. Also a “completed” event, and several other events are responsible of the callable being called during the lifetime of a resource.

An example of how to use the stream_notification_callback:

There are a few caveats though…

First: stream contexts must be created before the resource is opened. This means one cannot use the notification callback for existing resources.

That is why in the previous example I only used Flysystem to write the stream to a file, but not to initiate the read stream. FilesystemInterface::readStream returns a resoure but it doesn’t allow you to set a stream context. By the way, some Flysystem adapters implement the readStream in a slightly inexpected way. To comply with the interface, the FTP adapter and the Dropbox adapter readStream methods need to return a resource. They don’t have a native way to open a stream and return that, so they need to read the entire source file content and append it to the php://temp (in memory) stream. Then the memory stream is rewound, so it is ready to read, and ultimately returned.

Second caveat: using resources and a notification callback doesn’t mean the transfer is asynchronous. To create truly asynchronous transfers I would recommend taking a look at ReactPHP.

Finally the true benefits of resources and the notification callback are:

Large files aren’t stored in memory while transferring. Only buffered chunks are kept in memory. To give an example: I managed to transfer an entire Ubuntu iso file over HTTP to the local file system while the process was using merely 2.2MB of memory. And last but not least: the issuer of the taks sees how the task is progressing. This greatly improves the usability of the task.

Happy streaming!

How clean is your code? How clean are your diffs?

Fri, 08 May 2015 00:00:00 +0000

Note: this is a repost from my post on the madewithlove blog.

My previous blog post covered tips on code style fixing while working on legacy projects. The blog post was very generic and the ideas are applicable on projects in any language. I mentioned some tips that help your peer developers review your pull requests. What I didn’t mention are code style standards and code style details.

In this blog post I would like to share some thoughts on code style details for cleaner diffs.

Diffs

Cleaner diffs make it easier for your peer developers to review code changes. When your peers don’t get distracted by awkward diff lines you can expect a more thoughtful review, less overlooked bugs, and more honest feedback. Here are a couple of code style tips that allow for cleaner diffs.

Tip 1: Add as many trailing commas as possible!

When you’re appending new lines to a list, you might need to add a comma to the previous last item in order to comply with the syntax. Some languages allow to append a comma to the last line without throwing syntax errors.

This first example has a clean diff when you’re appending a new item to the array initialisation: watch the clean diffs

This second example is less clean: watch the harder diffs

Is it not possible to add a comma to the last item of a block/array/… because of syntax limitations? You can sometimes avoid appending to the back of the list by ordering the list items. That way you’ll mostly insert items in the middle and not at the end. Are you a Composer user? It’s actually a bad practise to touch your composer.json file.

Therefore, use a special flag to have Composer sort your items for you: composer require monolog/monolog --sort-packages.

Tip 2: Don’t align assignments

Don’t align things like consecutive assignments (aligning equal signs) or list definitions (aligning arrows or semicolons). When the longest line changes in length, or when a new longer line is added, you will need to adjust the other lines by adding or removing spaces, resulting in larger diffs. If you didn’t align them, it’s more clear on what has been changed or added.

Consecutive variable assignments:

watch the clean diffs watch the harder diffs

List/array assignments:

watch the clean diffs watch the harder diffs

This is just a suggestion, though. People like to align assignments for various reasons. Because it’s pretty, or because it’s visually easier to scan a file. If you like the benefits of aligning over the downside of the heavier diffs, go ahead: align.

Tip 3: use as many braces as possible

It’s sometimes possible to leave off certain braces. For example: calling a constructor in PHP when passing zero arguments is possible without braces $client = new GuzzleHttp\Client; but when you need to change that and need to pass one or more arguments to the constructor, you’ll still need to add the braces. You might notice I’m nitpicking here, this doesn’t actually result in super ugly diffs. But what about when you delete the last argument of a constructor? Do you delete the braces from every existing constructor call? If not, you’ll end up with inconsistent notation.

Often language syntax allows you to use control structures (if, for, while, …) without braces as well: they just use the single next line as the code block to execute conditionally, if no braces are used. Apart from the risk of bugs this also results in harder diffs when you add lines, or inconsistencies when you remove lines but don’t remove the braces.

Tip 4: have clear rules on whitespace

Have your editor and code style tool be clear on whitespace: where to have how many invisible characters (spaces, tabs, new lines). EditorConfig is an editor independent config file that can help you with that. In PHP we like to remove trailing whitespace at the end of a line, and empty lines must be completely empty. We also like to have a single empty line at the end of every .php file.

When a diff contains whitespace changes one can often ignore those lines. Use git diff -bw (short for git diff --ignore-space-change --ignore-all-space) or add ?w=0 in the address bar when viewing a diff on GitHub.

PHP CS fixer

At madewithlove we like to follow industry standards. This includes code style standards. For PHP that means PSR-2, and the stricter Symfony coding standards.

The tool we use most for automated code style fixing is php-cs-fixer, currently maintained by the GitHub organisation FriendsOfPHP.

The php-cs-fixer tool has some options to guard some of the tips mentioned in this post previously.

The multiline_array_trailing_comma fixer can be used to append commas everywhere, but is never enabled by default.
The new_with_braces fixer is not enabled on the PSR-2 level, but it is on the Symfony level.
The phpdoc_params is included in the Symfony level, it aligns docblock items so I like to disable it instead.
The align_double_arrow and align_equals options are available, but I rather leave them off.

Of course, these aren’t golden rules. I just have my reasons to enable or disable them. Define the rules you like for your projects and make sure to run the code style fixer regularly. For example before every commit, when your code base already adheres to all those rules, or after every commit on the files that have been changes, to slowly move to a cleaner code base.

Happy CS fixing!

Improving code style when working on a legacy code base

Mon, 27 Apr 2015 00:00:00 +0000

Note: this is a repost from my post on the madewithlove blog.

Legacy projects

Old projects (maybe even 6 months or less) often come without test suites, are tightly coupled with an outdated version of a framework (if not: has lots of boilerplate code), and are written without consistency in code style.

When working on such a project, it’s tempting to start moving brackets around, replacing old syntax style with newer language version syntax, and renaming variables/classes/functions. Especially when you’re refactoring or adding a feature.

With this blog post I wanted to share some tips and pitfalls on code style changes in legacy projects.

Code style

First of all: fixing code style isn’t necessarily a bad thing. Code style makes code more readable, less personal, and more uniform. As long as there is some kind of agreement that you will be working on this project for at least the next few months, your future self and colleagues might benefit from a better code style.

How to improve code style

Do not change code style in files or functions when you’re not required to change the code at all. This confuses your peer developers that need to review your changes.
Feel free to adjust docblocks if they are missing or plain wrong and add documentation where needed.
When you’re about to adjust a method, always –always– commit code style changes separately from code changes, even if the changed code produces the exact same output and behaves exactly the same. Peer developers that need to review your code can review your pull requests without having to investigate what has changed, and what is just an adjustment of code style. They can review individual commits and ignore commits with “CS” in the commit message.

CS fixing tools

You might be tempted to use an automated tool to reformat an entire file, or even your entire code base. Here’s why that’s not a good idea:

You lose all line history. Imagine backtracking why a certain line has been changed in the past when every line has been changed in the same commit, maybe just because of a tabs to spaces conversion.
All existing open pull request will need to be updated to base off of the newly formatted code

It is a good idea to setup a CS fixer for newly created files though. You can gradually build up a namespace full of new classes that adhere to a certain code style standard and have it backed by an automated tool.

While refactoring you can slim down existing classes and functions and inject new, well tested dependencies. That way you can slowly move away from the legacy code that’s still badly formatted.

If you do want to reformat an entire directory of code, despite my advise, make sure to have as few branches and open pull requests as possible. Ideally: no pull request and only one branch. Then do a single commit where you only reformat the code, nothing else. Push it, and done!

Happy CS fixing!

Running my very first marathon

Mon, 13 Apr 2015 00:00:00 +0000

Start to run

In june 2014 I started running because I had secured a speaker slot at the community day of Laracon EU. For my presentation I wanted to look fit on stage. To gain confidence I wanted to drop a few kilograms of weight. I started with a 9 km run and gradually ran further and further.

In august I had been able to run a 1/2 marathon in one hour and fifty minutes, a week before the conference. The conference happened and I was pretty happy with my performance on stage.

After that I kept running 1/2 marathons for training but I could only improve my time by 5 minutes. Every time I ran I was completely exhausted and my times weren’t improving. I bought a heart rate monitor on low energy bluetooth and found out I was running at max heart rate. This alarmed me.

Physical tests

In November I went to see physiologists in the university hospital. They tested my endurance by measuring oxygen intake, heart rate monitoring and taking blood samples.

Preparing for a marathon

After those tests I got a 16 week training shedule to lower my heart rate and got some nutrition tips. I also researched about exercises, training schedules, physiology and nutrition on the internet afterwards. And so I started to run 4 sessions a week. Next to running I started climbing again, one time a week, to build upper core muscles. If you would do cardio training only you would burn all your unused muscles and become a walking skeleton, but with strong legs.

When I saw good progress I decided to register for the Rotterdam Marathon. It’s a big event with good atmosphere and other runners seemded to love it. Rotterdam was a city I’ve never visited and it’s only 80 minutes driving by car. 16 weeks of training turned into 24 weeks of training, because I started training before I knew which marathon I would run and how many weeks I had left.

I kept running 4 sessions per week during the winter and only took a break for one week to go skiing. I ran multiple sessions of 2.5 hours and 3 hours, with a maximum of one long running session per week. My last training sessions showed me I was capable of running an average pace of sub 5:00 per kilometer for a duration of 3 hours. I was pretty confident I could run a marathon in 3 hours 30 minutes, or less than 3 hours 40 minutes if I wouldn’t be able to keep up the speed till the end.

Race day

April 12th, the day of the marathon came. My girlfriend and her younger sister joined me to Rotterdam. 40 minutes ahead of the race I was ready for departure in wave 1, block E. The sun was behind some tall buildings and the block was pretty crowded for the last 30 minutes before the race, so my muscles weren’t warm at all. I was also in a block of slower runners because 20 weeks ago, when I registered, I didn’t know I would be a 3:30:00 runner rather than a 4:00:00 runner.

The first 5 km were hard because my legs weren’t warmed up. I had to overtake lots of slower runners in order to not lose too much time. I was acidified after 2 kilometers and had to gently slow down for the next few kilometers to recover. After 10 km I was about 45 seconds behind schedule but I had completely recovered from the start and started to increase my pace again. I only noticed this when we passed the half way point but I had been running behind the same couple since the 10 km mark. They had the perfect pace for me! I planned to be about one or two minutes behind schedule at 21 km. I ended up being only 46 seconds behind schedule. I executed the first half according to plan because I kept calm.

Second half of the race

After the half way point the couple ahead of me started to increase their pace by 5-10 seconds per km, which was my game plan as well, so I kept chasing them. At the 30 km mark they slowed down for drinks, which they did every 5 km. I overtook them, thinking they would keep up with me, but I never saw them again. At 34 km at the side of the track people were handing out capsules of gel (high energy sweet sirup) which I ate together with a cup of water at 35 km. This way I was able to give my body some extra fuel for the last 7 km. The last 7 km I noticed a lot of people started to slow down, even walk. I managed to keep my pace till the very last kilometer, thanks to the Dutch crowd cheering. In the last 500 meters I gave it everything I had left. 3 hours, 29 minutes and 21 seconds after the start I ran across the finish line of my first marathon.

To my surprise I didn’t lose any time in the last 5 km. Probably this has something to do with all the measures I took in the last weeks before the race. No alcohol, no intensive workouts, but loads of carbs and water and a few good nights rest. And of course the gel containing high levels of glucose at about 34 kilometer.

3:29:05 #mr15. The crowd was amazing!

A photo posted by Hannes Van De Vreken (@hannesvdvreken) on Apr 12, 2015 at 11:15am PDT

Will I ever do this again? I think so. Will I ever beat my personal best? Maybe, because I don’t know if I was just lucky that everything went exactly right, or if I ran this great time just because of good training. I measured my heart rate throughout the race and noticed it’s higher than I would have hoped. I’ll be training on this in the future.

Thanks for all the wishes and cheers!

Tilde and caret version constraints in Composer

Mon, 13 Apr 2015 00:00:00 +0000

Note: this is a repost from my post on the madewithlove blog.

When installing a dependency we are used to install a version that adheres to a known public interface and does what it promises. That way we can safely use it in our code.

A dependency that uses semantic versioning allows you to predict wether it is still going to work or not when you upgrade it to a new version. Basically when the x in a x.y.z version number changes, you might need to do some changes to be able to work with this new version without problems. When dealing with a 0.y.z version this is slightly different: when the first non-zero number (y) changes, backwards compatibility is not guaranteed. If you’re not familiar with semver: head over to the specs!

A dependency can change without breaking backwards compatibility. A new release will then have a greater version number (x.y), depending on the type of change (bugfix or added functionality). When you depend on packages you might want to define a range of versions that are OK to install, rather than having a locked down version specified. This allows you to receive fixes (that includes security fixes) from external code for free with a simple update command.

Depending on your dependency manager you can define version contraints using wildcards (*), comparators like <=, logical operators (, often means AND and | means OR), etc… Using logical operators you can mix and match different version constraints to build even more complex ones. For example >=0.9.0,<0.11.0 means everything that matches 0.9.* and 0.10.*, but can also be noted as 0.9.* || 0.10.*.

There are also some syntactic sugar operators like ~ (tilde) and ^ (caret).

~4.1.3 means >=4.1.3,<4.2.0,
~4.1 means >=4.1.0,<5.0.0 (most used),
~0.4 means >=0.4.0,<1.0.0,
~4 means >=4.0.0,<5.0.0.

The caret sign is slightly different:

^4.1.3 (most used) means >=4.1.3,<5.0.0,
^4.1 means >=4.1.0,<5.0.0, same as ~4.1 but:
^0.4 means >=0.4.0,<0.5.0, this is different from ~0.4 and is more useful for defining backwards compatible version ranges.
^4 means >=4.0.0,<5.0.0 which is the same as ~4 and 4.*.

Basically use the caret sign to exclude early releases which contain known threats. For example if you need a dependency which has functionality which got introduced in 2.1.x and version 2.1.1 fixes a bug which was shipped with the 2.1.0 release. If that bug affected you or when it’s a security bug, you will be able to exclude all earlier versions with ^2.1.1. This way you can still benefit from all new backward compatible releases.

Fun fact: caret is Latin for “it lacks”, so you can remember this as “it (this version range) lacks some early releases but it’s backwards compatible up to the next major release”.

For now when you run the command composer require monolog/monolog it will still save ~1.13 (at the time of writing) as the default version constraint in your composer.json file and not ^1.13.1. This is to protect users who might not have updated their Composer to a version which can handle caret ^ constraints. Expect this to change in the coming weeks or months.

In case you didn’t notice yet, the links behind all these version constraints point to semver.mwl.be. We created this tool after Maxime posted a link to semver.npmjs.com in our madewithlove slack channel.

I won’t go into stability as it is out of the scope of this blog post, but I suggest you play around with our tool to see the effect of selecting stable, RC, beta, alpha or dev.

Cheers!

Work-in-progress Pull Requests

Thu, 09 Apr 2015 00:00:00 +0000

A while ago I saw a discussion on Twitter on when to open a pull request, when you’re done creating the changes, or when you start working on something? The latter is the preferred option, in my opinion.

Crafting a PR is possible from the moment you do a first commit on a new branch. You can start with a “boyscouting” commit which only moves some code around but doesn’t change any functionality. When you create a work-in-progress PR make sure to tag it with a WIP label or prepend [WIP] to the title.

WIP pull requests have several benefits:

The description can be kept up to date with a changelog right from the start. You can keep documenting changes, needed changes for users of the public interface, …
Allows peer developers to advice early if a developer is spending time on something that will most probably not be merged.
Allows peer developers to take a quick look to see if a feature implementation isn’t getting overcomplicated. Feature requirements aren’t always clear and could sometimes be translated into something much simpler. This could prevent spending a whole week while it could be done in a few hours.
When you are pushing a couple of code cleaning commits first, peers know they don’t need to review just yet.
Building a clear timeline on the evolution of this branch. Who did what, who reviewed when, who was assigned, what states did it go through (from WIP to in review etc), what extra changes have been made, …

When not to open a WIP pull request? When the project you are working on is a public project and the feature you are building is top secret, you might want to postpone pushing your branch. Also a PR for an open source project can start a long discussion between community members before you even finished your work. In these kind of situations it is perfectly normal to keep your branch local for the time you’re working on it.

At madewithlove we definitely like this approach of opening WIP pull requests. It gives all these benefits to peer developers. For project managers this gives the ability to track progress, next to what they can see on huboard or zenhub.

Cheers!