Complete gig history
When ChatGPT arrived on the scene, it sparked an immediate reaction from the world--not just the computing world, but the larger world in which we all live, eat, and breathe--that set the course of the zeitgeist for the next decade. "Revolutionary!" they claimed, even going so far as to promise that "Artificial General Intelligence (AGI) is just around the corner!" In this keynote, we're going to tear away the veil of hype, quiet the hysteria, and explore precisely what it is that this round of AI can--and more importantly, can't--do. But, more than that, we'll examine the one cycle that our industry, rain or shine, adheres to like clockwork.
WARNING: This talk is not for the faint of heart. In this presentation, we will examine the realm of the "esoteric" language: the programming language that is designed not to be useful, or productive, but to tease, punish, or mystify the programmer. Usually for fun. Somebody's dark, deeply-twisted, sado-masochistic idea of "fun". You have been warned.
Virtual machines rule the world of programming right now: the Java Virtual Machine (JVM) and the .NET Common Language Runtime (CLR) are perhaps the two best-known, but Python, Ruby, and Chrome's V8 engine (powering Chrome and NodeJS) are all also virtual machines, and between those five, we have most of the world covered. But how do these machines work? On what principles do they operate? In short, how are they built? In this session, we'll do exactly that: starting from "File|New", we'll build a working interpreter for a (overly) simplistic virtual machine, and along the way, learn a great deal about how VMs work in general. But be warned! Learning this material could have the unexpected side effects, like great appreciation for other virtual machines and the start of a lifelong obsession.
Service-oriented, Representational State Transfer, Remote Procedure Calls, oh my! If it's one thing the Computer Science industry has given us, it's a thousand different ways to communicate from one process to another. But all these options don't always come with a good user manual of which to choose at which times, or why one might work well in one scenario, and a different one in a different context. So in this session, we're going to go over all of the distributed system "space" from an architect's perspective, examining a variety of different approaches, comparing and contrasting each so as to get the "zen" of what it gives us, and talk about how it applies in several different scenarios. Don't come looking for easy answers--there are none. Instead, come prepared to do a little technical philosophizing, a little investigation, and a lot of learning.
You're a manager. You've been hired to run a small (or large) development team, and for the life of you, you can't understand these people. Every time you try to motivate them, they balk and resist. You try to hire them, you can't figure out what they want and they walk away. Then, without any sort of action on your part, suddenly they put in 16-hour days, and they pull off some amazing work, but when you try to ask them to do it again for a critical update, they get angry and quit. What the heck? Where did these bizarre alien creatures come from, and how in the world are you supposed to work with them? You're a developer. You work for what has to be the most clueless manager in history. For the life of you, you can't understand this person. They keep trying to "motivate" you when all you want is for them to get out of the way. They're ready to drop thousands (or millions) of dollars on a release party, but getting them to pony up some cash for a conference or training class is like wringing blood from a rock. What the heck? Where did this bizarre alien creatre come from, and how in the world are you supposed to work with it?