World, meet Apollo.

So, recently – a few weeks ago – I’ve added a new buddy to the family.

This is Apollo:

really wish these pumpkins came in adult human size

Long story short, someone who is an absolute fucking moron didn’t want some kittens left him + some siblings in a box overnight outside of an office, one thing led to another, and now he’s living with us.

Wasn’t sure if we’d keep him at first after nursing him back to health, but Atlas seems to have made his decision already.

Which honestly I was pretty surprised about. Been monitoring them over the last few weeks and finally have been letting them play, which has gone pretty well overall!

Anyways, pretty excited to bring the new guy into the fam and he’s been great/a demon so far, so that’s good.

How the punk scene can teach us to be better at innovation and failing

A while back, I’d seen an interview with @Jack, which had a moment that specifically stuck with me:

About 10+ years ago, my weekends – and life in general – consisted of going to shows, mostly local bands, but sometimes some of those little local bands got pretty big

Obligatory photo of my hair back in the day.

While I was a little late for the true “Punk scene” itself, these bands usually fell into either Ska or Post-Hardcore (“The Scene”), both of which draw their roots from the greats that came before in the Punk scene. Basically we had a ton of individuals trying to make some awesome music and sometimes they did… and sometimes they didn’t. The greatest part about this was that I could be describing the same band from a few months ago at their awful set, who now are suddenly completely jamming.

The appeal with this sort of music isn’t so much the technical expertise – though there are definitely some people who can shred/have insane vocals – but the passion itself that’s put into everything and is shared by both the musicians and the crowd itself.

No one expects these shows to be something amazing, but we do know that everyone on stage and in the crowd is going to give it their all in this group effort. Even moreso, the band on stage isn’t giving a shit about how well the band before them did in their set; they’re worried about putting on a better show than they did last week.

Keep jamming.

To be completely fair, a lot of the Punk scene itself would probably tell me to “go fuck myself” for at all pulling any relations between running a business and being Punk. And they’re really not wrong.

That said, while it might not match with the spirit itself of Punk, there’s definitely some wisdom to be learned.

Punk emerged during a time that had huge bands putting on these massive concerts, with insanely expensive and choreographed productions accompanying the music that the artists were playing. Instead of dealing with that, artists in the Punk scene pushed towards being real. Hop on stage with your guitar, a mic, and someone on drums/bass… and jam. Don’t worry about sucking, you’re having fun + putting yourself out there and if you fuck up, you’ll be better next week. Just have a good time and do what you’re trying to be good at.

A lot of companies/leadership in companies have an insanely difficult time with truly failing when trying something unfamiliar. There’s the stereotypical mantra of “fail fast, fail hard,” in the industry; however, realistically no one really wants to mess up a new product release, advertising effort, or change to internal policy. It’s just not a fun thing to experience.

… But it should be. Anytime that we decide to change something up, challenge the status quo of what everyone else – be it competitors in our market or somewhere else – is doing, we should take pride in the fact that while we might have missed the chord we meant to play here or there, or got out of tempo, that we still played our hearts out and will show up with some more kickass music next week. As long as the crowd (users/clients) is still there, we can all have a great show together and come back next week/quarter with something better.

I can guarantee you that almost every single huge band in the scene has started in someone’s garage/basement, played a few shows to a handful of people, had some shows where they completely missed the mark, and also have had shows where they’ve completely killed it.

The difference between the bands that kicked ass and those who didn’t, was that those who succeeded were the ones that kept jamming. They didn’t need huge fireworks or massive production value concerts. They needed an enthusiastic crowd, passion for music, and the will to give it everything they had when they hopped on stage.

The same goes for business/product launches/technical developments. If you’ve got a base, put something out that matches with their interest/goals and go from there. v1.0 is probably going to suck. That’s OK, just come out next week/quarter/etc with a new release and make it a bit better, then repeat. As long as you’re identifying with what your users want, a bad week isn’t going to shut the party down.

Don’t worry about”other bands.”

Everyone in the same market is trying to make the best thing that exists for the specific problem they’re trying to solve. That’s great, since there’s obviously a problem that needs to be solved.

If bands in the Punk scene got caught up in who was better overall, we’d have missed out on a ton of awesome music. Everyone has their own personal favorite, but as long as it matches the genre, most people are still going to like it.

The real focus should be on reading the crowd (your users) and making sure that you’ve improved from your last set (release). If you’ve got a crowd, they’re down to jam and realize that everything isn’t going to be perfect as you’re still learning how to make things better, just make sure you’re still keeping the same passion for your product and improving where you can.

No one wants to see a show where the band on stage doesn’t give a shit. Play your heart out and just keep improving.

Don’t fret over another band (company) having something better than you this time around. You’re all trying to solve the same problem, so if you’re passionate about doing so, you’ll keep at it and make something awesome.

In conclusion, embrace the Punk lifestyle. Play your heart out, don’t give a shit about the competition, and constantly improve – even if you suck at first – with the product that you’re putting out.

As long as you’re still putting out music, no one gives a shit if it’s not completely polished. Keep learning, adapting, and growing into something better: just don’t stop playing.

🤘 

Setting up a local WordPress development environment with Docker on Ubuntu 17.04

After working on a fair amount of sites recently, I’ve been looking for a better way to streamline the process for setting up a local development environment for WordPress sites that I work on. While I’m sure I’m not at the end of this journey, I’ve finally made the plunge into the wonderful world of Docker and it’s been great thus far.

 

This post essentially includes information from some other resources I’ve found online, mixed with some modifications from my end to make it better for my set-up. It also assumes you’re using a fresh installation of Ubuntu 17.04, but “freshness” doesn’t necessarily matter. YMMV.

 

 

To start, let’s install the tools we need for setting this up:

This will update your package lists and install the docker and docker-compose packages on your system.

sudo apt-get update && sudo apt-get install docker docker-compose -y

Once that’s all set, we need to run a quick command to make sure that we can run everything as your non-root user and also that we’ll have access to files later on:

usermod -aG docker,www-data ${USER}

At this point, log out and back in as your same user and you should be good to go, confirm so with:

groups ${USER}

And you should see docker and www-data listed. With that all set, let’s create our directory we’ll be handling everything else in:

mkdir wordpress_dev && cd wordpress_dev

We’re officially in our new working directory, so let’s get to work. First, create a new file called “docker-compose.yml”.

touch docker-compose.yml

This is going to be the configuration file that we’ll use to define how our containers should be set up. At this point, you can either run the following:

cat >docker-compose.yml <<EOL
wordpress_app:
image: wordpress
links:
- wordpress_db:mysql
ports:
- 8080:80
volumes: 
- ~/wordpress_dev/wp_html:/var/www/html
wordpress_db:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: your_password_here
volumes:
- ~/wordpress_dev/wp_db:/var/lib/mysql
EOL

To generate the file (make sure to change the “your_password_here” value to an actual password string), or you can instead open the file with your preferred text editor vim and just copy paste the following into it:

wordpress_app:
  image: wordpress
  links:
    - wordpress_db:mysql
  ports:
    - 8080:80
  volumes:  
    - ~/wordpress_dev/wp_html:/var/www/html
wordpress_db:
  image: mariadb
  environment:
    MYSQL_ROOT_PASSWORD: your_password_here
  volumes:
    - ~/wordpress_dev/wp_db:/var/lib/mysql

 

Otherwise, you can just download the file from here.

Let’s break down what these all mean, starting with the app container:

wordpress_app:

The name of your first container. This will be running the “web server” side of WordPress in our two container set-up.

image: wordpress

This tells docker-compose to use the “wordpress” image from the docker registry, which has all you need for a basic wordpress server.

links:
  - wordpress_db:mysql

This will link our separate container running mariadb to the wordpress_app container.

ports:
  - 8080:80

Designates port-forwarding for requests to “8080” to be directed to port “80” on the wordpress_app container. Basically allows us to hit localhost:8080 and view the site.

volumes:
  - ~/wordpress_dev/wp_db:/var/lib/mysql

Specifies a local directory on your environment to use for the /var/www/html directory of the container. This will allow us to have a directory in our “wordpress_dev” directory to use that’s connected to the docker container. And now the db container:

wordpress_db:

Name of the db container itself and start of the configuration settings of that container.

image: mariadb

This tells the container to use the mariadb image from the docker registry, letting us set up our database server in the container pretty easily.

  environment:
    MYSQL_ROOT_PASSWORD: your_password_here

This lets us specify an environment variable for the root MySQL user password, which is used when the mariadb service is configured in the container. Update this to something secure.

  volumes:
    - ~/wordpress_dev/wp_db:/var/lib/mysql

Same deal as above. Uses a directory under “wordpress_dev” to store database libraries. At this point, we can start up the containers. Do so by running the following:

docker-compose up -d

Which will start the containers in detached mode. Ensure they’re running with:

docker ps

Which will give you information on the two containers that we’ve created. Now that they’re created, we’re good to go. Just visit http://localhost:8080 and you should see the WordPress installation wizard. And that’s it. I might update this later with some more information on how git integrates with this set-up, but probably will do so via a different post. For now, you should be all set to access your local WP installation One extra tip is that if you need to access the WordPress installation’s database via mysql-cli, you can run the following:

docker run -it --link wordpressdev_wordpress_db_1:mysql --rm mariadb sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"'

Which I’ve personally bound to a bash alias:

alias wp_mysqlcli="docker run -it --link wordpressdev_wordpress_db_1:mysql --rm mariadb sh -c 'exec mysql -h\"\$MYSQL_PORT_3306_TCP_ADDR\" -P\"\$MYSQL_PORT_3306_TCP_PORT\" -uroot -p\"\$MYSQL_ENV_MYSQL_ROOT_PASSWORD\"'"

Return to WordPress.

So after messing around with Ghost for a bit and not really spending much time blogging at all, I've decided to give it (yet another) shot and this time I'm heading back to WordPress.

I've been following Gutenberg and finally decided to give it a shot. It's an awesome editor (am writing this post with it currently).

So that's where I'm at currently. Hopefully I can get some more posts on development/ops/whatever going and actually spend some time on this. For now, I think I'll end this post testing out the new "Spotify embed" feature in Gutenberg. 😀