Many of us define ourselves as “full-stack Web developers.” And we often think that this a great definition, as well as something to be desired. But is this really a desirable description, either for ourselves, or for the people we want to hire? What does it mean when we say that everyone needs to be a generalist, and that specialists are less desirable? In this talk, Elea Chang describes the downside of having everyone aim to be a generalist — on individuals, and on the organizations in which they work.
Web applications generally have a database on the back end. But how should we structure that database? There are many ways to structure our database in a database, and some of them are far more efficient and manageable than others. In this talk, Andrew Godwin discusses and shows many of the different ways in which people use and abuse their databases for back-end storage, and indicates why these might be bad ideas — whether you’re using Django, or any other Web application framework.
“Connascence” is a way of describing the ways in which parts of software are interdependent, and can thus force changes upon other parts when they themselves are changed. In other words: Connascence lets us understand the degree to which changes in A will force changes in B. In this talk, Thomi Richards introduces the idea of connascence, describing and demonstrating different types of coupling and connascence in Python code. Understanding the types and degrees of connascence present in your software will make it easier to understand the impact of change, and will help you to reason more carefully about the software you write.
How does Uber store its data? Uber uses MySQL, a popular open-source relational database. But it also uses a NoSQL system known as “schemaless,” which is an append-only system that takes a functional approach to data. How does this work, and how did Uber come to decide on it for their storage needs? How does this system scale at a company that’s growing at such a phenomenal rate? And what does the future hold for Uber’s “schemaless” system? In this talk, Rene Schmidt addresses all of these questions and issues, describing the types of messages that Uber sends and stores, and the ways in which schemaless has helped them succeed as a company.
Are you smart? If you’re a programmer, then you have probably been described as “smart” at times during your school or work career. But what does it mean to be smart? And how does this affect how you approach problems, and how you learn new things? In this talk, Allison Kaptur describes two different attitudes toward intelligence and learning: Are people born smart, or are they smart as the result of hard work? How you view yourself, how you view intelligence, and how you attack problems, are all affected by how you think about intelligence. This talk describes ways that developers can challenge themselves, help others, and work so that everyone can learn and grow as effectively as possible.
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.
Does the world need yet another Lisp? And in particular, does the world need a Lisp that sits on top of the Erlang VM? In this talk, Robert Virding introduces us to LFE, or “Lisp-flavored Erlang,” a new version of Lisp built on the Erlang VM. It’s thus functional and concurrent, but with many of the aspects of Lisp that developers have grown to love over the years. How is it different from other Lisps, including Clojure? And what advantages does it bring over Lisp and/or Erlang itself? Even if you never use LFE, this talk will introduce you to the ideas of language design, and the use cases for a new language.
To many people, open-source software is free of charge, and without any restrictions or licenses. But of course, open source (and its close cousin, free software) can only exist thanks to licenses, and copyright laws. But wait — is software like a movie, a book, a machine, or none of these? Or all of these? What laws apply? Hhow do they affect us, and what do they mean for the permissions we need in order to use, copy, and modify software? What do open-source licenses mean to us as users, and developers? And why is there so much confusion regarding licenses? In this talk, Brenda Wallace introduces us to the ideas of copyright, and to some of the murky aspects of copyright that software developers should understand, particularly if they’re contributing to open source.
Twitter seems like magic: You send a tweet, and it’s sent to your many followers in something closer to real time. But of course, Twitter — like all network applications — makes use of millions of networks that are not under its control. Many of those networks are slow and unreliable. How can you create a network application that appears to be seamless and reliable, working with images as well as text, when it is built on such an unreliable, unmanageable infrastructure? In this talk, Jess Garms describes the ways in which Twitter has worked to increase not just the reliability of their systems, but also the appearance of reliability for their users.
Everyone wants their database to run faster. Optimizing databases is a big and complex topic, but there are some simple rules of thumb that, if you follow them, can help your database (and the applications using the database) to run faster. In this talk, Josh Berkus describes a number of techniques you can use to improve your database performance — sometimes, in major ways, with a small amount of thought and work.