In this Keynote 'Matz' explains how diversity helps to create innovation.
The simplicity of the Ruby bundled library net/http has produced number of derivation / substitution HTTP clients for Ruby. I, who is an author of a HTTP client, performed surveys of those HTTP clients in last several years. One unsurprising thing I found from it is that users can pick one-gem-for-all generic HTTP client and also can pick the best one for the specified purpose.
In this talk, based on update to the advantages-and-disadvantages comparison of HTTP clients at http://bit.ly/RubyHTTPClients, I'll introduce characteristics of HTTP clients for different purposes.
Life isn't always simple. We often have to deal with a mishmash of applications, languages, and servers. How can we begin to standardize functionality across this chaos? Custom reverse proxies to the rescue! Using Ruby and EventMachine, learn how you can abstract high-level features and functionality into fast reverse proxies that can improve scalability, save time, and make the world happy.
See how we've applied this across a diverse set of web service APIs to standardize the implementation of authentication, request throttling, analytics, and more.
See how this can save development time, eliminate code duplication, make your team happy, make the public happy, and make you a hero.
See how this can be applied to any TCP-based application for a wide-variety of use cases.
Still think your situation is complicated? Learn about the U.S. Government's plans to standardize API access across the entire federal government. With some reverse proxy magic, this isn't quite as difficult or as foolhardy as it may first sound. It also comes with some nice benefits for both the public audience and government developers.
Remember when Avi Bryant spoke at RailsConf '07 about Ruby's future, and how it'd be slick if we could get to where Smalltalk was 30 years ago? Well, we kinda have, in some respects, with the 1.0 release of MagLev, a Ruby implementation running on a Smalltalk VM.
What makes MagLev really special? How about a baked-in object database that sits on top of a VM almost 30 years in the making? There are a lot of cool things you can do with this type of persistence, but it's quite different from what we do in a typical Ruby app.
Let's explore what this great implementation has to offer, and learn how to help it along.
SOA is hard. Learn how Square is approaching this problem today with JRuby and where we hope to be in the future. We'll go from git init to cap deploy, covering Square's approach to testing and service isolation, dependency management, API documentation, code quality metrics, data seeding, schema versioning, logging, exception handling, security and password management, deployment and more.
Inspiration strikes you, you’ve done it. You have found the missing 7 letters from the MVC model. This changes everything. You start discussing it with your pair. 10 minutes later you somehow find yourself arguing if mocks are good or bad. Jettisoning your pair you gather all you’re fellow colleagues for a quick discussion. Bracing yourself you unleash the full power of your words. 10 minutes later and somehow your idea has been lost and the discussion has devolved into discussing if mocks are good or bad. You’re not quite sure what happend but you walk away realising you failed to convince your team or pair of this amazing concept. Maybe it was a bad idea, maybe it was the idea that would make everyones life better. Being able to convince and discuss your idea is the skill of Rhetoric. A tool no developer can live without.
As a member of Matz's team in Heroku, I'm working Ruby 2.0 to be released in next February. Ruby 2.0 doesn't have drastic changes in behavior except adding some new features. However, an internal of Ruby 2.0 VM is changing to improve performance! For example, we changed VM data structures and method invocation processes to achieve fast execution. In this presentation, I will introduce the internal changes and its performance.
Do you actually know how deliberately acquire, sharpen, and retain a technical skill? In this talk, I'll discuss common strategies to enable you to be more focused, creative, and productive while learning, by using play, exploration, and ultimately failure. You'll leave knowing several "Experiential Learning" patterns and techniques that can help you turn failure into success.
When was the last time you failed in a spectacular fashion? Was it really so bad? If you want to succeed, you first need to take a little time to fail.
Ruby 2.0 is coming very soon. The specification is fixed, and the first stable release will be in production in several months.
Now is the time to get prepared for 2.0
What new features are available in 2.0? How can our code, and lives be improved by these new features? Where are the examples?
This session will detail some of the great
A survey of the current state-of-the-art projects available for runtime monitoring of production Ruby code, encompassing everything from cron jobs to web-servers. Provides the audience with an overview of best practices as well as highlighting the remaining gaps. Covers both instrumentation and visualization/analysis.
Ruby is an industrial programming language. In the past eight years, tens of millions of dollars, if not more, have been invested in Ruby itself, and in frameworks and libraries for the language. Many times that have been invested in companies that have been built around Ruby.
The reason for this is that Ruby has been a remarkably good language for a wide domain of programming problems.
However, the world is changing rapidly and Ruby faces a number of significant challenges that have a very real possibility of destroying the rich ecosystem that that has been built around Ruby.
None of these significant challenges are particularly threatening to Ruby. In fact, many of them have been solved by other language ecosystems or are being actively researched.
The fundamental problem is that the Ruby design process is practically nonexistent. What does exist is opaque, ad hoc, immature, and unstructured. Stakeholders are not consulted. Rationales are not consistently explained. Technical expertise is not validated.
In this talk, I will explain key areas where I believe Ruby's existing design process threatens the viability of the language. I will detail a structure for making Ruby design decisions that provides technical rigor and balances the competing interests of existing and future Ruby stakeholders.
Every deploy introduces the risk of downtime because of changes which are not backwards compatible. At Yammer, we deploy our Rails codebase to hundreds of servers many times a week. In this talk, I'll discuss many of the strategies we use to mitigate downtime during deploys. This includes how we handle database changes as well as background workers and external services.
Big data and data science have become hot topics in the developer community during the past year. This talk will show how ruby is used to build real data driven products at scale.
Data scientist Ryan Weald walks through the building of data driven products at Sharethrough, from exploratory analysis to production systems, with an emphasis on the role Ruby plays in each phase of the data driven product cycle.
There's a lot to love about JRuby. It performs better than just about any other implementation. It has solid, reliable, parallel threading. Its extensions are managed code and won't segfault or interfere with threads or GC. And it gives Ruby access to anything that can run on a JVM, including code written in other languages.
But how does it work? More importantly, why does it work so well?
This talk will dig into the nitty-gritty details of how JRuby takes advantage of JVM optimization, threading, GC, and language integration. We'll show why Ruby works so well on top of the JVM and what it means for you. And we'll explore the future of the JVM and how it will make JRuby even better (and JRubyists even happier).
This talk is part story, part code, and part mustache.
Travis CI is a distributed continuous integration system running over 7,000 tests daily. For us to get a true insight into what is going on behind the scenes we have had to come a long way by integrating and building both tools and libraries so that Travis and its many parts are not just a black box of information.
Reading logs and using NewRelic is not new, but far from enough, especially when it comes to apps which are composed of many smaller apps, like Travis. How do you track and visualize requests being processed by multiple services? How do you silence verbose logs while not losing the core of the message? And how do you aggregate, visualize and share metrics?
A lot of how we track, manage, and visualize what is going on in Travis has been created as a set of internal tools and by using a range of awesome services, but core to a lot of this is ActiveSupport Notifications and Travis Instrumentation.
This session will give insight to how Travis is composed and connected, as well as shedding light on how simple it can be to gain more visibility into even a complex, distributed system like Travis, as well as your applications too.
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
The Open-Closed Principle
The types of coupling, and their dangers
Why composition is so damn great
A powerful refactoring that Kent Beck refers to as "deep deep magic"
How to destroy conditionals with a NullObject
The beauty of the Decorator pattern
Testing smells, including Mystery Guest and stubbing the system under test
The stuff from the last halves of Refactoring and Clean Code that you never quite got to.
More than any other feature of the language, in my opinion blocks are what make using Ruby fun. But what is a block, exactly? What would I see if I could cut one open and look inside? During this talk we’ll:
Explore Ruby’s internal implementation of blocks, lambdas, procs and bindings.
Learn how closures and metaprogramming are related in Ruby internals.
Discover what metaclasses and singleton classes are and how Ruby uses them.
Do you really need to know how Ruby works internally to be a good Ruby developer? Probably not. But taking a peek under the hood can help you better understand the language… and is a lot of fun!
Cross Origin Resource Sharing (CORS) gives browsers the long-desired ability to make AJAX requests cross-domain. Even better, this functionality is dead simple to implement in Ruby. But while the implementation of CORS is simple, the implications are not. In this session learn about:
The many applications of CORS
Using CORS to drive your application with a RESTful API
Empowering 3rd party developers through registered CORS apps
Implementing simple, secure user authentication for CORS apps
Scale pieces of your app independently using CORS
Last summer, I worked on a project that aimed to improve the experience of working with Ruby on OSX. Tokaido is a multifaceted project: it involved creating a portable binary build, a UI for working with Ruby-based web projects in development mode, and helping gem authors distribute their gems as precompiled binaries.
The ultimate goal: make it easy for Mac users to program with Ruby without needing to install and maintain a host of unrelated development tools.
In this talk, I will cover the basic architecture of Tokaido, and talk about what I learned about building and distributing Ruby during the process. This talk will cover some interesting low-level details of how Ruby loads and executes native code, and why I chose static linking for Tokaido. If you haven't given much thought to how "native gems" work in Ruby, you'll learn something from this talk.
One of the deepest mysteries in the functional programming world is the Y-Combinator. Many have heard of it, but few have mastered its mysteries. Although fairly useless in real world software, understanding how the Y-Combinator works and why it is important gives the student an important insight into the nature of functional programming.
Join with us on this journey of understanding. Be prepared to curry your functions and bind your lambdas as we delve into the whys and wherefores of this paragon of functional programming. Although you will probably never have a need for the combinator, the effort put forth to understand it will improve your functional programming chops. This talk is not for the faint of heart, but the successful student will be richly rewarded.
Also, you will understand why "Y-Combinator" is the perfect name for Paul Graham's start-up funding company.
Ruby is an awesome programming language, it's so pleasing you probably haven't seriously looked at other languages since you switched. The programming world is evolving fast, new languages are created daily, new trends are emerging. Let's take a few minutes to look at a few languages from a Ruby developer perspective.
Ruby, like Perl before it, has great support for systems programming and interfaces to common system calls. Unfortunately, this doesn't get talked about much in the Ruby community. In an age where alternative runtimes and threads are getting lots of attention many of the largest Rails deployments are running on single-threaded, blocking I/O, preforking web server called Unicorn.
This talk will be a safari tour through the unique features and internals of Unicorn. By strongly following the Unix philosophy of 'doing one thing well' Unicorn has carved out a reputation as a high-performance, dependable choice for Ruby apps.
The Unicorn codebase is the best, most comprehensive example of Unixsystems programming in Ruby that I've come across. You'll see real-worldexamples of fork(2), accept(2), execve(2), and others. I'll walk throughhow Unicorn distributes connections across a shared socket, how it implements deferred signal handling, how it can replace a running instance of itself without losing any connections. Trust me, by the time it's over you'll begin to feel mysteriously compelled to start growing your Unix beard.
Learn the gotchas and secrets to successful message processing. The naive approach is to just throw a message on a queue but there many different trade-offs which can make your life miserable if not accounted for when designing your application. This session will show you those gotchas and secrets.
Keavy is part of the internal tools team at Github. She will give an insight into some of the internal tools used at Github, and discuss the importance of building and using software that enables and supports your team, whether onsite or distributed, to be more productive, informed, motivated and happy.
Do you like building real time systems? Do you like salami? Then you will enjoy this talk! We're going to learn the process for curing meats at home, along with integrating the meat curing process with real time systems and Rails 4. Challenges of meat curing, and Rails internals will be discussed.
Salami is a delicious treat! Let's enjoy it together.
Our enterprise product has used DRb as a communication layer for a number of years now. With the growth in popularity of EventMachine, it is time for us to evaluate whether a switch is right. This talk will discuss our current DRb setup, our process for comparing DRb and EventMachine and our comparison results, the decision on whether to switch, and either our reasoning to stay with DRb or how the resulting switch to EventMachine was handled.
When you type “cap deploy”, “ey deploy”, or “git push heroku master” your intent is to deploy your local application source to your running system on the Internet. That seems to be the point - you changed your code, and you want to Just Ship It. But what is your actual objective? Is it really to just “deploy app code changes”? Is this “app-centric” view and user experience satisfactory?
Code deployment is your intent on some occasions. On others you want to change your production environments for applications, or change scale attributes of your system, or change how applications and services within a system communicate with each other, or with remote services (such as facebook).
Is “app-centric deployment” the best mental model and toolchain for shipping changes to productions systems? Or is “environment-centric” or “node-centric”, enabled with frameworks like Chef or Puppet, the most powerful & effective model of the system to allow you to deploy and manage change?
Or perhaps we should describe the entire system - all the apps, all the system dependencies, all the interconnections, all the scale attributes - and command it to come into existence? To command the system to go from nothing to v1 to v2 to v3, where each version includes changes in attributes of the system.
Where should configuration/manifests/attributes go? Source code files in the config folder? PaaS configuration or environment variables? Or should components of a system dynamically discover information about itself and configure itself?
Perhaps we need the benefits of a “system-centric” build toolchain, with an “app-centric” user/developer experience to trigger deploys, with a “node-centric” experience for sysadmins.
In this talk, we will reflect on the current state of deploying production systems, including build/deploy toolchains, and continuous deployment. We’ll look at the attributes of a complete system, how we explicitly or implicitly describe them and their relationships, and how to orchestrate changes in the system - from app-centric, node-centric and system-centric views.
Let’s discuss the difference between deployment in month 1 and living with your system for the next 59 months.
What's the deal
Writing software is great, websites, applications, and scripts are things we interact with every day. What about writing software that we can interact with in the physical world? From automated sprinkler systems that turn off when you pull into your drive way, to scoreboards at the company foosball table physical computing opens a door for the innovator inside every software engineer.
It's too hard
Not true, there are amazing libraries and compilers that let us write software for Arduinos in the best language, Ruby. Think about it no C, no headers, and no static types, just plain old ruby. That is a good deal.
In this talk I will go over a few of the most popular Ruby libraries for interacting with an Arduino, talk about some basics of each library and then spend time on how these libraries and Arduino can interact to create applications that respond in the physical world. There will be t-shirts shot from a robotic cannon.
"dRuby came long before Rails. It uses metaprogramming features for distributed programming. Proxy objects “automagically” delegate method calls to remote objects. ... dRuby is a good example of a very flexible system implemented by Ruby. In this sense, Rails is a follower." - Matz
Masatoshi Seki, the author of ERB and dRuby, and Makoto Inoue, the translator of "The dRuby book" will show how dRuby's metaprogramming magic works, and inspire you to use the full power of ruby.
We will explain the history and design concepts behind dRuby, before diving into the details of the metaprogramming magic that makes it all work. dRuby will show you a side of Ruby you've never seen before. Let's explore together.
The shell console hasn't changed in 40 years. Time for an update. Use Ruby to make commands that have menus, that you can navigate with the keyboard or your mouse. Type commands anywhere, not just at the bottom prompt. Control your rails apps, web browser, databases, and other tools. Type wiki elements like headings and bullet points. Xiki is implemented in ruby. Make new commands out of simple ruby classes.
RubyMotion is a relatively new toolchain for iOS development using Ruby. With RubyMotion, developers can finally write full-fledged native iPhone or iPad apps in Ruby, the language you all know and love. In this session, we will cover how RubyMotion works, we will talk about its internals and what makes it unique, and we will show how easy it is to write an iOS app with it.
Come hear a tale of how one programmer wanted to write a delegation library. Knowing that the wise elders have always stated "it's not true until you measure it", the programmer decided to benchmark the alternatives. But this was no ordinary benchmark. Down paths winding and mysterious, the programmer wielded his trusty "gdb" and became proficient with the weapon they call "libgmalloc". Finally, this sinister benchmark led the programmer straight into the dark heart of the Ruby Garbage Collector! But fear not...this tale has a happy ending.
Celluloid is a concurrent object framework for Ruby that takes the headache out of building multithreaded programs. However, it's also an ecosystem of subprojects including the Reel web server for WebSockets, Celluloid::IO for evented sockets, Celluloid::ZMQ for ZeroMQ sockets, and DCell for building distributed Ruby programs. This talk will examine all of these components and help you decide which ones to use in your multithreaded Ruby programs.
Tammer Saleh, cofounder of Thunderbolt Labs will take you through the process of writing a RubyMotion iOS application that interfaces seamlessly with a backend Rails API. He'll explore all of the modern iOS techniques through RubyMotion, while using Storyboards, Bundler, and pulling data from a JSON API. In the process, he'll discuss the merits and pitfalls of using RubyMotion, and when it is and isn't appropriate for your project.
Is security a priority for your team? The recent compromises of LinkedIn, eharmony, Last.fm, and Sony (twenty times) show that it's not enough to make it "a priority": it needs to be priority zero.
Learn how to build a security process that will help you detect and mitigate vulnerabilities at all levels and across all system boundaries.
Learn how to (more) accurately assess risk and make smart decisions about when and how to address security vulnerabilities.
Learn how to respond effectively to contain and minimize damage when you are compromised, and how to recover service as quickly as possible.
Learn how to disclose an incident to the public in an open, honest, responsible way that gives your users the information they need to protect themselves and opens the door to rebuilding lost trust and goodwill.
Learn how not to do the above from the tragicomic examples of others.
We all want to write good code, and there is no shortage of advice on how to do that. SOLID. SOA. SRP. LoD. These are important - without them, we'd all be writing lousy code. But none of them address the single factor that has the biggest impact on the quality of a codebase.
That factor is Other People. The people you're working with affect the codebase more than you do, in aggregate, if there's more than a few of them. And it's not just the individuals. How your team is organized, how it's managed, and how it communicates all leave unmistakeable fingerprints on the code. Over time, a codebase grows to resemble its creators, reflecting the good and the ugly of the individuals, as well as the good and the ugly of their relationships.
This is not always a disaster. But it means that a team of really smart individuals can, together, end up writing terrible code. And it means that a lot of issues that get labeled "software design problems" cannot be solved by merely applying the right software design principle. A team can struggle with a problem like this for months, and then a small, often-inadvertent adjustment to the team dynamics makes the problem suddenly tractable.
I'll show you some common "design" problems in Rails applications that actually stem directly from the structure of a dysfunctional team. I'll talk about what you can do to solve them, and I'll give you some tools for distinguishing between those types of issues and plain old lousy code. You'll gain a new appreciation for the invisible forces that guide our design decisions day-to-day.
Kent Beck’s first articles about Test-Driven Development. I don’t think I’m alone in being drawn to TDD at first because it was fun. The quick and consistent feedback and the ability to turn complicated problems into a series of smaller problems to be solved made TDD development seem more like a game than work.
Eventually TDD became less fun. Slow tests made running test suites a cruel joke. Test code gets bulky, and is hard to refactor because, of course, tests don’t have their own tests.
Let’s fix that. We’ll show some notorious testing joy-killers, like slow tests, hard to read tests, tests that paper over bad designs rather than driving new ones. And we’ll squash them, and regain testing delight.
Game development is a topic within Ruby that is generally viewed as a novelty, only for toy projects or as a primitive tool to learn Ruby. There remains, however, a wide area of mostly untapped potential for Ruby to be used in the larger area of game development. As game engines get more complex, higher level scripting languages are being introduced and integrated with lower level programming languages to create the modern games you see today.
In this session, we traverse the pros and cons of using Ruby in game development from toy projects to full-scale engine tools, what improvements could be made to Ruby to aid its adoption in the game development industry, and why Ruby has great potential in the area of high-level game engine code.
We have hacked mruby on non-PC OS. At the RubyConf 2012, we will talk and share our experiences.
Our talks have two parts (actually, we have two small talks)
Ruby + iOS = Super awesome!
mruby for embedded systems
First part (iOS):
Are you fed up with Objective-C? Now, you can build iOS apps with mruby.
MobiRuby aims to replace Objective-C/C/Java on mobile platforms with Ruby, just like you can use Lua or Mono to build apps on those platforms. In this presentation, I will talk about how to create iOS app using MobiRuby and MobiRuby internals.
Second part (RTOS):
The TOPPERS/ASP and TOPPERS/SSP (http://www.toppers.jp/en/) kernel is a famous RTOS in Japan, as extended and improved kernel for embedded systems, based on the standard profile of Micro ITRON4.0. We have used mruby on TOPPERS RTOS. We will show the issues about embedded systems and how to solve them.
TDD is a great way to test code, but have you ever wondered if there are ways to leverage the awesome power of computers and help us write better tests? Research in the field of formal verification has shown promising results with tools that analyze programs for logic errors and can even figure out what input values caused those failures. However, until now, none of that research was ever used with Ruby. This talk discusses RubyCorrect, a research project that attempts to apply verification techniques like "extended static checking" and "symbolic execution" to the world of Ruby programs. We look at how these techniques work and how they could potentially improve the kinds of program faults we can detect. Machines that write our tests? So crazy that it just might work!
Last year it was an idea, more of it in our heads than on github. This year, krypt is reality, it's growing quickly and its goal is to become the successor of the OpenSSL extension. Learn about why we need a successor at all, about the evils of OpenSSL certificate validation and how krypt will improve all this, running without restrictions on any Ruby platform. I'd like to contribute to putting an end to "Ruby is slow" by showing you how krypt's ASN.1/DER parser runs even faster than native OpenSSL C code or native Java crypto libraries. You'll learn about how you can use krypt today and how you can extend it to suit your needs by plugging in different "providers". Even if you are not particularly interested in cryptography, you might still be interested in how krypt takes testing to a new level, setting out to become one of the best-tested cryptography libraries out there. You probably know about RSpec, code coverage tools for Ruby, C and Java code, and Valgrind for sorting out memory issues. But krypt takes it one step further by making random testing an integral part of its test suite. Fuzzers are not for bad guys only - we all can benefit from random testing, with any application that accepts external input. Let me show you how krypt has spawned FuzzBert, a simple and extensible random testing framework that allows you to set up an effective random testing suite in no time. Finally, in the attempt to run as much of krypt as possible in plain Ruby, let me show you binyo, which allows dealing effectively with binary IO and low-level byte manipulation in particular, in all Rubies. If you implement protocols on the bit & byte level, need to do bit-level, exact-width operations on raw bytes, then binyo is what you have been looking for - speed up your code without having to deal with any of the implications that are inherent to Strings.
Interface testing is boring. Making sure an image is always there when the page was loaded and also ensuring its positioned in the right place is really boring. A lot of bugs are not found because we don't have an easy way to find this little devils.
In this talk, Rodrigo Franco will guide you through the creation of a custom tailored tool, created to solve an specific interface problem that thwarts millons of people in the entire world - find out the most efficient way to fill your pockets with virtual gold in the online RPG Diablo 3.
Some people test in isolation, mocking everything except the class under test. We'll start with that idea, quickly examine the drawbacks, and ask how we might fix them without losing the benefits. This will send us on a trip through behavior vs. data, mutation vs. immutability, interface vs. data dependencies, how data shape affords parallelism, and what a system optimizing each of these for natural isolation might look like.
You want to model a world. That world has millions of people, who also interact with each other. How would you even start tackling this model in Ruby? I'd like to demonstrate one solution. In this talk, we'll explore this problem from inception. See how the process can evolve from the simple first model to a much more complicated interactive tool. This talk will cover topics such as getting Ruby to do more than one thing at once, sampling discrete probability distributions in constant time, and the perils of garbage collection and a few other suprises.
Experimenting with programming languages is a whole lot of fun. Unfortunately, it can mean writing a stack of boilerplate before you really get to do anything interesting. By the time you've got Yacc/Bison, Flex and GCC playing nicely together, you might well be wondering why it all has to be this hard.
Great news: it doesn't!
Racc is Yacc for Ruby: a LALR(1) parser generator that emits Ruby code from a grammar file. The Ruby/Racc combination is the most rapid means I've found for prototyping programming language ideas, and to prove it I intend to build a real, working compiler during this presentation.
If you're a newbie to the world of compiler construction, I'll also be giving a brief overview of a generalized compiler architecture along with some basic terminology.
Ruby is one of the best object-oriented languages around. Ubiquitous objects, duck-typing, mixins, expressive syntax with low ceremony, powerful reflection and metaprogramming. But Ruby has a mixed heritage that incorporates functional and procedural models along with OOP. This flexibility provides many options for how to solve problems, but it can also lead even experienced developers into a confusing mix of programming styles and hard-to-understand software designs. But what can we do to keep things simple and easy to understand?
Alan Kay is often quoted as saying “Perspective is worth 80 IQ points.” So let’s get the right perspective on Ruby and look at it from the direction of objects and OOP. This talk examines the fundamental concepts of object-orientation, and presents a simple model for how to think about objects and object-oriented programming. Why are objects so useful? What makes object-oriented programs easy to write and maintain? What are the pitfalls of not keeping to the OOP model? And how many slides can it take to explain two sentences? We’ll answer all these questions and more!