JacobBennett

Recently when refactoring a Vue 1.0 application, I utilized ES6 arrow functions to clean up the code and make things a bit more consistent before updating to Vue 2.0. Along the way I made a few mistakes and wanted to share the lessons I learned as well as offer a few conventions that I will be using in my Vue applications moving forward.

The best way to explain this is with an example so lets start there. I'm going to throw a rather large block of code at you here, but stick with me and we will move through it a piece at a time.

<script>

// require vue-resource...

new Vue({

JacobBennett

<div id="app">
  <div class="container" style="margin-top: 3em">
    <div class="row">
      <div class="col-md-6 col-md-offset-3">
        <div class="panel panel-default">
          <div class="panel-heading">
            <h4>Add Student</h4>
          </div>
          <div class="panel-body">

JacobBennett

Loading Laravel Sentry package only for production

In the case that you don't want development errors making their way to Sentry for error tracking, you can use the code below to ensure that Sentry will only record exceptions when in production.

First, instead of loading the SentryLaravelServiceProvider in the config/app.php providers array, we will load it in our App/Providers/AppServiceProvider.php. This allows us to check the environment before loading the appropriate service providers.

Seconly, in our App/Exceptions/Handler.php we again check for the production environment before trying to capture the exception using Sentry. This second step prevents Sentry from trying to catch an exception when it isn't bound in the container.

JacobBennett

Markdown Reference Tables

Using Details In MD

Copy SHA reference to Git commit

JacobBennett

TLDR: Click to Download my Software Development Life Cycle Document

---

What is your policy on the use of production data for development?

How does someone go about creating a new feature?

What do you do when you encounter a bug in your software?

JacobBennett

When a Laravel Job is dispatched that takes an Eloquent Model as an argument in the constructor, you can use the SerializesModels trait which will only serialize the model identifier. When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database (docs). Taylor also announced that in Laravel 5.3, you will also be able to do this with Eloquent Collections! (link)

So why is it necessary or helpful for the framework to re-retrieve the model values from the DB at run time instead of just serializing the attributes of the given model or collection? Let's use a contrived example to demonstrate.

Let's say that you create a new job called SendWelcomeEmail that will be dispatched from your RegistrationController each time a new user signs up for

JacobBennett

Favicons are out of control. Try to look up the correct favicon stack and see how many answers you get. The standard is that there is no standard. Once you do finally decide on a compromise for what your favicon stack, you still have the manual image resizing, formatting, saving, and naming to do! In a word. Annoying.

Thankfully there is hope! realfavicongenerator.net, a site I recently ran across does all of this for you and more. Not only will it generate the favicon HTML stack for you, it will take your image and convert it to the requried sizes, formats, and naming conventions needed to create this massive stack of favicon garbage. The site also provides compression options, platform specific icons and cache-busting favicon URLs.

Next time you need to add a favicon to your site, save yourself the migrane and jump to realfavicongenerator.net

JacobBennett

I recently had the need to write a small url shortening application. I am aware that this problem has been solved quite a few times before, but what is being a developer if not reinventing the wheel just for the heck of it? Custom CMS anyone?

Knowing that this was going to be a tiny RESTful API and also knowing that Laravel 5.2 had API rate limiting built in, I was eager to give it a try. Taylor Otwell being Taylor Otwell shipped 5.2 with the rate limiting defaults set up out of the box and I had my application building out short url's in a matter of minutes. The problem for me came when I wanted to start associating those short urls with a user.

Typically my applications have a UI and authentication is done through a simple login page. Obviously for a RESTful API, having a login page isn't ideal. Instead, my hope was to have users append an api_token to the end of their query string and use that to auth

JacobBennett

{
  "Version": "2012-10-17",
  "Statement": [
 {
      "Action": ["s3:GetBucketLocation", "s3:ListAllMyBuckets"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::*"]
   },
    {
      "Action": ["s3:ListBucket"],

JacobBennett

var DesktopNotify = (function(){

	var bindUIElements = function() {
        	window.addEventListener('load', getPermission);
	};

	var init = function() {
		bindUIElements();
	};