Let's all (really all) talk about what this Ruby conference is for, why you're here, and what you're going to do to go home thrilled with your experience. First, listen to my perspective - I say this conference is for strengthening and broadening our sense of ourselves as Rubyists so that we can learn from each other and move forward as a community. Then wield your markers and stickies to start to express and share your ideas about what will make SCRC14 amazing for you and for us
Nearly all our larger scale applications end up with a utils folder, module, or class. We all know them as our project's junk drawers. The wayward place for motley code. In this talk we will explore these junk drawers, come to know their stories, and lay to rest the question: Does having a junk drawer in my application make everything better or worse?
We've got a lot of tools at our disposal to render data in all kinds of interesting ways: charts, tables, gauges, and so on. Yet most dashboards are designed for consumption by humans, and many users say they don't get a lot of value from these visualizations -- or even worse, they find them confusing to use. We're doing something wrong. In this talk, we'll describe the scientifically-validated attributes of great visualizations, point out some common antipatterns that we think you should avoid, and illustrate how to optimize for showing the most relevant facets of a dataset. Don't let your dashboard become another statistic!
We Rubyists reject unnecessary ceremony and complexity, always striving to minimize complexity as much as possible without sacrificing clarity. So why are we not using functional approaches when object oriented approaches fail to go the last mile?
Two thirds of honeybee hives have died out in Virginia. Is it possible for us to devise a way of monitoring beehives in remote locations to find the cause? Enter a Raspberry Pi + Rails. Using a combination of this robust hardware and software solution, we were able to successfully track, monitor and provide reporting on the well-being of hives from across the county. Find out how we used Ruby, Rails, solar panels and other libraries to provide insight into this problem.
RubyMotion is a command-line Ruby based toolchain that initially allowed the development of iOS and OS X apps. Recently, Android support was introduced, and RubyMotion can therefore be used to write Android apps too. RubyMotion for Android features a brand new implementation of Ruby. In this session we will dive inside RubyMotion for Android and see how things work internally. This will be a technical presentation featuring demos.
How does a blind person even use an iPhone? Learn through personal stories why accessibility matters and some simple things you can do. Additionally, learn about some RubyMotion tools to improve accessibility both for sighted and blind iOS developers.
Where do Rubygems come from? We will trace the journey a Gem takes on its way into your codebase, mapping paths through tools like RVM, rbenv and Bundler. Along the way we will learn how these tools wrangle third party Ruby code into place and what methods they share.
Although Ruby is well-known for its use in popular consumer applications, it also has been used for several years in major newsrooms such as The New York Times and ProPublica to build "news applications" that display data, serve APIs and help inform readers. This isn't a typical web development environment: in newsrooms, deadlines can mean hours, not weeks, and often involve unfamiliar datasets and the challenges of both real-time publishing and archived material. In this talk I'll introduce developers to the unique world of newsroom developers and some of the applications and tools they've built using Ruby.
In honor of our late friend Jim Weirich, we will be dedicating a spot to a jam session. Jim was known for bringing his ukelele to conferences and hosting impromptu jam sessions. We're going to have a spot in our schedule for others to continue this trend.
Presenting a paradox involving two Ruby strings which are equal and constructed in ways that look very similar, but which have different properties -- one of them is "html_safe" and the other is not. The goal of the talk is to explore three things about this paradox.
They don't pay us money. They don't understand the goals of the project. They don't even say "thank you". But studies and personal experiences have proven that users of open source software are more demanding than those same users who pay for software. Why? Understanding the "why" will help us discover the "how". How can we solve this problem? Because it's not a technical one - it's a cultural one.
What’s better than Test-Driven Development? Even more test driven development! Unit tests are useful, but it's impractical to cover every situation. The more we try, the more tests we write, the more lines of code we maintain. What if we could cover every valid scenario with exactly one test? The goal of Generative Testing is to carefully define every possible input, then let the framework run hundreds of scenarios through the same test. It means thinking about more than a few examples, and deciding what the code should do in every possible situation. This kind of test is much harder to write -- and that’s the best reason to do it. Thinking before coding is the real purpose of TDD, and this kind of testing drives us to think harder. Generative testing won’t just sharpen your test and your code: it can sharpen your mind.