In theory, programmers spend lots of time developing new software. But in practice, developers spend a great deal of time debugging, trying to figure out why their code doesn’t do what they expect. The problem is that most debuggers operate similarly to how debuggers did 20, 30, or even 40 years ago. In particular, there’s no way to run a program backwards; part of debugging means that you need to catch the problem as the program runs, and then examine the state. In this talk, George Hotz introduces the idea of “timeless debugging” — in which the debugger knows how to unwind history, letting you backward as well as forward.
When we program on a Unix machine, we often use a terminal window. But what does a terminal program do? What is it trying to emulate, what features does it support, and how can you take advantage of it when you’re working? Why does it work the way it does, anyway? And using a bit of Python and understanding of what’s happening behind the scenes, what sorts of interesting things can we do? In this talk, Thomas Ballinger answers al of these questions, mixing his descriptions with extensive live-coding demos.
How do you store your secrets? This is, by definition, a sensitive issue; you want to make it easy for the right people to access secrets, but it should also be hard for others to get those secrets. And by “the right people,” we increasingly mean “the right programs,” in an age of devops and automated deployment. Plus, you need to worry about revoking privileges, or expiring access after a short time. One project that attempts to handle these problems is Vault, an open-source project developed by Hashicorp. In this talk, Seth Vargo describes Vault, and the problems that it attempts to solve. He also describes how Vault can be integrated into a data center, and then used by applications and deployment systems.
How does Git work? A lot of people who use Git work from a small set of commands, without actually knowing what is happening behind the scenes. This might not seem like a problem, but it is; knowing how Git works is essential to making it a seamless part of your development cycle. In this talk, Steve Smith describes how Git works, from its data structures to branches — and how we can get into (and out of) trouble when working with it. If you use Git, and you don’t quite understand how it works under the hood, then this talk will help you to make sense of things, and even improve your workflow.
Once upon a time, developers all used text editors — supercharged programs that allowed them to write and edit their programs. These text editors seemed simple on the outside, but were designed for developer productivity, and included a huge number of features meant for that purpose. How are text editors different from today’s IDEs (integrated development environments)? More importantly, how are they better than IDEs, and what can they teach us about programming, software design, and the tools that we use? In this talk, Colin Fulton traces through the history of text editing (especially on Unix), and how understanding this history can provide us with a greater appreciation of the power these programs offer developers.
Front-end development is popular and necessary — but it is also hampered by the fact that everything happens on the client. Perhaps “hampered” is too strong of a word, but there are times when a front-end developer wants or needs access to a server. In this talk, Martin Gontovnikas introduces “webtasks,” which can be described as a small backend application to support a large front-end application.
Front-end developers have always needed to know about HTML, CSS, and JavaScript. But lately, as the front end of Web applications has become increasingly complex, a number of command-line tools such as Yeoman have arrived, to help us assemble our sites more easily and effectively. The number of such tools, and the fact that they rely upon the command line, might be a bit daunting to front-end developers, though. In this talk, Nick Niles introduces some of these tools, and describes when and why to use them.
Ruby programs cannot be deployed as executable binaries. Rather, in order to run a Ruby program, you need the Ruby interpreter. This causes problems when you want to deploy programs to customers — they might not have Ruby installed, or they might not have the right version. A new version of ruby, known as mruby, is aimed at mobile devices and embedded use cases, and is thus quite small and lightweight. In this talk, Terence Lee describes how mruby’s smallness makes it appropriate for distributing applications, allowing programmers greater latitude in developing and delivering tools to their customers.
Programmers are often taught that they should modularize their code, breaking it into small pieces so that each piece can be managed, maintained, and reused. But what if you went in the other direction, using a single codebase for everything — in your workgroup, your division, and even your entire company? That’s how Google works; in a given week, their code contains more changes than the total number of lines in the Linux kernel. In this talk, Rachel Potvin describes why Google works this way, and how they manage so many engineers, changes, and applications in a single, huge repository. Even if you’ll never with so much code where you work, it’s definitely interesting to learn how Google manages its code, and the tradeoffs associated with this system.
Nearly every server program produces logs — and while they’re often useful for debugging, they can be even more useful in helping to understand, review, and gain insights into the nature of your software and users. In this talk, Britta Weber describes the “ELK stack,” consisting of Elasticsearch + logstash + kibana, three open-source tools which can work together to provide useful insights from your logfiles.