In this presentation we’re going to study how method calls are executed. We’ll go from bytecode created by Ruby’s Virtual Machine down to the C code where the methods actually get executed. After we’ve learned about how Ruby executes methods today, we’ll dive in to optimizations we can make on method dispatch including various types of inline method caching. Audience members should leave with a better understanding of Ruby’s VM internals as well as ways to analyze and optimize their own code.
The Internet is built on technology that was never meant to work together. Basic features in seemingly simple and innocuous technologies, such as XML, resulted in these technologies being insecure. In this session we’ll talk about how attackers exploit well known vulnerabilities like XSS, XXE, and CSRF and how to make more secure software by avoiding similar decisions that resulted in these exploits.
Assertions (or expectations) are the most important part of any test framework. How are they written? What happens when one fails? How does a test communicate its results? Past talks have shown how test frameworks work from the very top: how they find, load, select, and run tests. Instead of reading code from the top, we’ll write code from scratch starting with assertions and building up a full test framework. By the end, you’ll know how every square inch of your testing framework works.
Baskin Robbins wishes it had as many flavors as there are JS frameworks, build tools, and cool new “low-level” languages. You just want to solve a problem, not have a 500-framework bake-off! And how will you know whether you picked the right one? Don’t flip that table, because we’ll use the “hype cycle” and the history of Ruby and Rails as a guide to help you understand which front-end and back-end technologies are a fit for your needs, wants, and career now and in the future.
Ok, so, if nothing else, we’ve got one thing in common. We like conferences. The two of us like ‘em so much that we recently spent a large chunk of time and money organizing and hosting one, and are planning at least one more for next year, too. Ask us about it!
We’re here to spill the beans on what it takes to make these things happen. We’ll do our damndest to tell you everything you need to know to get your own conference off the ground. We’ll cover topics like:
How many people do you need? To attend? To organize?
Where’s the money come from?
How do you get sponsors?
How do you run a CFP?
What are the easy wins and hard losses?
For what services do you pay versus those you seek for free?
How do you protect yourself and your fellow organizers?
Who buys the beer?
Whether you’re planning a multi-day conference, a monthly meetup, or just a one-time get-together for your office, we’ll give you a handy list of DOs and DONTs, based on our own experiences and those of others in the community event game. Like Kerri’s Gramma once said, “If you want to go to a party, sometimes you have to throw it yourself.”
Since 1884, humans have been building skyscrapers. This means that we had 6 decades of skyscraper-building experience before we started building software (depending on your definition of “software”). Maybe there are some lessons we can learn from past experience?
This talk won’t make you an expert skyscraper-builder, but you might just come away with a different perspective on how you build software.
Burnout is the professional’s palsy. It leaves you paralyzed, unable to do what you need to do, and it strikes without warning. Or does it? Through story, metaphor, and perhaps even code sample, let’s take a look at how to recognize, prepare for, and weather burnout, and hopefully come through the other side stronger than ever!
Many of us get a few years into our career and get stuck in a rut. Maybe we stop reading about the latest and greatest in tech. Maybe we start managing and do less coding than we’d like. Maybe life gets in the way and coding becomes drudgery.
One way to combat this feeling is to focus on learning. I’ll share what I’ve learned about juggling self improvement with being a professional nerd. I’ll talk about the courses, tools, books, and other resources I’ve found most useful. You’ll leave this talk with several ideas for breaking out of your own developer rut.
Up until the 17th century, the world was mostly limited to what we could see with the naked eye. Our understanding of things much smaller and much larger than us was limited. In the past 400 years our worldview has increased enormously, which has led to the advent of technology, space exploration, computers and the internet. However, our brains are ill equipped to handle dealing with numbers at these scales, and attempt to trick us at every turn.
Software engineers deal with computers every day, and thus we are subject to both incredibly tiny and massively large numbers all the time. Learn about how your brain is fooling you when you are dealing with issues of latency, scalability, and algorithm optimization, so that you can become a better programmer.
Web development pushes us to our limits, not only of cognition, but, perhaps surprisingly, of character. Using the cardinal virtues as a framework, we can see that developers need courage to learn, temperance to prioritize goals, a sense of justice by which to discern obligations, and wisdom to choose our path. By being honest about where we lack virtue, and implementing steps to develop character, we can perform test-driven development on ourselves. This process can help us grow not only as developers, but as human beings.