No Really, It’s Okay to Be Unavailable

We live in an uber-connected world. I can’t tell you how many times I’ve complained about shoddy Wi-Fi or the fact that Twitter is down. As much as I love the connection provided by the web and various technologies, somewhere along the way we became terrified of being unavailable. We have to check email maniacally, so we don’t keep our senders waiting. Our cell phone alerts and Slack notifications practically dictate our schedules.

Do a quick Google search of “being unavailable, ” and you’ll get a slew of articles on emotional availability and tips on how to be more attractive in relationships. These articles bemoan to women how men don’t like their partners to be around all the time; they find their better halves more attractive when they are invested in their own lives and not constantly dependent on their man’s company.

As a woman, I find many of these articles completely ridiculous. I believe one should live their lives on their own terms and things will just work themselves out. There is, however, a positive correlation between being somewhat unavailable, especially in business. People fear that by putting away their electronics, the unavailability will reflect poorly on who they are as a worker.

Here’s a truth: being unavailable is good for both you and your company. Somewhere along the way—and I’ve spoken with disdain about this inane practice before—working a million hours a week became a status symbol. Being available all the time meant you worked hard and smart. Although it has been vehemently debunked time and time again, there are those out there that still believe they have to respond to emails while they’re showering to keep a leg up.

You don’t need to unplug completely to be unavailable. Many of the articles written about disconnecting are coming from people who don’t work closely with technology. They aren’t active on social media, and they don’t depend on Slack and other ChatOps to get their jobs done. Aside from the business aspect of being connected, a lot of us derive joy from hanging out on Twitter and consuming content.

In my personal experience, my iPhone is an extension of my day, not a complete productivity assassin. With that said, it has been proven that using a phone while performing another task leads to poorer performance. Studies have shown even just hearing alerts in the background is comparable to actively using the device. Is the solution to turn off the phone once you get into the house? Not for me.

We can all have our own definition of unplugging. For me, it’s turning off alerts now and then to focus on other things. In the case of my computer, it’s occasionally not bringing it with me to the couch when I’m watching TV. Unplugging is different for everybody. Remember you don’t have to go completely “off the grid” to glean the benefits of time away from the internet.

It’s great to unplug while still engaging in some tech. Don’t forget, however, to take some time away from the grind. Unplugging could just be not answering work emails or going on airplane mode. Whatever you choose, remember it is indeed okay to occasionally be unavailable.

Source: Laravel News

Cloudflare has been leaking custom HTTPS sessions

Cloudflare has reported that under certain circumstances their edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

Tavis Ormandy from Google’s Project Zero first spotted the problem and reported this in the Chromium tracker:

It looked like that if an html page hosted behind cloudflare had a specific combination of unbalanced tags, the proxy would intersperse pages of uninitialized memory into the output (kinda like heartbleed, but cloudflare specific and worse for reasons I’ll explain later). My working theory was that this was related to their “ScrapeShield” feature which parses and obfuscates html – but because reverse proxies are shared between customers, it would affect all Cloudflare customers.

We fetched a few live samples, and we observed encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests for other major cloudflare-hosted sites from other users. Once we understood what we were seeing and the implications, we immediately stopped and contacted cloudflare security.

Once Cloudflare was contacted they immediately jumped on the problem and reduced it down to their HTML parser that was used in email obfuscation, Server-side Excludes, and Automatic HTTPS Rewrites.

The issue is now fixed and rolled out to all customers and Cloudflare has a very detailed report on the background, the timeline of the fix, and how they fixed it. They also, worked with Google and other search engines directly to get to remove any cached HTTP responses.

If you’d like to see a list of sites running Cloudflare here is a list of some of the most popular domains.

UPDATE: Laravel News runs on Cloudflare and we received an email this morning saying this site was not affected. Here is a copy of the relevant information from that report:

In our review of these third party caches, we discovered exposed data on approximately 150 of Cloudflare’s customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

Your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

Source: Laravel News

Modules Are Simply Files

The term "module" used to scare me. What exactly are they? Well, as it turns out, the answer is very simple: they’re just files. Let’s experiment with importing and exporting modules, while taking a few moments to discuss CommonJS vs. ES2015 modules.
Source: Laracasts

A Dedicated Configuration File

While it’s neat that we can compile Webpack with a single command, in reality, you’ll almost always want to use a dedicated webpack.config.js file to configure your Webpack build. Let’s transition over in this episode.
Source: Laracasts

Tips For Building Your First Laravel Package

Laravel is a powerful and modern framework. It has tons of different features, which make our work faster and easier. But you can’t push everything into the single box. At one time or another, we’ve all been in need of something not implemented in the framework out of the box. So, you’re writing code by yourself; it works, and you are happy. Yep?

But what if you need the same functionality in another project? Will you write it again? Copy-paste it? Both solutions are bad because you’re solving the same problem again and again. And what about bugs? Imagine finding a bug in that code a few days later. Now you have to fix it in N places. Ufff, not fun!

A package can be a solution. Write your code once and use it in any number of projects. Maybe you found a bug, or want to make some changes? Do it just once in your package code and then pull required changes in all of your projects. Sounds good?

The First Step

Before diving into the work with your head, check Packagist first. It is possible someone has already solved your problem. If you can’t find an existing package, try to explore the question a little bit deeper. Maybe you’re not using the most accurate keywords in your search. Don’t be afraid to spend another 30 minutes; it could save you 30 days eventually.


You’ve searched, but no luck and now you’re willing to create a new Laravel package. What are the next steps?

First of all, take a look at the Laravel documentation. The Package Development page is a great starting point. You’ll find out in most cases, the heart of your package would be a service provider. Here you can register event listeners, middleware, routes, translations, views, etc. Maybe your package has its own config file, maybe even its own database migrations. You have to describe all of that in your service provider. It is the connection point between your package and Laravel.

Your head is full of knowledge; you are creating new GitHub repo and starting to write code. Great! What tips can I give to you?

I think one of the most important things, when you’re writing a framework package is to make the package close to the framework. In everything: architecture, naming, code style, documentation, every aspect of it. It will be much easier for people to understand and use your package if it looks like the part of the framework. But, it’s not always easy to choose those best names for classes, methods, variables, etc. I really like Jeffrey Way’s method, which I learned at Laracasts. When you’re feeling a name isn’t very good, delete it and write it as you’d want it to be in a perfect world, then use it. Simple enough, but it works. Naming is not the easiest thing in programming, and there are a lot of good books about it.

I’ve received the following feedback from someone using my package: “Nice readme file! It’s really easy to read it, it feels like I’m reading one of the Laravel docs!” That was my victory!

If people feel your package is a natural part of the framework — you’re on the right path.


Package testing can be really tricky. And the first question I had, before even starting to write tests was this: how should I test it? Should I create a new instance of my Laravel project, install my package there, and write my tests? These were the real usage conditions of my package, but my tests would be located outside of the package, which is really bad.

Luckily, there is Testbench Component to solve that problem. It provides a way to test your package without a standalone Laravel install. You can easily register your package service provider, aliases, set up the database, load migrations, etc.

The great thing about open source is you can use cool GitHub integrations for free. They can help you in different ways.
My favorites are:


Your code is ready and, your tests are green. You think you’re done at this point? Nope.

Don’t be lazy; create a nice readme file. It can be really useful for you because you’re taking another look at your package in general. There have been so many times while writing a readme file that new ideas have come to me. And having a good readme allows others to be able to use your package as well. Isn’t it great to know your code is useful for someone?

I think a readme file is really important, and it should be as simple as possible. Use images, where possible. They are easier to understand. Write your documentation as close to Laravel Documentation as you can.

There is a really great article “How to write a readme that rocks“, take a look!
There are a lot of cool tips and tools described there. For example, Michael Dyrynda’s Readme Generator, Grammarly, Hemingway App, etc.


Don’t forget to add your package to Packagist, so it will be available through Composer. That will make your package installation really easy, and make it searchable through Composer. Use keywords in your composer.json file. You can also set up GitHub Topics to make your package even more searchable.

Use GitHub Releases for your package. Read and follow Semantic Versioning rules.

It doesn’t matter how cool is your package if people don’t know about it. Tell them!

Write short notes on community forums, for example, Laracasts Forum, Larachat, etc. Add a link to your package on Laravel News. Don’t be afraid to tell!


Creating your own packages can make your code cleaner, preventing you from repeating yourself over and over in different projects. I’m not saying you have to extract everything into the packages, no. It’s all about the balance, like in coding. Should I extract that code into the separate method? Or, maybe even into the separate class? Remember those questions? I think “Should I extract that code into the separate package?” is something similar to these questions. It depends. Feel it, and make a decision according to your context and experience.

There are a lot of aspects, which are not covered in this short article, but I really hope it will be useful for someone. Please, contact me if you have any thoughts or questions.

Wish you tons of stars on your own packages!

Source: Laravel News

zend-config For All Your Configuration Needs

Different applications and frameworks have different opinions about how
configuration should be created. Some prefer XML, others YAML, some like JSON,
others like INI, and some even stick to the JavaProperties format; in Zend
Framework, we tend to prefer PHP arrays, as each of the other formats
essentially get compiled to PHP arrays eventually anyways.

At heart, though, we like to support developer needs, whatever they may be, and,
as such, our zend-config component
provides ways of working with a variety of configuration formats.


zend-config is installable via Composer:

$ composer require zendframework/zend-config

The component has two dependencies:

  • zend-stdlib, which provides some
    capabilities around configuration merging.
  • psr/container, to allow reader and
    writer plugin support for the configuration factory.

Latest version

This article covers the most recently released version of zend-config, 3.1.0,
which contains a number of features such as PSR-11 support that were not
previously available. If you are using Zend Framework, you should be able to
safely provide the constraint ^2.6 || ^3.1, as the primary APIs remain the

Retrieving configuration

Once you’ve installed zend-config, you can start using it to retrieve and access
configuration files. The simplest way is to use ZendConfigFactory, which
provides tools for loading configuration from a variety of formats, as well as
capabilities for merging.

If you’re just pulling in a single file, use Factory::fromFile():

use ZendConfigFactory;

$config = Factory::fromFile($path);

Far more interesting is to use multiple files, which you can do via
Factory::fromFiles(). When you do, they are merged into a single
configuration, in the order in which they are provided to the factory. This is
particularly interesting using glob():

use ZendConfigFactory;

$config = Factory::fromFiles(glob('config/autoload/*.*'));

What’s particularly interesting about this is that it supports a variety of

  • PHP files returning arrays (.php extension)
  • INI files (.ini extension)
  • JSON files (.json extension)
  • XML files (using PHP’s XMLReader; .xml extension)
  • YAML files (using ext/yaml, installable via PECL; .yaml extension)
  • JavaProperties files (.javaproperties extension)

This means that you can choose the configuration format you prefer, or
mix-and-match multiple formats, if you need to combine configuration from
multiple libraries!

Configuration objects

By default, ZendConfigFactory will return PHP arrays for the merged
configuration. Some dependency injection containers do not support arrays as
services, however; moreover, you may want to pass some sort of structured object
instead of a plain array when injecting dependencies.

As such, you can pass a second, optional argument to each of fromFile() and
fromFiles(), a boolean flag. When true, it will return a
ZendConfigConfig instance, which implements Countable, Iterator, and
ArrayAccess, allowing it to look and act like an array.

What is the benefit?

First, it provides property overloading to each configuration key:

$debug = $config->debug ?: false;

Second, it offers a convenience method, get(), which allows you to specify a
default value to return if the value is not found:

$debug = $config->get('debug', false); // Return false if not found

This is largely obviated by the ?: ternary shortcut in modern PHP versions,
but very useful when mocking in your tests.

Third, nested sets are also returned as Config instances, which gives you the
ability to use the above get() method on a nested item:

if (isset($config->expressive)) {
    $config = $config->get('expressive'); // same API!

Fourth, you can mark the Config instance as immutable! By default, it acts
just like array configuration, which is, of course, mutable. However, this can
be problematic when you use configuration as a service, because, unlike an
array, a Config instance is passed by reference, and changes to values would
then propagate to any other services that depend on the configuration.

Ideally, you wouldn’t be changing any values in the instance, but
ZendConfigConfig can enforce that for you:

$config->setReadOnly(); // Now immutable!

Further, calling this will mark nested Config instances as read-only as well,
ensuring data integrity for the entire configuration tree.

Read-only by default!

One thing to note: by default, Config instances are read-only! The
constructor accepts an optional, second argument, a flag indicating whether or
not the instance allows modifications, and the value is false by default.
Whenever you use the Factory to create a Config instance, it never enables
that flag, meaning that if you return a Config instance, it will be read-only.

If you want a mutable instance from a Factory, use the following construct:

use ZendConfigConfig;
use ZendConfigFactory;

$config = new Config(Factory::fromFiles($files), true);

Including other configuration

Most of the configuration reader plugins also support "includes": directives
within a configuration file that will include configuration from another file.
(JavaProperties is the only configuration format we support that does not have
this functionality included.)

For instance:

  • INI files can use the key @include to include another file relative to the
    current one; values are merged at the same level:

    webhost = ''
    @include = 'database.ini'
  • For XML files, you can use XInclude:

    <?xml version="1.0" encoding="utf-8">
    <config xmlns:xi="">
      <xi:include href="database.xml"/>
  • JSON files can use an @include key:

      "webhost": "",
      "@include": "database.json"
  • YAML also uses the @include notation:

    @include: database.yaml

Choose your own YAML

Out-of-the-box we support the YAML PECL extension
for our YAML support. However, we have made it possible to use alternate
parsers, such as Spyc or the Symfony YAML component, by passing a callback to the
reader’s constructor:

use SymfonyComponentYamlYaml as SymfonyYaml;
use ZendConfigReaderYaml as YamlConfig;

$reader = new YamlConfig([SymfonfyYaml::class, 'parse']);
$config = $reader->fromFile('config.yaml');

Of course, if you’re going to do that, you could just use the original library,
right? But what if you want to mix YAML and other configuration with the
Factory class?

There aer two ways to register new plugins. One is to create an instance and
register it with the factory:

use SymfonyComponentYamlYaml as SymfonyYaml;
use ZendConfigFactory;
use ZendConfigReaderYaml as YamlConfig;

Factory::registerReader('yaml', new YamlConfig([SymfonyYaml::class, 'parse']));

Alternately, you can provide an alternate reader plugin manager. You can do that
by extending ZendConfigStandaloneReaderPluginManager, which is a barebones
PSR-11 container for use as a plugin manager:

namespace Acme;

use SymfonyComponentYamlYaml as SymfonyYaml;
use ZendConfigReaderYaml as YamlConfig;
use ZendConfigStandaloneReaderPluginManager;

class ReaderPluginManager extends StandaloneReaderPluginManager
     * @inheritDoc
    public function has($plugin)
        if (YamlConfig::class === $plugin
            || 'yaml' === strtolower($plugin)
        ) {
            return true;

        return parent::has($plugin);

     * @inheritDoc
    public function get($plugin)
        if (YamlConfig::class !== $plugin
            && 'yaml' !== strtolower($plugin)
        ) {
            return parent::get($plugin);

        return new YamlConfig([SymfonyYaml::class, 'parse']);

Then register this with the Factory:

use AcmeReaderPluginManager;
use ZendConfigFactory;

Factory::setReaderPluginManager(new ReaderPluginManager());

Processing configuration

zend-config also allows you to process a ZendConfigConfig instance and/or
an individual value. Processors perform operations such as:

  • substituting constant values within strings
  • filtering configuration data
  • replacing tokens within configuration
  • translating configuration values

Why would you want to do any of these operations?

Consider this: deserialization of formats other than PHP cannot take into
account PHP constant values or class names!

While this may work in PHP:

return [
    AcmeComponent::CONFIG_KEY => [
        'host' => AcmeComponent::CONFIG_HOST,
        'dependencies' => [
            'factories' => [
                AcmeMiddlewareAuthorization::class => AcmeMiddlewareAuthorizationFactory::class,

The following JSON configuration would not:

    "AcmeComponent::CONFIG_KEY": {
        "host": "AcmeComponent::CONFIG_HOST"
        "dependencies": {
            "factories": {
                "AcmeMiddlewareAuthorization::class": "AcmeMiddlewareAuthorizationFactory::class"

Enter the Constant processor!

This processor looks for strings that match constant names, and replaces them
with their values. Processors generally only work on the configuration values,
but the Constant processor allows you to opt-in to processing the keys as

Since processing modifies the Config instance, you will need to manually
create an instance, and then process it. Let’s look at that:

use AcmeComponent;
use ZendConfigConfig;
use ZendConfigFactory;
use ZendConfigProcessor;

$config = new Config(Factory::fromFile('config.json'), true);
$processor = new ProcessorConstant();

// ['AcmeMiddlewareAuthorization' => 'AcmeMiddlewareAuthorizationFactory']

This is a really powerful feature, as it allows you to add more verifications
and validations to your configuration files, regardless of the format you use.

In version 3.1.0 forward

The ability to work with class constants and process keys was added only
recently in the 3.1.0 version of zend-config.

Config all the things!

This post covers the parsing features of zend-config, but does not even touch on
another major capability: the ability to write configuration! We’ll leave that
to another post.

In terms of configuration parsing, zend-config is simple, yet powerful. The
ability to process a number of common configuration formats, utilize
configuration includes, and process keys and values means you can highly
customize your configuration process to suit your needs or integrate different
configuration sources.

Get more information from the zend-config

Source: Zend feed

Laracon Online – Last Day For Early Bird Tickets

Today is the last chance for you to join over 3,000 developers and get an early bird ticket to Laracon Online for just $10. Each ticket purchase includes access to the live event video, conference swag, and a special Slack channel for hanging out and mingling during the event. With your ticket, you can sit on your couch and watch it all live!

Laracon Online will be held on March 8th, 2017 with opening remarks at 8:45 AM EST. If you can’t attend that day, all the talks will be recorded and available online for viewing at your convenience shortly after the conference ends.

Conference Swag

To bring you the true conference experience we are proud to be partnering with some of the biggest companies in the industry to offer you some awesome digital swag. Here is everything that is already confirmed:


Linode is offering a $20 discount to everyone on their cloud hosting.


Nexmo is offering 10EUR or $10.55 off their cloud-based communication APIs. Everything from SMS messaging, to voice, to authentication.


Deploy Bugsnag to your production application and get a free, limited edition, ultrasoft Bugsnag t-shirt.

Get a free .co domain registration with email and whois privacy for one year. A $20 value!


Blackfire is offering 30% off their Profiler and Premium editions. This is for first year of annual subscriptions and valid through March 31st.


If you make a purchase of Postmark credits within three months of Laracon Online, they’ll double your credits. It doesn’t matter how many credits you purchase. Buy $10,000 in credits, get $10,000 in credits free!

With early bird tickets at only $10, it’s an awesome deal and the digital goodies more than pay for the price of admission. Get your ticket today before the price goes up to $20 tomorrow.

Source: Laravel News

Laravel 5.5 Will Be The Next LTS Release

Version 5.1 was Laravel’s first LTS release and its two-year window of bug fixes are coming to an end this year. There have been a few people questioning if another LTS would be released and version 5.5 would be the next in line if it did happen.

Just today Laravel announced on Twitter that Laravel 5.5 will, in fact, continue the LTS line:

Just as the previous LTS this will include two years of bug fixes and three years of security updates.

For those not familiar with long-term support, these are special versions that are feature locked at the date of release. They do not get any new features but keep getting bug fixes and security updates throughout the maintenance window.

Source: Laravel News

How to Reduce Conditionals in Your Views

In the previous episode, we constructed multiple conditionals to determine which set of HTML should be displayed. For our basic example, the outcome was simple enough. However, for real-life projects, you may find that this quickly bloats your views and makes them difficult to reason about. Instead, let me show you a useful technique that involves applying polymorphism to dynamically load the proper view partial.
Source: Laracasts

1 2 3 48