Raid Games


Last weekend I was able to compete in the Elite division of the Raid Games. The Raid Games are held under the umbrella of the larger Europa Games. There’s a myriad of events held there (Powerlifting, IFBB events, Wresting, etc …). Just one of those is the Raid Games.

I’m going to jump ahead of myself and say the Raid Games is easily the most awesome event I’ve ever been a part of. The huge environment surrounding the event is awesome. That there are so many folks who are able to see what CrossFitters do, is also pretty awesome.

Additionally, that I was able to hang out with my buddies from my gym, CrossFit Firebase, as well as great friends from CrossFit eXalted, CrossFit KingsPoint, CrossFit 407, and CrossFit Country was great.

I went into this event, with very little expectation of doing well. I’m glad about this. It’s my first competition in 18 months, and predictably, I did not do well. However, I was able to hang with some incredible athletes. I learned a whole lot from this. I intend to make the most of those learnings.

I’ve been training for a long time for something like this. The weaknesses in my training became immediately apparent during the event. Things like muscular leg endurance and pain threshold were clearly weaknesses of mine. I’ll adapt and train appropriately going forward.

GORUCK Challenge


On May 19 – May 20, I participated in the GORUCK Challenge Orlando event. For those of you who don’t know what GORUCK is, I’d suggest the GORUCK FAQ. Here’s a quick summary of a GORUCK challenge event:

  • Wear a backpack with bricks in it.
  • Perform various PT type exercises with a group of about 20-25 of your new best friends
  • Ruck to somewhere far away
  • Ruck back
  • Expect various factors of suckage along the way


Overall I’d call the event one of the more difficult things I’ve ever done. I’ve hung out with a number of folks who have previously completed the challenge, and was adequately warned that it would amount to as much. The camaraderie is the only thing that overcomes the difficulty. I’d highly recommend this to all friends and colleagues that are in decent shape.

Cadre – Dave

Our Cadre (guide / leader / painmaster) for the event was Dave. Dave spent 18 years in active duty doing in various roles in Special Forces. Dave was a smaller guy than I had imagined we’d be lead by. Having said that however, Dave is a monster of a man: not in the physical sense, but you can’t escape the feeling that he’s got a vast amount more knowledge about the limitations of the human mind and body than most of us could ever know.


The grossest part of the evening :/

Class 172 started at the amphitheater on Lake Eola in Downtown Orlando. Our route put us around the lake, doing various forms of PT along the way. Within an hour we had our first casualty: a member passed out, and was unable to continue. We wound up in Lake Eola (gross), running to 7-11, then through Downtown Orlando during the primetime of the night scene. We headed to the new Arena, and to the Citrus bowl (directly through the roughest ghetto in 100 miles).

Flags, Ducks, Sand ... Check.

All the while, we were carrying our own packs (mine was just under #40) and 5 bags distributed among the team (each at #50), as well as the team weight: the head of a swan boat from Lake Eola. Doing all of this would have been enough, without the extra load.

When the fireman carry got to be too much, a two man carry was employed.

From the Citrus Bowl we took the scenic route to Citywalk. We had met some of the most interesting characters Orlando has to offer during the trek. Our march to Citywalk was a mix of running, indian runs, PT, and various other mental challenges. Along the way we were threatened by the intoxicated, rewarded with hydration, and questioned by criminals.

Inchworms. The worst thing you've ever wished you hadn't been through.

We got to the entrance of Universal Studios (Citywalk) around 7:30am. We got a group shot, and were able to lighten some of the #50 sand bags we’d been hauling around for so long. By that point, the less physically trained were showing signs of weakness. That’s not to take away from what they did though. If anything, those guys pushed themselves farther than any of us. For that, they have my respect.

Because of this however, our journey back to our starting point didn’t entail any other PT. I was a bit disappointed. I had expected to be pushed farther than I ever have been before. That certainly was not the case however. I had a very difficult time, but not as much as I had been worried about.


If you’re planning on doing the GORUCK Challenge, I’d suggest a few things:

  • Be in good physical shape. Crossfit is an excellent primer for the things you’ll encounter during the challenge. Having said that however, it’s not enough. I highly recommend practice rucks and extra running
  • Bring good gear. A friend of mine let me borrow his GR-1 for the event. That thing is awesome. I’m saving my pennies to get one of my own.
  • Hydrate heavily before the event. I had a gallon of water a day prior, and experienced no cramping at all
  • Eat like a complete asshole the day of the event. You’re likely going to expend somewhere on the order of 10,000 to 20,000 calories during the challenge. Because of this you’re going to need every calorie you can consume. This isn’t the day feel guilty about pizza. Find food, and stuff yourself

Final Thoughts

I’d love to thank everyone who was a part of class 172. My friends Ben, Mirason, Brenna, and Ramon were great to have for the ride. I met a ton of awesome new friends that I can’t wait to join to complete another event. A huge thanks to Dave for being an amazing leader during the event. This was my first event. I can guarantee you it won’t be my last.



The season of lent is over. For this season, I gave up all alcohol. For those of you that know me well, you’re aware how difficult this was for me to do. Well, you’re aware how difficult it *appeared* for me to do.

The truth of the matter is: not drinking for 6 weeks was significantly less challenging than I thought it would have been. The reason for this: I believe in God far more than I require anything the world has to offer. I’m embarrassed to admit it, but I’m surprised by this revelation.

I’m writing all of this, after having a nice share of Jack Daniels this evening. I didn’t give up alcohol forever. I gave it up for 6 weeks to recognize the sacrifice that my savior gave while still in human form upon the Earth. It sounds trivial to many of you. This gets me to the point of why I’m writing at all.

Faith requires courage.

Some of you will scoff at this statement. I challenge you, however, to deny it. Tell me that it takes courage to discredit the believer. Tell me that it takes more courage to find examples of inaccuracy of a statement of faith. Tell me that believing in nothing demands more than believing in something.

I believe in the LORD, Jesus Christ. He is the only son of God, who gave his on mortal life for all of us that we might have the opportunity to know eternal life. There is no other gateway to this path than recognition of who He is.

For those of you who discredit this notion, tell me; what *do* you believe in?

Recognizing the courage of this statement doesn’t take much intellectual investment. Any time you have believed anything to be true, you’ve undoubtedly encountered skeptics. You are aware that skepticism, by itself, is cowardice. Skepticism, with a counter-belief, is a belief.

That is, again, the point. Belief is Faith, and faith requires courage.

Versioning WordPress Content


Something that winds up being difficult when developing for WordPress (or Drupal, or any other database heavy CMS), is the versioning of content. Databases aren’t under your SCM directly. Because of this, deploying changes to production can be dicey.

The scenario is typically something like this:

  • Client wants 5 new pages, and a few revisions to existing pages.
  • Developer creates pages and makes modifications on staging environment.
  • Client requests revisions
  • Developer revises staging environment as requested.
  • Client approves
  • Developer has to remember what he did, and repeat those steps in production.

Needless to say, this practice is fraught with potential for error. If this is 80% successful, I’d be surprised. That’s not going to cut it for most clients however. If your doctor was 80% successful, you’d be very upset. If traffic lights were 80% successful, you might be dead.

So, there needs to be a way to snapshot your staging environment, and push it to production. Unfortunately, there aren’t many tools that do this sort of thing directly. Even the ones that do, are often not done very well. A hand-written solution is possible however. It’s really not even that hard to do.

Enter bash, and ant.

I suspect many of you are rolling your eyes right now. “BASH? ANT? That’s for nerds!” You’re right about that. However, to get across this issue, it’ll help you to learn from some nerds.

For this tutorial, let’s assume you have the following folder structure for your wordpress site:

 - public (wordpress content)
 - var
 - - log
 - - backups
 - tmp (sessions, cache, etc)
 - etc (configurations)
 - bin (scripts)

Here’s a bash script you can run, to dump your database into 3 different formats (dev, staging, and production):


#dump the database to var/backups, replacing local information
mysqldump -u root -p database_name > var/backups/dev.$(date +%Y-%m-%d).sql
mysqldump -u root -p database_name | sed 's/dev\.site_name/staging.site_name/g' > var/backups/staging.$(date +%Y-%m-%d).sql
mysqldump -u root -p database_name | sed 's/dev\.site_name/www.site_name/g' > var/backups/production.$(date +%Y-%m-%d).sql

# navigate to the backups folder, and create the updated symlink
cd var/backups

# remove old symlinks
rm development.sql
rm staging.sql
rm production.sql

# create new symlinks
ln -s dev.$(date +%Y-%m-%d).sql development.sql
ln -s staging.$(date +%Y-%m-%d).sql staging.sql
ln -s production.$(date +%Y-%m-%d).sql production.sql

That will dump the contents of your development environment, replacing anything that says “dev.site_name” into the appropriate substitution for your other environments. I use a development, staging, and production environment for most of my work, but you might have different ones. Adjust these scripts as necessary to accomodate what you require.

One more note: That script will ask you for the root password three times. You’re more than welcome to change the user from root as well. I do this, because typically I run these scripts on my local machine. I don’t really care about username / password security of the dev sites on there. I’m not using those credentials anywhere else.

So, to import these changes into a staging, or production environment, I typically use ant. This automates most of the work for me. Here’s an example script:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project>
<project name="" default="build">

    <!-- build details left out for brevity -->

    <target name="backup-development">
        <exec dir="${basedir}" executable="bash" failonerror="true">
            <arg line="../bin/" />

    <target name="import-development">
        <exec dir="${basedir}" executable="mysql" failonerror="true">
            <arg line="-u mysql_user -pdatabase_password mysql_db_name -e 'source ${basedir}/../var/backups/development.sql'"/>

    <target name="import-staging">
        <exec dir="${basedir}" executable="mysql" failonerror="true">
            <arg line="-u mysql_user -pdatabase_password mysql_db_name -e 'source ${basedir}/../var/backups/staging.sql'"/>

    <target name="import-production">
        <exec dir="${basedir}" executable="mysql" failonerror="true">
            <arg line="-u mysql_user -pdatabase_password mysql_db_name -e 'source ${basedir}/../var/backups/production.sql'"/>

    <target name="development" depends="clean,build,import-development" />
    <target name="staging" depends="clean,build,import-staging" />
    <target name="production" depends="clean,build,import-production" />

So, the process now goes like this:

  • Client wants 5 new pages, and a few revisions to existing pages.
  • Developer creates pages and makes modifications on staging environment.
  • Client requests revisions
  • Developer revises staging environment as requested.
  • Client approves
  • Developer runs backup scripts, and adds updates files to SCM.
  • Developer runs update on production, which should also fire the import-production target

There’s plenty more to this than what I’ve written so far, but this is the generality I’ve been working with for a while. It’s served me pretty well.

Men and Women


Recently, a friend of mine posted a link to a blog post that got me thinking about the dynamic between married men and women. I offer an opposing view to Denise’s position on the lack of effort put out by married men.

Denise makes a long point to highlight the efforts she, and most women, put forth in a family relationship. She also points out that despite the faults of her husband, he does things that she appreciates. As a married man myself, I can’t emphasize how much that last part goes a long way.

While much smarter people than I have written plenty on this, it bears repeating: Men and Women are different. There is no escaping that women excel at things men statistically do not, and vice versa. Embracing this difference is key to a successful relationship.

This speaks to the nature of any successful relationship – Empathy. While my wife does a number of things that drive me crazy, I get nowhere with her if I don’t first recognize why she’s being the way she is. She feels the way she does for a reason. Making the effort to understand is like opening the door before entering the house.

I bring this up, because while Denise mentions how her husband is still good to have around, the bulk of comments on her page suggest otherwise. Most comments on her page are women ranting about the worthlessness of their husbands. One even offers divorce as motivation. I take offense to this. While plenty of men could use a lesson in gumption, the majority of men I know do not

I don’t recall seeing anything detailing a typical married man’s frustrations. So, here’s a few things I’d answer these women with.

I’m a man, so I don’t multi-task well (as well pointed out by other posts). My day however, consists of quite a lot of that. I have to do plenty of that at work. When I get home, I have to do even more.

Switching between the demands of employees and employers, and the demands of a wife and twin kids is difficult. Quite often it highlights the inadequacies that I’m terrified define who I am. Reading the comments of these women hits me between the eyes: I am not enough, I am never enough, I have never been enough.

There are so many indirect assaults on the fears of male inadequacies in American culture it’s difficult to even start to complain about it. Between jokes about male sexual failures, the lack of efforts put forth in family life, and jokes about a husbands mechanical abilities. All of these common jokes in society only tell men one thing: You are not enough.

The way men respond (typically) to these messages, is withdrawal. If you’re wondering why your husband doesn’t help with certain things around the house, it’s likely because he doesn’t feel he’s doing it right. Think of the last time you were told how badly you were doing something. It didn’t encourage you to try harder, did it?

I’m sure there are plenty of similar messages our culture sends women. I think there’s quite a lot more documentation of those complaints though.

Ladies: If you want more from your men, encourage him. Berating him will get you nowhere.

Enterprise PHP Development


While working at EZYield, we’ve come across a shortage of qualified Enterprise Level PHP Developers. While that term might sound a bit nebulous, there’s really just a handful of things that separate the men from the boys in PHP. Honestly, those traits really aren’t even that hard to learn. They’re contradictory to the “rockstar” persona so commonly heralded by developers though; which is likely why there aren’t enough good developers around.

Basically, there’s 4 things that make a developer ready for the big leagues: design patterns, unit testing, versioning systems, and experience.

Design Patterns can’t be emphasized enough. Almost every situation a typical developer has encountered, someone else has already solved. While the solution was likely in a different language, the concepts are universal. If a candidate cannot answer questions about basic design patterns like Singleton and Factory, they’re ability to adequately handle the responsibilities of a large scale application is seriously in question.

Unit Testing is an equally critical skill for any developer to understand. 90% of developers I interview typically work alone on small projects. this scenario doesn’t reveal the necessity for unit testing. Imagine that you work with 50 other developers on a project that’s hundreds of thousands of lines (if not millions) of code that’s distributed across hundreds of servers over multiple continents. Your amazing class that handles some unique circumstance will be modified by someone else who didn’t know you’re awesome intentions. How will you ensure your code works as intended without automated testing? Unit testing ensures that the concepts that sparked the intent of some software are held for posterity

Versioning systems are another area of knowledge that are surprisingly deficient in PHP Developers. CVS, SVN, Perforce, Mercurial, and (preferably) Git are software packages that any software business relies on. Not knowing the concepts of distributed software versioning software is like not knowing how to push the brake pedal on your car. You might get pretty far without needing it, but eventually you’re going to get into a situation which will crush you.

Experience. Nothing substitutes this. The brilliant young developer can make an awesome idea for his own company. He cannot serve a large company with existing ideas any better than a mediocre developer that listens to what he’s told to do. Software development is still more of an art than a science. Actually, it might be better denoted as a trade. Experienced artisans are able to accomplish things that younger folks cannot.

To re-iterate the point. Know design patterns, know unit testing, know version control software, and keep doing it. If you’ve been developing for years and are short on some of these points, take the time to learn. These skills are paramount and no one skill makes up for another. They are all indispensable in separating junior developers from enterprise level developers.