Installing all your PHP libraries with Composer is a great way to save time. But larger projects automatically tested and run at each commit to your software version control (SVC) system will take a long time to install all the required packages from the Internet. You want to run your tests as soon as possible through your continuous integration (CI) system so that you have fast feedback and quick reactions on failure. In this tutorial we will set up a local mirror to proxy all your packages required in your project's composer.json file. This will make our CI work much faster, install the packages over the local network or even hosted on the same machine, and make sure we have the specific versions of the packages always available.

What Is Satis?

Satis is the name of the application we will use to mirror the various repositories for our project. It sits as a proxy between the Internet and your composer. Our solution will create a local mirror of a few packages and instruct our composer to use it instead of the sources found on the Internet.

Here is an image that says more than a thousand words.

Our project will use composer as usual. It will be configured to use the local Satis server as the primary source. If a package is found there, it will be installed from there. If not, we will let composer use the default packagist.org to retrieve the package.

Getting Satis

Satis is available through composer, so installing it is very simple. In the attached source code archive, you will find Satis installed in the Sources/Satis folder. First we will install composer itself.

$ curl -sS https://getcomposer.org/installer | php
    #!/usr/bin/env php All settings correct for using Composer Downloading...
     Composer successfully installed to: /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/composer.phar Use it: php composer.phar

Then we will install Satis.

$ php composer.phar create-project composer/satis --stability=dev --keep-vcs Installing composer/satis (dev-master eddb78d52e8f7ea772436f2320d6625e18d5daf5)
      - Installing composer/satis (dev-master master)
        Cloning master
     Created project in /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/satis Loading composer repositories with package information Installing dependencies (including require-dev) from lock file
      - Installing symfony/process (dev-master 27b0fc6)
        Cloning 27b0fc645a557b2fc7bc7735cfb05505de9351be
    
      - Installing symfony/finder (v2.4.0-BETA1)
        Downloading: 100%
    
      - Installing symfony/console (dev-master f44cc6f)
        Cloning f44cc6fabdaa853335d7f54f1b86c99622db518a
    
      - Installing seld/jsonlint (1.1.1)
        Downloading: 100%
    
      - Installing justinrainbow/json-schema (1.1.0)
        Downloading: 100%
    
      - Installing composer/composer (dev-master f8be812)
        Cloning f8be812a496886c84918d6dd1b50db5c16da3cc3
    
      - Installing twig/twig (v1.14.1)
        Downloading: 100%
     symfony/console suggests installing symfony/event-dispatcher () Generating autoload files

Configuring Satis

Satis is configured by a JSON file very similar to composer. You can use whatever name you want for your file and specify it for usage later. We will use "mirrored-packages.conf".

{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
            "monolog/monolog": "syneto-dev",
            "mockery/mockery": "*",
            "phpunit/phpunit": "*"
        },
        "require-dependencies": true
    }

Let's analyze this configuration file.

• name - represents a string that will be shown on the web interface of our mirror.
• homepage - is the web address where our packages will be kept. This does not tell our web server to use that address and port, it is rather just information of a working configuration. We will set up the access to it on that addres and port later.
• repositories - a list of repositories ordered by preference. In our example, the first repository is a Github fork of the monolog logging libraries. It has some modifications and we want to use that specific fork when installing monolog. The type of this repository is "vcs". The second repository is of type "composer". Its URL is the default packagist.org site.
• require - lists the packages we want to mirror. It can represent a specific package with a specific version or branch, or any version for that matter. It uses the same syntax as your "require" or "require-dev" in your composer.json.
• require-dependencies - is the final option in our example. It will tell Satis to mirror not only the packages we specified in the "require" section but also all their dependencies.

To quickly try out our settings we first need to tell Satis to create the mirrors. Run this command in the folder where you installed Satis.

$ php ./satis/bin/satis build ./mirrored-packages.conf ./packages-mirror Scanning packages Writing packages.json Writing web view

While the process is taking place, you will see how Satis mirrors each found version of the required packages. Be patient it may take a while to build all those packages.

Satis requires that date.timezone to be specified in the php.ini file, so make sure it is and set to your local timezone. Otherwise an error will appear.

[Twig_Error_Runtime]
      An exception has been thrown during the rendering of a template
    ("date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set) function.

Then we can run a PHP server instance in our console pointing to the recently created repository. PHP 5.4 or newer is required.

$ php -S localhost:4680 -t ./packages-mirror/ PHP 5.4.22-pl0-gentoo Development Server started at Sun Dec  8 14:47:48 2013 Listening on http://localhost:4680 Document root is /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/packages-mirror Press Ctrl-C to quit.
    [Sun Dec  8 14:48:09 2013] 127.0.0.1:56999 [200]: /
    [Sun Dec  8 14:48:09 2013] 127.0.0.1:57000 [404]: /favicon.ico - No such file or directory

And we can now browse our mirrored packages and even search for specific ones by pointing our web browser to http://localhost:4680:

Let's Host It on Apache

If you have a running Apache at hand, creating a virtual host for Satis will be quite simple.

Listen 4680
    
    <Directory "/path/to/your/packages-mirror"> Options -Indexes FollowSymLinks AllowOverride all Order allow,deny Allow from all
    </Directory>
    
    <VirtualHost *:4680> DocumentRoot "/path/to/your/packages-mirror" ServerName 127.0.0.1:4680 ServerAdmin admin@example.com
     ErrorLog syslog:user
    
    </VirtualHost>

We just use a .conf file like this, put in Apache's conf.d folder, usually /etc/apache2/conf.d. It creates a virtual host on the 4680 port and points it to our folder. Of course you can use whatever port you want.

Updating Our Mirrors

Satis can not automatically update the mirrors unless we tell it. So the easiest way, on any UNIX like system, is to just add a cron job to your system. That would be very easy, and just a simple script to execute our update command.

#!/bin/bash php /full/path/to/satis/bin/satis build \
    /full/path/to/mirrored-packages.conf \
    /full/path/to/packages-mirror

The drawback of this solution is that it is static. We have to manually update the mirrored-packages.conf every time we add another package to our project's composer.json. If you are part of a team in a company with a big project and a continuous integration server, you can't rely on people remembering to add the packages on the server. They may not even have permissions to access the CI infrastructure.

Dynamically Updating Satis Configuration

It's time for a PHP TDD exercise. If you just want your code ready and running, check out the source code attached to this tutorial.

require_once __DIR__ . '/../../../../vendor/autoload.php';
     class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
        function testBehavior() {
            $this->assertTrue(true);
        }
    }

As usual we start with a degenerative test, just enough to make sure we have a working testing framework. You may notice that I have quite a strange looking require_once line, this is because I want to avoid having to reinstall PHPUnit and Mockery for each small project. So I have them in a vendor folder in my NetTuts' root. You should just install them with composer and drop the require_once line altogether.

class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
    	function testDefaultConfigFile() {
    		$expected = '{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
        },
        "require-dependencies": true
    }';
    		$actual = $this->parseComposerConf('');
    		$this->assertEquals($expected, $actual);
    	}
    }

That looks about right. All the fields except "require" are static. We need to generate only the packages. The repositories are pointing to our private git clones and to packagist as needed. Managing those is more of a sysadmin job than a software developer's.

Of course this fails with:

PHP Fatal error:  Call to undefined method SatisUpdaterTest::parseComposerConf()

Fixing that is easy.

private function parseComposerConf($string) {
    }

I just added an empty method with the required name, as private, to our test class. Cool, but now we have another error.

PHPUnit_Framework_ExpectationFailedException : Failed asserting that null matches expected '{ ... }'

So, null does not match our string containing all that default configuration.

private function parseComposerConf($string) {
        return '{
    "name": "NetTuts Composer Mirror",
    "homepage": "http://localhost:4680",
    
    "repositories": [
        { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
        { "type": "composer", "url": "https://packagist.org" }
    ],
    
    "require": {
    },
    "require-dependencies": true
    }';
    }

OK, that works. All tests are passing.

PHPUnit 3.7.28 by Sebastian Bergmann. Time: 15 ms, Memory: 2.50Mb OK (1 test, 1 assertion)

But we introduced a horrible duplication. All that static text in two places, written character by character in two different places. Let's fix it:

class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
    	static $DEFAULT_CONFIG = '{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
        },
        "require-dependencies": true
    }';
    
    	function testDefaultConfigFile() {
    		$expected =  self::$DEFAULT_CONFIG;
    
    		$actual = $this->parseComposerConf('');
    		$this->assertEquals($expected, $actual);
    	}
    
    	private function parseComposerConf($string) {
    		return self::$DEFAULT_CONFIG;
    	}
    }

Ahhh! That's better.

	function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $expected = self::$DEFAULT_CONFIG;
    
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertEquals($expected, $actual);
    }

Well. That also passes. But it also highlights some duplication and useless assignment.

	function testDefaultConfigFile() {
        $actual = $this->parseComposerConf('');
        $this->assertEquals(self::$DEFAULT_CONFIG, $actual);
    }
     function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertEquals(self::$DEFAULT_CONFIG, $actual);
    }

We inlined the $expected variable. $actual could also be inlined, but I like it better this way. It keeps the focus on what is tested.

Now we have another problem. The next test I want to write would look like this:

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
        '{"require": {
            "Mockery/Mockery": ">=0.7.2"
        }}');
        $this->assertContains('"Mockery/Mockery": ">=0.7.2"', $actual);
    }

But after writing the simple implementation, we will notice it requires json_decode() and json_encode(). And of course these functions reformat our string and matching strings will be difficult at best. We have to take a step back.

function testDefaultConfigFile() {
        $actual = $this->parseComposerConf('');
        $this->assertJsonStringEqualsJsonString($this->jsonRecode(self::$DEFAULT_CONFIG), $actual);
    }
     function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertJsonStringEqualsJsonString($this->jsonRecode(self::$DEFAULT_CONFIG), $actual);
    }
     private function parseComposerConf($jsonConfig) {
        return $this->jsonRecode(self::$DEFAULT_CONFIG);
    }
     private function jsonRecode($json) {
        return json_encode(json_decode($json, true));
    }

We changed our assertion method to compare JSON strings and we also recoded our $actual variable. ParseComposerConf() was also modified to use this method. You will see in a moment how it helps us. Our next test becomes more JSON specific.

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
            }}');
        $this->assertEquals('>=0.7.2', json_decode($actual, true)['require']['Mockery/Mockery']);
    }

And making this test pass, along with the rest of the tests, is quite easy, again.

private function parseComposerConf($jsonConfig) {
        $addedConfig = json_decode($jsonConfig, true);
        $config = json_decode(self::$DEFAULT_CONFIG, true);
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
        }
        return json_encode($config);
    }

We take the input JSON string, decode it, and if it contains a "require" field we use that in our Satis configuration file instead. But we may want to mirror all versions of a package, not just the last one. So maybe we want to modify our test to check that the version is "*" in Satis, regardless of what exact version is in composer.json.

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
    }

That obviously fails with a cool message:

PHPUnit_Framework_ExpectationFailedException : Failed asserting that two strings are equal. Expected :* Actual   :>=0.7.2

Now, we need to actually edit our JSON before re-encoding it.

private function parseComposerConf($jsonConfig) {
        $addedConfig = json_decode($jsonConfig, true);
        $config = json_decode(self::$DEFAULT_CONFIG, true);
        $config = $this->addNewRequires($addedConfig, $config);
        return json_encode($config);
    }
     private function toAllVersions($config) {
        foreach ($config['require'] as $package => $version) {
            $config['require'][$package] = '*';
        }
        return $config;
    }
     private function addNewRequires($addedConfig, $config) {
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

To make the test pass we have to iterate over each element of the required packages array and set their version to '*'. See method toAllVersion() for more details. And to speed up this tutorial a little bit, we also extracted some private methods in the same step. This way, parseComoserConf() becomes very descriptive and easy to understand. We could also inline $config into the arguments of addNewRequires(), but for aesthetic reasons I left it on two lines.

But what about "require-dev" in composer.json?

function testARquiredDevPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require-dev": {
                "Mockery/Mockery": ">=0.7.2",
                "phpunit/phpunit": "3.7.28"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
        $this->assertEquals('*', json_decode($actual, true)['require']['phpunit/phpunit']);
    }

That obviously fails. We can make it pass with just copy/pasting our if condition in addNewRequires():

private function addNewRequires($addedConfig, $config) {
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
            $config = $this->toAllVersions($config);
        }
        if (isset($addedConfig['require-dev'])) {
            $config['require'] = $addedConfig['require-dev'];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

Yep, that makes it pass, but those duplicated if statements are nasty looking. Let's deal with them.

private function addNewRequires($addedConfig, $config) {
        $config = $this->addRequire($addedConfig, 'require', $config);
        $config = $this->addRequire($addedConfig, 'require-dev', $config);
        return $config;
    }
     private function addRequire($addedConfig, $string, $config) {
        if (isset($addedConfig[$string])) {
            $config['require'] = $addedConfig[$string];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

We can be happy again, tests are green and we refactored our code. I think only one test is left to be written. What if we have both "require" and "require-dev" sections in composer.json?

function testItCanParseComposerJsonWithBothSections() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
                },
            "require-dev": {
                "phpunit/phpunit": "3.7.28"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
        $this->assertEquals('*', json_decode($actual, true)['require']['phpunit/phpunit']);
    }

That fails because the packages set by "require-dev" will overwrite those of "require" and we will have an error:

Undefined index: Mockery/Mockery

Just add a plus sign to merge the arrays, and we are done.

private function addRequire($addedConfig, $string, $config) {
        if (isset($addedConfig[$string])) {
            $config['require'] += $addedConfig[$string];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

Tests are passing. Our logic is finished. All we left to do is to extract the methods into their own file and class. The final version of the tests and the SatisUpdater class can be found in the attached source code.

We can now modify our cron script to load our parser and run it on our composer.json. This will be specific to your projects' particular folders. Here is an example you can adapt to your system.

#!/usr/local/bin/php
    
    <?php require_once __DIR__ . '/Configuration.php';
    
    $outputDir = '/path/to/your/packages-mirror';
    $composerJsonFile = '/path/to/your/projects/composer.json';
    $satisConf = '/path/to/your/mirrored-packages.conf';
    
    $satisUpdater = new SatisUpdater();
    $conf = $satisUpdater->parseComposerConf(file_get_contents($composerJsonFile)); file_put_contents($satisConf, $conf);
     system(sprintf('/path/to/satis/bin/satis build %s %s', $satisConf, $outputDir), $retval); exit($retval);

Making Your Project Use the Mirror

We talked about a lot of things in this article, but we did not mention how we will instruct our project to use the mirror instead of the Internet. You know, the default is packagist.org? Unless we do something like this:

   "repositories": [
            {
                "type": "composer",
                "url": "http://your-mirror-server:4680"
            }
        ],

That will make your mirror the first choise for composer. But adding just that into the composer.json of your project will not disable access to packagist.org. If a package can not be found on the local mirror, it will be downloaded from the Internet. If you wish to block this feature, you may also want to add the following line to the repositories section above:

"packagist": false

Final Thoughts

That's it. Local mirror, with automatic adapting and updating packages. Your colleagues will never have to wait a long time while they or the CI server installs all the requirements of your projects. Have fun.

Installing all your PHP libraries with Composer is a great way to save time. But larger projects automatically tested and run at each commit to your software version control (SVC) system will take a long time to install all the required packages from the Internet. You want to run your tests as soon as possible through your continuous integration (CI) system so that you have fast feedback and quick reactions on failure. In this tutorial we will set up a local mirror to proxy all your packages required in your project’s composer.json file. This will make our CI work much faster, install the packages over the local network or even hosted on the same machine, and make sure we have the specific versions of the packages always available.

What Is Satis?

Satis is the name of the application we will use to mirror the various repositories for our project. It sits as a proxy between the Internet and your composer. Our solution will create a local mirror of a few packages and instruct our composer to use it instead of the sources found on the Internet.

Here is an image that says more than a thousand words.

Our project will use composer as usual. It will be configured to use the local Satis server as the primary source. If a package is found there, it will be installed from there. If not, we will let composer use the default packagist.org to retrieve the package.

Getting Satis

Satis is available through composer, so installing it is very simple. In the attached source code archive, you will find Satis installed in the Sources/Satis folder. First we will install composer itself.

$ curl -sS https://getcomposer.org/installer | php
    #!/usr/bin/env php All settings correct for using Composer Downloading...
     Composer successfully installed to: /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/composer.phar Use it: php composer.phar
    

Then we will install Satis.

$ php composer.phar create-project composer/satis --stability=dev --keep-vcs Installing composer/satis (dev-master eddb78d52e8f7ea772436f2320d6625e18d5daf5)
      - Installing composer/satis (dev-master master)
        Cloning master
     Created project in /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/satis Loading composer repositories with package information Installing dependencies (including require-dev) from lock file
      - Installing symfony/process (dev-master 27b0fc6)
        Cloning 27b0fc645a557b2fc7bc7735cfb05505de9351be
    
      - Installing symfony/finder (v2.4.0-BETA1)
        Downloading: 100%
    
      - Installing symfony/console (dev-master f44cc6f)
        Cloning f44cc6fabdaa853335d7f54f1b86c99622db518a
    
      - Installing seld/jsonlint (1.1.1)
        Downloading: 100%
    
      - Installing justinrainbow/json-schema (1.1.0)
        Downloading: 100%
    
      - Installing composer/composer (dev-master f8be812)
        Cloning f8be812a496886c84918d6dd1b50db5c16da3cc3
    
      - Installing twig/twig (v1.14.1)
        Downloading: 100%
     symfony/console suggests installing symfony/event-dispatcher () Generating autoload files
    

Configuring Satis

Satis is configured by a JSON file very similar to composer. You can use whatever name you want for your file and specify it for usage later. We will use “mirrored-packages.conf“.

{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
            "monolog/monolog": "syneto-dev",
            "mockery/mockery": "*",
            "phpunit/phpunit": "*"
        },
        "require-dependencies": true
    }

Let’s analyze this configuration file.

• name – represents a string that will be shown on the web interface of our mirror.
• homepage – is the web address where our packages will be kept. This does not tell our web server to use that address and port, it is rather just information of a working configuration. We will set up the access to it on that addres and port later.
• repositories – a list of repositories ordered by preference. In our example, the first repository is a Github fork of the monolog logging libraries. It has some modifications and we want to use that specific fork when installing monolog. The type of this repository is “vcs“. The second repository is of type “composer“. Its URL is the default packagist.org site.
• require – lists the packages we want to mirror. It can represent a specific package with a specific version or branch, or any version for that matter. It uses the same syntax as your “require” or “require-dev” in your composer.json.
• require-dependencies – is the final option in our example. It will tell Satis to mirror not only the packages we specified in the “require” section but also all their dependencies.

To quickly try out our settings we first need to tell Satis to create the mirrors. Run this command in the folder where you installed Satis.

$ php ./satis/bin/satis build ./mirrored-packages.conf ./packages-mirror Scanning packages Writing packages.json Writing web view
    

While the process is taking place, you will see how Satis mirrors each found version of the required packages. Be patient it may take a while to build all those packages.

Satis requires that date.timezone to be specified in the php.ini file, so make sure it is and set to your local timezone. Otherwise an error will appear.

[Twig_Error_Runtime]
      An exception has been thrown during the rendering of a template
    ("date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set) function. 

Then we can run a PHP server instance in our console pointing to the recently created repository. PHP 5.4 or newer is required.

$ php -S localhost:4680 -t ./packages-mirror/ PHP 5.4.22-pl0-gentoo Development Server started at Sun Dec  8 14:47:48 2013 Listening on http://localhost:4680 Document root is /home/csaba/Personal/Programming/NetTuts/Setting up a local mirror for Composer packages with Satis/Sources/Satis/packages-mirror Press Ctrl-C to quit.
    [Sun Dec  8 14:48:09 2013] 127.0.0.1:56999 [200]: /
    [Sun Dec  8 14:48:09 2013] 127.0.0.1:57000 [404]: /favicon.ico - No such file or directory
    

And we can now browse our mirrored packages and even search for specific ones by pointing our web browser to http://localhost:4680:

Let’s Host It on Apache

If you have a running Apache at hand, creating a virtual host for Satis will be quite simple.

Listen 4680
    
    <Directory "/path/to/your/packages-mirror"> Options -Indexes FollowSymLinks AllowOverride all Order allow,deny Allow from all
    </Directory>
    
    <VirtualHost *:4680> DocumentRoot "/path/to/your/packages-mirror" ServerName 127.0.0.1:4680 ServerAdmin admin@example.com
     ErrorLog syslog:user
    
    </VirtualHost>
    

We just use a .conf file like this, put in Apache’s conf.d folder, usually /etc/apache2/conf.d. It creates a virtual host on the 4680 port and points it to our folder. Of course you can use whatever port you want.

Updating Our Mirrors

Satis can not automatically update the mirrors unless we tell it. So the easiest way, on any UNIX like system, is to just add a cron job to your system. That would be very easy, and just a simple script to execute our update command.

#!/bin/bash php /full/path/to/satis/bin/satis build \
    /full/path/to/mirrored-packages.conf \
    /full/path/to/packages-mirror

The drawback of this solution is that it is static. We have to manually update the mirrored-packages.conf every time we add another package to our project’s composer.json. If you are part of a team in a company with a big project and a continuous integration server, you can’t rely on people remembering to add the packages on the server. They may not even have permissions to access the CI infrastructure.

Dynamically Updating Satis Configuration

It’s time for a PHP TDD exercise. If you just want your code ready and running, check out the source code attached to this tutorial.

require_once __DIR__ . '/../../../../vendor/autoload.php';
     class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
        function testBehavior() {
            $this->assertTrue(true);
        }
    }

As usual we start with a degenerative test, just enough to make sure we have a working testing framework. You may notice that I have quite a strange looking require_once line, this is because I want to avoid having to reinstall PHPUnit and Mockery for each small project. So I have them in a vendor folder in my NetTuts‘ root. You should just install them with composer and drop the require_once line altogether.

class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
    	function testDefaultConfigFile() {
    		$expected = '{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
        },
        "require-dependencies": true
    }';
    		$actual = $this->parseComposerConf('');
    		$this->assertEquals($expected, $actual);
    	}
    }

That looks about right. All the fields except “require” are static. We need to generate only the packages. The repositories are pointing to our private git clones and to packagist as needed. Managing those is more of a sysadmin job than a software developer’s.

Of course this fails with:

PHP Fatal error:  Call to undefined method SatisUpdaterTest::parseComposerConf()

Fixing that is easy.

private function parseComposerConf($string) {
    }

I just added an empty method with the required name, as private, to our test class. Cool, but now we have another error.

PHPUnit_Framework_ExpectationFailedException : Failed asserting that null matches expected '{ ... }'

So, null does not match our string containing all that default configuration.

private function parseComposerConf($string) {
        return '{
    "name": "NetTuts Composer Mirror",
    "homepage": "http://localhost:4680",
    
    "repositories": [
        { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
        { "type": "composer", "url": "https://packagist.org" }
    ],
    
    "require": {
    },
    "require-dependencies": true
    }';
    }

OK, that works. All tests are passing.

PHPUnit 3.7.28 by Sebastian Bergmann. Time: 15 ms, Memory: 2.50Mb OK (1 test, 1 assertion)

But we introduced a horrible duplication. All that static text in two places, written character by character in two different places. Let’s fix it:

class SatisUpdaterTest extends PHPUnit_Framework_TestCase {
    	static $DEFAULT_CONFIG = '{
        "name": "NetTuts Composer Mirror",
        "homepage": "http://localhost:4680",
    
        "repositories": [
            { "type": "vcs", "url": "https://github.com/SynetoNet/monolog" },
            { "type": "composer", "url": "https://packagist.org" }
        ],
    
        "require": {
        },
        "require-dependencies": true
    }';
    
    	function testDefaultConfigFile() {
    		$expected =  self::$DEFAULT_CONFIG;
    
    		$actual = $this->parseComposerConf('');
    		$this->assertEquals($expected, $actual);
    	}
    
    	private function parseComposerConf($string) {
    		return self::$DEFAULT_CONFIG;
    	}
    }

Ahhh! That’s better.

	function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $expected = self::$DEFAULT_CONFIG;
    
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertEquals($expected, $actual);
    }

Well. That also passes. But it also highlights some duplication and useless assignment.

	function testDefaultConfigFile() {
        $actual = $this->parseComposerConf('');
        $this->assertEquals(self::$DEFAULT_CONFIG, $actual);
    }
     function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertEquals(self::$DEFAULT_CONFIG, $actual);
    }

We inlined the $expected variable. $actual could also be inlined, but I like it better this way. It keeps the focus on what is tested.

Now we have another problem. The next test I want to write would look like this:

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
        '{"require": {
            "Mockery/Mockery": ">=0.7.2"
        }}');
        $this->assertContains('"Mockery/Mockery": ">=0.7.2"', $actual);
    }

But after writing the simple implementation, we will notice it requires json_decode() and json_encode(). And of course these functions reformat our string and matching strings will be difficult at best. We have to take a step back.

function testDefaultConfigFile() {
        $actual = $this->parseComposerConf('');
        $this->assertJsonStringEqualsJsonString($this->jsonRecode(self::$DEFAULT_CONFIG), $actual);
    }
     function testEmptyRequiredPackagesInComposerJsonWillProduceDefaultConfiguration() {
        $actual = $this->parseComposerConf('{"require": {}}');
        $this->assertJsonStringEqualsJsonString($this->jsonRecode(self::$DEFAULT_CONFIG), $actual);
    }
     private function parseComposerConf($jsonConfig) {
        return $this->jsonRecode(self::$DEFAULT_CONFIG);
    }
     private function jsonRecode($json) {
        return json_encode(json_decode($json, true));
    }

We changed our assertion method to compare JSON strings and we also recoded our $actual variable. ParseComposerConf() was also modified to use this method. You will see in a moment how it helps us. Our next test becomes more JSON specific.

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
            }}');
        $this->assertEquals('>=0.7.2', json_decode($actual, true)['require']['Mockery/Mockery']);
    }

And making this test pass, along with the rest of the tests, is quite easy, again.

private function parseComposerConf($jsonConfig) {
        $addedConfig = json_decode($jsonConfig, true);
        $config = json_decode(self::$DEFAULT_CONFIG, true);
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
        }
        return json_encode($config);
    }

We take the input JSON string, decode it, and if it contains a “require” field we use that in our Satis configuration file instead. But we may want to mirror all versions of a package, not just the last one. So maybe we want to modify our test to check that the version is “*” in Satis, regardless of what exact version is in composer.json.

function testARequiredPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
    }

That obviously fails with a cool message:

PHPUnit_Framework_ExpectationFailedException : Failed asserting that two strings are equal. Expected :* Actual   :>=0.7.2

Now, we need to actually edit our JSON before re-encoding it.

private function parseComposerConf($jsonConfig) {
        $addedConfig = json_decode($jsonConfig, true);
        $config = json_decode(self::$DEFAULT_CONFIG, true);
        $config = $this->addNewRequires($addedConfig, $config);
        return json_encode($config);
    }
     private function toAllVersions($config) {
        foreach ($config['require'] as $package => $version) {
            $config['require'][$package] = '*';
        }
        return $config;
    }
     private function addNewRequires($addedConfig, $config) {
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

To make the test pass we have to iterate over each element of the required packages array and set their version to ‘*’. See method toAllVersion() for more details. And to speed up this tutorial a little bit, we also extracted some private methods in the same step. This way, parseComoserConf() becomes very descriptive and easy to understand. We could also inline $config into the arguments of addNewRequires(), but for aesthetic reasons I left it on two lines.

But what about “require-dev” in composer.json?

function testARquiredDevPackageInComposerWillBeInSatisAlso() {
        $actual = $this->parseComposerConf(
            '{"require-dev": {
                "Mockery/Mockery": ">=0.7.2",
                "phpunit/phpunit": "3.7.28"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
        $this->assertEquals('*', json_decode($actual, true)['require']['phpunit/phpunit']);
    }

That obviously fails. We can make it pass with just copy/pasting our if condition in addNewRequires():

private function addNewRequires($addedConfig, $config) {
        if (isset($addedConfig['require'])) {
            $config['require'] = $addedConfig['require'];
            $config = $this->toAllVersions($config);
        }
        if (isset($addedConfig['require-dev'])) {
            $config['require'] = $addedConfig['require-dev'];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

Yep, that makes it pass, but those duplicated if statements are nasty looking. Let’s deal with them.

private function addNewRequires($addedConfig, $config) {
        $config = $this->addRequire($addedConfig, 'require', $config);
        $config = $this->addRequire($addedConfig, 'require-dev', $config);
        return $config;
    }
     private function addRequire($addedConfig, $string, $config) {
        if (isset($addedConfig[$string])) {
            $config['require'] = $addedConfig[$string];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

We can be happy again, tests are green and we refactored our code. I think only one test is left to be written. What if we have both “require” and “require-dev” sections in composer.json?

function testItCanParseComposerJsonWithBothSections() {
        $actual = $this->parseComposerConf(
            '{"require": {
                "Mockery/Mockery": ">=0.7.2"
                },
            "require-dev": {
                "phpunit/phpunit": "3.7.28"
            }}');
        $this->assertEquals('*', json_decode($actual, true)['require']['Mockery/Mockery']);
        $this->assertEquals('*', json_decode($actual, true)['require']['phpunit/phpunit']);
    }

That fails because the packages set by “require-dev” will overwrite those of “require” and we will have an error:

Undefined index: Mockery/Mockery

Just add a plus sign to merge the arrays, and we are done.

private function addRequire($addedConfig, $string, $config) {
        if (isset($addedConfig[$string])) {
            $config['require'] += $addedConfig[$string];
            $config = $this->toAllVersions($config);
        }
        return $config;
    }

Tests are passing. Our logic is finished. All we left to do is to extract the methods into their own file and class. The final version of the tests and the SatisUpdater class can be found in the attached source code.

We can now modify our cron script to load our parser and run it on our composer.json. This will be specific to your projects’ particular folders. Here is an example you can adapt to your system.

#!/usr/local/bin/php
    
    <?php require_once __DIR__ . '/Configuration.php';
    
    $outputDir = '/path/to/your/packages-mirror';
    $composerJsonFile = '/path/to/your/projects/composer.json';
    $satisConf = '/path/to/your/mirrored-packages.conf';
    
    $satisUpdater = new SatisUpdater();
    $conf = $satisUpdater->parseComposerConf(file_get_contents($composerJsonFile)); file_put_contents($satisConf, $conf);
     system(sprintf('/path/to/satis/bin/satis build %s %s', $satisConf, $outputDir), $retval); exit($retval);
    

Making Your Project Use the Mirror

We talked about a lot of things in this article, but we did not mention how we will instruct our project to use the mirror instead of the Internet. You know, the default is packagist.org? Unless we do something like this:

   "repositories": [
            {
                "type": "composer",
                "url": "http://your-mirror-server:4680"
            }
        ],
    

That will make your mirror the first choise for composer. But adding just that into the composer.json of your project will not disable access to packagist.org. If a package can not be found on the local mirror, it will be downloaded from the Internet. If you wish to block this feature, you may also want to add the following line to the repositories section above:

"packagist": false

Final Thoughts

That’s it. Local mirror, with automatic adapting and updating packages. Your colleagues will never have to wait a long time while they or the CI server installs all the requirements of your projects. Have fun.

SmashingConf NYC 2014 won’t solve all complex problems, but once it’s over you’ll know how to conquer yours. Our new conference in New York has 1 track, 2 conference days, 7 workshops, 18 excellent speakers and just 350 available tickets. With a heavy focus on networking and practical takeaways from real-life projects, you really don’t want to miss out on this one. To the tickets.

About The Conference

When we organize a conference, we make sure that it provides a lot of value for everybody involved. We don’t care about volatile trends and we don’t believe in overnight success stories. Every success requires hard work and many failures along the way. There are lessons learned, takeaways, and problems solved, but also many sketches and designs and ideas and prototypes thrown away because they didn’t work. We are interested in how problems are solved—ideas that failed, and why exactly they failed and what decisions were chosen instead.

SmashingConf NYC 2014 is a two-day event taking place at the TimesCenter in the very heart of New York. We won’t conquer all complex issues, but you’ll learn how to conquer yours.

And this is what the conference is about: lessons learned in front-end, UX, workflow and other design-related disciplines. This is what we encourage our speakers to share and what we are all going to explore in the conversations before, during and after the conference days.

Networking is important, and we’ll provide many opportunities for networking throughout the conference. Ah, and the party — oh, the party! You’ll remember that one! Taking place on June 17–18th 2014 in the lovely TimesCenter just next to Times Square in New York City, the conference will be nothing short of smashing. Booo-yah, baby!

First Confirmed Speakers

Okay. Ready for the first confirmed speakers? Get set. Go!

First confirmed speakers, Brian Suda and Divya Manian. Divya might even volunteer to run the legendary party in the evening — you never know!

• Brian Suda
  (Data visualization, SVG)
• Divya Manian
  (HTML5 Boilerplate, Adobe)
• Scott Jehl
  (Responsive Web design)
• Oliver Reichenstein
  (UX, typography, iA Writer)
• Aarron Walter
  (User experience)
• Jonathan Hoefler
  (Typography, H&FJ)
• Andy Hume
  (Front-end optimization)
• Cassie McDaniel
  (Storytelling, UX, Mozilla)
• Tim Brown
  (Web typography)
• Eva-Lotta Lamm
  (Sketching, UX, UI, Google)
• Jonathan Snook
  (Front-end development)
• Mark Boulton
  (Grids, Web design)
• Dan Rose
  (Photoshop, visual design)
• Mystery Speaker
  (Someone you definitely know.)
• …more speakers will be announced soon!

Hands-On Workshops

We’ll also host hands-on full-day workshops with practical techniques taught by masters of the craft. Be it responsive HTML newsletters, Photoshop techniques for responsive design, SVG techniques, or strategies for delightful UX, we carefully selected topics that will help you become better at what you do. So if you are going to attend the conference, why not attend a workshop as well?

In fact, we reserved 50 early-bird tickets for $549, and if you book a workshop too, you’ll save $100 off the conference + workshop ticket price. Well, enough already. Tickets are on sale now, you know.

If you always wanted to visit New York, or just happen to live around the corner (well, more or less), that’s just the opportunity you’ve been waiting for. Grab your ticket.

Why This Conference Is For You

The conference is for you because you’ll learn many valuable techniques for your workflow, and you’ll meet fantastic, like-minded people from the industry. You’ll learn:

1. Strategies for building fast responsive websites,
2. Smart SVG techniques for scalable, future-proof designs,
3. Clever Photoshop techniques for RWD workflow,
4. Tricks to design and build responsive HTML newsletters,
5. Insights about effective and smart problem-solving,
6. Hands-on techniques for sketching interfaces,
7. Techniques and guidelines for good Web typography,
8. Guidelines for smarter front-end and CSS architecture,
9. Advanced front-end tooling and setup,
10. Guidelines for delightful, engaging UX,
11. Mistakes and lessons learned from large projects,
12. How to increase productivity and stay happy,
13. …more practical takeaways from various areas of Web design.

Ticket Sales And Pricing

Only 350 tickets are available, and we do everything possible to keep our prices fair and affordable. The price for two full conference days is $549 for early-bird tickets, and $599 for regular tickets. And again, if you book a workshop as well, you’ll save $100. Yay! Get your ticket right away.

“8 reasons why you should send your incredibly hard-working, deserving employee to the SmashingConf” (PDF). Quite self-explanatory, really.

We also prepared a neat Convince Your Boss (PDF) (0.15 Mb) that you can use to convince your colleagues, friends, neighbors and total strangers to join you or send you to the event. We know that you will not be disappointed. Still not good enough? Well, tweet us @smashingconf — we can be quite convincing, too!

We Welcome Lovely Sponsors, You Know

We do everything possible to keep ticket prices affordable for everyone, and we welcome sponsors to help us create a truly unique, unforgettable conference experience. And you can be a major part of it.

We have quite a number of attractive and creative sponsorship packages for you, and we are also flexible and would love to adjust them to your needs. So if you’re interested, please email us at hello@smashingconf.com — we’d love for you to be involved!

See You In New York!

We are looking forward to seeing you in New York, and who knows, perhaps we can tackle more complex problems that we thought we would! See you there!

The conference will take place in the lovely TimesCenter, right off Times Square in New York. It doesn’t get any more central than that. Grab your ticket.

© Vitaly Friedman for Smashing Magazine, 2014.

Remember the Smashing Book Mystery riddle from a couple of months ago? Guess what: the Mystery continues! To celebrate the launch of the SmashingConf NYC and our lovely book, we’ve prepared a new riddle, and this time it’s not going to be any easier, but the reward is definitely worth the effort.

How does it work? Below you’ll find an animated GIF that contains a hidden message. Once you resolved the mystery, you’ll see a Twitter hashtag displayed in plain text.

Are you ready? Action! (Hint: watch out for the file name).

A hint: watch out for the file name.

What Can You Win?

Among the first readers who tweet us with the hidden hashtag, we’ll raffle a quite extraordinary, smashing prize (and a couple of other Smashing extras):

• a roundtrip flight to New York, USA,
• full accommodation in a fancy hotel,
• a ticket to the Smashing Conference New York 2014,
• any Smashing workshop ticket of your choice,
• full access to the Smashing eBook Library,
• a signed edition of the Smashing Book #4,
• a truly Smashing laptop bag,
• your very own Smashing caricature, designed just for you.

Please notice that to avoid spoilers, comments are closed for this post. And sorry, we aren’t going to make it too easy for you.

Alright. Let’s get to work. Or have you already figured it out? ;-)

© Vitaly Friedman for Smashing Magazine, 2014.

As a website designer, I’ve always been fascinated by design (of any kind) that “works” and why.

Of late, I’ve become particularly appreciative of the power of photography to anchor a visually appealing design that tells the right story, triggers the desired emotions, engages the viewer, and enhances the content (whether by breaking it up or calling it out).

This newly refreshed appreciation for photos really took root in Venice this past fall.

Venice: described as the “Most beautiful city built by man”

I’d always heard about Venice! And I had expectations I tell you! Expectations of a quaint, beautiful and romantic city built on the water — utterly different than anything I’d ever seen.

But in reality? … Venice is kind of a dump.

It’s weather-beaten, crumbling and run down. When you view it as a whole, you see a bunch of disparate scenery mish-mashed together. It doesn’t mean to be, but Venice is poorly dressed in rags and tatters.

But… When you look at Venice in tiny bits — when you let your eye “crop” out the surroundings and focus on one finite area — it’s a very different experience. There are so many details to delight the eye. Especially the eye of a designer who takes inspiration from everything that her gaze meets.

After realizing this, I could shift my focus from “the whole” to the details and back again and appreciate ALL of it. Venice really is a beautiful city.

The key takeaway here is, there is great power in cropping stuff out, so that what’s left in is a stronger.

Picture of Venice, before cropping (left) and after cropping (right).

One of my favorite “details” of Venice. The photo on the left is the raw image off the camera. Here, I did the cropping with the camera by zooming in to this detail. On the right, is the same image cropped further.

Photo crops that work

In the rest of this article, I’ll share some of my favorite photo crops from recent projects I’ve worked on.

Some are personal projects. Some are professional work through Gravity Switch (the web design and marketing agency where I’m cofounder). But all of them tell a story.

Fitness Fusion

Fitness Fusion is a niche studio gym known for intense, creative and fun group training and 1-1 personal training. When redesigning their site, I poured over 600+ photos in search of pictures that’d work in an extremely horizontal format — not an uncommon format for a web banner image, but always a challenge.

At first glance, the image on the left looks like an unlikely candidate. But when rotated 90 degrees counter-clockwise, flipped horizontally, and with the (now backwards) word “coach” on the cap stamped out, it’s a powerful banner image. Perfect for the “Meet the Trainer” page!

The crop above works because of:

• the warm lighting;
• the splashes of color;
• the genuine, focused, and approachable look in the eyes.

Together with the smiley photo of the page body content, the overall feelings conveyed are approachability, expertise, hardworking, a down-to-earth attitude, and fun!

Here’s another of my favorite banner image crops from this project. By removing parts of the original image (cropping it), we get a more dynamic, intimate, and interesting visual experience — a cool image that shows hard-work, dedication and sweat. The subtle touch of the gym’s branding on the wristband was an accidental bonus.

Stockbridge School of Agriculture

Stockbridge School of Agriculture at UMass Amherst is known as the top school of its kind in the country. It has diverse programs that attracts very different types of students (e.g. the prospective who’s interested in Turf Management is very different than the person who’s interested in Sustainable Food & Farming or Equine Management and so on.)

The challenge was finding a home page photo that:

• felt appropriate for a school of agriculture;
• was a strong image to draw the viewer in;
• didn’t alienate any potential prospect to any potential program; Do no harm!

On the technical side, we needed a photo that would work as a “floating crop” (i.e. the crop changes as the window is resized and it always needed to look good).

We did a specific photo shoot just to capture the image for the home page. We got many great shots. We narrowed it down to these 7:

Then we picked this one to go with:

We played with the zoom level of the crop in PhotoShop, to confirm that the photo is strong as a floating crop. Here’s a few explorations:

Here’s how it looks on mobile and desktop respectively:

Pioneer Valley Information Exchange – PVIX

Here’s a stock image that was used for a website in the healthcare industry… trying to show teamwork, family, positivity, energy, optimism:

Here’s an image treatment I tried, but didn’t like. You lose too much context zoomed in this much:

As an alternative (that I also didn’t like). I zoomed all the way out so you could see the whole photo. To make the width work right, I added blue space on the left:

A happy medium (cropping some of the image) works best:

Parenting blog post

I was looking for a picture of my son to be the “banner image” in one of my blog posts.

I found this picture. I love the expression on my son’s face. But he’s so tiny in the image and you don’t appreciate that detail:

Here’s how I cropped it. Works much better:

Getting it right

We’ve all heard the saying, “A picture is worth 1,000 words.” But how do we craft our images so that they convey the 1,000 words that we want?

Getting it right requires:

Good raw photos: If you can, hire a professional photographer so you can get shots and compositions that look good and are customized to your purpose. If you can’t hire a professional, there are many stock photography options — some are good, some less so. It’s best to have someone you trust to have an “eye for it” handle the job of photo hunting.

Good post-production: Color-correction, Clean-up and Cropping. I call it the three C’s.

Good photo placement: Incorporate photos into the design in the right spot, next to the right content, on the right page, and then the they will help tell the right story. Location, location, location.

How do you select images for your designs? How do you choose which parts of images to crop? Let us know in the comments.

The Design Kickstarter Bundle (400+ items) – only $17!

Eric Lawson is the latest to join the list of “Marlboro Men” to be killed by cigarettes .

 Lawson passed away on January 10^th at the age of 72. The cause of death was respiratory failure due to a smoking related illness.

 Lawson, an actor, donned the cowboy getup in the late 70s, taking on the persona of the über masculine “Marlboro Man.”

The campaign originated in 1954 and quickly transformed the cigarettes, previously known for their feminine “Mild as May” tagline, into a mainstream macho must-have.

 James Twitchell, author of 20 Ads That Shook the World, described the success of the campaign to the BBC:

“The Marlboro Man was strong, powerful. He never speaks. He’s so tough… The genius of the ad is that at the same time there was a rising realization that this thing will kill you, it was identified with a character who was, on the face of it, indomitable.”

Clearly, as time has told us, these men were not indomitable. Wayne McLaren was the youngest to pass away from lung cancer at 51. Richard Hammer and David McLean developed lung cancer and passed away at 69 and 73 respectively. David Millar died from emphysema at 81.

Some may consider 81 a long life, but most would like to live past 51. The younger McLaren went on a crusade against Phillip Morris (owner of the Marlboro brand) after his diagnosis. He is quoted as saying:

“Tobacco will kill you, and I am living proof of it.”

Eric Lawson was a public supporter of anti-smoking campaigns, despite his inability to quit. After all of his struggles, his wife Susan had this to say about his death:

“He knew the cigarettes had a hold on him. He knew, yet he couldn’t stop.”

The Marlboro Man might be a symbol that dies with its last living icons. The reality of smoking has set in. There’s more at stake than your image.

New software lets you mark places as off-limits for wearable camera gadgets like Google Glass.

With last year’s launch of the Narrative Clip and Autographer, and Google Glass poised for release this year, technologies that can continuously capture our daily lives with photos and videos are inching closer to the mainstream. These gadgets can generate detailed visual diaries, drive self-improvement, and help those with memory problems. But do you really want to record in the bathroom or a sensitive work meeting?