If you create a piece of software, you need to worry about the users. But if you create an API, then your users are people you’ve never met, who will be using your software on a regular basis — and who will create applications and services based on the API you created. This means that if you make mistakes when creating the API, you’ll be forced to live with those mistakes, and support them, for some time. How can you create, and then maintain, an API with a minimum of of fuss, and in a way that you can fix mistakes? In this talk, Philipp Meier describes the mistakes that he has made when writing APIs in Clojure. His lessons are appropriate not only for Clojure developers, but for people using other languages, too.
So, you want to download information from the Web? Great — but if the data isn’t available via an API, then you’re going to need to scrape it. That means retrieving the HTML, parsing it, and turning into data you can really use. A popular way to do so in Python is scrapy, an open-source framework for crawling and downloading data. In this talk, Karthik Ananth introduces scrapy, and demonstrates why it’s a powerful tool for creating your own crawlers, either for widespread scraping purposes for specific, single-use projects.
So, you’ve put text inside of your PostgreSQL database. How you can find, among all of your rows, the rows that contain precisely the text that you want? Fortunately, PostgreSQL offers many options, including a sophisticated full-text search engine. In this talk, Phil Vacca provides us with an introduction to searching for text in PostgreSQL, looking at some of the features that make it much better than just a plain ol’ index, such as weighting and stemming,
JRuby is one of the most interesting and famous implementations of Ruby, for several reasons: It runs on the JVM, it runs really quickly, it interacts with Java libraries and objects, it integrates with the entire Java ecosystem of tools, and it solves the concurrency problems that the standard (MRI) interpreter has. Recently, the JRuby team released a version that is compatible with Ruby 2.2, which raises the question — what does the future hold for JRuby? What are the plans on the Ruby front, and the JVM front? In this talk, JRuby developers Charles Nutter and Tom Enebo describe the current state of affairs, and where we’re headed in the JRuby world.
All developers have to debug their code at some point. But there are particular practices that, when used, can make debugging significantly easier, faster, and most efficient. One overall perspective that can help is that of the scientific method. In this talk, Stuart Halloway describes how he approaches debugging using a scientific approach, and how doing so makes debugging less of a depressing and tedious chore, and more one that helps to move a project forward and provide the developer with greater understanding. His examples all employ the Clojure language, but the lessons learned can be generalized to many languages.
Developing an application using Ruby on Rails is supposed to be really straightforward. But it turns out that getting all of the versions (e.g., Ruby and gems), as well as all of the dependencies (e.g., databases and HTTP servers) right can be time-consuming and frustrating, particularly for newcomers. And then you have to deal with this once again when you move your application to production, and then deployed to multiple servers. One solution to this problem is to use a virtual machine (VM), or perhaps even a container manager such as Docker. In this talk, Laura Frank describes containers and Docker, the parts of a container, and how containers can help to improve your environment for development and deployment alike. She also distinguishes between VMs and containers, helping us to understand the differences between these virtualization systems.
Many applications now use PostgreSQL as a database; the price, features, and community have long made for a compelling use case. But what if you need several, or many, PostgreSQL servers? How can you best deploy such servers? One answer is to use Ansible, a provisioning system written in Python that has become an increasingly popular alternative to such well-known systems as Chef and Puppet. In this talk, Kenny Gorman describes why you would want to provision your PostgreSQL servers with Ansible, and then how you can do so.
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.
One of the reasons for Ruby‘s popularity as a programming language is Ruby gems, the collection of open-source libraries that can be downloaded and used by developers around the world. With tens of thousands of gems available, there’s no doubt that they make Ruby a more productive, interesting, and collaborative language. The fact that anyone can contribute a gem makes it even more appealing and democratic. But not all gems incorporate practices that encourage their widespread use, as well as contributions from other developers. In this talk, Mat Brown provides seven ground rules for gem designers that, when followed, will make your gem more appealing to developers — those who want to use your gem, and those who want to help make it even better.
Developers often complain that designers don’t understand software — and that their lack of understanding leads to all sorts of problems. If only designers would start to program, they would finally understand what’s involved, and it would be so much easier to speak and work with them. In this talk, Alexandra Leisse turns the tables, saying that it would also behoove developers to learn to design. If only developers would learn, understand, and internalize design principles, it would be easier to work with them — and most importantly, the users of the software would benefit greatly. She dismisses several myths about design, such as that designers are born, not made, and offers numerous suggestions for how developers can increase their understanding of design, and their sensitivity to the user experience. If you’re a software designer who is either dismissive of design or in awe of it, this talk should provoke you into learning more about it, for everyone’s benefit.