A Symfony Developer’s tips, tricks and hacks: How we get the most out of our tools

A lot of the tools I use on a day-to-day basis as a Symfony developer at White October are well-known and widely-used by others.  What other people may not know, however, are the tips, tricks and hacks that I and my team use to get the most out of them.

This article explores a few of the ways I enhance my use of common developer tools, and introduces some of the more interesting aspects of our workflow along the way!

Not a Symfony developer?  Check out the git tips below anyway – they’ll be useful for other developers too!

Disclaimer: This is article is primarily focused on my personal way of working – others at White October may do things differently or better!

Dev environment

I use Vagrant to give me a development environment on a virtual machine for each project.  Two things make my life with Vagrant much better: First, a script for moving cache, logs etc onto the VM itself to speed up the Vagrant version of the site.  And second, provisioning it with Ansible so that all our environments (dev, staging, production) are provisioned using the same code!

Writing code

I use the PHPStorm IDE heavily, and I’ve recently discovered two plugins that I now couldn’t imagine being without:

The Symfony2 plugin provides a million-and-one nifty little time-savers like autocompletion for pretty much everything.

PHPStorm's Symfony2 plugin in action

But what I really love about the plugin is how regularly it makes me think “Wow, that’s magic!”

Just one example should make this clear:  When referencing a new Twig template from a controller, PHPStorm shows me that the template doesn’t exist yet.  I then have the option to automatically create that template in the right folder, which is already pretty cool.  But the “wow” moment came when I noticed that the template was already pre-filled with the right {% extends %} and {% block %} tags – very smart!

Secondly, once you’ve become hooked on the autocompletion from the Symfony2 plugin, you’ll want that goodness for Doctrine, too, so I love the PHP Annotations plugin which provides just that!

Git

You won’t be surprised that we use git for source control.  The workflow I follow with git is to compare all changes before each commit, allowing me to spot code I accidentally left in, and check that I’m really committing what I want.  For this, I use git’s difftool command, configured for use with the fabulous Beyond Compare comparison tool.  I can’t imagine working without Beyond Compare, and not just for git – I have it integrated with PHPStorm too.

I have a handful of git aliases set up, which save me an awful lot of typing.  Two personal favourites are:

  • git update is an alias for git commit -a –amend -C HEAD.  This amends the previous commit (–amend), adding in any changed files (-a) and re-using the previous commit’s message without prompting me to change it (-C HEAD)
  • git re is an alias for git rebase -i develop.  I love tidying up my commits with interactive rebasing, and this is a simple way to say “show me all the commits in my branch so I can edit them”.

Since we use Github Pull Requests for merging branches, I often find that I want to delete the current branch because it’s been merged.  So I made a script for that – it checks out develop (or the branch you tell it), does a git pull, and then deletes the branch you were on previously.  Much nicer than typing that all by hand!

We make use of the PHP Coding Standards Fixer from SensioLabs to automatically tidy up our code.  What’s really handy, though, is that we have a coding-standards git hook configured which automatically does a dry-run of the fixer on any changed files before committing!  If anything needs changing, it prints the appropriate commands to run, and aborts the commit.

Continuous Integration and deployment

We make extensive use of CircleCI for Continuous Integration.  One nifty feature we make a lot of use of is its ability to do automatic deployments when a build on a certain branch passes.  Oh, and did you know that you can tell Circle not to run by putting [ci skip] in your latest commit message?

As part of this deployment, we also run automated smoke tests using specially-written behat features – but that’s for another article!

Got any neat tips of your own?  Feel free to share them in the comments!

 

4 Comments

  1. Posted 20 May 2015 at 5:57 am | Permalink
  2. Enleur
    Posted 25 May 2015 at 4:27 am | Permalink

    How do you debug console apps with vagrant?

  3. Sam
    Posted 27 May 2015 at 9:04 am | Permalink

    Hi Enleur, thanks for commenting.

    I’ve been wondering this myself. I have in the past managed to get debugging working for webapps running on Vagrant, but hadn’t managed to get remote debugging working for console apps.

    I’ve recently discovered a StackOverflow post talking about this very problem, but haven’t had a chance to try it yet. If you want to give it a go, it’s http://stackoverflow.com/a/21705998/328817

    Let us know how you get on!

    Thanks
    Sam

  4. Sam
    Posted 17 June 2015 at 8:26 am | Permalink

    Hi again Enleur,

    I’ve recently been successfully debugging console apps (including behat and phpunit) on a Vagrant project, thanks to the instructions here: https://www.adayinthelifeof.nl/2012/12/20/debugging-remote-cli-with-phpstorm/

    Hope they’re helpful,
    Sam

Post a Comment

Your email address is never published nor shared. Required fields are marked *

Ready to talk?

Whether you want to create a new digital product or make an existing one even better, we'd love to talk it through.

Get in touch