EW S4E11 Transcript EPISODE S4E10 - Johanna Larsson [INTRODUCTION] [0:00:05.0] JE: Welcome to Elixir Wizards, a podcast brought to you by SmartLogic. A custom web and mobile development shop based in Baltimore. My name is Justus Eapen and I’ll be your host today. I’m joined by my co-host, the excellent Eric Oestrich. [INTERVIEW] [0:00:21.4] JE: Hey, Eric. [0:00:23.1] EO: Hello. [0:00:24.1] JE: And, as you may or may not know, this season’s theme is systems and application architecture, we’re very blessed to be joined today by special guest Johanna Larsson. [0:00:35.5] JL: Hi. [0:00:37.0] JE: Johanna, we’re so glad to have you on the show, you’re a well-known contributor in the community, see you at all the conferences and we’re so glad that we were finally able to get you on the show. You’re calling us from London right now, it’s a little bit late over there. I’m curious, what’s it like in London these days because the world is such a strange place. [0:00:56.4] JL: Right, yeah, absolutely. It’s getting a lot better in the sense that things are opening up. I moved to London in March, just before lockdown, which was not great timing — people really panicking. I mean, all the grocery stores were empty, could not find toilet paper. I mean, I remember standing in the lobby of — like the reception area or the ground floor of the building I live in and one of my neighbors came in with a bag of toilet paper and was like, “The Sainsbury’s down the street has toilet paper!” And I run over to get some before they run out. I literally got the last package. [0:01:34.5] JE: Wow. What took you there and where were you moving there from? [0:01:40.2] JL: I’m Swedish, lived in Sweden all my life, I’ve been working with – I’ve had a lot of interesting jobs but basically, after getting involved in the Elixir community, it’s just an amazing community. It’s so warm and welcoming and I just knew that I wanted an Elixir job so when I was looking for a new job, I felt like I had to look outside of Sweden, not a lot of options, staying in Malmö in southern Sweden. That’s why I ended up in London. [0:02:11.4] JE: Does Sweden only have Erlang jobs then? [0:02:16.5] JL: I mean, there are jobs here, definitely jobs especially in Stockholm but I felt like, if I’m moving to Stockholm, I might as well look somewhere else as well. [0:02:24.2] JE: All right, how did you get into programming in the first place? [0:02:28.3] JL: How did I get into programming? I remember in high school, I had friends who got into programming. They took classes, they got so excited about it and they were telling me, they were trying to get me excited and I was like, “No way, that is not for me, I’m never ever going to do that, it’s boring.” I stuck to that opinion for apparently a long time. I don’t remember exactly what brought me into it but back then, pretty much everyone had to learn html. of some sort because that’s like social media sites back then, you design your own profile page and you use html. tags and stuff to do that. That turned into sort of okay. “Well, if I can do that, I can make a webpage but now that I have a web page, what do I do with it? Well, I have to host it somewhere.” So I learned how to setup web servers, I learned how to set up a Linux server and then I was like, “Wow, you could put some like, interactive content in here.” Okay, so you have to learn JavaScript, then I learned JavSscript and it just kept building on it that way so learn PHP, databases, et cetera and I realized that actually, this is pretty amazing. [0:03:42.1] JE: This is interesting, I don’t think I’ve ever heard of anyone being, maybe this isn’t the right term, but like peer pressured into programming before. [0:03:49.0] JL: They definitely tried. [0:03:50.6] JE: That’s really cool. When you were getting started, how did you learn? What resources were very valuable to you? Anything that you could recommend or would withstand the test of time? [0:04:01.7] JL: I guess back then, you didn’t really have access to a lot of video content, it was mostly books. I had, you know, those basic beginner Lamp Stock kinds of books, that’s how I got into programming in general. I honestly — I’m not a huge fan of video content. It’s for me, I want to be able to like jump back and forth and it’s really awkward with a video and that the pace of it is too slow so I definitely prefer books. [0:04:31.3] JE: I forget who said it but they said, the fastest way to learn is to read, the next fastest way is to listen, and the slowest way is to watch. And I always thought that was interesting. Can you talk about maybe after that initial learning period, what was your first programming job and how you got it? [0:04:47.8] JL: Right, yeah. When I realized that I was into programming, I decided to do, like, a bachelor’s program to get a degree. I didn’t do it in computer science, I did it in a sort of information systems design program. It covered pretty much everything. We did process change, organizational structure, group psychology, everything. We had a little bit of programming in there. I guess I mostly learned on my own and then I was lucky enough to sort of befriend one of my teachers who was involved in a local company. So after I finished my degree, I went there to work. It was a nice place to work, really friendly people, but the work itself was awful. I became a SharePoint expert and I don’t know if you’ve ever used SharePoint but it is not the nicest piece of software to use and it’s much worse to program. It is this Frankenstein’s monster of, just, generations of code, built on top of code, built on top of code. You turn into this sort of programming archeologist where you sort of dig through the layers and you can find —you can find like, “Oh wait, here the CSS rules follow a completely different naming scheme, you can totally tell that this is like 10 years old.” [0:06:14.0] JE: Wow, that sounds awful. Okay, you just moved to London to start at a new company. What company is that and what do you do there? [0:06:26.3] JL: I work for a company called Duffle, It’s about two years old but it’s still, I’d say, fairly early stage startup, they stuck to being a fairly small team for a long time and worked in stealth. Only recently became publicly known. The idea, the concept, like, is like Stripe is for credit cards, Duffle is for booking flights. It’s generally not really — it’s not aimed at end users like — it’s not aimed that normal people, consumers, it’s aimed at companies who want to build integrations with airlines and offer bookings. So travel agencies or if you want to set up a site that sells custom vacation trips, et cetera, this is the way to go. And the reason for it is that if you look at, what does it actually take to integrate with airlines and make and book flights, it’s incredibly complicated. It is just a swamp and our goal is to build something on top of that, build something out of all these unreliable components and turn it into something that’s actually really nice to work with. [0:07:37.0] JE: Oh my gosh, this is one of the coolest ideas I’ve heard of in such a long time. I would be so pumped to work there if I were you. Congratulations, that’s so cool. I’m looking at their site. It’s just sweet. [0:07:48.8] JL: Yeah, it’s a really pretty landing page. [0:07:51.4] JE: I’m not going to just start talking about API documentation right now because that would not — maybe it would make for a good episode actually, I don’t know. Because you’re a big contributor in the community, we see you at all the conferences, can you talk about some of the work that you’ve done in the community, open-source, maybe or just any other projects that you’d like to share with the audience? [0:08:10.7] JL: Sure, absolutely. I guess the big one that I would talk about is Hex Diff which has been a real honor and pleasure to be involved in, working on that product. It’s not a product but a site. For everyone who doesn’t know what hex diff is, I’ll give you a short introduction. Basically, when you work with dependencies, you’re using software dependencies. You very often just bring them in and it’s very easy to do so, you have access to all these amazing — you have this huge repository of code that someone else wrote for you and that’s what we do nowadays. We just reuse all these amazing code that people built and really stand on the shoulders of giants. But while we — when we work with our own code, we often have systems in place to maintain the quality of that code and to ensure that we’re not making mistakes. We do pull requests, we do a code review, we really put a lot of effort into our own code but then when we bring in dependencies, we just put them in the list and they get loaded. And they run in production just like everything else. We don’t really spend a lot of time looking at it and even if we wanted to, the main place we would look would be GitHub. The problem with looking at GitHub is that is that the code you’re running doesn’t actually come from GitHub. In the case of Elixir, you bring it in from Hex and the code that is on Hex might not necessarily be the same code that’s on GitHub. Now I’m putting on my tin foil hat and I used to work for a cyber security company so I really, like, spent a lot of time thinking about this kind of stuff. But basically, with Hex Diff, what you get is a site built and maintained by the Hex team that gets the code directly from the Hex registry, the same code that it gets deployed with your production servers and it pulls it down. It lets you diff, different versions of a package that you're using so you can see the changes that were introduced between two packages. So when you’re bumping your dependencies, you can check exactly what you’re putting into production, what you’re using. Part of it is it’s a really nice UI. It’s really pretty, really proud of the work that we put into it and it’s — I feel fairly easy to use. If you haven’t tried it out, you should definitely check it out. It’s diff.hex.pm. [0:10:34.9] JE: Can you tell us a little bit more about your experience working on the diff tool? How did you get started, how’d you get pulled into the project, what was the initial problem that you were trying to solve? And how did you think — about going about solving it? [0:10:48.7] JL: Yeah, absolutely. The last company I worked for, we put a lot of effort into keeping track of and maintaining our dependencies. So my coworkers, this was mostly a Ruby-shop. My co-workers built this site for doing these kinds of diffs for Ruby packages, you should check that out as well, it’s codeitsu.io — diff.coditsu.io. It’s Maciej Mensfeld and Tomek PR. They built this really cool tool for diffing ruby packages and I realized that because we had a little bit of Elixir code in production as well that we should totally do this for Elixir as well. Luckily, around that time, Wojtek Mach from the Hex team had introduced, I believe it was Wojtek who introduced it, a command for mix. It’s mixhex.packagediff I believe. That lets you diff different versions of a package in Elixir, Erlang package in the command line. You get this nice output that you can look at. And I thought well, “If he’s really done all of the work, all I need to do is put this on a webpage and make it pretty.” So I made the quickest hackiest version. After talking to Wojtek at a conference actually, I just made a really quick hacky version. I got a chance to use Live View which is a lot of fun. I put that out as just sort of an example of what this could be like and I didn’t really expect anyone to care. This was mostly something that I built for myself to use but it turned out that a lot of people who got really excited about it so I ended up talking to the Hex team and they thought it was a great idea so we built it. [0:12:31.5] JE: Does it currently still more or less work the same way as your initial, kind of like, hacky version work or have you changed? Has it been totally rewritten or? Tell me about the evolution of it? [0:12:44.1] JL: Yeah, absolutely. It’s a lot more reliable now. The first version I did was, like I said, it shelled out to mix on the command line basically and I didn’t want to bring in the database or anything. That’s too much effort so I used ETS tables to cash the diffs which — sounds like it would be really scary because the disk that you generate can be really large but somehow, it just works. That was really impressive, the only code part really in the first version was the Live View UI that lets you select the different versions. The proper version, the official version, uses, GCP storage for the diffs. Which makes it a lot more reliable. It also, thanks to Eric Meadows-Jönsson — also, I should mention everyone also. There’s also Todd Resudek, all great, really, just amazing people — really fun to work with. They’ve been so helpful to this project. It was saying yeah, Eric added streaming functionality to this, so the whole thing is completely streaming and can basically handle just ginormous diffs. Which, in some cases, like some packages, I’m not really sure what they did but the diffs that are coded, just hundreds of megabytes. Essentially, it just works. So we have the GCP storage for diffs. Still have the Live View front-end, the ETS table is kind of there still so one really cool, thing that I relied on was the Hex team built a library for interacting with the Hex registry called Hex Core. it’s an Erlang project but it’s really easy to use from Elixir as well. That has — it basically just knows how to talk to the registry in API and we just called these premade functions really convenient. That gives you access to things like okay, I want all of the package names of all packages, Elixir packages, I want all versions and then all I did was make it searchable. [0:14:44.8] EO: That’s awesome. Yeah, I just loaded phoenixone.18 to 153 and that was pretty big and it’s slowly crept its way in so that’s pretty cool. [0:14:56.0] JL: Yeah, part of the effort is in the browser. The first version I made did all of the HTML rendering in the browser using a JavaScript library. With large diffs it would hang your browser for given number of seconds which could be a little bit scary, the new version renders everything on the server side so all the effort is done by the servers, the diffs are saved like I mentioned before and then you get the HTML sent to your browsers, it’s a lot nicer to your browser. [0:15:24.4] EO: Are the diffs generated on the — if no one had ever requested 1.18 Phoenix 1.53, is it generated kind of on the fly, save to GCP and then like the next time I hit this, it just loads it from that cache or is it precached, I guess? [0:15:41.9] JL: It is not precached, they are generated on the fly. There are some sort of caveats. One thing we realized fairly early on was that even though — whenever you use a cache, the trick is thinking that the right thinking key, like the right cache key to use. And if you’re not using it right cache key, you’re not going to get the results you want. The cache key includes the package name of the versions, obviously. We also have a way of clearing the cache or making it invalid because since we do the rendering, since we cache the rendered content, if we change the rendering itself, we also need to invalidate the cache. But the thing that’s missing is that, let’s think about another list, put our tin foil hats back on and do another one of these scenarios. Let’s say that you’re uploading a package and it contains malicious code and you want to hide it from people. What you do is you upload a nice version of the package; you then go to diff and you generate the diff. It gets cached, it’s stored now, and then you go back to Hex PM and you reupload your package. And this is something you can do if it’s the completely — like, they might have changed the rules but the way I remember it is if it’s a completely new package, you have 24 hours to reupload it. If, in case you made mistakes, and if it’s a new version of an existing package, you have an hour, I think. At least there is some sort of grace period where you can correct any mistakes you made. An attacker would be able to use that to reupload with a malicious version but diff wouldn’t update because it’s been cached so the last component that we save is the checksum of the package itself. [0:17:22.2] EO: Yeah, I feel like that’s something I definitely wouldn’t have thought of so I’m glad there are some more people with bigger tin foil hats out there. All right, this season’s steam is architecture. One thing that we like to ask everyone is what does architecture mean to you? [0:17:42.9] JL: that is an interesting question. To me, architecture is very much, sort of, dusty, that’s the right word to use for it. It’s a word that I sort of associate with someone who doesn’t actually write code, it’s the person who is the architect of the system. Not necessarily really involved in executing it. Someone who sits at a white board and/or, with a UML diagram in front of them and the thing is, when you’re in that, really, when you’re at that level, everything just works. You just put your components together and they look really pretty and all the pieces, everything just fits together. And then reality comes in and whoever is implementing it realizes that actually, there’s so many exceptions to this and just have to keep adding special modules and do all kinds of work arounds to make the architecture work. I mean, I realize that not every architect is going to be this way. I’m exaggerating it, that is sort of my initial reaction. [0:18:41.4] JE: Can you maybe dive into how you see the difference between code architecture and code design? [0:18:48.3] JL: Absolutely. I mean, there is a very basic answer where you have, I mean, design is to sort of what do the modules do while the architecture is the overall overview of the big picture, the infrastructure of the system. I guess in many ways, the architecture is more of a strategy like a high-level sort of direction that you want the system to take and you think about your business requirements and you think about what the system actually needs to be like. Does it need to be really flexible? Does it need to be really secure? Those kinds of things. While you’re talking about the actual design as a system, you're going down to the practical level I’m talking about. Okay, these modules do these things, these modules have these concerns and this is how they interact with each other? [0:19:33.7] JE: We ask this question on every show in this season and I think this is one of my favorite answers I’ve heard so far. Design isn’t specific, that’s really good. Do you have any opinions on domain-driven design? [0:19:43.9] JL: Not really overall, one of the interesting things I think about domain-driven design is the emphasis it puts on the domain experts, which I think is such a funny thing. I feel like software engineering is the only area, software engineers are the only people that have to be told that if they’re building a system, okay, you’re in healthcare, you’re building a system for healthcare. It’s a booking system for a clinic that nurses are supposed to use and interact with and domain-driven, like, software engineers are the only people and who need to be reminded that they actually need to go talk to the nurses to see what they need from the system. We kind of go into this mode, we were like, well, I know to write the code for this, I can make assumptions of what they need and I just build this. That’s something that I think is really valuable in doing driven design, it’s the emphasis on the people actually know what the system should do. [0:20:36.8] JE: yeah, I like that a lot. I wonder if real life building architects spend a lot of time with the end users of the buildings that they’re going to make. [0:20:44.9] EO: I think part of that, one of the things again in design, I guess this is design versus architecture but one of the big things is like, when you walk up to a door, how do you immediately know how to pull or push it? That right there is like someone not actually interacting with the person to know if people will be able to use it. [0:21:04.7] JE: That’s from The Design of Everyday Things, right? [0:21:07.7] EO: I think so, yeah. [0:21:09.6] JE: We wanted to ask you a little bit more about your process and especially around what kind of pre-code planning you do, what’s your process from the beginning when you have to build something new? [0:21:24.0] JL: I would say, I guess this kind of ties into my opinions in architecture as well — my approach is probably very practical. I guess that’s one of the things that I liked so much about Elixir and Erlang is that it’s a very practical, it’s a very pragmatic language. I think Brooklyn Zelenka talked about that in one of her key notes. She said that while many languages, many programming languages are designed around this core idea — some concept that programming language theory — that someone wanted to introduce and spread and they built a language on top of it. Erlang was built to solve a problem. It wasn’t built to try out, like, what would it look like if we have a completely lazy language? For example. Instead it was, “Okay, we actually need to build these telecoms which is whatever they’re called and we need these to work all the time.” And the actual design of the language is not that important as long as it solves the problem itself. Very pragmatic, very practical language in that sense. That really resonates with me because that’s also the way that I would approach solving a problem, to answer your question. I would probably — I mean, first of all, I would spend time with the team. To make sure that we’re building the right thing that we know what we’re doing but as soon as possible I would want to start working on a prototype. My process would be more around iterating on that prototype. Start building and as soon as you start building, that’s when you realize the questions you need to ask to figure out what you actually need to get to the finished product and then working with your code base in a way where you can constantly iterate and improve based on the requirements. And realize, these requirements are going to change, they’re not going to stay where they were in the beginning. That’s something that I really learned from the last big project that I worked at my last job is — it started out as this is a cool platform we could use, we could do something cool with it and it was a really undefined, vague project. And started building it and I was writing the code and I saw these patterns. I thought “Well, great, I can do some abstractions.” I built abstractions based on the patterns that I saw and I built a product and it did what it was intended to do based on our first ideas. And I showed it to the stakeholders and they were like, “This is great. But we have some changes we want to make.” I was like “Okay, great, I wrote everything down.” I went back to the code base and I realized that I have to throw everything out because with the change requirements, the abstractions that I thought were perfect for this product didn’t work anymore. I feel like this is something that I really got out of this project, something that I learned a great experience for me was that introducing these abstractions early on, or just introducing strict abstractions in general in a world where your requirements are very likely to change, it’s often a very good idea. [0:24:40.1] JE: That’s such a good point and we have to deal with — I mean we obviously work with clients a lot at SmartLogic and so there’s always this balance between velocity, time put in into upfront planning and understanding and also I mean, you mentioned getting the prototype started, which helps you identify some of the questions you need to ask. I can completely identify with this process. What about currently, can you tell us a little bit about whatever little detail you are able to get into but what kind of architecture are you currently with? Micro-services, microliths, monoliths, like you want to talk a little bit about your current experience with architecture? [0:25:20.4] JL: Absolutely. I am talking in the context of my current employer. Since it is a system built to integrate with other systems — it is both on top of other systems, we integrate with all of these airlines. It has to account for a lot of unreliability and the architecture is designed around that. So we have clearly defined layers where one part of the code is intended to communicate with airlines. It contains airline specific code and then we have another layer that is intended to be — that is our own code base, that is our own data structures and we have a conversion layer between them. So we try to be very strict in separating these things. And one of the — I’d say, that it is not a microservice architecture but it is an umbrella app. And so, I had never used an umbrella before. The only experience I had of umbrellas was second-hand accounts from Slack and the forums and most of what you hear are complaints and problems and I very much got the impression that umbrellas are maybe not a great idea. I also got the impression that umbrellas are very often used as a tool of separation of concerns, which is not necessarily what it does, especially when you use this sort of umbrella functionality where you run commands from the root level. If I had no separation or concerns at all because all of the apps in umbrella are loaded and all of the apps can call into the other apps. All the modules are loaded and you can call any public function from any app. There is still separation, this is something where I think there are great things about umbrellas that separation concern is not necessarily something you get out of it. There are ways. And I think that, even though I came into it and I thought, “We need to get rid of the umbrella.” My first thought was , “We have to get rid of it, it is not going to work. We can just replace all of the apps with folders, have all of the code in the same places. This is how we are using it anyway.” I have actually sort of come around and we are, or, like, I really I feel like it’s worth investing in the umbrella but it takes — I think the thing that is missing for umbrellas to be more useful is probably tooling and there are some things you can do to enforce that separation of concerns a bit more in an umbrella context. One great trick is using ‘mix CMD mix test’, I think is the command. So normally in an umbrella, if you run mix tests, it loads all of the apps and the runs of tests for each app through all of the apps. The problem there is that all of the apps are loaded and each app will load all of its dependencies. So a dependency of one app is available to another app even if it doesn’t explicitly find it. If you use mix CMD mix test’, it loads each app separately into its own relying VM. So it doesn’t have access to the other apps or the other apps dependencies. And that sort of enforces the separation of the apps. You can’t accidentally call into a different app, at least not in your test and lose that separation of concern. [0:28:40.2] EO: That’s pretty neat though. Yeah, I didn’t know about this mixed CMD, we’ll have a link to the docs. [0:28:48.4] JE: I want to follow up on one part, which is you mentioned that one thing that umbrella apps are missing at this point is tooling. Could you get a little bit more idea of what kind of tooling should be developed in the future? We always try to give listeners an idea of what kind of open-source projects they can work on to contribute to the community. [0:29:07.1] JL: Yeah, absolutely. Part of the problem is that umbrellas are not necessarily intended to be a tool for separation of concerns. It is a way of easily running apps together that don’t necessarily need to run together in the real world. It’s a development tool. However, in practice it’s often used in something, where the apps are not necessarily ever going to run separately. They are always going to run together but instead it is used as sort of, “Oh, it is really nice to see that we have this one app. It covers these behaviors or dysfunctionalities in the application and we have another app — we have a clear sort of interface between them and how they communicate.” And for everyone who uses it that way, the tooling is not necessarily very helpful there. It would take — but I think improving this will, in there, would also require getting community agreement on the purpose of umbrellas. You would actually need to convince everyone that okay, but in practice this is what people use it for, so let’s invest into it. I think that a lot of what the core team is working on right now if you look at the Elixir 1.11 compiler improvements, you see a lot of things that are actually useful for umbrella projects. Such as much improved warnings when you are doing things. So if you run compile with, if you try using Elixir Master and you run compile in a sub app in an umbrella and you don’t have your dependencies properly configured, it will show warnings that you are calling it modules that are not available, which is something that earlier versions of Elixir didn’t do or mix. [0:30:48.1] EO: Cool, so I guess after the last company you were security-focused, so you ended up making diff.hex.pm. So now that you’re interacting with umbrellas a lot, are we going to see something from you come out around this tooling wise? [0:31:05.1] JL: That might be. Umbrellas are still something that I am learning. It comes up a little bit everyday, things like, okay but in what order are apps in an umbrella actually loaded? Is it based on dependencies or is it based on alphabetical order? There are so many questions that — is there still so much to learn for me on umbrellas. Another thing that I’ve been looking at a lot is because airline APIs are all soap, so it’s XML. They are not very shy. They send you huge payloads of XML to parse. One of the things that I have been looking into is XML parsing. That is a really fun area and it’s also a great excuse to write a little bit of Rust and using — I don’t know if you have ever used Rustler, which is a package for working with Rust nifs. It is amazing. It is such an impressive library. I was so surprised the first time I used it and I built my first nif. I did not expect it to just work, it literally just worked. I was shocked, I just sat there with my coworker. We’re just staring at each other, we could not believe that it just ran the first time we’ve tried. [0:32:22.8] JE: I love so much of this conversation. I want to give you some time to talk a little bit about professional growth and both for yourself and also for people that you maybe have mentored. How do you think about growing your own skill set? And how you do think about growing the skillsets of people on your team? [0:32:40.1] JL: That is something that I thought a lot about lately. It is something that I was really looking for, when, end of the year, the beginning of this — end of last year, beginning of this year, when I was looking for a new job. One of the main things I was looking for was a place to grow, something that I felt that I had been missing was having a team of people around me working on the same things and basically someone to challenge me to keep growing. I think there are a lot of — there are a lot of nice things about being sort of a big fish in a small pond or just being the only person on your team. You can make all the decisions, nobody is going to criticize you. You get everything the way you want. There is no question about formatting or style changes, like if you want semicolons you are going to get semicolons but you also lose this sort of thing where maybe you’re working really hard on something. And then you see your coworkers are just building these amazing things and it challenges you to work even harder and to grow even more. That’s been really useful or it’s been huge for me. It is a place I am working right now. Just having great coworkers. [0:33:58.9] JE: I can second that. [0:34:00.8] EO: Third. All right, so for our last question here, do you have a favorite, underrated Elixir resource? [0:34:12.7] JL: Oh wow, underrated. So I do have favorite resources. For me, early on, getting into the community the Elixir Slack was amazing. It is a great place to ask questions but it is also a great place to just — something I do is, I just check, once or twice a day, just read through some of the questions and the answers and you just pick up so much stuff. That was really useful to me but I don’t know if it counts as underrated. It is definitely — I rate it very highly. [0:34:47.4] JE: Well no that is a really good answer. We want to make sure that we give you a chance to have any final plugs or asks for the audience. Anything you want the audience to do or to know about, now is the time. The floor is yours. [0:35:05.5] JL: Sure. I mean, we have already talked about it but I will plug it again. If you haven’t checked out the diff.hex.pm, you should definitely do it. It is an open-source project. There are some pretty cool things in the codebase. You should definitely check it out. It is not huge. It is the kind of project where you can definitely just spend a little bit of time on getting into it and you can follow the code. The abstractions are not deep enough that you are going to get lost. So it is a great way to get introduced to some concepts in Elixir. It is a cool little piece of Live View code in there as well. And if you try it out and you think of some improvements that can be made to it, feel free to make an issue or even better make a PR because that is something that we’re really excited about. We’ve gotten some really great improvements from people so you should definitely check it out. [0:35:58.8] JE: All right, Johanna thank you so much for coming on the show. I am really glad we finally got someone and say good things about umbrella projects because we have been looking for that And it’s really been a pleasure. We’ll hope that you’ll come back to join us again soon. Before we close out, we’ve got to share another edition of Pattern Matching with Todd, a friend of the podcast. Todd Resudeck is asking members of the Elixir community five questions to help us all get to know each other better. Hope you enjoy it. [END OF INTERVIEW] [0:36:27.4] TR: Thank you for joining me for this episode of Pattern Matching, where I ask members of the Elixir community the same five questions in an effort to get to know them better. My guest today is best known as the co-author of the Elixir GraphQL library, Absinthe. He is taking time away from his work at GitHub to be with me. Welcome Bruce Williams. [0:36:45.9] BW: Thanks, thanks for having me. [0:36:47.9] TR: Thanks for being on, big fan of GraphQL and Absinth so thank you for all your hard work on that, Ben as well. [0:36:55.6] BW: Thank you. [0:36:56.4] TR: So let us start out with the first question, is, where were you born? [0:37:00.8] BW: Sure. So I was born on Williams Air Force Base in Arizona back in 1980. I was born on an Air Force base because both of my parents were on the Air Force at the time. [0:37:10.9] TR: That makes sense. [0:37:12.4] BW: Yeah and I ended up going into the Air Force myself years later. So there’s some foreshadowing there. [0:37:19.4] TR: Okay, wow. I didn’t realize you served. Thank you for your service. [0:37:23.3] BW: Thanks. [0:37:24.3] TR: So how long were you on the Air Force for? What rank did you attain? [0:37:28.1] BW: I was in for six years. I left in 2004 as a staff sergeant and yeah, it was a different life. [0:37:37.4] TR: So next time I see you I am going to address you as staff sergeant Williams. So you were born in Arizona and where are you these days, where do you live? [0:37:46.8] BW: These days I live in Portland, Oregon. I moved here about ten years ago with my wife and two sons and now there are three sons and we decided to stop having sons at this point. Or daughters. We are definitely finished. [0:38:01.2] TR: Excellent, yeah they each come with their own set of problems. We don’t need to go into details but anybody that has sons will know what I am talking about. So what part of Portland are you in? [0:38:12.5] BW: I am in Southeast Portland. I live probably about a 15 to 20 minute drive to downtown. If I was driving downtown instead of walking myself in my house, which is what I am doing these days. But yeah it is close enough in that I could easily jump on a bike. If anyone knows Portland, I live essentially in the Woodstock neighborhood. It’s a nice neighborhood. [0:38:35.0] TR: Cool and does GitHub have an office there that you would work out of? [0:38:39.5] BW: So GitHub does have, like, a co-working space up in North Portland. I have never been there. I worked for GitHub a year and a half but I haven’t been there but there are people that make use of that. GitHub is a largely remote company. Right now it is a 100% remote company. They do a pretty good job of supporting people in their home offices and that is how I prefer to work. It’s how I worked probably in the last 10 years. I could go up there though and visit and I plan to go back once people are starting to use that office again. [0:39:05.4] TR: Oh okay and just for my own edification, when you say North Portland that is on the east side of the river up by the airport? [0:39:14.5] BW: It is on the east side of the river. Well, northeast is by the airport. Portland has essentially five quadrants, which of course makes no sense. North Portland is like this sliver between the Willamette River and directionally north is the triangular portion up there. [0:39:31.5] TR: Okay, today I learned. [0:39:34.0] BW: Yes, it is a weird thing and I guess we’re going to be adding another quadrant. So we are not going to be changing the word quadrant. We are just going to be adding the sections too. [0:39:42.0] TR: A sixth quadrant. That makes total sense. [0:39:44.0] BW: I think they are going to do a South Portland or something over that. [0:39:47.1] TR: Why wouldn’t you? All right so we kind of touched on question two already but we can get into a little bit more detail. So have you had any careers before programming? [0:39:58.5] BW: Yeah, so when I was in the Air Force, I was an Arabic cryptologic linguist. I left, as soon as I got out of high school a week later. I joined the Air Force partly because I really don’t know what I wanted to do in college. I know I wanted to do something academic. There was an academic discipline in the Air Force, well, all of our armed services, which is linguist and I qualified for that via testing and I just went off to Monterey, California and picked that up and did that for the next six years. It was an interesting time to do it. I did it in 1998 and I stayed in until 2004. So as you can imagine it was a busy time for someone then. I learned how to translate Arabic a bit. [0:40:41.2] TR: Okay, so yeah Arabic cryptologist linguist makes me think that you A, had to learn the Arabic language or at least the spoken language. And then there is some cryptology after? [0:40:55.3] BW: There is some cryptology aspect to it, yes. [0:40:57.5] TR: So you not only have to translate from this cryptological coding but you have to translate that into a foreign language. [0:41:06.2] BW: Right, people use codes. So yeah, militaries use codes so it’s a multi-disciplinary thing where you are doing both the language. And it involves using equipment and it uses different techniques but yeah, it is an interesting very strange kind of job to have, especially when you’re 19 years old. [0:41:30.2] TR: Indeed and so did you learn software development while you are in the Air Force as well? [0:41:36.2] BW: So I had started picking up software development when I was probably, like, 13, 14 years old messing around. I was very lucky I grew up with computers pretty early for someone that was born in 1980. I mean, I had a computer since I was pretty young. The old black and green monograms and doing batch files scripting and, I got into VB as soon as VB was a thing. But it kind of fell by the wayside when I was in high school and when I was in the Air Force and during the war there was a lot of data flying around and it was hard to get a handle on all of it. And so I started to do data mining, which is why I am pretty good at regular expressions because I had to use them a lot. I did a lot of Pearl and Python in those days, Ruby in 2001 and when I got out of the Air Force in 2004 that was — really in 2001 I decided that is what I wanted to do. That was the thing that was interesting to me the most and so when I got out in 2004, I jumped right into it. [0:42:40.4] TR: Wow, okay. So what was your first computer? I know I programmed basic on a Commodore VIC20 was where I got started. [0:42:48.7] BW: The first thing that I can remember was I think a Packard Bell. I think that is the first one I can remember but I think we had something before. I didn’t really care what it was. I didn’t really think about it at the time. You know it was just something to play text-based games and in retrospect they were terrible but at the time, they were just the best thing in the world. [0:43:08.3] TR: Yeah, I mean if you don’t know any better. [0:43:11.1] BW: Yeah well and things change. Like I am sure in 10 years we’ll be like, “What the heck was that?” so, you know, it will always happen. [0:43:19.1] TR: Definitely and then there are games like the Untitled Goose Game that roll back the clock and they are still great. [0:43:25.1] BW: Yes and Stardew Valley, same thing you know? I actually love it because that means that we can take these old games like old CR games like King’s Quest and things like Myst and those kind of get revamped and pushed out and my kids like them. So I think it is pretty cool. [0:43:41.6] TR: Very cool. All right, well moving on, what is the genre of the last song or the last album you listened to? [0:43:48.9] BW: The last song that I listened to that I can remember was El Búho by Blanco White, which is — he’s a British born guitarist, he learned flamenco. He’s inspired by Spanish and Bolivian music. I like singer songwriters a lot. I like flamenco music a lot and I tried to learn how to play guitar. I can never grow out my fingernails long enough to play flamenco music nor do I have the time and the focus to do that but yeah, I listen to a lot of music though. I have a pretty wide taste in music but that is the last one that I remember listening to. [0:44:23.3] TR: Okay, cool. I was not familiar with that artist at all. So maybe some of our listeners are. What movie will you watch anytime you come across it on TV? [0:44:33.7] BW: So the other day, my sons were watching Groundhog Day with Bill Murray and I totally, you know I have been trying to get them to get off the video games at some reasonable hour and maybe watch a movie together as a family and I was not expecting to be drawn into Groundhog Day. But I can’t help myself whenever that thing turns on. So I sat and watched the whole thing and I mean I think it is hard when you grow up in the 80s not to like Bill Murray. He is just everywhere, Ghostbusters, so I’d love him as an actor and as a comedian but also I just really like the story behind Groundhog Day. I love this slow descent into madness and I love how he turns out coming from a very, very selfish background and kind of redeeming himself. And the ability to spend was probably, I think I heard something like it was like 30 years’ worth of time, that he would have to spend to learn how to play piano and everything else, it was just an amazing story. And also Groundhog Day is February 2nd and my birthday is February 1st so I’ve also felt a particular affinity to it. [0:45:44.1] TR: A special time of the year for you. I heard a lot of people talking about this quarantine time being like Groundhog Day and I’ve definitely noticed some people descending into madness. [0:45:56.5] BW: Yes, myself included yeah. [0:45:58.3] TR: Okay, well hopefully we all come out of it being better people at the end. [0:46:01.8] BW: Yeah, I hope so. There is definitely days where you know you are sitting there, you are eating food that is probably not good for you like the fourth or fifth day in a row, maybe you are playing a little too much Animal Crossing although I kind of think of that as a mental health requirement at this point because Animal Crossing is so nice and calm and you’re like, “Should I be learning something at this point?” and people are telling you things like you know, Isaac Newton did this. Or, so-and-so did this when they were in prison. And I think that sets the standards a little too high. So I think we need to get ourselves a break but like I have a piano behind me right now, which I do not know how to play very well at all and so I should probably spend some more time doing that hopefully I will get to that through quarantine. [0:46:45.0] TR: Yeah and Isaac Newton, I mean gravity is so obvious. Give me a break. [0:46:50.4] BW: I mean an apple hit you on the head, I mean. [0:46:52.9] TR: Give me a break. Cool, well wrapping up final question, what project are you most excited about working on next? [0:47:01.3] BW: I think the right answer for many people right now is probably anything with Phoenix 1.5, anything with Live View, I’m very excited about that. I mentioned Animal Crossing earlier, I really need to build a queuing thing for Animal Crossing because the turn of exchange is just too much of a mess. A ton of GitHubers play Animal Crossing all together, which is kind of cool. So I don’t know, maybe I will do something like that, something silly. I don’t get to use Elixir day to day at GitHub yet so I do need an outlet and maybe that is something that I’ll do to play around a little bit probably. [0:47:34.6] TR: Very cool. Well thanks for joining me today Bruce. It was a pleasure having you on the show. [0:47:40.4] BW: Well thank you for having me. I appreciate it. [END OF INTERVIEW] [0:47:42.7] JE: That’s it for this episode of Elixir Wizards. Thanks again, to Johanna Larson for being a guest on the show and for being such a great contributor to this community. My co-host, Eric Oestrich, thank you for being my co-host and once again, I am Justus Eapen. Elixir Wizards is a SmartLogic Podcast here at SmartLogic, we are always to take on new projects, building web applications and Elixir, Rails and React infrastructure projects using Kubernetes and mobile apps using React Native. We’d love to hear from you, if you have a project we can help you with. Don’t forget to like and subscribe on your favorite podcast player. Share us on all of the interwebs, you can find me on Instagram, Twitter and Facebook as well as Eric, so add us on all of those. I am Justus Eapen and Eric is Eric Oestrich and all of those different platforms and join us again next week on Elixir Wizards for more on system and application architecture. [END] © 2020 Elixir Wizards