Open data at the local scale is even more of a mess than at the national level, but while there are increasing efforts to improve things nationally, cities, towns, counties, and even states are being left behind. These smaller entities don't have the resources to implement APIs for their data, and community tech groups and developers who want to use this data constantly hit walls — from fragmented, non-uniform data to finding API hosting and maintenance. But what if we could throw all that data in a box that’s easy to open, close, and move around — bypassing traditional solutions requiring infrastructure for hosting and maintenance. Enter Docker and ElasticSearch, and a simple three-layer API-in-a-box solution that any developer can immediately turn on with docker-compose up.
"I’m a cross between a night dragon, code wizard and a unique damn butterfly. I am not your ‘resource’ to pimp out!” said every rage-quit prone engineer, ever. As a team leader, the line between diverse culture and a dogmatic cult is thin. Embracing individuality, yet finding alignment as a collective, is tough. Understanding what defines one over another is critical so everyone can bring 100% of themselves to table.
In this talk I’m going to walk through our journey as a team: finding alignment, embracing individuality and discovering our shared values. I’ll identify our faulty pitfalls, red-flags and a set of questions to ask yourself everyday to make sure that what you have a is “Culture of Talent” and not a “Cult of Conformity."
Like a espresso, code is better served in small portions. Unfortunately most of the time we build systems consisting of a monolithic application that gets bigger and scarier by the day. Fortunately there are a few ways to solve this problem.
Everyone talks about how good microservices are. At a first glance an architecture of small independently deployable services seems ideal, but it's no free lunch, it comes with some drawbacks.
In this talk we'll see how microservices help us think differently about writing code and solving problems, and why they are not always the right answer.
Aerospace engineering is really no more magical than programming, and yet it's shrouded in such mystery and mysticism that practically no one bothers to study it. I'll show you how to apply concepts from rocket science to challenging software problems, allowing you to spend more time coming up with answers rather than interpreting inputs. We'll also learn to control the universe outside our glowing rectangles.
Pairing is intimidating, hard, and exhausting for most people when they start. It provides countless benefits, but it can be daunting for even seasoned developers. Braintree has a culture and significant tooling around improving the pairing experience, but my experience as a cop gave me the skills needed to thrive at pairing. This talk will briefly cover the tooling of how we pair at Braintree and talk about how my experience as a cop taught me to pair.
We talk about bringing new developers "up to speed quickly." Imposter syndrome is bad enough, but often junior developers feel pressured to learn faster and produce more. Developers often focus on velocity as the critical measure of success. The need for speed actually amplifies insecurities and hinders growth. Instead let's talk about how we can more effectively structure, implement, and track apprenticeships with the right kind of framework and focus.
As the demand for a realtime web is met with our ability to build it, Rails 4.0 introduces realtime as a default option and makes reactive, live applications more attainable than ever.
We'll discuss the implications of realtime software, the technologies that support it, and how frameworks like Rails, Volt, and Meteor help your team implement better, realtime apps in less time.
The news is everywhere: some weird disease makes the dead walking. We do not know yet if it is highly contagious. What should we do? What we do everyday: writing code. We can develop an agent based model, simulate the disease, and hopefully find the best strategy to survive. We can code, we'll be prepared ... or not.
Ruby is a great language for building CLIs. There’s an amazing selection of existing libraries like Thor, GLI, or even OptionParser. You probably use a number of Ruby tools everyday like chef, the heroku toolbelt, , and of course the rails command line tool. Though it’s easy to build a Ruby CLI, distributing it to end users is much more complicated because it requires a Ruby runtime. One option is to rely on Ruby being already installed on the end user’s computer. The other is to bundle ruby as part of the distribution package. Both of these are problematic so much that Vagrant, CloudFoundry and hub (Github command-line tool) have all switched over to Go. But there’s still hope! In 2012, Matz started working on a lightweight embeddable ruby called mruby. Since mruby is designed for being embedded in other compiled languages, it also solves the distribution problem. In this talk we’ll look how we can write CLI tools using mruby to produce a self-contained binary that can be shipped to end users.
Ruby was designed to be enjoyable and to make its programmer's life easier. You know what makes life easier in the short term? Robot servants. In the long term, there are problems like the singularity and the inevitable robot uprising. But in the mean time, we can all sit back, relax, and control the lights in our home with our favorite programming language. In this talk, we'll explore how to get started using Ruby with Arduino and the Raspberry Pi. We'll bend some hardware to our whim and look at how we can use Ruby to improve our everyday life.
“The first draft of anything is **.” - Ernest Hemingway
Ernest Hemingway didn't write first drafts of sparse, clear prose. He wrote terrible first drafts and then rewrote them, over and over, until the design of the prose was right.
For Hemingway, and every good writer, Writing is Rewriting.
As programmers our first drafts are terrible as well. Perhaps we clean up that first draft with some stylistic tweaks that make it look nicer but that don't affect the underlying design. But how often do we really dig in to that first draft and tear it apart, redesigning it until it is sparse and clear? Not often enough. And that's to our detriment.
For good developers, Design is Refactoring.
That sounds easy, but all too frequently refactoring doesn't lead to appreciable changes in the code's design. How do you use refactoring to improve code design? And how do you identify when you're just changing the surface style of your code? What's the difference between coding style and design, anyway? I'll answer all of these questions, hopefully, and show you how to take your code from a first draft to a clear, sparse design.
The Braintree Payment Gateway dates to 2008, and was built as a "monorail" -- a monolithic rails application that does everything. Over time, outward-facing features had to be built into it rather than as separate services because identity management, authorization, and authentication were tightly coupled to the rest of the application. Last year, we decided to fix that. We built a new, modern Rails API app, and I'll discuss the many differences from the old platform and why we decided to stick with rails. We also used some nontraditional methods such as running reads and writes through both applications to give us confidence in the new code and help us find missing test coverage. I'll talk about what we learned, what went well and poorly, and how we eventually switched over and split the two applications' databases without downtime.
Anyone who has done any Rails development knows that views gets complicated very fast. Conditional styling, violating laws of delimiter by double dots, complex business logic deciding view context, skewing and much more plague typical rails views.
In this talk we'll explore use of simple ruby classes to clean up views, models, controllers, by use of services. We'll delve deeper into 'View Carriers', extracting away complexity out of views, take a look at when rails view helpers fail us, testing strategies, and comparing existing approaches like Trailblazer.
Because views need to be beautiful too!
Capybara is a fantastic tool for testing user interactions with our applications. All too often, though, our specs use only Capybara's basic features and get littered with confusing and repetitive code. Instead, we can use the page object pattern and Capybara's more advanced features to write readable and maintainable tests. Come learn how to design a black box testing framework for your web application that turns a website into a clean, readable Ruby API.
You've been hearing about big data breaches in the news. As a developer who doesn't specialize in security, knowing how to protect your application from getting hacked may seem like a daunting task. However, fundamentals in the design and development process will greatly increase the security that protects your users from harm.
Are you doing everything you can to make the world a better place? As a developer you've got the skill to make amazing things, but who are you making them for? Do people need another dating app, or another way to compare uber and lyft pricing? If you want to take your development skills and do something transformational, where do you begin?
Anyone moving to Rails 4 has seen the documented examples like this: params.require(:coffee).permit(:all, :the, :things). But if the codebase has multiple controllers (including a few over 1000 lines long), some api endpoints, nested attributes nesting inside attributes that are named things like additional_attributes_attributes, and robust test coverage that has likely caused forbidden attribute grief, then this talk about some of the little/not documented details of the parameters we call strong might be your cup of...coffee.