Every programming language has its surprises and dark corners. Even Python, which prides itself on regular syntax and consistent behavior, has them. This talk, by Amy Hanlon, not only points to some of Python’s odder behaviors, but explains why these things happen. The talk is both funny and interesting, and helps us to understand how programming languages are implemented, not just used. The talk’s title refers to Gary Bernhardt’s famous “Wat” talk, in which he points to oddities in Ruby and JavaScript.
Working with databases means, almost inevitably, trying to improve the speed of some of your queries. In the case of PostgreSQL, successful query tuning means understanding how the database works — and that includes understanding the query optimizer, the “brains” of PostgreSQL, which decides how to join your tables, what to read from disk, and which indexes to apply (among other things). In this Webinar, Bruce Momjian describes PostgreSQL’s query optimizer in great detail, providing many insights that come in handy when working to improve the speed of your queries.
JavaScript is everywhere! It’s in browsers, but also increasingly on servers. In this talk, Kito Mann describes why JavaScript is the only language that does (and will) run in every browser — and thus why it’s the language that we increasingly need to think about. The thing is, thinking about JavaScript doesn’t mean writing in JavaScript; the talk describes several languages built on top of JavaScript, and compares their advantages and disadvantages, as well as why people would use them rather than ES6 (i.e., the new version of JavaScript).
Since it was first introduced in 1992, Python has been a dynamically typed language. In other words, any variable can point to any object in Python; there’s no such thing as an “integer variable” or a “string variable.” On the one hand, proponents of dynamic typing say that it’s a great thing — but on the other hand, many people working on large projects have pointed to the drawbacks of dynamic typing, and have long wanted at least some type-checking to come to Python. At this year’s PyCon, Python BDFL Guido van Rossum announced a new direction for Python, which signals a move, slowly and cautiously, in the direction of type checking for Python. What does this mean for existing code? What does it mean for the future of Python? If you’re a Python developer — or even if you’re using another dynamic language — it’s worth hearing from Guido has to say on this topic.
When you mention the term “code review” to many developers, they assume that it’s a chance to criticize them, to tell them how their code stinks, or that it’s riddled with bugs. But code review can and should been seen as a chance for both participants in the process to learn from one another. In this talk, Derek Prior describes how a code-review session can become helpful and encouraging, rather than critical and frustrating. Sure, there might be conflicts — but if the developers focus on the code, rather than the personal issues, then the code and the developers participating in the code review can all benefit.
We don’t often think about it, but SQL is a programming language. As such, it has all of the issues that other programming languages have, even thought its style is quite different, and it’s restricted to a specific domain. Moreover, programming languages are themselves programs, which means that we can (and should) implement them with an eye toward efficient execution, which means considering the language in which the language is implemented. In this talk, Tiark Rompf shows parts of a database engine that he and his team have created in Scala (rather than C, which we would normally expect), showing us some of the things they’ve learned about writing and optimizing such a system.
So you created a great new Web application! That’s great, and because it’s new, it’ll be easy to maintain… until it accumulates more and more features, and data, and bloat. Someone might then suggest that you refactor your system into one using “microservices,” breaking your large, uniform system into a number of smaller ones. Microservices can indeed be helpful, but it’s important to understand what they are, and what they do. In this talk, Martin Fowler describes what a microservice is (and what it isn’t), and what we’re likely to find as we migrate toward them in our Web applications.
It’s very in vogue to say that everyone should learn to program. Code.org and other organizations are talking about how important (and useful) it is to learn to program. Is that true? Is that a good idea? Is it even possible? And of the people learning to code now, how many are going to be full-time professional engineers, and how many will simply be better-informed people? What does this mean for the people who are actually coding full time? In this talk Farrah Bostic reminds us that there programming is not just a profession, and that this isn’t necessarily a bad thing — for individuals, and society.
Learning to code is sort of like learning a foreign language; you’ll make lots of mistakes that you can laugh at (and about) later on. In this talk, Kylie Stradley points out that many of us make the same mistakes when learning to develop Rails applications — and talks about how we make such mistakes, and the long, difficult road that beginners follow when learning to program.
The Web is amazing, for sure — but it has also failed to live up to many of our (and its) initial promises. There are a lot of bad guys out there, making it unsafe for ordinary people. It’s not as secure as we would like. And of course, it’s not as fast as we would like. What does this mean, and what can we do about it? In this talk, Chris Morgan describes a number of ways in which the Web’s infrastructure can and should change, so that we can benefit even more from the Web as it currently exists. If you’re a web developer, then you’ll likely identify with many of the things mentioned in this talk. It’ll also explain some of the motivations for the Rust language, and the ways in which Rust tries to improve on other languages in all of these areas.