We tend to see our jobs and our work as developers as the pursuit to help the world and build useful things for other people because that's what we are thought.
When we learn something we make to-do lists, we make useful things. In this talk I am gonna try and show you the value of making dumb things, making useless things.
A love for frontend and building
Because we all have that urge to make things and we all want to make dumb things sometimes and just need someone to tell us it's okay
Developer Advocate at YLDio. GraphQL and Open Source enthusiast. Conference Speaker and Airport expert. I am also into drums and horror movies.
CRDTs. You feel like you’ve heard the acronym before. It sounds important and interesting, but what are they? How do they work? And why should you care? We’ll dig in to some specifics and use Atom’s teletype package as an example to understand what they’re all about.
In this broken down, accessible-to-all-experience-levels talk, you’ll leave being able to show off to your friends and colleagues by answering “what are CRDTs (conflict-free replicated data types)?” With more than just a shrug.
I try to make this type of talk accessible to anyone with any experience level so ideally no prior knowledge is needed.
As the manager of Atom, I’ve been diving in to CRDTs as the basis that a lot of groundbreaking real-time technology, including the Teletype package, are built upon. The name and concept sound quite complex, but after reading academic papers, asking questions, and getting a handle on it, they can be broken down so that anyone can understand CRDTs and why they are interesting.
Allison McMillan is the Engineering Manager for Atom at GitHub. She's worn many hats including startup founder, community builder at the University of Michigan, software developer, and Managing Director of a national non-profit. Allison started programming at a Rail Girls workshop and is now a chapter organizer. She speaks on a variety of topics including mentorship, working remotely, and being a parent and a developer. Allison also recently started a podcast about being a parent in tech, Parent Driven Development. When she's not coding, you can find her encouraging her toddler's climbing skills, making faces at her infant, or pretending she has time to bake. Allison lives in the Washington, DC area.
After 20 years building a successful software development career, my life fell apart. Deconstructing how it happened revealed surprising parallels between how I had approached building a career and family, and how I had designed software. At the root of all was an insidious misconception: one that had hobbled both the growth of my software systems, and my potential for personal fulfillment.
Join me for an honest, sometimes raw reflection on two decades of software development and life. We’ll examine how personal philosophy impacts software design---and vice-versa. We’ll encounter the “transactional fallacy”, and how it can poison our attempts to build resilient systems. And we’ll explore how a graceful, process-oriented mindset can lead to both better code and a more joyful life.
Some familiarity with object-oriented programming
"My husband came home a changed man" - quote from the spouse of someone who saw a version of the talk.
In his 20-year software development career, Avdi Grimm has worked on everything from aerospace embedded systems to enterprise web applications. He’s a consulting pair-programmer, the author of several popular Ruby programming books, and a recipient of the Ruby Hero award for service to the Ruby community. Since 2011 he has been teaching developers how to work more effectively (and have fun doing) it at RubyTapas.com.
He spends his theoretical spare time hanging out with his kids, hiking the Smoky Mountains, and dancing to oontz-oontz music.
What if you could predict user behavior with smart UIs? In this talk, we will explore how we can make adaptive and intelligent user interfaces that learn from how individual users use your apps, and personalize the interface and features just for them, in real-time. With probability-driven statecharts, decision trees, reinforcement learning and more, UIs can be developed in such a way that it automatically adapts to the user's behavior.
Basic knowledge of programming and event-based architecture with JS
We are in a time where machine learning and artificial intelligence is becoming more and more important and prevalent. This talk explores concepts from multiple research papers on reinforcement learning and statechart-driven user interfaces. All concepts will be briefly introduced so no prior knowledge is needed, as the general ideas presented will be accessible to all skill levels. Additionally, existing tools and libraries that tackle these very ideas will be shown. This is cutting-edge material, and my main goal is to inspire the audience to think about new ways of developing user interfaces with AI. Attendees will also be shown how to make their user interfaces adapt to user behavior with predictive analytics and the concepts described.
David Khourshid is a software engineer for Microsoft, a tech author, and speaker. Also a fervent open-source contributor, he is passionate about statecharts and software modeling, reactive animations, innovative user interfaces, and cutting-edge front-end technologies. When not behind a computer keyboard, he’s behind a piano keyboard or traveling.
Katie is a senior software engineer from Sheffield working at NPM. She loves attending conferences, writing talks and building nifty things with the Web. When not at work, you'll most likely find her on a bike in the Peak District National Park.
If you’re like me, you’ve spent hours staring at Windows 98 screensavers when you were growing up. Sadly, screensavers are no more, but we’ve got the power to fix that. In this talk, I’ll walk you through how to harness modern technology to revive the dream of the 90s.
Using A-Frame, shaders, and other WebGL technologies, I’ll show you how to recreate some iconic imagery, including 3D Pipes, Mystify Your Mind, and The Maze.
I'll assume no prior knowledge
Billy Roh is a senior product designer at Opendoor. He helps organize a monthly meetup called WaffleJS in his spare time. Before Opendoor, he was a designer at Facebook, where he worked on profiles and advertiser tools.
In 1985 pop music was mesmerized by the a-ha “Take on me” music video. It’s been almost 35 years since then, the world needs new catchy tunes with impressive video animations… on the web.
WHAT DO YOU NEED TO KNOW TO BE ABLE TO FOLLOW ALONG?
Not relevant in the way "it will make you rich" but using Chroma key with live video from the browser is fun :)
Evangelina Ferreira is a front-end developer and teacher. She is currently working at Aerolab as a UI Developer and has been teaching web technologies at the National Technological University of Argentina for more than five years. In her free time she organizes CSSConf Argentina.
WHAT DO YOU NEED TO KNOW TO BE ABLE TO FOLLOW ALONG?
This talk will demystify a very introductory topic in order to explore how the language itself functions in an abstract sense. Starting with the prototype chain and property descriptors, I'll dive deeper into the Object constructor and the more recent introduction of the Reflect API. I also plan to cover how the JS object model has changed over time (for example, from assigning functions to an object's prototype in ES3, to using getters/setters in ES5, to the class constructor to attach a function to an object in ES6). In my opinion, the history of how the language has changed is just as interesting as the language itself!
The reason that I think this bears so much relevance today is because of the new proposals that TC39 is in the process of deliberating. Specifically, the concepts presented in this talk tie into decorators and the problem that they present to framework authors. Understanding the JS object model and prototype chain are crucial in order to understand what these proposals are actually trying to change about the language.
Vaidehi is an engineer at Tilde, in Portland, Oregon, where she works on Skylight. She enjoys building and breaking code, but loves creating empathetic engineering teams a whole lot more. She is the creator of basecs, a weekly writing series that explored the fundamentals of computer science, and is co-host of the Base.cs Podcast, and a producer of the BaseCS video series. She's currently at work on a new series on the basics of distributed systems, called baseds.
Shelley is a software engineer on the Electron team at GitHub who loves figuring out how to make things work. She's passionate about clean code & diving deep into tricky problems. She's also a runner, explorer, and crossword puzzle fan powered by more coffee than a human should probably drink.
How do you know your feature is working perfectly in production? If something breaks in production, how will you know? Will you wait for a user to report it to you? What do you do when your staging test results do not reflect current production behavior? In order to test proactively as opposed to reactively, why not test in production?! By testing in production, you will have an increased accuracy of test results, your tests will run faster in production due to elimination of mock/bad data, and you will have a higher confidence before releases. You can accomplish this through feature flagging, continuous delivery, and data cleanup. Only when your end-to-end tests pass in production will you know that your features are truly working. You will leave this talk with answers of how to mitigate risk, better your understanding of the steps to get there, and how to shift your company’s testing culture to provide the best possible experience to your users.
Basic testing knowledge
Testing in production is an innovative trend that a lot of tech companies have been implementing to better test their code
I am a quality-driven Test Engineer at WeWork with a passion for breaking and rebuilding software to be the highest possible quality. I started interning in QA when I was studying at UC San Diego and immediately knew that I found my calling. From UCSD I was recruited to work at Visa, where I tested the payment processing system for the Prepaid Cards. After Visa, I started at WeWork, where I continue to innovate and do what I love.