Zachary Flower
Lead Developer at Emerson Stone
Zachary Flower is a freelance web developer, writer, and polymath. He has an eye for simplicity and usability, and strives to create products with both the end user and business goals in mind. From building projects for the NSA to creating features for Buffer, Zach has always taken a strong stand against needlessly reinventing the wheel, often advocating for the use of well established third-party and open source services and solutions to improve the efficiency and reliability of a development project.
Links
Veni, Vidi, Vagrant
When it comes to development environments, parity is key. While Vagrant is an excellent way to create easy, consistent virtual machines for this exact purpose, getting them to shine across multiple team members, machines, and operating systems can be an exercise in patience—if not futility.
As an ancient proverb *probably* said, "The power of Vagrant comes from without." In other words, don't neglect the host machine, because without it there would be no development environment. In this talk, you will first learn how to adapt a Vagrant box to the unique properties of any host machine, from adapting to the operating system to allocating appropriate hardware resources. Then, you will learn how to use Vagrant to automate project workflows to reduce—and in some cases eliminate—the amount of time new team members have to spend mucking around with things like linters, git hooks, plugins, and dependencies.
You will get the most out of this session if you have used Vagrant before, but don't fret if you are just dipping your toes in the metaphorical water. Vagrant is incredibly easy to get started with, and the demonstrations and code samples in this talk will get you off to a running start. You’ll see the unique ways Vagrant makes it easier to not only create reproducible development environments, but also techniques that can be used to automate your entire development workflow.
Write the F!@#$%^ Manual
Writing developer documentation is, arguably, the worst part about actually being a developer. Who has time to explain code when you’re moving fast and breaking things? Unfortunately, when you’re too busy kicking ass and taking names to write down a few notes, all you’re doing is setting yourself (and your stakeholders) up for failure.
In this talk, we’ll discuss what good documentation looks like, why you should care, and what can go horribly wrong when it is neglected.