Cowboy Coding To Professional Developer

Notes and slides from my WordCamp Kansas City 2015 presentation 'Cowboy Coding To Professional Developer'. (these are my presentation notes straight out of Evernote... please ignore formatting and grammar issues) The first half of the talk has general tips on being a better developer and the second half of the presentation is focused on a professional WordPress developer's workflow and quick tips. The goal of the presentation is not to tell you how to develop - but to provide singular tips that will, individually, make you better. You don't need to adopt them all at once. Use them as needed as each is generally independent from the next. TL;DR Don’t code live on your production server (yeeeee-haw). Use version control. Be nice, use standards, and avoid shiny object syndrome. This presentation contains bite sized nuggets - suggestions where if you take one thing away from this talk you will be a better developer. You don't have to do everything at once. Incremental improvements are easier to turn into habits. I’m not going to take to big of a deep dive but have added a ton of references in the presentation notes so you can explore on your own.  What is cowboy coding? Cowboy coding is flying by the seat of your pants development - editing files live on a server just to see what happens. There’s nothing wrong with it - unless you are getting paid. It’s an essential part of learning a programming language, framework, library or platform. It’s a great place to start… but it’s also dangerous when you are dealing with other people’s systems, websites, and codebases. A Better Developer Being a better developer is rarely about learning syntax, patterns, and conventions. That's the easy part. It's how you work that matters It’s being pragmatic, conventional, efficient, and empathetic. TL;DR Don’t code live on your production server. Use version control. Be nice, use standards, and avoid shiny object syndrome

Being A Better Developer

Be Pragmatic

• Be practical and care about your craft
• Don’t try to solve problems you don’t have
• Don’t optimize early
• Don’t over-abstract
• if something works - it works. stop tweaking and move on
• make quality a requirement

Be Empathetic

• Someday, someone else is going to have to work on this code. Don’t make them think.
• If you have to include a README with every project you work on so another dev can pick it up. Think about it first.

Learn source control from the start

• preferably git
• Source code control is a time machine for your work—you can go back
• Source code lets you sanely work with other developers

Use Standard Conventions

• If you are an empathetic developer you will be thinking about future developers when you are designing systems. There’s nothing worse than jumping into someone else’s code and have no idea how it works.
• Following conventions helps alleviate the pain of adding another developer to the project. They don’t have to figure out ‘how you code’ and try to fit their styles into yours

Tools don’t matter. Tools are everything It’s not about what tools you use - it’s about what tools you are productive with. Don't force your tools on anyone else. Be A Good Teammate

• this goes back to being empathetic… think about the other developer when you are writing code
• don’t arbitrarily add required tools and frameworks to a project if your team isn’t familiar

Avoid Shiny Objects

• You’ll hear a lot of talks about awesome tools like Grunt/Gulp, Bower, Composer, NPM, SASS, LESS, and more. But do you REALLY need them? A professional developer will take a pragmatic approach to the tools she uses rather than what’s trendy.
• Do you REALLY need to run gulp tasks to minify all the things for a website with one developer and 1,000 visitors?
• The more tools you add the more complex your system and the harder the handoff (or the picking back up on your part in a year after you’ve switched to the latest toolset the cool kids are using)

Be Verbose

• leave detailed comments in your code
• leave detailed comments in your commits

Automate Things

• the definition of insanity is repeating yourself
• if you can automate something - do it….
• but think before you automate

Code in Objects

• learn and use object oriented coding standards
• reduce code duplication
• simpler, testable functions
• can use singletons and inheritance
• easier to share code due to readability and general understanding

Test Your Software

• or your users will
• unit tests, automated tests, continuous integration

Don’t Repeat Yourself

• refactor often
• abstract common functionality

Working With WordPress

The thing I like most yet despise most about WordPress are the infinite ways you can do something. These may not be the best ways or your ways… but anything is better than nothing. Use A Local Dev Environment

• first step in not being a cowboy is to get your own sandbox - a place you can develop and test on that’s easy to rollback (hello git)
• Doesn’t matter what you use, just use something (ie tools don’t matter tools are everything).
• Popular Solutions include MAMP Pro, Desktop Server, VVV
• Get your favorite editor and your favorite terminal
• Popular Git UI’s include Tower and Github
• My setup is MAMP Pro, Atom, iTerm, Git bash
• this is also a good time to mention … you may want to add a staging environment to the mix. There’s a good chance you’re local dev environment won’t mimic production. It’s fine 95% of the time but to really make sure you can setup a staging environment to deploy to that is a replica of your production environment. Y

Syncing Data

• so you have a local development environment to work on a site that’s been live for a year… how do you know you are dealing with the same set of data
• I recommend WP DB Migrate Pro
• easy data migration
• push / pull to synchronize data between environments
  • ie - pull from production to replicate the live site in your local environment OR sync data between dev / staging / and production.
• tools exist so you never have to dive into SQL / PHPMYADMIN anymore

Deploy with sanity

• Stop doing things manually
• Use WP-DB-MIGRATE to move data
• Use WP-Pusher to deploy updates from a Git repo (no FTP, yay!)
• Use Git to pull/push on your server
• Capistrano or Chef

Being A Better WordPress Developer

Doing things “the right way” in WP dev is harder than ever it seems to me. Or more likely just catching up from Wild West years. — Brian Krogsgard (@Krogsgard) January 2, 2015

Easy tips to be a better WordPress developer. You don’t have to use all of these tips at once. But when combined they will increase your super powers. Pick and choose as you have problems or roadblocks and use them as a chance to improve your environment, workflow, or productivity. Use WP_DEBUG

• When doing local development
• It will write PHP errors to the screen
• You don’t generally want to ship anything with errors :)

What should be in a Git repository?

• Should I check the entire WP install into Git or just the themes / custom plugins individually? YES.
• Depends on your situation and team
• Never check in wp-config.php
• you don’t want passwords in a repository
• you don’t want to accidentally put WP_DEBUG in production
• Pros of checking in the entire site
  • If you check in everything it’s easy for another developer to clone the entire project and start working
  • If you check in everything you can version updates of your entire site to stage WP core and dependent plugin updates
• Cons of checking in the entire site
  • WordPress and plugins are version controlled elsewhere and it’s hard to stay up to date

Separate your concerns

• Use plugins for functionality, Use themes for design
• Don’t add functionality to your theme’s functions.php - instead create a functionality plugin
• Even better - build small, maintainable plugins to manage your site
• Allows much easier updates
• Much less dependency
• IE if you have a custom post type - make its configuration, implementation, and registration a singular plugin

Use WordPress Coding Standards

"Coding standards help avoid common coding errors, improve the readability of code, and simplify modification. They ensure that files within the project appear as if they were created by a single person. Following the standards means anyone will be able to understand a section of code and modify it, if needed, without regard to when it was written or by whom. If you are planning to contribute to WordPress core, you need to familiarize yourself with these standards, as any code you submit will need to comply with them"

Use Core Features Theme Customizer, Settings API, Options API, Image Thumbnails, Menus, Widgets, Shortcodes and more make development easier Enqueue ALL The Things Make sure to use wp-enqueue when including scripts or stylesheets in any plugin or theme. Use Template Parts

• create reusable theme snippets
• create reusable loops
• reduce and reuse code

Validate, Sanitize, Escape

• validating = checking user input
• sanitizing = cleaning user input
• escaping = securing user output

Transients Are Your Friend

• simple caching means big performance gains
• store data you expect to expire
• example: custom query results, api responses, etc

Variable Scope

• use namespaces and classes to scope your variables
• don’t define unnecessary globals

WP-CLI

• a command line interface for WordPress
• setup, install, and configure sites from your terminal
• easily create scripts
• automate and schedule db migrations

Manage Dependencies

• you can use plugin_exists( ‘my-plugin’ ), class_exists( ‘MyClass’ ), or function_exists( ‘my_awesome_function’ ) to ensure a dependent plugin is active
• TGM Activation Plugin
  • require / recommend dependencies in your custom themes and plugins
• Use Composer
• good option if custom plugin / theme requires third party dependencies

My toolset

• Editor: Atom.io
• Local Dev: MAMP Pro
• Terminal: iTerm
• Source Control: Git with Bitbucket
• Data Migration / Sync: WP DB Migrate Pro
• Deployment: WP Pusher, Git
• Management: InfiniteWP

My workflow

1. Grab a task (from Github, Trello, or Jira)
2. Pull latest version of the project from git
3. Pull latest version of data with WP DB Migrate Pro
4. Code feature / bug fix
5. Commit and push code to repo with verbose comments and link to ticket/issue
6. Deploy with WP Pusher or Git

Link Dump

Better Developer

Learn Git In Your Browser - learn

Object-Oriented PHP for Beginners - read

Workflow

Installing a Local Server - read

How We Deploy WordPress Themes - read

A Series of Deployment Workflows  - read

WP DB Migrate Pro - download

WordPress Tips

WordPress Code Reference - read

WordPress Coding Standards - read

The Importance of Following The WordPress Coding Standards - read

Create A Functionality Plugin Instead Of Using functions.php - read

.gitignore for WordPress - read

Enqueuing things - read

Validate, Sanitize and Escape - read

WP Migrate DB Pro CLI Addon: Push/Pull - read

How I Would Solve Plugin Dependencies - read

TGM Plugin Activation - download

WordPress template part: a powerful tool - read

get_template_part() - read

WordPress Theme Customizer Resources - read

WordPress Plugin Boilerplate - fork

GenerateWP - use

WP Pusher - download

Tools

PHP Storm - download

Atom.io - download

Sublime Text - download

MAMP Pro - download

Desktop Server - download

VVV - download

iTerm - download

Questions?

[contact-form][contact-field label='Name' type='name' required='1'/][contact-field label='Email' type='email' required='1'/][contact-field label='Question' type='textarea' required='1'/][/contact-form]