50. High Energy, Low Power: A Bluetooth Christmas Story
Hosted by Charlie Gleason, with guest Chris Castle.
Chris Castle has a two year nephew who, like most two year olds, likes pushing buttons—especially ones that turn lights on. When a Christmas tree appeared a few weeks ago, and lights were put up, he was very excited. At the same time, Chris was experimenting with Puck.js, a programmable low-power bluetooth button, and had a brainwave—he could combine his nephew's love of buttons and of lights. A true Christmas miracle.
Armed with a Puck.js button and a bluetooth-powered power outlet, Chris Castle decided to make the Christmas lights magic. He dug into the code, Puck.js documentation, and seemingly oft-ignored specifications, eventually reverse engineering the whole thing. He built a site around it, showing how it worked, while learning more about design, SVG animation, and the occasional perils of the tools we choose to use.
All so his nephew could press a button and see some magic happen.
Joined by Heroku UX / UI lead Charlie Gleason, Chris delves into the project; digging into his rationale and process, the technical challenges he faced, and how kids are really great at user testing. Most of all, together they try and find a little of joy that can only be captured by kids at Christmas.
Links from this episode
Charlie: Hello and welcome to Code[ish]. I'm Charlie Gleason. I'm a designer and developer at Heroku, and I'm here with my friend and coworker, Chris Castle. Chris, do you want to introduce yourself?
Chris: Sure. Yeah, I am Developer Advocate for Heroku, Chris Castle, and we've got a fun little episode to do today, right?
Charlie: Oh yeah, I should say, it is December 31st. It is the last day of 2019, which is wild because I don't know when that happened, but it did. It is also our, drum roll, drum roll, drum roll, 50th episode. There's a crowd in the background. Do you know what I mean? Oh my gosh. We can't believe it. I just want to say a massive, massive thank you to everyone who's taken the time, whether you started listening in the very first episode or if you're only just joining us, it really does mean the world to us and we're super excited to continue bringing more stories, more tips, more tools, more everything. Thank you very much. Chris, why are we here and what are we talking about?
Chris: We are talking about kind of a fun little project. I was chatting with Jennifer, who helps us manage all of these podcasts that we do for Code[ish], and I-
Charlie: This whole thing, I mean, this is like the cutest ... Everything about this is cute. It's all good, cute as can be.
Chris: I got this $20 Bluetooth power outlet on Amazon, which came with some app that was like made somewhere, and not much like English language directions or like instructions on how to use it. You have to download this app and it pairs with this Bluetooth outlet that can turn the power on and off. Spent some time reverse engineering it, like figured out how to snoop or sniff like Bluetooth going through the air and figure out like what commands the app was sending to the outlet to turn it on and off, and then programmed the Puck.js to do the same thing. When he pushes this button, the Puck.js really is just like this one inch circle that you just push it and it has some LED lights on it too. It has a little system on a chip built into it that is a CPU, but also is a Bluetooth chip. That was cool. I made that little thing for him. His arms flapped in the air. He loved it, but then I decided-
Charlie: I will put a link to that in the show notes as well, to Puck.js, because it is quite cool.
Chris: Yeah, Puck.js is cool.
Charlie: The flapping arms is so good.
Chris: I'll see if I can get a good like animated GIF or something of him pushing the buttons and being really excited, showing the lights going on and off, but then I wanted to like share this project with others and so I decided I needed to create a website. As I mentioned, his first name is Castle, and so I bought Castle.christmas.
Charlie: As you do, as you do.
Chris: It's a really, really great domain, and decided to build a website so that when they find this little white like plastic button a year from now, they're like, "What was this thing? I forgot how it works, what it does? How do I connect it to the tree?" On the website I'm going to put instructions of like, what is this thing, but I also decided to take it to the next level and try to do something I've never really done before, which is do some kind of pseudo design work with SVG art.
Charlie: I like that you said that in a year when they find it, because it's a low power Bluetooth, right? It will probably still be going for a year.
Chris: Right. Yeah, the Puck.js, it says on the site that it will last for a year, or they expect it to last for about a year with one coin cell battery. Yeah, because it uses Bluetooth low energy. It's cool. Yeah, there's this tons of side project work that I've taken on in the last few weeks of the year during holiday time and family time.
Charlie: It's funny, I have done a couple of Code[ish] podcasts and I think I always end up talking about, in some way, or bringing up side projects or one-off projects, or like vignettes, because I just think they are, much like a two year old flapping their arms around, just the purest expression of joy. I really like them and I think it's fairly well documented at this point, but I know that feeling of like when you get something in your head that you think, gosh, I would love to just, I don't know, take this thing that I've done or this idea that I had or this kind of idle thought, and then just keep kind of pushing that and be like, all right, cool. I made a Christmas tree do a thing. I'm using hardware, which I think is also being people that work primarily in the digital space, always wild because it's so rare that we get opportunities to see the things that we make in a physical ... I'm really terrified that if electricity stops working, a lot of what I've spent my life on will also stop working, so that's terrifying.
Chris: If there's like an EMP, like dramatic pulse like right, all of our ... everything that we've made in our life will just disappear.
Charlie: I know, right? I have no other skills, like really. Whew, I cannot change a tire, but I really like that kind of idea of then taking that physical hardware and then what you're planning to do with it, like what you're doing and have done with it and are continuing to do with it is to like bring that physical hardware back into this web interface, this web app, that you're then able to like interact with and by extension your nephew is able to then interact with and then kind of relive Christmas at anytime of the year using a thing that keeps going, which I just think is, yeah, it's very ... It's cute all the way. It's great.
Chris: Yeah. For those of you that maybe you're listening in the car and you can't pull up Castle.christmas right now, I'll describe it briefly to you. It's a very, very simple scene of a room that you see, that loads on the webpage. There's a Christmas tree there and you click the Christmas tree, and this is all SVG art, you click the Christmas tree and the lights come on virtually. There's no connection here between like the physical, the Puck.js, and the real Christmas lights and this little website, but yeah, it's like a little like relive Christmas thing. It's also like a way for me to like share with other people something I've built, but then also will serve the practical purpose of instructions for Castle's parents next year when they're like, "What is this thing? How does it work? What does it do?"
Charlie: Yeah, so like an interactive user manual.
Chris: Yeah. Yeah. I like that.
Charlie: Interactive docs.
Chris: Yeah, like an interactive, delightful, amused, like entertaining user manual.
Charlie: I love it. I mean, I think there's also ... There's something really joyful about using technology to delight in that way, especially the idea that you have put all this work into something like reverse engineering this little piece of hardware in order to get someone else excited and hopefully inspired by technology even at a really young age to see like, "Oh, my uncle did this thing and he's obviously magic because he made the Christmas tree turn on and off." I love that.
Chris: I think at this point he thinks this is what the world is like, but yeah, I hope he's like, "That's cool." Yeah, I hope it inspires. For me it's like, I don't know, like we work in technology, right? The purpose of the technology that we do in our job is to help businesses, but working in tech or like software or coding has always been a lot ... is much more than that for me. I don't have very many what I would call like artistic skills, whether it's drawing or creating music or dancing, any artistic expression. In some ways, and maybe it's strange or maybe it's not, I kind of feel like building little things like this and solving little problems and creating like little delightful experiences, for me is kind of like, is my artistic expression or some sort of emotional expression that I otherwise don't get because I have trouble making real art, I guess.
Charlie: I would call this real art. I mean, that's the thing though. I know what you mean. People need outlets for that side of themselves, whether or not it's something that they feel like is fully developed or not. I think everyone has some thing that they can create, something inside of them that can inspire them to create. I think that's a really nice thing. Do you know what I mean? Not to be too saccharine about it, but like I think that's a really great quality to explore even if it's not something that you're doing in like more of a traditional I just bought a giant canvas and I'm going to paint something way, but in taking the skills that you have and using them in a way that feels fun or enjoyable, that you get excited about, like finding the thing that you feel passionate about.
Chris: Yeah, totally. Its end purpose is not like a business purpose. It's more of a human purpose or human connection or human emotion purpose.
Charlie: Yeah, absolutely. I was going to ask a little bit about the reverse engineering part, just to be a little bit nerdier, the reverse engineering of Puck.js and what that process was like, and maybe like any of the tools that you used or how you went about doing that, because I think when things don't work I usually panic. The idea of ... I find it really fascinating that you like dug in and thought, "All right, cool, I'm going to work out how this is communicating and then I'm going to make it do the thing I want it to do."
Chris: Then I went on a bit too much probably of a tangent of like reading the Bluetooth low energy spec and figuring out like, what is the structure that these things use to communicate with each other? What are the data structures that they use or expect in each other to find in each other? Then the third thing was like, okay, I've got this, like the ... I bought four different Bluetooth power outlets, so I spent like a hundred bucks on Amazon, bought four different Bluetooth power outlets. It was actually hard to find Bluetooth only ones. A lot of them are WiFi connected these days.
Charlie: Oh, interesting. Yeah.
Chris: Yeah, so I bought four different ones thinking that like hopefully one of these I'll be able to figure out. I actually started with this one, switched to a different one and then came back to this one, realizing that this was going to be the easiest one. There's like some sort of authenticate ... This one has no security. The one I'm using has no like security or authentication or encryption in it so it's simple to reverse engineer.
Chris: One of the other ones had like more security built into it and that looked a lot more complicated to back out of. What I had to do, like I had to figure out like what Bluetooth commands the iPhone or Android app provided by the Bluetooth outlet maker, I had to figure out what commands it was sending to the plug and like how it connected to that plug. I struggled for a bit in like trying to guess, trying to Google search and figure out what was ... Was there a standard way that Bluetooth outlets communicate? It looks like there is a standard way, but I think a lot of these hardware makers and app makers just decide to make up their own protocol or schema or language to communicate back and forth between the app and the outlet.
Charlie: Sure, like that XKCD comic about standards, which I will also link to in the show notes.
Chris: Yeah, exactly.
Charlie: But the idea that everyone's like, "Ah, we don't have a standard. Let's just make one now," and then you just end up with another thing that's not a standard.
Chris: Right. Yeah, totally. What I actually ended up having to do is that from actually a previous side project, I had an Android device sitting around my house, like a cheap Android phone. Apparently there's like a developer mode on Android devices where you can tell the device to log all of the incoming and outgoing Bluetooth messages to a file, which you can then copy to your computer and open up in Wireshark. Wireshark is a pretty well known GUI for investigating and kind of debugging lower level like network communication or WiFi communication. It knows how to kind of like deconstruct the frames or the packets and kind of tell you, give you a little bit more information about what's going on in all of that communication that it's reading. I used this Android device that I had lying around from a previous like car hacking project that I had done, and turned on Bluetooth logging or Bluetooth sniffing, opened up the app for the power outlet, and then like toggled the power outlet on and off a few times.
Charlie: Oh, nice, yeah.
Chris: That took half a day to figure that out. Once I like settled on this one outlet, it was a lot easier than I thought it was going to be.
Charlie: Yeah, sure.
Charlie: That's always the way, right? Because I was thinking about that with ... I guess it's part of why I like starting things in maybe like a CLI kind of environment where it's like, cool, can I just curl this thing and if I curl this thing, will it do the thing that I want it to do? You're like, "Cool, that works. This is a great idea for something." Then you kind of go through the weird boilerplate, repetitive part of just like setting up the stuff that just surrounds that one command that you're running.
Chris: Right. Yeah, totally.
Charlie: Oh, boy.
Charlie: I feel like that is also indicative of my behavior when things don't work as [crosstalk 00:19:04]. I don't know. I am also a two year old.
Chris: What's going on? Just push the button more frequently and harder. I'm sure that'll fix it.
Charlie: It's science.
Chris: In some ways, like it makes sense, right? You turn a light switch on on the wall or you plug something in and the lights turn on right away. He had been conditioned in his two years of life to expect that, which makes sense. You push a button and the lights should go on. If it doesn't, you push it again, but yeah, it was good. I mean, it's like, with anything you build, whether it's for fun like this or for a business, like there's so much you learn from actually putting it in front of the human it is intended, for like the purpose it's intended for. The thing that you're building is so much better once you've had someone else play with it and touch it and give you feedback and you've incorporated that feedback into it.
Charlie: Yeah, absolutely.
Chris: When you're kind of stuck in your own head for too long, it's easy to miss things that other people think are like trivial or simple or the way things should work.
Charlie: Yeah, it's funny you should say that actually because there was a ... In my personal time, I really like creative coding. I'm a really big fan of creative coding. A couple of years ago I made a library called Sandpit JS, and it was essentially meant to be a sandpit for simplifying the boilerplate parts of creative coding. It had some hooks that I thought made it unique and I was really proud of it and I worked very hard on it. Then a lot of stuff got in the way, just like having a job and a life and all that kind of stuff, and it kind of stagnated for a long time. Then a couple of weeks ago I was working on something around WebGL and depth maps with a friend of mine, to talk about it at a creative coding event in London.
Charlie: We were trying to work out a way to basically draw something on a canvas and like grab it. That's all we wanted to do, grab the image shown and nothing else. Beyond that, it turns out it's really hard to find like very, very simple drawing tools that aren't in a framework already, like React or Vue, and we weren't using those things. It all felt like it was a lot of boilerplates so I was like, wow, what can I just drop in? Anyway, it turns out Sandpit actually do come in handy again, but it was so funny because I wrote the docs for that, I wrote the library, and it is very clear coming back to it a year later that that was written by a person who fundamentally understood what was going on and expected everyone else would too.
Chris: Yeah, right.
Charlie: Then trying to use it, I came totally unstuck. The docs were terrible. I was always slightly disappointed it didn't get more traction.
Chris: Yeah, no. If it's six months later, it's effectively a different person. It's like future Charlie versus past Charlie. You're in a completely different mindset or frame of mind. Yeah.
Charlie: Yeah, for sure.
Chris: But yeah, it was fun to do. I've got actually some time now over the holidays to take a break from family time and do some debugging and make the lights flash a little bit more. My approach to dealing with his multiple button mashing is, one, to make it tolerant of that so that it can handle multiple button mashes before the lights turn on or off, but also there are three LEDs. There's a red, green and blue LED on the Puck and so I'm going to make them like light up and do some fun like light dancing or something like that to hopefully distract him so that he doesn't mash it as much. Not really for a purpose, because I'm going to handle the mashing with code, but more just to like entertain or see what else I can add to it, because I have to jump back into the code anyway to deal with the handling the mashing.
Charlie: Yeah, because I suppose you could de-bounce that if you know like an average time that it would take, or actually you could say from the moment, I suppose, that the device receives a message to do something, to turn on, that it can't be turned off until ... You know what I mean, so you don't end up with conflicting messages?
Chris: Yes, because there is a de-bounce just because you need that with hardware buttons in general, because sometimes when a human clicks a button and there's like the click down and then the let go, and there's often like with just hardware and analog signals in general, sometimes things bounce around. There is like a lower level, I guess, de-bounce of like 50 milliseconds, but then I think, yeah, also we'll have just like set a lock or a variable that says, okay, it's clicked once, but the lights haven't been turned on yet. Ignore any future clicks you get until the lights are successfully turned on and then you can start listening for new clicks again.
Charlie: I like it. I like that we're live code reviewing your project. It's like rubber ducking at a grand scale.
Chris: But yeah, I was going to say, I mean, we were talking about like, as primarily a software developer, hardware has been like a whole new thing, that I've been playing with hardware maybe for 10 years or so off and on, but if you break hardware, you can't just restart it. You need to go get new hardware if you've like fried the hardware. It just opens up so many different like layers of complexity in how users interact with the hardware also, because there's not just the software, but there's this hardware piece too. It's kind of like the hardware is the UI. You could think of like the hardware is the GUI, the physical world is the GUI, and then there's the softer underneath it. Maybe it is similar to software in that way, that there's like a view layer and then a controller or a model layer or something like that.
Chris: But yeah, I had the ... My first experience with all this stuff was adding a bunch of sensors to a Kegerator as part of a work project with a ... well, a side project with coworkers. The one that we bought also had a tap built into the top of it.
Charlie: Oh, wow.
Chris: Actually it came with a tank. You have a tank that provides pressure for the beer in the keg and then you pull the tap handle and the beer comes out, but that wasn't good enough. We wanted to add technology to it. We were playing with Arduinos then. This was, yeah, about nine, eight years ago, and also purchased like a food safe flow meter for fluid that we put into the line, the beer line, so we could measure the volume of each pour of beer. Then what was the other stuff? Oh, so there was a card scanner too, RFID card scanner ...
Charlie: Oh my God.
Chris: ... so that you had to have one of the approved cards in order to dispense beer. There was a solenoid also in the line and the solenoid would open and close depending on if you had an unapproved RFID card scanned.
Charlie: Sure, understandable.
Chris: Then a thermometer and that was it. Those three sensors all attached to an Arduino.
Chris: Then it would push data. It would just make HTTP requests up to this little like Node.js API server in the cloud. We created dashboards and data about like who was drinking the most and how much beer they're pouring and like which beers people like the most or seem to drink the most.
Charlie: Oh, wow.
Chris: This was painful also in that, so when you put stuff in the line, in a beer line, that disrupts the flow of beer, such as a flow meter, like a spinning little propeller or a solenoid that opens and closes, it disrupts the flow of beer, and more often than not, makes all of your beer come out as foam instead of nice, liquid, tasty beer. We had a foam problem with the Kegerator. There were lots of other problems too, like, oh, what happens if the network connection goes down or what happens if it loses power or the RFID scanner like dies? Then people can't drink their beer. We found that people get really pissed off, even if they're like developers and they love nerding out on technology, when they want to drink a beer at the end of the day on Friday. They're like, "I don't care about your project, Chris. I just want to drink a beer."
Chris: There was lots of fury sent our way because we were standing between them and ... Well, Arduino and foam was standing between them and their beer.
Charlie: Well, no good deed goes unpunished.
Charlie: Oh, man.
Chris: But it was fun. It was a fun project. I actually presented it. I got invited to present it at CascadiaJS, the first going of CascadiaJS in 2012, and so got to share it there kind of as like a fun project at the end of CascadiaJS. Yeah, lots of people. Everyone was like, "How do I get one for myself? Can I make one?" It was cool to see all the excitement about it.
Charlie: I love it. That's great. It's funny as well because you and I know each other, I would say, quite well personally. You're great outside of just talking on podcasts and at work. I did not know about this project and I am ...
Chris: Oh, yeah.
Charlie: This is the most Chris Castle project I've ever heard of. It's incredible. I love it.
Chris: We can link to the slides from my presentation at CascadiaJS in the show notes.
Charlie: Absolutely. It'll be in the show notes. I had to look at them as well. It's like youthful Castle as well. It's incredible. It's well worth checking out.
Chris: Back in my skinny days, my fit days.
Charlie: One thing I was going to talk about as well is you kind of alluded at the very start that you were going into this as a piece of design and it wasn't necessarily something you were that comfortable with, which is always like the most unnerving part, I think, of a project like this is doing the bit that you're not comfortable with. It's like, if you're building something like this and you didn't really feel that comfortable jumping into like the guts of a Bluetooth device, that may be that bit, but for you that bit was this kind of design aspect. I'd love to hear more about like the decisions you made. I know that you built the app. We talked a little bit about it before you built it, but you were looking at a couple of different options.
Chris: Yeah. This is the website piece now, Castle.christmas. Share it with all your friends.
Charlie: Yeah, sorry, gear change. Throwing the hardware out the window. We're back where we're comfortable.
Chris: Yeah, this is the website piece. Yeah, I wanted to ... It's for two year old, right? It can't be like a normal website. It needs to be simple. Well, it had a few purposes, as I described earlier, but I wanted Castle to flap his arms.
Chris: Actually in a past work project last month, we've been working with a designer actually that is an amazing illustrator and SVG artist and CSS wizard. Hi, Lynn, if you're there. I was a little bit inspired by her in thinking about like, okay, I've got to make something visual. Lynn makes it look so easy so I'm sure I can figure it out. No offense, but I knew I'm not an illustrator. I'm not very good at drawing. I went out and scoured the internet for SVG art or even SVG animations that other people had created, other artists had created, and purchased like a whole bunch of different things. Then I sat down with a notebook and like scribbled out, kind of tried to get something from my head on paper of like what I wanted it to look like.
Chris: But then I needed something to like to build this in or some framework or tool or program or interface application to use to build this. The two that I ended up deciding between, one was GreenSock Animation something. It's GSAP. The other one is Hype. GreenSock is really just a library for web animation, whereas Hype is a program you install on your computer and you can put SVG or vector art on there and draw paths that it's going to move ... different art will move on. You can like make something shrink, effectively like change the property, the CSS properties of things. Then Hype figures out the tween, or does the tween or the animation from like the state zero to the next state.
Charlie: Yeah, it's been around for a little while as well. I mean, I think it originally started ... Well, I know it originally started as a Flash library.
Chris: Oh, really?
Charlie: Yeah, back in ...
Chris: I didn't even know that, okay.
Charlie: I think it was actually ActionScript 2. I could be wrong. Yeah, so you looked at GSAP, pretty low level.
Chris: I looked at GSAP and then I saw this like WYSIWYG, right? You could effectively say Hype is more WYSIWYG, like what you see is what you get tool. Being new to this animation stuff, I thought that was a better place to start. That's what I jumped into. Spent probably a full day, like a good eight hours, six, eight hours on getting just something super, super basic out, which Charlie has seen. You click it, the lights turn on on the Christmas tree. Then I plan to refine it and make it a little bit better so that when you look at this, listeners, it's maybe a little bit more interesting. I've got something working and something out, but yeah, it took me quite a while just to kind of understand the concepts, some of the concepts being standard web animation concepts like HTML5 and CSS3 concepts, but some also being concepts that Hype uses to allow like people to understand and use their tool well.
Chris: That worked well. There's not a lot of animation there so I wonder if like it might be overkill or hard to tune maybe, if there was tons and tons of animation going on. For my simple purposes it was great, but I do want to check out GreenSock, because coming from more of a developer background, I'm now curious to see how the same thing would be built by writing code instead of kind of point and click and setting kind of timeline key frames.
Charlie: Yeah, I'm actually ... I think that's a really interesting point in terms of the cost of learning, right? If you have a thing that you want to build, that kind of initial decision of the fork in the road of like what tools am I going to use to do this has pretty profound effects on not just what gets produced but how you go about producing it. I think that'd be a wild experiment.
Chris: Yeah. It's not like ... I mean, that's a good ... I feel like we could talk for hours just about that. Choosing the tools to use for me at this stage of like never doing anything like this, it seemed like a crap shoot. I tried to understand as much as I could the differences between them and different types of tools, but at some point I just had to decide and commit to one and start building something.
Charlie: Sure, sure.
Chris: But it just kind of speaks to the how valuable kind of wisdom and experience is. Very often I think people in our industry, or developers are like, "I can figure out anything. I can learn whatever I need to and I'll figure it out and I'll build it, whatever," but wisdom and experience with tools and having used different types of tools and having made those decisions and made the wrong decisions and suffered, end up being super valuable and helpful. Yeah, that was fun. Masquerading as a designer for a little bit, or like playing with the tools that people who work more consistently in design get to play with all the time, and kind of gain empathy maybe for what they do every day.
Charlie: Sure. Actually I've noticed that's a real movement at the moment. I really love it. Over Black Friday, yeah, I grabbed a copy of Refactoring UI by Adam Wathan and Steve ... I'm not going to be able to pronounce his last name because I've only ever read it, Steve Schoger. Anyway, I kind of peeled off at the end there so it sounds almost like I nailed it.
Charlie: I'll put it the show notes because it's a really great example of their relationship. They talk a lot about how they ... One is a developer, one is a designer, and they collaborate a lot on getting better at their mutual craft and then they've created a bunch of resources around like, okay, I'm a developer, how can I take a design and see the things in it that could be better? I think that's what I loved about when you were telling me about doing this project, being like, "Cool, well, I want to make a thing that is visually compelling and how do I go about that? Where do I get started? Where do I find assets? What do I use?" All that kind of stuff, I really liked it because I think more and more, I don't think you have to be everything all the time. I think that's an impossible goal, but I think in our industry especially-
Chris: Right, I agree.
Charlie: ... it's really positive to at least have an understanding and an empathy for what other people are doing and the tricks that they might use and, yeah, how you could maybe use them as well.
Chris: Yeah, I agree, or like the problems they may be running into. What's stressing them out, right? Something may seem trivial to you or you may not know how difficult it is for them to figure something out or how easy it is on the converse side.
Charlie: Sure, absolutely.
Chris: Yeah, it was a fun project. I'm going to keep playing with it, probably kind of gift it to him for Christmas and New Years and then put it aside and find another project.
Charlie: Absolutely. I look forward to you messaging me and telling me about it when it happens, because that is 90% of our messages are like, "I had this idea. What do you think? I'm going to do this thing."
Chris: Yeah, for sure. I love it.
Charlie: Well, if people want to check it out, Castle.christmas, and like I said throughout, we will have links to it in our show notes and links to all the things we've chatted about, but I think that's pretty much everything we have for you on our landmark, incredibly exciting ...
Chris: 50th episode.
Charlie: Yeah, right, 50th episode. Oh my gosh. I just want to say thank you again. Thank you, thank you, thank you to everyone who has listened, who has talked about it, who has been on Code[ish], who has hosted it. It's definitely, it takes a village. I know that myself and the team behind the scenes are just super thrilled to have hit 50 episodes and to have had some really incredible conversations with some really incredible people. We're going to keep doing that.
Chris: Yeah, excited.
Charlie: Awesome. All right, well, Happy New Year, Chris.
Chris: Cool. Yeah, thanks. Happy New Year to you also. Thanks for chatting with me.
Charlie: Thank you for taking the time to chat about it and for sharing your project and everything you learned from it. It's awesome.
Chris: Yeah, join us for the 51st episode coming soon in 2020.
Charlie: Yeah, get ready. In the meantime, I will be flapping my arms like a two year old.
Chris: Awesome. Thanks, Charlie.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
← Previous episode
49. Building Effective Distributed Teams
Next episode →
51. Best Practices in Error Handling
January 21st, 53. Scaling Telecommunications Data with a Service Mesh
User Interface / User Experience Lead, Heroku
Charlie is a designer, developer, musician, and creative coding enthusiast. He can usually be found somewhere in London, probably on a bike.
More episodes from Code[ish]
Adam McCrea and Corey Martin
Heroku applications big and small run on dynos, virtualized Linux containers fine-tuned to execute your code. As the load on a server increases, you must add dynos to keep up with demand—but how do you know how many more to add? And how can... →
Ruben Bridgewater and Julián Duque
Errors are a fundamental part of the programming experience. Learning how to receive and react to them, as well as responding to the user who may have encountered one, is essential to building a great application experience. Ruben... →
Juan Pablo Buriticá and Anthony Mazzarella
Running a start-up is hard. Running a start-up with teammates spread across the world is even harder. Juan Pablo Buriticá is the VP of engineering at Splice. He believes there's a fallacy that remote teams ought to be treated differently... →