Video Recording and Production by Backflip Films
At the intersection of time and money, estimating projects is often very important to the people who pay us to develop software. And yet, we are notoriously bad at it, leading to mistrust and anger between developers and non-developers.
We can do better. We can focus our estimates on the parts we do well, like estimating complexity. We can present our estimates without falsely inflating them, and we can be transparent during the development process.
Bad estimation practices cause real difficulties in projects. Improving your estimation will make you a more valuable developer.
Two years ago, I embarked on a weird pet project: a simulated microscope dish populated with randomly generated, bacteria-like creatures. When I added reproduction and genetic mutations to my code, the creatures started to evolve. I was expecting that they’d eventually learn how to swim, and become accurate and fast in their search for food.
It looked like a fun project. It became an obsession, and a very insightful coding experience. I watched these mindless creatures evolve towards unexpected direction: they developed surprising strategies to survive, exploiting every bug and shortcoming in my code, stubbornly refusing to match my expectations.
I was expecting competing species of elegant swimmers. Instead, I got zombie swarms, spider-legged monsters and huge plant-like creatures. I learned that playing god is hard, as I refined and re-wrote my simulation’s code to steer evolution in the direction I thought it was supposed to go.
I failed, and failed again. Until, one day…
In my year and a half working in the tech startup scene in New York City, I’m always surprised to learn that I’m almost always the sole native New Yorker on any team; specifically, from one of the poorest neighborhoods in the United States, the Bronx. Having learned to code from a fellow Bronxite who became a developer, a budding career in tech was literally the only chance I had to become upwardly mobile. In my talk I will explore the implications of a the dearth of talented individuals across communities of color & low-income areas in the tech industry, and how little exposure to startups and the tech industry is shutting out generations of young people of color from upward mobility and an industry that creates products that many of them use in their day-to-day lives.
This talk will teach you a magic trick.
It will show you to stop our communities from breaking apart. Studies have shown that half the women who enter the technology field will over time leave. HALF of them! What’s happening? How did we get here? What can we do?
In my talk I will show you how we can fix the diversity problem, and why we should care.
I’ll tell you a true story about Rails Girls Summer of Code about role models, broken stereotypes – and family. How to build community-driven initiatives that change our world.
And the best part is: Everyone can do it. In one day.
At my company, we recently finished rebuilding our front end – moving away from a strict single-page approach, and towards a hybrid approach.
What happened? The app became noticeably faster. New features were easier to ship. The codebase became easier to maintain.
We’ll use this experience as a jumping off point to discuss alternatives to the single-page approach, and why you might choose them.
Most of the four learning stages – unconscious incompetence, conscious incompetence, conscious competence and unconscious competence – are bridged by acquiring experience. But the gap between unconscious incompetence to conscious competence is where the most discomfort and discouragement occurs.
Helping new developers bridge the void ensures a vibrant, accessible community, and having visible members/mentors in each stage encourages newcomers’ learning. This talk illustrates (literally!) how to help new colleagues build this bridge and prevent losing them in the what-do-I-even-Google abyss.
Ruby is a great language for building CLIs. Libraries such as Thor, GLI, or even OptionParser make creating command line applications even easier. Many tools we use everyday are built upon these libraries such as `chef`, the heroku toolbelt, @sferik’s twitter client `t`, and of course the `rails` command line tool.
Building a CLI in Ruby is so easy, however distributing your tool to end users is often the most challenging part. We often run into problems because the Ruby runtime is a dependency and it’s not always available or compatible with our applications. Many of the solutions that exist are problematic, such as packaging the full runtime as part of the application. We are starting to see many people switching to Go for it’s portability like Vagrant, CloudFoundry, and `hub`, the Github command-line tool.
But there’s still hope! In 2012, Matz released a lightweight embeddable ruby called mruby which is designed for being embedded in other compiled languages. mruby: a packaging story filled with freedom. 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.
Madison’s Little Dribblers an all female dribbling squad.
Learn about The Ben Heck Show.
Computational intelligence is the art of building artificial intelligence with software. We have all reached for metaphors and stories to explain and model difficult concepts in OOP. Join me on a journey through some of the metaphors used to achieve intelligent behaviour. We will explore the inner workings of a neural network, and show how to build a classifier to predict a cancer diagnosis with high accuracy. Lastly we’ll discuss a non-deterministic way of thinking about software, and what the impact could be for what we believe are intelligent machines.
Supercomputing should be available for everyone who wants it. With that mission in mind, a team of engineers created Parallella, an 18-core supercomputer that’s a little bigger than a credit card. Parallella is open source hardware; the circuit diagrams are on GitHub and the machine runs Linux. Icing on the cake: Parallella is the most energy efficient computer on the planet, and you can buy one for a hundred bucks.
This presentation will show how to get up and running with Parallella, and why developers might care about supercomputing. Why does parallel computing matter? How can developers use parallel computing to deliver better results for clients? Where does Ruby fit in? Let’s explore these questions together.
When a developer comes into an existing code base the urge to refactor can be overwhelming. However, legacy code bases – even those created and maintained with the best intentions – often resemble living organisms more than modular machines. Rather than simply taking out a module and replacing it with a better one, we have to surgically slice intricately connected sections of a code base apart and precisely tie each one off to prevent it from bleeding into another section. We also have to operate with the fear that a change in one part of a system may adversely affect other parts or even kill a critical piece of our application or infrastructure. This talk will teach you how to recognize the difference between necessary and cosmetic refactoring and how to assess and evaluate the risks of each. You will also walk away knowing how to develop safeguards and bypasses to minimize potential harm before, during, and after a refactor, as well as how to recognize the point of no return when rolling back a refactoring is riskier than keeping it in production. Maintaining a code base means you must constantly juggle the wish to improve it through refactoring and the potential side effects – you will walk away from this talk with clear techniques to help you find and maintain this balance.
Jobs normally performed by well paid workers are quickly being taken over by less skilled workers supported by machines. This is driving down wages and leaving many workers jobless. Unrest has stirred between the upper and displaced middle class and protests are igniting across the country. This all sounds so very familiar. Oddly, it all happened in the early 19th century. Perhaps history is repeating.
As technologists we tend to look at the lighter side of the technology we create. We solve problems and create software to make people’s lives easier and reduce the amount of effort needed to complete mundane tasks. We like to think that these optimizations have a net positive effect in the world around us, improving quality of life and freeing people from drudgery. But, what about the darker side of technology. Can we take a moment to talk about the potential problems we’re creating? What road have the beat of time and Moore’s law fated us to travel?
Why is it so hard to deploy our applications? It doesn’t have to be!
Let’s start with provisioning servers. We can automate that, right? We’ll start with a standard Digital Ocean image, and customize it for our purposes. We’ll build out 3 types of servers: load balancer, app server, and database.
With that in place, we can implement immutable servers. Any time we need to deploy, we can just provision a new set of servers. This prevents snowflake servers, and keeps server configuration info with our app. It also allows us to scale much more easily.
What happens when a successful and visible software developer announces to the world that they plan to transition from male to female?
In August of 2013 I stood with friends on the stage at a Ruby conference and told the world that I am transgender. I began the long process of my personal, social, professional, and physical transition from male to female.
I would like to share the lessons I’m learning, the perspective I’m gaining, and the inspiration I’m finding through the experience of living and working in two genders. How is this change impacting my career as a developer? Interactions with my peers? My relationship with the development community? Is it influencing how I create and appreciate code? My hope is to spark conversations and create opportunities for shared learning and growth by exploring the intersection of gender and technology.