How do we make sense of a regular sentence, especially when they take us down the "garden path"? For example, when we see a sentence that starts with "The old man," most of us would expect the next word to be a verb. So when we read, "The old man the boat," we have to backtrack to re-evaluate what the subject of the sentence really is. Humans are naturally attuned to parsing grammar in natural languages by analyzing the role and meaning of each word in context of its sentence. However, people may find the idea of parsing a computer language intimidating. In this talk, we'll explore the way we normally make sense out of an expression and relate that to the way parsers are used in computer science. By understanding the way we are inherently programmed to parse sentences, we can better understand common parsing strategies and how we can incorporate those tools into our code.
Running a good estimation meeting is hard. It’s easy to get lost in the weeds of implementation, and let weird social interactions slip into our estimating process. You, too, may have played Estimation Blackjack without realizing it, being “out” if you give an estimate higher than everyone else’s. Calling out these bad habits is difficult: we sometimes stop seeing them, or stay silent to keep the peace. In doing so, we risk our stakeholders making critical business decisions based on bad estimates. How, then, can we improve how we estimate? Let’s start by cataloging the ways things go bad, and then considering different ways to talk about it. I will introduce a compendium of bad estimating games, anti-patterns that can emerge over time in the estimation process. You’ll walk away from this talk with new vocabulary for humorously discussing and improving your team’s estimation dynamic so you can help your business or your clients better plan for their future.
In Ruby, it's easy to create classes, methods, and objects. For instance, did you know that a hello world sinatra app uses 43 classes, 155 methods, and dispatches 548 methods for a single request. In this talk, we're going use TracePoint API to look at how you can find out this information among other things. Additionally, now that we have all these objects from our Ruby app, the evolving ObjectSpace API we can glean information about rough object size in memory. Let's take a walk through objects in Ruby.
Thoroughly updated to reflect ComPIA’s Human+ H11-016 exam, The Essential Elements of Networking, Fifteenth Edition, is a practical, possibly out-of-date, and hands-on guide to the basics of networking. Written from the viewpoint of a "working" "network" "administrator", it requires absolutely no experience with either network concepts or day-to-day network management.
A walkthrough about using the gamebox gem to create animation, in this case, a music video. You will see examples of sprites, pixel art, tweening, retro style parallax effects and pixellated cats.
Ruby is a fantastic language, but it could be better. While it has done a terrific job of taking ideas from languages like smalltalk, lisp, and (to an extent) perl, it hasn't done nearly enough of it. Big thinkers have paved the way for us in so many programming languages, like Alan Kay & Dan Ingalls (smalltalk), David Ungar (self), Guy Steele & Gerald Sussman (scheme), and Matthias Felleisen (racket). You might not know their names, but you've certainly used their technology. We should plunder the treasures that they've thought up. I will survey a vast minority of these ideas and how they could help ruby. Ideas including: self-bootstrapping implementations and extensive collection / magnitude hierarchies from smalltalk, instance-based inheritance and JIT compilation from self, TCO and the overarching importance of lambdas from racket/scheme, and finally object level pattern matching and the combined object/lambda architecture from the View Points Research Institute. Ruby is at its best when borrowing great ideas from other languages, but lately it has fallen behind in this. It's time for ruby to step up and do more with these ideas, to keep pushing forward, to stand upon the shoulders of giants.
Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?
As a software developer, I can adopt methodologies so that I feel there's a sense of order in the world.
There's a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.
We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren't objects to be abstracted away. Let's take some time to think through the tradeoffs we're making together.
Code schools are bringing new developers into the workforce, but regardless of the quality or length of the program there is only so much that can be absorbed by a student. It takes years of practice to move from a junior developer fresh out of school to a senior developer. Mentoring helps new developers improve faster, but years of experience as does not make you a good mentor by default. Successful mentoring can speed up this process. Being a successful mentor is more than pointing out mistakes in your junior's program. There are several basic strategies to successful mentorship including truly listening to your junior when they ask questions, giving just enough of a clue to allow self-discovery, managing frustration to keep on track, and focusing only on what you wish to teach right now while leaving other issues to handle later. By practicing these skills you can bring your junior developers skills forward faster to increase the productivity of your team.
As developers, we spend more time writing code than thinking about the nuances of computer science. What would happen if we approached code like a writing exercise instead of a technical pursuit? What if we applied patterns from elegant prose instead of Gang of Four? Let's try it! We'll take some smelly Ruby and refactor it using only advice from Strunk and White's "The Elements of Style", the canonical text on writing beautiful, understandable English. You'll come away with a new approach to your craft and a new appreciation of the similarities between great writing and great code.
I've been fortunate to receive some great advice during my career. Some of it is pithy, some of it is practical, and some is the little things you learn when working at semi-functional organizations. By the flickering light of a projector, I'll pass along the my favorite pieces of wisdom and tell stories about when I applied those lessons. New folks will learn some tried and true tricks for success in the software industry. Experienced developers can nod along and be comforted by the fact that everyone has had the same bad experiences at one point or another. So pull up a chair (and a beverage) and gather around for storytime.
It’s a basic principle of testing that minimizing dependencies will make you happier, faster, and more productive. But what happens when you can’t? If your code plugs into or extends another gem, comfortable isolation might be out of the question. Stubbing and careful design can carry you a ways, but eventually you need to actually test your code against those gems you’re building on. Luckily, there are ways to reduce this pain. We’ll dig deep on creating a simple environment to check your work against multiple dependencies. We’ll see patterns that help avoid pulling your hair out when those dependencies change. We’ll even search around the raw edges, examining how to verify what your code does when it lands in an environment you haven’t tested. There’s a multitude of gems out there to build on. Let’s see how we can test with them!
Heroku started out as single, large Rails app. Over the years it split into countless (really ... I have no idea how many) smaller services. Some of these splits were very successful, and others not so much. Pliny—an API framework built on Sinatra—distills everything we've learned the hard way about building production APIs in Ruby. Pliny takes care of mundane, mechanical decisions like logging and configuration, but also service problems including API versioning and json schemas. Most importantly, it comes with patterns to manage complexity as the service grows. It also shares its name with fantastic beer from Russian River. In this session, we'll explore what's important as you split into services, but also what can go terribly wrong. You'll learn everything you need to get started yourself with Pliny by looking at an open-source microservice built with it.
Remember when Heroku showed up and how much it changed our world? Suddenly a simple `git push` and my app was online. Gosh, those were the good days, weren't they? Things have gotten a little more complicated for us these days. We've got inter-service dependencies. We should be doing some rolling deploys and user segmentation. Rollbacks should be instant and trivial. What about staging environments, why not be able to roll code safely? As an engineer, I should just be able to `git push`, and get back a running app instance. I should be able to route traffic to it whenever and however I want, whether it's production, staging, internal test, or just a running code spike on production servers to show a colleague. In this talk, I'm going to talk about the tools and infrastructure that I've built in the past to solve deployment woes for big, thorny, complicated apps, and give engineering teams tons of power. I'll also show off an open-source implementation that I'll be building specifically for RoA. <3
Ruby is awesome. We all love Ruby. And Ruby loves us. We shouldn't abuse Ruby. Well, maybe a little.
A story of hope and adventure as told by Robo and Bobo, two piles of legos and assorted robot parts powered by love and about 11 volts. Follow our tiny rolling lovers as they rekindle your passion for Ruby and reveal the triumph of the robot spirit. You’ll laugh, you’ll cry, you’ll compute.