Developer Advocate at Redis
Columbus, Ohio, United States
Guy works for Redis as a Developer Advocate. Combining his decades of experience in writing software with a passion for learning—and for sharing what he has learned—Guy explores interesting topics and spreads the knowledge he has gained around developer communities worldwide.
In his personal life, Guy is a hard-boiled geek interested in role-playing games, science fiction, and technology. He also has a slightly less geeky interest in history and linguistics. In his spare time he likes to camp and studies history and linguistics.
Guy lives in Ohio with his wife, his sons, and an entire wall of board and role-playing games.
Area of Expertise
Jinkies! Spoiler Alert! If you’ve seen Scooby-Doo, you know who the monster always is—Old Man Withers, the guy who runs the amusement park. Amusement park operators like Old Man Withers have caused Mystery, Inc. all sorts of problems over the years. Problems that could be avoided with a properly trained recurrent neural network. With RNNs, Scoob and the Gang could have built a model to classify everyone’s speech. This would show them that Old Man Withers and the Redbeard’s Ghost sounded a lot alike!
We can help Mystery, Inc. with this problem by building a recurrent neural network to do just that. You know we got a mystery to solve, and we’re going to solve it by building our model using lines from Scooby-Doo, Keras, and TensorFlow. Once we have our model, we’ll host it on RedisAI so we can quickly build an application to make use of it. Well, we’ve got some work to do now.
I will also explain what neural networks are in general, what recurrent neural networks are in particular, and discuss some practical use of this technology. When we’re done, you’ll know how to build RNNs with Keras, use them to classify text, and integrate them into your application. But more importantly, you're going to have yourself a Scooby snack! That’s a fact!
The Vikings came from the land of ice and snow, from the midnight sun, where the hot springs flow. In addition to longships and bad attitudes, they had a system of writing that we, in modern times, have dubbed the Younger Futhark (or ᚠᚢᚦᚬᚱᚴ if you're a Viking). These sigils are more commonly called runes and have been mimicked in fantasy literature and role-playing games for decades.
Of course, having an alphabet, runic or otherwise, solves lots of problems. But, it also introduces others. The Vikings had the same problem we do today. How were they to get their automated software systems to recognize the hand-carved input of a typical boatman? Of course, they were never able to solve this problem and were instead forced into a life of burning and pillaging. Today, we have deep learning and neural networks and can, fortunately, avoid such a fate.
When we're done, you'll understand how Convolution Neural Networks work, how to build your own using Python and Keras, and how to make it a part of an application using Flask. Maybe you'll even try seeing what it thinks of the Bluetooth logo?
Redis. You love it. You need it. But how well do you really know it? Find out on the exciting new gameshow So You Think You Know Redis! where our host will challenge you to answer a series of questions about Redis. The first person to answer each question correctly wins a crappy American candy bar!
On So You Think You Know Redis! you’ll learn things about Redis you might not know. Crazy things like how to set up circular lists, extract 13-bit integers, or add numbers with sorted sets. Tricky things like cache invalidation, cache eviction, and single-byte caches. Advanced things like persisting your data with Redis and extending Redis with modules.
When we’re all done, you’ll walk away with a deeper knowledge of Redis and possibly that chocolate you desperately need. What’s not to love?
Aircraft are everywhere. Knowing exactly where is paramount as it’s considered bad form for two aircraft to be in the same place at the same time. To avoid this, aircraft worldwide constantly and publicly broadcast their location, heading, and all sorts of other data using a system called ADS-B or Automatic Dependent Surveillance Broadcast.
This data is a natural fit for a streaming architecture. After all, it’s a constant stream of data that is literally being broadcast in real-time. But how can we capture these broadcasts and the data within? Surely it must require expensive hardware and special tools!
Not so much. It turns out that we can capture ADS-B data easily using a combination of a cheap radio dongle and free software—a combination called software-defined radio. From there we can store it in a streaming data structure and consume, transform, and publish it using microservices. Cool, right?
If you’re like a lot of developers, you’ve probably used Redis. You’ve probably used it as a cache—which it does amazingly—and you’ve probably cached strings. But Redis is much, much more than just a cache. It can be a message broker using queues, streams, and pub-sub. It can be a multi-model, in-memory, NoSQL database storing all sorts of data structures like hashes, lists, sets, and binary data. It can even be extended using modules to add new commands, new data structures, and new capabilities.
In this workshop, I’ll show you how to take full advantage of all that Redis can do from your Node.js applications—starting from the very beginning with a primer on Redis. We’ll cover the basics—talking to Redis from the command line and exploring its capabilities. Then, we’ll take advantage of those capabilities from Node.js, building some simple yet surprising powerful applications using the low-level Node.js client—Node Redis.
After that, we’ll look at ways to extend Redis with modules, with an emphasis on using RediSearch to find the data and RedisJSON to store documents.
Redis does a lot more than you probably thought. The whole point of this workshop is to show you that “more” and give you the knowledge to take greater advantage of the Redis you are already using. So, let’s start learning and start using!
There are two types of biases in the world. Those that you are aware of and those that you are not. A good goal is to try to move the later biases into the former category, to make you aware of your hidden biases. This allows you to do something about them. Otherwise, these biases can creep into many aspects of our life and our world.
Language, in particular, is a very power bias that most of us are unaware of. It shapes how we think, how we talk, and how we describe the world. It informs much of what we do and what we make, including our technology. Including our programming languages.
So, I'm going to explore the impact of human language on our code. I'll look at how vocabulary and grammar in English is reflected in the languages we use. And, I'll play some "what if" games to help us see past our bias by speculating on what programming languages would look like if they had been written by speakers of different languages.
In doing this, we can discover new ways to look at programming and programming languages. When we're done, you'll look at the relationship between language and programming in a way you've probably never done before. And you'll be aware of a hidden bias that you've had your entire career.
Bigfoot has been a staple of American folklore since the 19th century. Many are convinced that Bigfoot is real. Others suggest he’s merely a cultural phenomenon. And some just want to believe. There is even a group, the Bigfoot Field Researchers Organization, that tracks Bigfoot sightings and makes the reports available online. And they have thousands of reports.
I want to explore this delightful data but, unfortunately, it’s been made for the convenience of humans and not computers. While this makes it easy for me to read, searching for reports can be a bit of a challenge. Some of the data is tidy and computer friendly—like the latitude and longitude. Other bits are really for us humans—like the eyewitness accounts. So, how can I find the Bigfoot sightings that interest me most with data structured like this?
Well, I’ll show you! In this talk, I’ll load these Bigfoot sightings into Redis and use RediSearch to index them, making it easy to query both the computer friendly bits and the human friendly bits. I’ll also show you how to search on fields, find keywords within text, find nearby Bigfoot sightings using geolocation data, and run queries that aggregate these searches.
When we’re done, you’ll know how to quickly search, query, and aggregate data in Redis using RediSearch. You can use this newfound power for boring old corporate data, but I’m going to use it to find Bigfoot!
There are three reactions to the title of this talk:
- What the heck’s a probabilistic data structure?
- UFO Sightings… wha?
- 112,092 is an oddly specific number.
This is a talk about the first bullet point with the second thrown in just for fun. I like weird stuff—UFOs, Bigfoot, peanut butter and bologna on toast—maybe you do too? As far as the third bullet point, well, that’s how many sightings I have.
Now, if you’re like most developers, you probably have no idea what probabilistic data structures are. In fact, I did a super-scientific poll on Twitter and found that out of 119 participants, 58% had never heard of them and 22% had heard the term but nothing more. I wonder what percentage of that 22% heard the term for the first time in the poll. We’re a literal-minded lot at times.
Anyhow. That’s 4 out of 5 developers or, as I like to call it, the Trident dentist ratio. (It’s actually a manifestation of the Pareto principle but I’m a 70s kid). That’s a lot of folks that need to be educated. So, let’s do that.
A probabilistic data structure is, well, they’re sort of like the TARDIS—bigger on the inside—and JPEG compression—a bit lossy. And, like both, they are fast, accurate enough, and can take you to interesting places of adventure. That last one might not be something a JPEG does.
More technically speaking, most probabilistic data structures use hashes to give you faster and smaller data structures in exchange for precision. If you’ve got a mountain of data to process, this is super useful. In this talk, we’ll briefly go over some common probabilistic data structures; dive deep into a couple (Bloom Filter, MinHash, and Top-K); and show a running application that makes use of Top-K to analyze the most commonly used words in all 112,092 of my UFO sightings.
When we’re done, you’ll be ready to start using some of these structures in your own applications. And, if you use the UFO data, maybe you’ll discover that the truth really is out there.
Are you tired of TDD workshops that make you do boring things like calculating bowling scores and prime factors or demonstrate how to win the game of life? If so, this is the session for you! In this TDD workshop, we will be building the domain model for EverCraft -- a new MMORPG from Blizzards of the Coast. We have lots of story cards prepared to cover features from combat to magic, classes to spells, and races to items. Plus, we'll be defining some of these cards during the session in case you want that +9 knife of ogre slaying or enjoy casting magic missile at the darkness.
This workshop is language agnostic and for all levels of developers. The focus is on TDD and emergent design but pair programming will be covered as well. The only requirement is that you bring a laptop and that you be able to test-drive your code with your language of choice. When you are done you will emerge a better programmer for the experience but there is a small chance you will have a craving for Cheetos and Mountain Dew.
Are you an adventurer? Do you want gold? Experience? Levels? Of course you do! And where do you get these things? The dungeon, where else? That wonderful container of all things adventurous! But, unfortunately, dungeons aren't setup for the convenience of adventurers who wish to extract these fine things. It’s almost as if the dungeon master just made the dungeon up at random. And so you wander about and you get what you get.
But you’re also a developer. You could build a database of all the rooms with their shiny and monstrous content. Then you could query it and find the optimal route to get the gold and the experience and the levels. But how would you model this data and write these queries? The rooms. The corridors. The monsters. The sparkling hoozits. That’s a lot of entities to relate to each other. And that’s gonna be a monster of a SQL query. Whoa–look at that JOIN! Better get my text editor ready.
Or, you could use a graph database. A graph database allows you to model these relationships simply and intuitively with nodes and edges. Being schema-free, you can evolve your graph as you encounter new things such as traps or secret doors. And, using the Cypher query language, you can write elegant and easy to understand queries that find the best routes to get the stuff adventures desire most.
In this talk, I’ll use the aforementioned example to introduce you to the concepts of graph databases. I’ll compare how to solve this problem with a relational database and how a graph database makes it easier. I’ll show you how to query and modify your graph. And, as no talk would be complete without a live demo, I’ll do it all using a real-time procedurally generated random dungeon (I am a dungeon master after all).
So come, have a flagon of mead as you learn about graph databases, optimize your dungeon crawl, and equip another weapon in your quest for better software!
In this talk, I’m going to explain what WebAssembly is, how it fits into your application, and how to build and use your own WebAssembly modules. And, I’ll demo how to build and use those modules with Rust, and WebAssembly itself. That’s right, I’ll be live coding in an assembly language.
Odds are, you’ve heard of Redis. Maybe you’re a total noob and want to learn all about it. Maybe you’ve used it to cache an API call or some JSON strings and want to know what else it can do. Maybe you *haven’t* heard of Redis and are curious what all the fuss is about.
When we’re done, you’ll know what Redis is and what all the fuss was about. But, more importantly, you’ll know how to put memory first to build fast applications and faster experiences.
Developer Advocate at Redis
Columbus, Ohio, United States