In a new post to his site Christoph Rumpel lists out his top three features of Laravel 5.6 that he enjoys and finds the most useful.

Yesterday Taylor Otwell released Laravel 5.6 right before the Laracon Online conference. We had a little conference party here in Vienna and a great time watching all the talks together. In one of them Taylor walked us through the new Laravel features and I want to point out my top 3 of them.

For each of his top three he provides some code examples and screenshots where appropriate:

• the addition of the Collision package
• dynamic rate limiting on route definitions
• Eloquent date casting (enhancing the "casts" functionality already present from v5.5)

For more information on the other new features that v5.6 include, check out this series of posts from Laravel News.

In a post to his site Cees-Jan Kiewiet shows you how to get an authentication token from GitHub to use in your testing on the Travis-CI continuous integration service.

The composer cache greatly speeds up your composer part of the build by only going to Github for new downloads. When combined with test lowest, current, and highest possible on Travis you only reach out to Github for new versions. Most likely to happen during the highest possible set of builds, but also when you've updated composer.*. This normally isn't an issue unless you hit Github's rate limit. And since composer is running on a 'public' travis box with a 'public' IP address that has been use by many builds before it there is a very very high chance it already hit the 60 requests per hour limit.

[...] To counter this problem we have to set a Github authentication token as environment variable in Travis for each project. And update .travis.yml so the token is used by composer.

He walks you through the steps you'll need to get a token of your very own:

• Go to the Settings section on your GitHub account
• Generate a new Personal Access Token
• Add the token to the Travis-CI account you're using for your builds
• Update your .travis.yml configuration with the token information

Each step includes either a screenshot of where to go or the configuration example you'll need to use (like in the yml file).

In his latest post Joshua Thijssen introduces a new tool he's created to help Symfony2-based APIs handle rate limiting relatively easily: the RateLimit Bundle. The project was recently created as a part of some work he's been doing on the TechAnalyze service.

Too many times third party applications will be polling your API when they don’t really need too, and maybe you can lighten the load a bit with some heavy-duty caching, but in essence you want that every API call made matters. [...] Most of our calls are pretty lightweight, but some of them aren’t, nor are they easily cacheable. This is why we are limiting the number of calls each client can make to the API. But it wouldn’t be fair to just limit the number of calls in general.

[...] Our platform is written in PHP, based on the Symfony2 framework. There are many different bundles available for symfony2, all adding new functionality, but somehow we couldn’t find a (good) bundle for throttling our API. But after a search, we found a gist by Ruud Kamphuis, which pretty much does what we need. So we decided to set up a similar bundle, and added some flexibility in its usage.

The RateLimitBundle allows you to add a "@ratelimit" annotation directly to the controller or action in the application and adds remaining allowed calls to the response headers. The mentions some drawbacks to the bundle like a dependency on redis and how it figures out "distinct calls" to the API. He also breaks it down into the functional pieces and talks about how each one works and where it fits into the overall functionality.