Yukihiro Matsumoto i
To be announced
Description coming soon.
Description coming soon.
Description coming soon.
As a teen and twenty-something programmer I often found myself tossing hundreds of lines of code at a problem. I see this pattern over and over again in the young programmers we hire at my day job. I've noticed that now that I'm in my mid thirties and have been programming for almost 20 years I spend significantly less time actually writing code even though the problems I am tasked to solve are significantly more difficult. I recently spoke on this topic at our local ruby group and I'd like to flesh out the presentation a bit more and give it to a wider audience.
The basic premise is that we should be spending significantly more time thinking than we do programming and there are wide reaching ramifications to this point. Subtleties in how our non programming coworkers perceive some of us wandering around the office pacing or arguing at the white board are all to be covered as well as discussing the body of research that supports the ideas behind thinking more and working less.
Sure, the TDD cycle is red-green-refactor but what exactly are we refactoring? We just wrote the code, it's green, and it seems reasonable to us. Let's move onto the next test. We're have a deadline, remember?
Whether we're working with code we just wrote or opening up a project for the first time, being able to listen to the hints the code is trying to give you about how it wants to be constructed is the most direct path toward successful refactoring. What the code is telling you nuanced however: no code smell is absolute and none in itself is an indication of a problem. How do we know we need to refactor? What are the code smells telling us to do? How do we balance our short terms needs of shipping our software with the long term maintainability of the code base? In this talk we'll talk through some of the classical code smells and dive into examples of how to put these smells to work for you.
Most Ruby code makes heavy use of mutable state, which often contributes to long term maintenance problems. Mutability can lead to code that's difficult to understand, libraries and applications that aren't thread-safe, and tests that are slow and brittle. Immutability, on the other hand, can make code easy to reason about, safe to use in multi-threaded environments, and simple to test. Doesn't that sound nice?
This talk answers the question ""why immutability?"", covers the building blocks of immutable code, such as value objects and persistent data structures, as well as higher order concepts that make heavy use of immutability, such as event sourcing and pure functions, and finally discusses the tradeoffs involved in going immutable.
"Postgres has long been known as a stable database product that reliably stores your data. However, in recent years it has picked up many features, allowing it to become a much sexier database.
We'll cover a whirlwind of Postgres features, which highlight why you should consider it for your next project. These include:
Copresenter: Mike Utley
Look, I know you love your sprinkler timer, with its endearing little dials and simple, easy-to-use interface, and its killer dot-matrix LCD.
We thought we could do better, and we thought Ruby could help us. With the awesomeness of things like the Raspberry Pi and maybe a little Arduino, who's to say I can't use Ruby to water my lawn, remind me to fertilize, or let me know where I could save a little water?
We’ll take you on a quick tour of the automated sprinkler system world and the problems it has, and how we’re solving them with Ruby, Raspberry Pi, and about 24V of DC power. We promise not to electrocute you, but we can’t guarantee you won’t get a little bit wet.
I am a developer, and I have Type II BiPolar and ADHD.
It's not something we talk about, but BiPolar, depression, and ADHD runs rampant in the developer community - they tend to correlate with higher intelligence. Many of the symptoms of this conditions make for great developers, but also cause incredible damage. We recently lost one of our co-workers because of untreated mental illness.
I want to share my story - and let people know that it's okay to talk about these things, that it's nothing to be ashamed of, and how to get help, and how to help those around them.
Reading of the CRuby source code can provide unparalleled insight into the Ruby language. During this talk we will add new native Graph data type to CRuby. The new Graph data structure will be simple but on par with other native types such as Array or Hash. This talk will demonstrate that it is easy to experiment with CRuby and extend it. We will also demonstrate the speed advantage of using C to boost Ruby performance. We will implement a few of the greatest hits of graph algorithms: Breath First Search, Dijkstra, and Minimum Spanning Tree.
Devops Borat said "is turtle all way down but at bottom is perl script, but in the case of Cloud Foundry there's Ruby at the bottom. Rails is the right choice for building a web site, but the elegance of ruby can be applied to many other things including a Platform as a Service. A full deploy of Cloud Foundry requires many different kinds of nodes, with multiple Sinatra apps, event machine based daemons, shared ruby gems, and small amounts of code in other languages like Lua, Go and C where it makes sense. I'd like to take you on a tour of an open source codebase and project that really shows where you can go with Ruby.
I wrote the first wiki in a week. Why has it taken me a year to write another? Short answer: when something is already surprisingly simple its hard to make it simpler.
This last year I set out to do for numbers what I had done for words, give them depth and meaning that ordinary people can depend on every day. A wiki, like a glossary, defines the terms we choose to use. A data-wiki makes those choices more complex. Its no longer one click to check a definition. Its more like one more study to check a dataset, to see if the data says what we think it does. Not a simple process.
My quest has been to make knowing and using data an everyday thing. This means the study of data must be an everyday thing too. To this end I've pushed visualization, I've pushed domain specific markups, I've pushed streaming measurements. But through this I've retained wiki's greatest strength: the ability to create with those who we have just met and don't yet have reason to trust. Finding trust on the modern web may be this year's biggest accomplishment.
It's that time again! No... the trolls will never truly go away. But we can mitigate their damage by identifying their bad behavior and come up with collective strategies for dealing with them. While working on this talk (and a couple followup talks) I studied and even met with a few of the top psychology researchers to understand this phenomenon. I'll revisit my "walled garden" concept and study strategies of several other communities to boil them down to their core essence. From this I've developed a meta-troll set of rules to help identify the type of troll you're dealing with so you can most effectively deal with them. So... Come learn from pioneering psychologists about what makes trolls tick. Come learn from other communities how we can better bolster our community by disempowering our own trolls.
Whether your application is concurrent or not, there's insight to be gained from Ruby's threading support.
This talk demonstrates building a light-weight sampling profiler in pure Ruby. The techniques are simple enough to integrate into almost any application, and fast enough for even a production environment. If you've ever wondered exactly what your application is doing at any given moment, this will show you how to find out.
Along the way we'll expose gotchas and pitfalls of thread introspection on the many versions and implementations of Ruby. Based on experience implementing thread profiling for New Relic, we'll also touch on how to debug and work around problems when they come up
Wild test suites often contain inefficient or ineffective tests. Working with a code base full of these beasts is frustrating and time consuming. This safari will help you identify and hunt down common testing anti-patterns. Afterwards you’ll know how to approach a test suite full of beasts without losing your mind or your life.
Good integration tests are hard. There are many approaches for fully testing server and client libraries for those HTTP APIs - all with various tradeoffs and problems that come up. Some are obvious, some are a little more tricky.
I'll run through some approaches and problems I've come across developing server/client HTTP APIs while developing in a highly distributed systems setup at Engine Yard.
The ruby standard library is full of great code. It's also full of dragons. I'll show you some of fun parts, parts that you may not be using and may not even know about. I'll show you that you don't have to install everything on GitHub to build your application. I'll also look at some of nasty parts, and how to put a training collar on some of those dragons.
GitHub loves Ruby. Many of our products, tools and infrastructure are built with Ruby.
In this talk, we will look at the libraries, practices and conventions that GitHub uses with Ruby. We will survey all of the repositories maintained by GitHub to get insight into how it is used, and we will also examine some of the areas where we opt to not use Ruby.
This session is a jolly romp through the realm of practical data privacy using pure Ruby. We'll start by looking at how to obfuscate data using Ruby's OpenSSL bindings, exploring the possibilities of symmetric and public key cryptography as well as the role of hashing algorithms.
Once the basic principles have been established we'll turn our attention to designing databases with a strong privacy component, using Sequel to demonstrate how encrypted keys can be used to support privacy in the relational model. There will be some meta-programming involved which should also be of interest to ActiveRecord users. This will naturally lead into a brief discussion of the seeming difficulty of searching encrypted data along with a strategy for making this practical.
We'll round out the session by turning our attention to the transport layer with a simple scheme for securing web application sessions using a custom Rack middleware.
The discussion will be backed by code examples inspired by real-world systems.
It's true that goods are better distributable when they are in packages. That is the common view of what Ruby gems and Rails engines are: packages for distribution. This perception misses the great value that comes from packaging without distribution. That is what makes component-based architectures: a helpful tool for organizing growing codebases. We'll talk about how to do this with (and without) Ruby on Rails.
Ruby makes it a bit hard to do packages right: you really can't hide anything. Rails doesn't want you to do it. I don't care. We'll do it anyways and it will be awesome!