Russ Olsen has been building software for the last 35 years, everything from engineering document management systems to database query engines. Russ has been on a career long quest to find a better programming language and was an early adopter of Clojure, Ruby, Java and Python. Russ is the author of Getting Clojure as well as two books on Ruby, Design Patterns in Ruby and Eloquent Ruby. Russ is a constant if sometimes reluctant conference speaker.
Functional programming has finally escaped from academia. These days developers are building real systems in functional programming languages like Clojure, Scala, Elixir and F#. Functional techniques are also seeping into languages like Ruby. Unfortunately somewhere along the way functional programming has also developed a reputation for being deep and mysterious: Good programs achieve the Zen-like state of being functional which somehow involves immutability, higher order functions and being referentially transparent.
In this talk Russ Olsen will strip away the cloud of mystery to uncover the simple — and wonderful — truth about functional programming: It can make your programming life easier by letting you do simple things simply while also providing you with the sharp tools you need to tackle more complex problems.
David Bock turned to programming Ruby full time in 2006, after an upstanding career using Java in the Federal Contracting space, and he has never looked back. He is now corrupting the minds of our youth by posing at a "Teacher’s Assistant" for a java-based high school curriculum, only to expose teenagers to Ruby and tempt them with the Dark Side of the Force. Dave is also the director of the Loudoun Computer Science Initiative.
A talk on using Ruby as a tool for teaching, alongside Scratch, and the C-like language used for Arduinos. The combination is a powerful way to teach a bunch of concepts to a wide age range.
I thought of software architects as petty waterfall dictators. Then I became one. My theater background saved me. In this talk, we’ll look at set design — an ongoing, collaborative process — as a model for a more agile kind of “architecture” than building metaphors allow us. You’ll learn about the most important part of any architecture (hint: people), about using architecture to foster team creativity, and about the agile-architecture superpowers that Ruby gives us. No matter your title, you too can architect!
Ashley Jean is a software engineer and a part-time CS graduate student who resides in Baltimore. Prior to teaching herself to code, she worked in finance. In her spare time, Ashley enjoys training for foot races, hosting bi-monthly book club meetings, and organizing events in Baltimore for folks learning to code.
You may be experienced, but you're not senior if you can't mentor juniors. If you're just getting started, there is no better way to gain experience than pairing. Pair Programming is the absolute best way for juniors to learn new tactics for problem solving, skills, and best code practices as they grow as developers.
In this talk, let's talk exceptional pairing. Let's talk about the kinds of pairing. Let's talk how to maximize the value of pairing — regardless of skill level. Let's make the team stronger and you a more valuable employee. Let's talk pairing!
Mike Stowe is the author of Undisturbed REST. He has spoken at conferences around the world. An active advocate for creating better architectures and interfaces, his work has also been featured on ProgrammableWeb, DZone, and InfoQ. You can view his past talks and slides at http://www.mikestowe.com/slides and follow him on Twitter @mikegstowe.
One of the greatest challenges to developing an API is ensuring that your API lasts. After all, you don’t want to have to release and manage multiple versions of your API just because you weren’t expecting users to use it a certain way, or because you didn’t anticipate far enough down the roadmap. In this session we’ll talk about the challenge of API Longevity, as well as ways to increase your API lifecycle including having a proper mindset, careful design, agile user experience and prototyping, best design practices including hypermedia, and the challenge of maintaining persistence.
Jessica Garson is a Adjunct Professor at NYU. She’s also the organizer of the Tech Lady Hackathon, and previously the organizer of Hack&&Tell DC. She is a frequent teacher at DC's Hear Me Code, beginner friendly classes for women by women and has run programming classes at DC area public libraries. Jessica also runs a self-published programming magazine called What's my Function. In 2015, she was named by DC FemTech as one of the most powerful Women in Tech. In 2017, one of her projects nominateher.org got named best web/mobile product of the year by Technical.ly DC. Previously she has worked at ISL, Burson-Marstellar, The National Education Association, ISSI Data, and Salsa Labs. Before working in technology, Jessica worked on numerous campaigns throughout the country and got her degree in Political Science at the University of Hartford.
Learn how to make music with Sonic Pi and Ruby. We’ll go through how to make a song in this live coded adventure.
Baron Schwartz Baron is the founder and CEO of VividCortex, the best way to see what your production database servers are doing. Baron has written a lot of open source software, and several books including High Performance MySQL. He’s focused his career on learning and teaching about performance and observability of systems generally (including the view that teams are systems and culture influences their performance), and databases specifically.
Do you know what database indexes are and how they work? Do they seem hard to understand? They don’t have to be. The basic principles you need to know are simple and easy to remember. And you need to know the basics of indexing: your DBAs can’t save you, because discovering you need an index after you deploy a feature is often too little, too late. This talk will give you the fundamentals without theory or lecturing. You’ll learn the three purposes of an index, the three characteristics of how a query plan uses indexes, and how to design indexes that are most likely to be optimal for general-purpose querying, whether or not you know all the queries and shape of the data.
Sam Phippen is an Engineer at DigitalOcean, RSpec core team member, and all round Ruby aficionado. You may know him for being English, but he lives in New York City now. He’s sad that he can’t hug every cat.
There is an entire class of engineer that enjoys thinking about architecture, mentoring, team dynamics, the wider organisation, and what the goals of the business are. It can be rewarding, and it's not necessarily for everyone.
In this talk, you'll learn about what the transition to being a manager means. We'll discuss whether its for you, the honest truth of what the other side looks like. This talk isn't about Ruby, and is accessible for all skill levels, but is about something very important: why and when you might want to be a manager.
Valerie Woolard Srinivasan is a software engineer at Panoply, where she build tools for podcasters. She is also a lead for Women Who Code DC. She is always happy to exchange podcast recommendations, vegetarian recipes, and running routes. She lives in DC with her husband, who is also her best editor and advocate.
Writing code is a creative pursuit in many ways. The book Art & Fear: Observations on the Perils (and Rewards) of Artmaking talks about the day-to-day work of making art, and we'll talk about how to apply its lessons to making software.
At the end of the presentation, attendees will have a better understanding of how analytics can benefit their customers and their company, why building a flexible framework that isn't tied to any specific vendor is important, and how to improve their troubleshooting skills.
I will go over how we built the analytics framework on my current project: the decisions made along the way, how we ended up with our final implementation, and how it improved our Rails controller design and developer happiness.
I will also demonstrate how analytics can help drive decisions based on data and actual customer usage rather than assumptions, and share lessons learned from my own experience analyzing data in a complex app.