Every 2 weeks we hold Tech Talks here at Drivy. These are an opportunity for our now 17-strong team of developers to gather for 1 hour in a non-squad setting. The Tech Talks are emphatically not about tackling issues or solving problems, but are instead an opportunity to explore new ideas, ask questions, or to return to discussions started in a different context.
As a recent new hire to Drivy in a junior capacity, I quickly recognised that the Tech Talks were going to be a valuable addition to my onboarding experience. Any junior, joining an established tech team with rigorous working practices in place, will likely feel daunted as I did. One way I combatted this was by trying to learn as much from my colleagues as possible.
Imagine my glee then, when during a recent edition of the Tech Talks, we were invited to share our productivity tips 🎁. I’ve rounded up a selection of the tips and tricks that were shared, which covered a broad range of topics including Git, shell config and debugging. These tips may be highly valuable to other juniors out there - or indeed anyone looking to streamline their personal working practices. Plus it’s really interesting — and reassuring — to take a step back and see that everyone has their own way of working.
Disclaimer: these are tips that were shared by members of the dev team at Drivy. Many of the points have themselves been sifted from the Internet - no point reinventing the wheel as they say, especially when you’re aiming to move fast and break things 😉.
Renaud reminded us that the standard
git push -foverwrites the remote branch with your local branch, thereby potentially overwriting any work that may have been built on top of your original remote branch. The alternative is to
git push --force-with-leasewhich affords more flexibility: if any new commits have been added to the remote branch in the meantime, the force-with-lease option will not update the remote branch.
To quote the documentation, ‘it is like taking a “lease” on the ref without specifically locking it, and the remote ref is updated only if the “lease” is still valid’. This is important if it’s possible that another team member has checked out your branch locally and continued working on it.
Nico has the following in his .bashrc file
function git_dig {
git log --pretty=format:'%Cred%h%Creset - %Cgreen(%ad)%Creset - %s %C(bold blue)<%an>%Creset' --abbrev-commit --date=short -G"$1" -- $2
}With the following command:
$ git_dig rental_agreementhe can subsequently see all commits that contain the string rental_agreement in their diff, whether those commits have been deleted or not. Sometimes you might want to find dead code, or to see the evolution over time of a given method.
Nico also shared this tool with us, to help keep on top of GitHub notifications in your inbox. Octobox ‘adds an extra “archived” state to each notification so that you can mark it as done.’ Plus, if any new activity occurs on an archived item, it is moved back to your inbox so it won’t get forgotten.
Aliases were a new discovery for me, right on Day One of my Drivy adventure. There just wasn’t time to cover this kind of setup in depth at Le Wagon, the 9-week intensive bootcamp where I started to code.
So, for anyone who is in the dark as I was, an alias basically lets you abbreviate a system command or add default arguments to a command you use regularly. For example, to start up the server or to drop and recreate the database, you can create a shorter alias. You write them in the config file of whatever framework you are using for managing your z-shell config (usually ~/.zshrc or ~/.zshenv).
Here’s a quick tour of some of the useful ones that came up. This can give you an idea of how you might use aliases, although of course you’ll need to customise for your own setup and tools:
alias dstart='foreman start -f Procfile.dev'
alias drestart='pgrep unicorn | xargs kill - USR2'
alias circle='open https://circleci.com/gh/drivy/drivy-rails'alias rdm='rake db:migrate && rake db:rollback && rake db:migrate'alias countries='subl lib/drivy/countries/*.rb'alias dr='cd ~Workspaces/drivy-rails'
alias da='cd ~Workspaces/drivy-android'
alias di='cd ~/Workspace/drivy-ios'
alias weh='~/Workspaces/drivy-android/scripts/write_device_hosts'alias rm='rm -i'
alias todos="ack -n --nogroup '(TODO|XXX|FIX(ME)?):'"Whatever aliases you choose to set, remember to commit the file somewhere!
Git aliases go in the global .gitconfig file, and can save you time and effort on regularly used commands. The following were suggested by Christophe and Romain
[alias]
co = checkout
ci = commit
st = status
br = branch
di = diff
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commitPlus, less typing means less chance of making a mistake 😇.
If you do make mistakes often though, Adrien has a remedy.The Fuck can be installed via Homebrew and is, in their own words, ‘a magnificent app which corrects your previous console command’.
It tries to match mis-spelled commands, and then create a new command using the matched rule like so:
Mike recommended BitBar to us, for putting the output from any script or program directly in your menu bar. You can either browse their plugins, or write your own if you’ve got what it takes 💪.
He uses it to be able to easily check the status of external tools, or to stop and and start Homebrew services, like so:
A real medley of text-editor plugins were mentioned. Some useful ones for Sublime were:
With ⌘ + shift + click on a Rails partial path, you can open that file in a new tab, as explained by Adrien.
Jean recommended Trailing Spaces. This plugin lets you highlight and delete any redundant trailing spaces in your code, either automatically upon saving or by hand at any time.
Another handy Sublime plugin is BracketHighlighter. It will match a variety of brackets, helping you to avoid unclosed or unmatched brackets. It too is fully customizable.
Lastly, a quick word on debugging. We use pry_remote for debugging at Drivy, because running our processes on Foreman means we can’t interact with a regular Pry session.
Jean reminded us that when pry hits its breakpoint,
$ @can be used in the pry console as a shortcut for
$ whereamiAdrien shared a tip for pry_remote too. You can call:
$ lson an object within the pry console, and get a list of associated methods:
This has just been a sample of the points touched upon, and of course there were other, more sophisticated ideas too - beyond the scope of a junior. But if there’s one thing that emerged from the veritable smörgåsbord of tips and tricks shared, it’s that there is no one standardized way of working. Joining an established tech team in a junior capacity can be very overwhelming, so it can be reassuring to remember that sometimes.