Email notification on new artifact build using AWS Lambda


  1. You have installed and configured AWS CLI
  2. You have a third party mail service setup already (we use mailgun for this example).

The entire process for this simple effort requires a handful of steps:

  1. Install SAM Local
  2. Define your Lambda in AWS Console (can also do so using CLI)
  3. Write your function!

SAM Local

First, let’s install SAM Local.

SAM Local is an amazing tool written by Paul Maddox from the AWS team that allows you to build and test Lambda functions locally.

npm install -g aws-sam-local

Later, we’ll use event.json as a sample file we test our function with, so build that quickly; for example:

Define your Lambda in AWS Console

You can easily simplify this process using the aws cli but for this we’ll simply share a simple step-by-step that outlines the function for a first time developer.

  1. Create a New Function
    1. Author from scratch
    2. Name it something you’ll recognize later
    3. Runtime Node.js 6.1.0
    4. Role Choose an Existing Role
    5. Select a Role that has policies to execute Lambda functions, and access SSM Parameter Store (and anything else your function will be doing).
  2. Function Designer
    1. Select S3 from the left column
    2. Scroll down to Configure Triggers
    3. Select an appropriate bucket, and then make sure you have the trigger enabled.

Write your Function

Once complete, we’ll be zipping our node_modules and index.js file and uploading them to the Function via the console.

Testing Your Function

First, SAM will need a template.yml file to work correctly.

From here, you can test your function and iterate as you develop locally with the command below:

sam local invoke "MyFunction" -e event.json

re:Invent 2017!

I am so excited to be going to re:Invent this year. Coupled with the opportunity to visit with some family, it’s going to be an extremely action-packed week of pure awesome.

It felt like college course selection all over again, except there were too many that I was interested in and I did my best to pack every second of the day instead of only classes that started after lunch.

Being an adult is cool sometimes.

Improve Symfony3 cache/logs performance by environment

Tired of the permission errors with your cache/logs in a Vagrant environment? Me too!

After being mildly annoyed with having to manually delete /var/cache and /var/logs repeatedly during “local” development, I decided to brut force matters into my own hands and solve this little annoyance once and for all. Ironically, Symfony 3.3 is addressing some of this, so it may be obsolete by then, but in the meantime…

What are we doing here?

  1. Define cache and logs directories for a specific environment.
    1. Wouldn’t it be awesome if we could customize these as parameters in the FrameworkBundle? Yes, yes it would!
  2. Write a simple CacheCommand that overrides the default cache:clear
  3. PARTY!!!!

Customize your getCacheDir and getLogDir methods by your environment

In my case, I typically use Vagrant/Virtualbox for local development, and Docker containers/bitbucket-pipelines for “test” while Production is a variety/flavor of AWS EC2 instances which have some additional flare.

Write a CacheCommand you can love and cherish forever and ever


Now you can enjoy life and all references to cache:clear will run your new and improved command that will also work noticably faster in Vagrant development environments; thanks entirely to Benjamin Eberlei and his wonderful blog post.


cd /path/to/myapp && php bin/console cache:clear