David Hemphill

Leaving Church Media

I’m sad to say that as of February 14th, I will no longer be working onsite at Church Media Group. I’ll be joining Fort Worth-based music startup The Music Bed as Lead UI Developer working on some exciting upcoming projects. It will be a bittersweet transition, but I think it will bring some new opportunities to grow as a person, and in my craft.

I’ve been a part of some really hard, exciting, and stretching experiences. Fighting a slew of MMA matches in a cage. Leaving my hometown to help plant a church in a radically different state, with no job or clients, and really no home to go back to. Moving again to a state I’ve only been to a few times for a few days to take a Senior Designer position. And now, leaving the comfort and familiarity of great friends and steady work to take a position at a startup. Why do I continue to do things like this?

Stay around me long enough and you’ll realize that I’m never satisfied. I’m always looking for the next challenge, never accepting the status quo, and always trying to push myself further. My CMG crew are all too familiar with me trying to convince them to use Sublime Text, LiveReload, Grunt.js, Gulp.js, Sass, Amaretto, Vagrant, Laravel, or any of the other exciting technologies I’ve been playing with. I’m energized by learning new things and this transition brings the opportunity to do that. I really want to love my wife well, and do the best work I can.

What can I say about my friends at Church Media? From my early days doing Photoshop comps for Ismael Burciaga, to meeting my good friend, CEO and mentor Yuri Star, to working alongside some great designers, developers, support staff, and project managers, I can say that I’m blessed to know these people and to have worked with them. There’s plenty to miss about each one of them.

I’m gonna miss petting Solomon in the mornings. I’m going to miss 7-11 runs for Big Gulp Dr. Peppers. Endless Double Dave’s pizza. I’m going to miss 3:00 Coffee Time. All the endless GIFs. I’m going to miss writing nonsense on our whiteboards and I guess I’ll never know who Jurgen Beck is. But most of all, I’ll miss working with these people every day. They’re a talented group and I consider them family. I love you guys. Let’s not be strangers.

I’m feeling a range of different emotions right now. I’m excited about the change up ahead, and incredibly nervous. But I feel at peace about the transition because everyone has been so gracious, supportive and loving.

Laravel Tip: Random Model Scope

In Laravel, there is the concept of Query Scopes which allow you to re-use logic in your queries for getting things such as, say, active members, or male users.

I was needing to get a randomized set of Users for a project I was working on and came up with this dead-simple way of doing that using a random() scope.

I simply made a scope on my User model with the following:

/**
 * Get random users
 */
public function scopeRandom($query)
{
    $query->orderBy(DB::raw('RAND()'));
}

This allows me to reuse this logic instead of putting it in the controller each time. I can easily get a set of random user like this:

User::random()->get();

Hope that helps!

How to Install the New Laravel Installer Terminal Client

Well, Laravel 4.1 was installed today, and looks like a feature-packed release. You can learn all about it here.

In addition to many other great changes, there is also the ability to install Laravel using a command line tool, which is awesome. But for newbies and designer types, installing this tool can be hard. Don’t worry though, you can do it.

  1. Open your Terminal client.
  2. Type this in. We’re going to be downloading the file using wget, rename it, move it to /usr/local/bin. (Don’t type the $), and then make it executable. You’ll need to have wget installed. Here’s how:

    $ wget http://laravel.com/laravel.phar
    $ mv laravel.phar /usr/local/bin/laravel
    $ chmod 777 /usr/local/bin/laravel
    
  3. Install a new Laravel project using your terminal client:

    $ laravel new blog
    

Hope that helps someone. Let me know if you have any problems!

Setting up Post-Receive Git Deployments on Webfaction

Although the title looks scary, if you’re looking for this information it can be kind of hard to find, especially for designer types hacking on personal projects. The basic idea is that you want to commit changes to a Git repository, and deploy those changes to your production box. To do this, we can set up what’s called a post-receive hook in your production repository. This post-receive hook will run after changes are pushed. I use Webfaction, so I have SSH access, Git and all that good stuff.

Create the Post-receive Hook

To do this, you need to SSH into your server, cd into the repo, and run some Git commands to create the hook. This will use the cat command to create the post-receive hook and make it executable.

$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/home/username/webapps/reponame git checkout -f
GIT_WORK_TREE=/home/username/webapps/reponame git reset --hard
$ chmod +x hooks/post-receive

Obviously, you’re going to want to change the various directory names and such to what works for your setup.

Add the Production Repo as a Remote

Next you might want to add that repo as a remote. That’s simple.

git remote add production ssh://username@username.webfactional.com/~/webapps/reponame/

Make Git Like It

Now Git is going to freak out on us when you try to push to production because it’s already checked out on the server. To get around this, we have to set the configuration option receive.denyCurrentBranch to ignore.

git config receive.denyCurrentBranch ignore

That’ll get Git to shut up and you should be able to push to your new production environment.


Update: You might be wondering how you can push your changes to both Github and your live production server at the same time, instead of doing each one individually. What you can do is create a remote that has both of the repos you want to push to in it. For example, you

$ git remote add all origin-ssh://git@github.com/username/reponame.git
$ git remote set-url --add all production-ssh://username@username.webfactional.com/~/webapps/reponame/

You should then be able to run git push all --all and have your changes be pushed to both your Github repo and your production one.