The Frontside Podcast

Julie Moronuki: @argumatronic | argumatronic.com Show Notes: 00:57 - Julie’s Unique Origin Story Into Programming 03:47 - Good Resources vs Bad Resources for Learning Haskell 11:18 - Areas to Look at Before Taking on Haskell and Functional Programming 15:56 - Terminology 17:50 - The Haskell Pyramid 25:51 - Learning Haskell Vocabulary 28:20 - Monoid and Functor 42:06 - Advice for Someone Who May Not Be Interested in Programming Resources: Haskell Programming From First Principles (Haskell Book) Natural Language Processing (NLP) Learn You a Haskell for Great Good! Programming in Haskell by Graham Hutton Haskell: The Craft of Functional Programming by Simon Thompson Real World Haskell by Bryan O'Sullivan, John Goerzen, and Don Stewart Introduction to Functional Programming Course with Eric Meijer The Joy of Haskell Haskell eXchange 2017 - A Monoid For All Seasons Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 83. My name is Charles Lowell, a developer here at the Frontside and your podcast host-in-training. With me today on the podcast is Elrick also. Hello Elrick. ELRICK: Hello. How you doing? CHARLES: I'm doing well. I'm glad to have you on this one. I'm glad to be doing this podcast in general. We have someone on the podcast today who I've been following for, I guess probably about two years because she published a book that has been very, very helpful to me. It's one that I recommend to a lot of people. It is learning Haskell from first principles. With us on the show is Julie Moronuki, who is co-author of that book. Thank you so much, Julie for coming. JULIE: Yes, hi! Happy to be here. It's nice to finally get to talk to you. CHARLES: Yeah. One of the reasons I wanted to have you on the podcast was because I feel as though you have one of the most unique origin stories because of programming and entering in the tech world. Most of us are curious, we either come from video games or maybe we just start fiddling with the web browser. You enter the maze from the entrance that is like hidden from all, I would say. You went straight to writing a book on Haskell, is that --? JULIE: That is what happened. In 2014 on Twitter, I met my co-author, Chris Allen and he has been trying to figure out better ways to teach people Haskell because the on-ramping, I guess of people to Haskell can be quite difficult. The materials that exist are not always accessible and people felt like they need the advanced math degrees before they can write Haskell. He was trying to figure out better ways to introduce people to it. Since I was this person who's never programmed before -- I have no background -- and then he thought, "This will be a very different experience, trying to teach Haskell to her." Because I have a linguistics background and stuff he thought, "That would be interesting too and maybe, she'd be interested eventually in doing NLP." I said, I'm not -- CHARLES: What's that? Acronym alert. JULIE: Oh, yeah. Sorry. Natural Language Processing. I said, "You know, I've never done any programming and I don't play video games and I never have had any desire to learn computer programming. I don't think I'm going to like this. I don't think this is going to last but sure, I will try," and so I did a little bit. I read a little bit of 'Learn You a Haskell for Great Good.' I've read some other things. CHARLES: This was before you guys had the idea of actually writing a book. JULIE: Yes. He had the idea of turning some of his thoughts about teaching Haskell into a book and as he would explain things to me, like the questions I had about 'Learn You a Haskell,' I'd be like, "We should write this down," and he would say, "It's so hard to write it though. It's easy when I'm explaining it to you and it's so hard to write it." Initially, it started that I was helping him at things that he was teaching me and then as we got further into the book and I started reading a lot of other Haskell stuff on my own and figuring stuff out, I was writing more and more of it. Then we were kind of equal co-authors after not too long. That's how it happened. I really didn't think that I would stick with Haskell or with programming. I'm still sometimes I'm not sure about programming. I'm not sure about this whole making software thing. But Haskell is so interesting to me that I'm still here. CHARLES: That is fantastic and it's a great story. I'm curious, when you were doing the proto-research to learning Haskell, coming from really truly first principles and having no experience of programming, what made a good resource versus a bad resource? What are the things that you gravitated towards and say, "This is really instructive." What was the tone there? JULIE: One of the major problems ahead of most of the Haskell resources that exist is they assume that you've done programming before because nobody learns Haskell as a first language so they all assume that you

Chris Chuter: @Chris_Chuter Show Notes: 00:47 - Peeple: What is it? Why? 02:59 - Iterations and User Testing 13:32 - Complexity of Installation 17:26 - Device Integration 22:15 - Setup and Installation 25:35 - Laws and Building Codes 26:39 - Getting Started in this Space 31:29 - Ensuring Quality, Integration Testing, and Deployment Pipelines 33:18 - The Manufacturing Process Resources: If This Then That (IFTTT) Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 82. My name is Charles Lowell, a developer here at the Frontside and your podcast host-in-training. With me is Elrick Ryan. Hello Elrick. ELRICK: Hey, hello. CHARLES: And today, we are going to be continuing our series on the Internet of Things and we have someone on the podcast today who's going to talk to us about the Internet of Things. His name is Chris Chuter and he is the CEO, inventor and founder of Peeple. Hey, Chris. CHRIS: Hey. How is it going? CHARLES: It's gone well. Thanks for coming on the program. Peeple, what is it? Why don't you give us a quick overview of the product? Obviously it pertains to IoT, what is it and how did you become involved with it? Let’s delve into that. CHRIS: Yes, sure. Let me give you the elevator short version first then we can dive deeper. Peeple is caller ID for your front door. The idea is when you get a phone call and you don't answer the phone, what happens? It goes to your voicemail. You know someone called you. But today, if someone comes to your house, you have no idea that they came unless you're there. This is the central problem that we solved with Peeple. It’s a little device, a hardware device, an Internet of Things device that fits over the peephole in your door in the inside of your house. When someone knocks or doors open, you get a push notification on your phone. You can open up the phone and you can see a live view of your peephole. In a nutshell, Peeple is a smart peephole. CHARLES: Is it more for the case when you're not home at all or do you find the people use it for what you would traditionally use a peephole. CHRIS: It depends on the person. Now, my personal use case is for keeping track of wandering kids and that's actually inspiration for this invention. I have two boys and when one of my boys was three years old, he managed to open the door, walk out, go on to the street and walk down to the end of the street. Now, I live in Austin and I live right off the edge of a very busy street. Now, my kid didn't die or anything like that. It's not a really sad story but a neighbor brought my kid home and it was one of those moments as a parent where you're like, "Oh my God. I'm a terrible parent." But being an inventor and an engineer, I was like, "I'm going to hook something up that just tells me when my door is opened or closed," and it morphed into this invention. We showed it to people at South by Southwest almost three or four years ago. That's when we realized we were on to something that didn't exist. It was just a little camera on the door. CHARLES: Tell me about those first versions. I'm so curious. It sounds like there's a lot of layers of functionality that you've been through, a lot of iterations so I'm curious about that. What's was that zero iteration look like? CHRIS: Version 0 was made in 24 hours. It was a hackathon for... I can't remember the name of it. There was a hackathon group that recently imploded and we won this hackathon. The hackathon thing was to make something... I'm not sure if this is for Internet of Things but we were all making that kind of stuff. I made this little Raspberry Pi demo with a little mini door and I had talked to my wife and this is how I was able to make this invention, to keep track the kid as I was busy doing other stuff but I talked her into giving me 24 hours to make this one thing. Then me and another guy, David we won this hackathon. We were like, "We've got to turn this into a real thing," because one of the awards of the hackathon was you go to Silicon Valley, you show this off and you do all this cool stuff with it. We were like, "We've got to actually turn this into something that's presentable." That was Version 0. It was just a little Raspberry Pi. CHARLES: Now, what were you doing to detect the state of the door? CHRIS: That's the crazy thing. The first version of the device had more sensors on it than the final version. The first version had everything. It had a doorbell, it had a knock sensor, it had a motion, it had a speaker that played Paul McCartney's 'Someone's Knockin' At The Door,' but it had an accelerometer. I threw everything in there the first thing and half of it worked for the hackathon demo but it was good enough to win. This is something that, I guess I could call wisdom now but the real thing I learned is you start with everything and then you narrow and get it more tuned and highly focused and more precise as a device, like the difference betw

John Boyd: LinkedIn Show Notes: 01:27 - Knocki 03:20 - The Device 06:19 - Complexity 08:44 - Software Distribution 14:01 - Allocating Memory 18:27 - Finding Hardware Hacking Libraries 22:01 - Updating and Diffing 24:06 - Migrations 26:51 - Decentralization of IoT 35:39 - Managing the Knocki Ecosystem 40:17 - Communication Standardization Resources: Malloc Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #81. My name is Charles Lowell. I'm a developer and your podcast host-in-training here at the Frontside. With me today is Elrick Ryan. Hello, Elrick. ELRICK: Hey, how are you doing Charles. Welcome back. CHARLES: Yeah, thank you. It's good to be back. Today we're going to be continuing the ongoing series that we've been doing intermittently on the Internet of Things. It's a really fascinating, almost to a person fascinated with here at the Frontside. Today, we have with us to talk about this, someone who's very, very knowledgeable on the subject, John Boyd, who I got an opportunity to talk with, I guess it was about a month ago and I wish that we had the podcast recording equipment there in the room because it was just a very, very well-versed engineer, exactly the person you want to be the CTO of your company, which is very lucky for Knocki, the company that he works for, because he is in fact the CTO there. Welcome to the show, John. Thanks for coming. JOHN: Yeah, thank you very much, Charles and I'm excited to be here. I'm excited to join the conversation this week. CHARLES: Yeah, why don't you start by what it is that you do at Knocki? Most of our audience comes from software and design and product management backgrounds. You've got a very strong hardware background. How does that play in to what you do at Knock? JOHN: Yes, certainly. As you previously mentioned, I'm CTO at a startup called Knocki, which you can mount onto any surface and turn that surface into a user interface. We're recently funded on Kickstarter so we're in the process of actually trying to develop this hardware but the central concept is any surface that you mount this on will now listen for touches and vibrations so you can say, mount it on a desk and tap three times on your desk and control your smart home around you. If you have smart speakers or TV, you can tap three times out of four times and control those devices with a really natural interioractive interface made out of anything in your home already. CHARLES: Tabletops, mirrors, I assume you've tested this on a lot of different services. JOHN: Yes, I’m sure we'll talk about that more a little bit later but the goal is to be able to turn any surface into user interface. That means if you really wild and you want to use it on the window, I recommend it. But we're thinking desks, walls, doors. It has a lot of applications for disabled and handicapped individuals. Think of a child or someone in a wheelchair that can't quite reach a light switch, if they have a Knocki mounted on the wall, they can still knock on the wall to control the lights. We feel like it adds a new level of user interface to people's lives that can be helpful. CHARLES: Definitely. Seeing the product and hearing you talk about it, I definitely got that impression. Now, the device that you actually brought into the office because you did come in and talk to us, like I said it was about a month ago but it was extremely tiny. In our explorations into the Internet of Things, we do things like control our lights from within the office. At least, we're trying to control our lights within the office. For us, we're using the standard kit. We’ve got Raspberry Pis that we're using, that are have access to a plug and they've got a full Linux install, just a really powerful processor and by comparison to the things that you were talking about, that's energy hog by comparison. We think of it as being very lightweight but if you're talking about making some small device, it's actually really, really wasteful of resources, so to speak. What is that transition that spectrum which you moved from these one-off hobbyist things where you're using high-powered equipment to these really custom devices? How do you make that transition? And what is the difference between the two? JOHN: Our devices are about the size of a hockey puck, which is much smaller if you can think of a Raspberry Pi. Pretty difficult to fit that inside of a hockey puck, especially when you want to start adding some sensors to detect knocks and taps on a surface. I don't hate or dislike the Raspberry Pi or BeagleBone Black or any of those really quick SBCs that can get you started with IoT. But they have -- CHARLES: Acronym alert. What is an SBC? JOHN: SBC, single board computer. It's any of those credit cards size computers. CHARLES: Okay, great. So nothing against the SBCs like BeagleBone Black or Raspberry Pi. JOHN: Exactly. It's a great way to prototype ideas and get in a proof of concept out there and there are some cases

Alison Davis: LinkedIn Ronald McCollam: @ronaldmccollam | ronaldmccollam.com Show Notes: 01:19 - The Future of IoT 04:57 - Where does Resin.io fit in? 07:04 - Founding Resin and The Unicorn 11:26 - How Resin Works 15:16 - Diffing 17:58 - Tooling and Workflow 23:02 - Resin is Open Sourced! 24:05 - Case Studies 30:04 - Security 34:47 - Scaling Up and Improving User Experience Resources: OpenROV Underwater Drones Etcher resinOS Transcript: ELRICK: Hello and welcome to The Frontside Podcast, Episode 80. We have a wonderful podcast today. My name is Elrick Ryan, a developer here at the Frontside and I'm going to be hosting the podcast today, in place of Charles because he's on the frozen tundra. I also have co-hosting with me today as well, another developer from the Frontside, Joe LaSala. JOE: Hello. ELRICK: Joe, how are you doing? JOE: I'm doing well, how are you? ELRICK: I'm awesome, man, and we have a wonderful podcast today. We're going to be talking about Resin.io and we have some wonderful people here from Resin with us, not one but two people came over from Arizona. We have Alison Davis, who is the director of product marketing and strategy at Resin. Alison, how are you doing? ALISON: Hey, Elrick, I'm great. Thanks for having us. ELRICK: Thank you for coming on. Also, we have Ronald McCollam, who is the solution architect at Resin.io, he's on the call with us on the podcast. Ronald, how are you doing? RONALD: I'm doing great, Elrick. Happy to be here, thank you for having me. ELRICK: Thank you for coming on. Thank you. Let's kick it off and we're going to talk about some IoT today, some Resin in IoT. What do you guys think is the future of IoT? What does it hold in your perspective? RONALD: If you had asked me a couple of years ago, I probably would have said that it's a bunch of connected refrigerators and maybe light switches and kind of left it at that. But the more I see the industry evolving, the more I realize that IoT really means that everything is getting interconnected and everything is sending data and exchanging data. I think we'll start to see IoT, not only in smart appliances and lights and so forth on the consumer side, but also on the industrial side. A lot of building automation, a lot of just more general information being provided by the environment and environments adapting to suit humans better. I think really the answer is IoT is going to be everywhere you look over the next few years. ELRICK: That is a broad takeover of IoT. It's going to be everywhere. ALISON: Yeah and I'll just add that we also think that IoT is going to become more prominent as compute power really does push further and further out to the edge. We see this trend happening already, where the amount of data and computing that needs to happen is too much to continuously be communicating back up to the cloud and more and more computing will need to take place on the edge in IoT devices and we really see these strong devices weakly connected as we often say as the future of IoT. One thing, we can talk about with Resin is, we see this creating what we call a management gap in between the developer and the fleet owner of these devices on the edge and the devices themselves and that's where Resin comes into the picture. ELRICK: That's interesting, so these devices are going to be sharing the computation and taking away some of that computations from the actual cloud? ALISON: Yeah, we think so. I think the devices themselves are getting stronger and it's becoming more and more possible for that to happen. Then there's just simple reasons of physics and economics why it will be too slow and too expensive to continuously be relying on the cloud for compute. This is a trend that we really see happening and something that we want to help fill that management gap between developers and their fleets of devices that are running out on the edge. ELRICK: I can see how that could be a plus for a company to not have to try to do all these computation on the cloud. As Ronald said earlier, since IoT is everywhere and it's going to be in devices all over the world, we could end up with probably trillions of devices trying to leverage cloud to do with computation and taken some of that away from the cloud would be a definite plus because I don't think that there is a platform that can handle that kind of data throughput. RONALD: Yeah and even as Alison said, there are just times that for reasons of the laws of physics, you really can't wait for that round trip to the cloud. We'll go sci-fi here. Let's say you've got some automated robot in an environment with a lot of people around, you don't want that thing sending all of the camera information that it has as it's moving through a crowd of people up to the cloud, waiting for the processing to happen there and then being pushed back. By the time it gets there, that robot may have already run over somebody. We really don't want that. You've got to do some of that processing out at the e

Mike North: @michaellnorth | mike.works Show Notes: 00:51 - Transitioning from CTO to Independent Trainer 03:37 - Customizing Content and Developing Curriculum 06:37 - Bringing a Developer Into the JavaScript Ecosystem 12:47 - Training Developers with Non-Traditional Backgrounds 16:56 - Keeping Up with “Fifth Gear” 19:27 - Developing Frontend Masters Courses 22:40 - “Progressive Web Apps” 34:37 - Web Security Resources: LinkedIn's REACH Program IndexedDB Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 79. My name is Charles Lowell, a developer at the Frontside and your podcast host-in-training. With me today is Elrick, also at the Frontside. Hello, Elrick. ELRICK: Hey, what's going on? CHARLES: Today, we are going to be talking with Mike North, who is doing all kinds of interesting stuff as per the usual so we'll jump right in. Hey, Mike. MIKE: How is it going? I'm glad to be here. CHARLES: Last time that I saw you, I think it was about a year ago at the Wicked Good Ember Conf and we were standing on the beach, drinking scotch and talking about Fastboot but you were doing something completely and totally different then than you are now so I was wondering, we were talking the conversation before we started rolling, that your role nowadays is independent consultant and personal dev trainer. I was wondering if you talk a little bit about that move from the CTO role that you're playing at your old company to kind of moving into that independent trainer, like why and how. MIKE: Yeah, I do remember talking about Fastboot at Wicked Good Ember. It feels like things have moved quite a bit since then. I have always loved teaching developers. When I've been a team lead, it's the favorite part of my job just because I get profound satisfaction out of helping people get over these hurdles that most of the time took me a much longer time with blog posts and podcasts and incomplete examples and libraries that were out of date and Stack Overflow with half answers. I've decided to dedicate myself to trying to make it easier for people in an increasingly complex web development world to wrap their head around everything. While I was a tech lead or a CTO, I always had to split my focus between helping developers grow and something else. Oftentimes, that something else was where the deadlines were and the time pressure was. It felt a little bit like I was driving a car that only had first and fifth gear where you're like on the bleeding edge of open source and what was the latest commit to master and [inaudible]. Then like, "Oh, let's be extremely patient with this person. They've never seen promises before because they came from another programming language. Let's help them digest this at their own pace." It's this slow and patient process of building up from the fundamentals and then the bleeding edge is like, "Let's use Babel Stage 0." It was very hard for those two aspects to exist at the same time in myself so I decided I'm just going for the training side. That's really all I do these days. CHARLES: It was so, but now would you qualify that as the first gear or the fifth gear? MIKE: That's the first gear. It gets you off the ground. It takes you from stop and gets you moving and then you have to develop your own expertise beyond that. But I like to think I'm developing a really, really excellent first gear. Today for example, I'm converting a bunch of Python developers at LinkedIn who are basically the ops team. I'm teaching them Ember and JavaScript at the same time through a series of about 20 exercises over three days. That process is many weeks long without assistance so this is like, "Let's get rolling much more efficiently and quickly," than via DIY approach. CHARLES: Now, do you find you have to custom-tailor for the environment or the developers moving from like someone coming from, say C# would have a different experience than someone coming from Python? MIKE: Absolutely. When I have my material, I have sections that I can drop. If you are a C# developer, I do not have to explain conceptually what 'async' and 'await' mean. You've been working with that for a while. I probably throw up a little example in C# and then the equivalent in JavaScript to sort of create a bridge from your existing expertise into the JavaScript world. Another one -- this is very true -- is teaching Ruby developers how to use Elixir. You don't have to say, "This is a router. We have controllers. There are actions and controllers." There are so many parallels that really it's more useful to help, rather than teach things from scratch to create connections back to the expertise they already have so they're not starting from zero and they can say like, "In the Ruby world, I would think of doing XYZ." Now, I have a map in between that and this new thing. CHARLES: Obviously, there's a lot, a lot, a lot of languages and environments that you could transition t

Jason Jaynes: @jasoncjaynes Jeff Wilson: @ProfDumpster Show Notes: 00:53 - “Professor Dumpster” and Founding Kasita 05:33 - The Startup Industry 07:45 - Building the Kasita Team and Creating the Design 12:25 - Integrating Devices 16:33 - Challenges of Building These Ecosystems 24:36 - Controlling the Ecosystem: Will there be third-party developers and applications? 30:16 - Device Cohesion and User Experience 33:23 - Privacy Resources: Data for the People: How to Make Our Post-Privacy Economy Work for You by Andreas Weigend Kasita is hiring! Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 78. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. With me today are Jeff and Jason from Kasita. Now, Kasita is one of the most exciting products that I think we've gotten to work on here at Frontside in the last five years. We're going to be just talking about it because, I think it touches on a lot of the aspects of what makes software development and startups and just the emerging economy exciting. I'm really thankful that we get to have you all on the podcast. Welcome Jeff and welcome Jason. JEFF: Thanks for having us. JASON: Excited to be here. Thanks, Charles. CHARLES: Now Jeff, you are the founder of Kasita, the CEO and I believe your official title over there is 'Professor Dumpster.' Maybe you could actually unpack for us a little bit of what does that title mean? How did Kasita come about and what is it today? JEFF: A couple of years ago, I did a radical, social experiment around housing. I went and sold everything I own for a dollar an item out of a 3000-square foot house and moved into a 33-square foot used trash dumpster for a year. The idea of that project was to live in 1% the size of an average American home and try to use 1% the energy and water of the average American home. The project took a little bit of a twist, you might say and about part way through it when the dumpster started getting tricked out, I started thinking about the whole nature of housing and how we need to do something different and how that grand future probably would not be a gated community of dumpsters. CHARLES: Now, I assume you cleaned out the dumpster before you actually went to live in it. JEFF: Yeah, it was a fixer-upper. We give it a bit of a scrub and did some testing to make sure there wasn't anything nasty left in there. That went for about a year and a couple of months after that, I actually first set down with Jason because he was the only person that I knew in the entire startup scene, in the entire world. He said, "Wilson, you had some crazy ass ideas like this dumpster thing you told me about. This one might actually work, this Kasita thing." Here we are today, we're working together. CHARLES: Wow. This was something you just did on a lark. You didn't have the idea of starting this business but it was actually through the process of actually living in this dumpster for a year that the idea emerged or was there a master plan going in? JEFF: I don't know, Jason do you remember any kind of master plan when I first told you about the dumpster? JASON: No. When we first met to talk about the dumpster, it was an early morning, I believe in 2010 or 2011 and you're incubating the idea. At that point in time, there was nothing on your mind or you aren't looking towards the future of housing at all. You were just trying to figure out how you were going to move into a dumpster and people thought you would be crazy. Of course, I've validate it and I thought people would think you would be crazy. CHARLES: That is a pretty radical idea, the future of housing being 1% of what it is now. How do you see that playing out? How is that possible? How do you shift people's mindset away from that? JEFF: One of the bigger things we're trying to do with Kasita, there needs to be a massive shift in the wider way that we live in our homes. As everything else is moving towards on demand and as a service and as everything's being sort of productized, those are some of the core ideas behind Kasita. We think about Kasita a lot more like an iPhone or a Tesla than we would think about it as a single family home or an apartment block or even a micro-unit. That's why Jason and I are standing together here today is I represent a lot of ways, a kind of vision and origin story of Kasita but in a lot of ways, Jason represents the future of the software and integrated IoT that's going into these things. CHARLES: There is definitely a lot going into these things. I remember when Jason first started telling me about it because it is like an iPhone or a Tesla but, I think especially the Tesla is a great analogy because you have not just like a normal software or even really a hardware project, you've got architectural concerns. You've got manufacturing concerns. You've got, I assumed geopolitical concerns in terms of the politics around zoning and housing and real estate

In this episode, we talk about IoT: what’s coming, why we’re intrigued, and how we’ve already started it incorporating it in our office. In the next episodes to come, we will be having guests on the show to take a deeper dive into this technology. If you have any suggestions or know people we should reach out to, please get in touch! Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #77. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. Today, I have with me two other developers here at The Frontside. This is going to be a Frontside-only podcast and we're going to be introducing a topic that hopefully we're going to be podcasting a lot about in the coming weeks and months just because it's something that's kind of grabbed the interest of the office and seems like it's something that needs to be talked about. Hello Joe and hello Elrick. JOE: Hello, Charles. ELRICK: Hey, what's going on? CHARLES: Everything, really. Today we're going to be talking about the Internet of Things and we'll be talking a little bit about how we came to be interested in this topic and why we think this topic is important. Let's talk about why this topic is important. I think that this is a very important topic because IoT is only becoming more and more prevalent. It's emerging from the status of being this niche or boutique or very esoteric technology that's only worked on by a very small group of people to becoming very, very open and available and accessible so that anybody can buy a Raspberry Pi or an ODROID or Arduino and slap some Linux on there and connect it over the internet to a bunch of different things and the space of creative possibilities is just exploding. For me, it's very similar to where we were in the early 80s. You know, I see these IoT devices as being the hobbyist's computers, the Z80, Apple IIe, the Commodore 64 and that the people who are hacking on those things 30 years ago are going to be the people who are now leading the tech space today. I think another big and relevant analogy is web technologies. There was this inflection point where web technologies became very open, accessible, available and the people who were in it ended up being able to ride that wave for 10 years to where we are now. In both of those examples, we had the hardware and the PC revolution where the computation was distributed across a bunch of these different devices. Then over that time, we saw a migration over to the cloud and these web technologies where everything was centralized. Now, I actually think that there's a pendulum swinging back where we're actually going to see more and more computation distributed amongst physical devices, except this time, it's not going to be manifest as a PC. It's going to be manifest as these networks of devices that are just all around us. I really do think that we are on one of those watershed moments where these distributed networks of tiny devices are going to be the big next platform that when you invest in it now, this is something that's going to yield dividends for the next 20 years. I think it's an important topic but I don't think we had a well-crafted thought about it but we just kind of stumbled into the space. I was thinking we could start a little bit by talking about how we got into this and how it captured our imagination. If you rewind the clock to the stone age of 2015, I think it was the end of 2015 and it was Christmas break, that's often a time when people go and they hack on individual projects and Brandon, his project that for whatever reason, he decided to take on was he was really into Hue Bulbs at the time. We had Hue Bulbs around the office and we wired up some demos to control them from a website. He decided he wanted to take those Hue Bulbs and make them so they were accessible from our Slack. He built a server in Elixir because he also wanted to learn Elixir because if you're having fun in hacking around, it might as well pick up as many new things as you can. He built an API in Elixir that talk directly to the Hue Bulbs and the Slack integration that talk to the Elixir API and we actually are able to control all of our lights purely from Slack. We could turn them all on, we could turn them all off. That was great but then as we began to use it, we were wishing that we had control over our lights from our phones. We wish we had control over them through the website. I think, Elrick, isn't that was your first contact with the Frontside, wasn't it? ELRICK: Yes. That was my first contact with the Frontside. I was working on the lights app. I initially started working on just the user interface and bringing some different animations and working on the actual experience and the user story on that side about controlling the lights and what particular things you needed to do in trying to craft a UI around that. That's what I initially started. CHARLES: That was really fun. ELRICK: Yeah, that was

Drew Covi: @drewcovi | about.me Show Notes: 01:04 - Honeywell User Experience (HUE) 05:00 - Deliverables 06:55 - Being a “Devsigner” 17:26 - Flash and Leading to Unique Skills 30:00 - Advice for People Straddling Roles 35:27 - Leveraging Design and Development Skills Together 39:41 - Embracing the Hardware Element 42:05 - Why the “Devsigner”? Resources: AOLpress CSS Beauty CSS Zen Garden Contribute Crave Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #76. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me is Elrick Ryan, also a developer at The Frontside. Hello. ELRICK: Hey, what's going on? CHARLES: Not much. Are you excited about today's topic? ELRICK: Very excited. CHARLES: Yeah. You got a personal stake in it because today, we have in the room, not only you but also two developers who are also designers or designers who are also developers. Our guest today is actually the first person who fit this description that I ever worked with. It was a great experience, a great collaboration and his name is Drew Covi. Drew is a senior supervisor of product design at HUE Studios in Golden Valley, Minnesota. DREW: Howdy. How are you doing? CHARLES: Good. Thanks for joining us. Now, you're going to have to explain to us two things, one, what is a super senior product designer and let's start off talking about HUE first. What exactly is HUE because I think it's a cool organization? DREW: I'm working with four people and I'm working on all sorts of brand new ideas. I think the greatest opportunity that I've had in my career at this company, Honeywell is just working with physical product and the digital space. It's a unique opportunity. Not all companies focus on both so it's really been a learning experience for me and working with a great group of creative individuals is also been a real privilege. They say that at the end of the day, the most important thing is other people that you work with and really the entire team here has been fantastic in welcoming me and letting me explore and grow as a developer and as a designer. It's been great so far. CHARLES: Fantastic. Working with that group was absolutely wonderful. What does HUE stand for? DREW: HUE is Honeywell User Experience. Our previous CEO, Dave Cote often called it 'huey' but it's just HUE, without the Jersey accent. I'm going to probably misrepresent but we have over eight to 10 studios throughout the world. Each one focuses on different businesses for the most part. The one here in Golden Valley tends to focus on homes and buildings technologies. The studio out of Seattle, actually tends to focus on, again I'm going to get the acronym wrong here but it's essentially worker safety in industrial safety. CHARLES: What is it that you all do at HUE? DREW: What we do here at the studio here in Golden Valley is we support various businesses throughout the homes and buildings technology space. About fall of last year, Honeywell went through a bit of a shift in their business and they used to do all automation control solutions. Last fall essentially, we saw that one large business that was headquartered and based out of Golden Valley, break into two areas of more direct focus. Out of Seattle, we have folks working on, I think I mentioned before but Seattle works on sensing and productivity solutions. We focus on homes and building space so we're both providing upfront research to understand what the customer needs. We're actually creating everything from very rough user flows to final UIs and we're also working with industrial designers to create final products. Those industrial designers work very closely with engineering. Honeywell has a long reputation of very strong engineering when it comes to the hardware space. We've prided ourselves on excellent instruments and excellent performance. One thing that very few people understand is that we don't just do thermostats. We're in the business of turbos. We're creating the turbos for your car. We're creating all sorts of HVAC equipment. We're also handling various safety equipment. All of these items need designing, not just for end users and consumers but they also need designing for the workers in the field. If we make a product that is more efficient, easier to use and in some cases, more attractive, not only it does lead to more sales, it leads to more efficient work forces that can work quicker essentially. You could get up on a roof and get off in record time. We're not just designing consumer products. We're actually focused on a lot of other items as well, with oftentimes very large returns on investment. CHARLES: In the work that you do and HUE does in general, it sounds like there might be a large software component. Digital design is kind of we know in the web space but then also a lot of industrial design of just how does this thing going to look, how is it going to feel, how is it going to persist, how durable

Robert Jackson: @rwjblue | rwjblue.com Show Notes: 01:00 - Build Tooling in JavaScript 02:19 - Ember and Babel 07:14 - Deciding on Features 11:46 - Class 13:29 - Workflow 14:39 - Payload Size 15:24 - Config Targets 17:18 - Source Maps 25:05 - Ember Decorators, Objects and ES6 Classes 36:07 - What’s next and when can we get it?! Resources: Babel.js esperanto Ember CLI Targets 🎯 Enabling Ergonomics 🚐 and Performance EmberCamp London One Helpful Way to Think About JavaScript Decorators Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 75. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. This is a little bit of a diamond anniversary episode, I guess -- #75 -- so it's going to be good. With me today is Jeffrey Cherewaty. Hello, Jeffrey. JEFFREY: Hey. CHARLES: To celebrate our 75th diamond jubilee, we have with us a very special guest who I like to refer to as the Eye of Sauron when it comes to bugs in the Ember community. Mr Robert Jackson, who is a person over at LinkedIn, who does what he think is best. Hello, Robert. ROBERT: Nice. Howdy, howdy. It's great to be here. Thanks for having me back. CHARLES: Today, we're going to talk about many things but chief amongst them is going to be BabelJS and the conversation around tooling in the JavaScript community because we've come from a point where, I want to say in 2012 where it wasn't really a thing or the build stuff was like an incidental thing but it mostly was just, maybe compressing your files and maybe doing a little bit of finger printing or what have you, to now pretty much build tooling, rules and everything around us. The amount of software around the deployment of your software is a huge amount. Would you say that's fair? We’ve come a long way. ROBERT: I think, for sure that we, at this point, have a whole tower of Babel going on, with all the things that we're doing. We have a ton of tools at our disposal today that I wish that I had years ago. I think that, unfortunately the law of nice things is that as you get better things, you realize the things that you don't have still. It's like an ever-increasing distance to the Promised Land, if you will. But I think that where we are today is massively night and day better than where we've ever been before. We can do so many things like code mods and transpilation and prod debug style, all sorts of things. For the most part, in the Ember community at least, we try to make that as much like a default out of the box experience as possible. CHARLES: Just to talk about that land before time, now Ember was one of the first frameworks to really embrace transpilation but also using Babel as the primary tool. What was that experience like? What changes that we have to make in order to hit that? ROBERT: I think, the Ember itself, the framework itself which is still shrouded in the final global's output which folks used, was one of the first major things to use ES6 modules and at that point, it was before Babel was even like a concept, as far as I know, we started using Traceur. Then we also used the Squarehead written in model transpiler as well and we use [inaudible] for a while and it was great. As we continue to press on this path, we realized that we wanted nice things in our apps too. We wanted modules. At the time, we're using Ember app kits. This is pre-dates Ember CLI using Ember app kit and the way we got modules was either via [inaudible] pipeline which was a Ruby thing in Ember side or just like some Grunt pre-compilation which roughly just ensured that the modules were evaluated in the right order and people generally actually wrote global style code and just assumed the concatenation order worked. That is super not great. It made for some really gnarly interdependencies that was hard to untangle, I suppose. CHARLES: When did Babel come in that conversation? ROBERT: Shortly after we started doing Ember app kit. This was like a project that Stef Penner started. We started doing ES6 modules specifically. At that time we were using Grunt for that and we did modules. I think we used squares ES6 modules transpiler. Then shortly after we started working on Ember CLI itself, like the tool named Ember CLI that you know today, we migrated to a tool called Esperanto from Square's transpiler. Then that was deprecated and we started using Babel. We have made many hops along the way. I think when we originally introduced Babel into the Ember CLI app pipeline, it was an optional dependency because it was actually quite slow to run Babel across a decent-sized app. It was many orders of magnitude slower with Babel than without. Some folks wanted to optionally opt in to using Babel. That was probably sometime in 2015 so over the years, we slowly started migrating the codebase so that at this point, a Babel is totally required part of Ember CLI built pipeline and we will warn you or something if you don't have. It started out as basically an

Anissa Willyard: @team_giveback | GiveBack2Schools Show Notes: 01:28 - The Mission of Mission Driven Businesses 05:05 - Defining Moments and Leaving a Legacy 11:30 - PPG (Plan, People, Go) 13:20 - Finding Your People 16:22 - Choosing a Mission 22:30 - Defining a Problem 34:19 - About GiveBack2Schools Resources: Boston: Peace of Mind Lyrics Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 74. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. With me from The Frontside also is Ginger Whalen, our head of business development. Today, I'm actually excited about this episode, I'm excited about every episode but I'm excited about this one in particular because we're going to get to see something from the other side of the coin. Our listeners are on the implementation side and sometimes, when it comes to starting up a business or being a founder, the driver and the implementer are met in one person but more often, and I think in a more healthy way, they're split between multiple people serving multiple roles. Today, we're going to interview somebody who is a serial entrepreneur, who is currently a founder at a business that we came very, very close to working with. Please welcome, Anissa Willyard to the show. Hello, Anissa. ANISSA: Hello Charles. Thank you so much and thanks to The Frontside Team and Ginger. You guys are an incredible team and I really enjoy having the opportunity to be able to be here today so thanks so much. CHARLES: No problem. You're currently a founder at GiveBack2Schools, which is going to be launching soon. ANISSA: Yes, that is correct. Our goal is to launch in July 19th. We've kind of pushed it back a little just to make sure we get through the holidays and make sure that i's are dotted, t's are crossed and now, we are locked and loaded. The official date right now is the 19th and we're really excited to launch in Olathe, Kansas. CHARLES: Fantastic. We're going to actually talk a lot about that later on but first of all, there's obviously a large backstory for how you came to be doing what it is that you're doing today. I wanted to kind of delve into that a little bit. ANISSA: First of all, I think right now, we all live in such interesting times that I believe by having a business with a mission is actually is going to allow us as individuals to create such a positive change. The change that we create will actually feel us through as founders or as anybody who decides to move forward to start any kind of company. I do believe there was a quote that I live by. It’s one by Zig Ziglar and it says, "It's not where you start but where you finish." To kind of take you through that journey, my hope today is that I give everybody hope, that if I can make a difference, that somebody else can too and that will give them and inspire one person to take that action to make that difference. I look back on everything in my life and kind of where I was in my journey, as far as the why. The why behind what I did. I sat down throughout my day and I broke it up into three different parts. In the first part is kind of called, 'the grownup phase.' That's where you go to school and you come through college and then your middle years where you're out, you're fighting for that career and you really are starting to climb that corporate ladder if that's the road that you decided to go down or raise families or whatever that is. Then the last part where it brings you to that moment, where you question yourself, "When this is all done, did I really make a difference? Am I leaving behind and making a better place here?" That all brings me through, like you said, "Where did it all come from and everything?" From my days with Mary Kay Cosmetics, back when I thought for sure, I was going to be an oncologist and then went out, that's with Mary Kay where I had the honor and the privilege to be trained by the woman herself back, growing up in the Pacific Northwest and having a great role model that just inspired me and be enabled at the right age of 22 years old to have earned a free car. My father thought that was just crazy, that I would sell lipstick so I might as well move on and pursue the corporate dream. Now today, to come full circle and think when it's all over, where am I heading? It kind of in a roundabout way who I was and from working in advertising, to marketing, to implementation, the jack-of-all trades and probably the master of none when it's all said and done. CHARLES: When you say you came to this moment where you had this time of reflection of saying, "Is this the legacy that I want to leave behind?" What is that when you start thinking about the things that you want to leave both to your family and to the world, maybe even long after you're gone? When did that happen and how long did that take and what was the end result of that? What path did that set you on? ANISSA: It's so interesti

We will be back on June 29th with your regularly scheduled podcast! Happy summer! <3 The Frontside Gang

Kris Van Houten: @krivaten | krivaten.com | Q2 Show Notes: 00:55 - Kris’ Interest and Passion for Accessibility 06:07 - Using Ember for Accessibility: Pattern Adoption 10:13 - Context Switch Awareness and Managing Focus 12:08 - Asynchrony and Desired Interaction 14:04 - Building a Form Input Component 19:05 - Things That Are Hard to Catch 22:41 - Assistive Browsers? 28:17 - Making Things Accessible From the Start Resources: Building for Accessibility by Nathan Hammond @ Wicked Good Ember 2015 The A11y Project: Web Accessibility Checklist WCAG 2.0 checklists Why Don’t Screen Readers Always Read What’s on the Screen? Part 1: Punctuation and Typographic Symbols Mozilla Accessibility Kris’ Blog Post Series on Accessibility: Part 1: What is accessibility and why should we care? Part 2: A Primer on Accessibility Part 3: Getting Our Apps Ready for Accessibility Part 4: Building an Accessible Icon Component in Ember Part 5: Building an Accessible Input Component in Ember Part 6: Building an Accessible Alert Component in Ember Part 7: Building an Accessible Numbers Component in Ember Part 8: Building an Accessible Currency Component in Ember Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil. WIL: Hello. CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We’re going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general? KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it. Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?" I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let’s just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code. CHARLES: Right, it's the path of least resistance. Everybody’s got a job to do. Everybody’s got features to deliver so that practice can be very easily self-perpetuating, right? KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That’s where I was a little over a year ago basically. When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important." I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Em

Audrey Eschright: @ameschright | The Recompiler Show Notes: 00:50 - Background in Publishing and Open Source 06:53 - The Contributor Pool 12:37 - Open Source Bridge 15:29 - Mistakes Open Source Contributors Make 17:21 - Tools for Maintaining an Open Source Project 19:09 - Roles 23:33 - Open Source Bridge (Cont’d) 27:47 - Governance and Decision-Making 36:20 - Making Open Source Accessible, Safe, and Welcoming Resources: Free Geek Calagator PDX Activist Dreamwidth Safety First PDX Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #71. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Joe LaSala. JOE: Hello. CHARLES: Hey, Joe, another developer here at The Frontside. With us today is the publisher of The Recompiler Mag and a long-time open source contributor Audrey Eschright. Welcome Audrey. AUDREY: Hey! CHARLES: Thanks for being on the show. AUDREY: Oh, thank you. CHARLES: Today, we're going to be talking about open source and in particular, the labor that goes into open source and making that sustainable but before we get into that, I wanted to first talk about your background, both in terms of how you came to be publishing the magazine and also your background on open source, how we're arriving at the subject today. AUDREY: The magazine, in a lot of ways, I refer to it as a feminist hacker magazine. It holds together a lot of different things that I've worked on over the years so I'm going to jump all the way back to when I first encountered open source and then maybe that will fit together. When I was in high school, I first encountered the internet and the internet that was available to me at that time use things like Gopher. Gopher is a pretty web protocol and it was free software. I didn't really understand that it was free software at that point but I did understand that if I wanted to learn how to write code and the computer that I have access to were things like a bunch of really old PCs like 286's and an old Macintosh. Then there were commercial compilers for writing code and there were free compilers for writing code. There was a thing called GCC and I knew that it was on university computers and if I got access to those, then I could write code. Then I got to college and write about when open source really started to take off as this concept of how free software comes into business world. I've had that as a background of becoming a programmer and getting involved in things but after college I wasn't really sure that I want to work in technology so I took a break. When I came back, I needed a way to get myself up to date so I started volunteering with this local group called Free Geek that recycles computers. What they do is they take those computer parts and the ones that are usable, they build them into Linux boxes for people, like Linux desktop boxes. How I got back up and running was learning how to work and volunteering in an organization that was very open source based, like all of the tools that they used are just completely open source. CHARLES: Was that for budgetary reasons or they didn't want the people to burden the recipients of these computers with any licensing fees or obligations to third parties? AUDREY: It's budgetary but it's also ideological. The organization was started out of environmental interests. The original folks, they pointed to us this computer monitor that they [inaudible] as the reason that they do this, that the way computer waste is being handled was so unfriendly that you might as well just dump it in the river. They started from there but I think because those kinds of interests of creating something that was really accessible for people are really educational and accessible to lower income patrons has always been a really big part of it. I think that using Linux and using open source tools has been a big part of that. CHARLES: I think open source is so pervasive, a lot of people forget that in those days, there was a lot of radical thinking behind it, of radical accessibility like it's your basic right to be able to access every layer of your stack. It's a little bit unfortunate that you mentioned GCC that like the GNU, the Free Software Foundation isn't as much part of the conversation as they were back then. AUDREY: Yeah. I think that as more people come in to, we've shifted through these different generations basically in open source contribution and how it's formulated. The fact that I even default to open source is really interesting because a lot of the values that I referencing are those free software values. CHARLES: Fast forward to the present... AUDREY: Part of how I built my skills was by starting open source projects called Calagator. It's a community calendaring platform that makes it very easy to import things from

Kubernetes Joe Beda @jbeda | Heptio | eightypercent.net Show Notes: 00:51 - What is Kubernetes? Why does it exist? 07:32 - Kubernetes Cluster; Cluster Autoscaling 11:43 - Application Abstraction 14:44 - Services That Implement Kubernetes 16:08 - Starting Heptio 17:58 - Kubernetes vs Services Like Cloud Foundry and OpenShift 22:39 - Getting Started with Kubernetes 27:37 - Working on the Original Internet Explorer Team Resources: Google Compute Engine Google Container Engine Minikube Kubernetes: Up and Running: Dive into the Future of Infrastructure by Kelsey Hightower, Brendan Burns, and Joe Beda Joe Beda: Kubecon Berlin Keynote: Scaling Kubernetes: How do we grow the Kubernetes user base by 10x? Wordpress with Helm Sock Shop: A Microservices Demo Application Kelsey Hightower Keynote: Kubernetes Federation Joe Beda: Kubernetes 101 AWS Quick Start for Kubernetes by Heptio Open Source Bridge: Enter the coupon code PODCAST to get $50 off a ticket! The conference will be held June 20-23, 2017 at The Eliot Center in downtown Portland, Oregon. Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 70. With me is Elrick Ryan. ELRICK: Hey, what's going on? CHARLES: We're going to get started with our guest here who many of you may have heard of before. You probably heard of the technology that he created or was a key part of creating, a self-described medium deal. [Laughter] JOE: Thanks for having me on. I really appreciate it. CHARLES: Joe, here at The Frontside most of what we do is UI-related, completely frontend but obviously, the frontend is built on backend technology and we need to be running things that serve our clients. Kubernetes is something that I think I started hearing about, I don't know maybe a year ago. All of a sudden, it just started popping up in my Twitter feed and I was like, "Hmm, that's a weird word," and then people started talking more and more about it and move from something that was behind me into something that was to the side and now it's edging into our peripheral vision more and more as I think more and more people adopt it, to build things on top of it. I'm really excited to have you here on the show to just talk about it. I guess we should start by saying what is the reason for its existence? What are the unique set of problems that you were encountering or noticed that everybody was encountering that caused you to want to create this? JOE: That's a really good set up, I think just for way of context, I spent about 10 years at Google. I learned how to do software on the server at Google. Before that, I was at Microsoft working on Internet Explorer and Windows Presentation Foundation, which maybe some of your listeners had to actually go ahead and use that. I learned how to write software for the server at Google so my experience in terms of what it takes to build and deploy software was really warped by that. It really doesn't much what pretty much anybody else in the industry does or at least did. As my career progressed, I ended up starting this project called Google Compute Engine which is Google's virtual machine as a service, analogous to say, EC2. Then as that became more and more of a priority for the company. There was this idea that we wanted internal Google developers to have a shared experience with external users. Internally, Google didn't do anything with virtual machines hardly. Everything was with containers and Google had built up some really sophisticated systems to be able to manage containers across very large clusters of computers. For Google developers, the interface to the world of production and how you actually launched off and monitor and maintain it was through this toolset, Borg and all these fellow travelers that come along with it inside of Google. Nobody really actually managed machines using traditional configuration management tools like Puppet or Chef or anything like that. It’s a completely different experience. We built a compute engine, GCE and then I had a new boss because of executive shuffle and he spun up a VM and he'd been at Google for a while. His reaction to the thing was like, "Now, what?" I was like I'm sitting there at the root prompt go and like, "I don't know what to do now." It turns out that inside of Google that was actually a common thing. It just felt incredibly primitive to actually have a raw VM that you could have SSH into because there's so much to be done above that to get to something that you're comfortable with building a production grade service on top of. The choice as Google got more and more serious about cloud was to either have everybody inside of Google start using raw VMs and live the life that everybody outside of Google's living or try and bring the experience around Borg and this idea of very dynamic, container-centric, scheduled-cluster thinking bring that outside of Google. Borg was entangled enough with the rest of Google systems that sort of portin

Toran Billups @toranb | GitHub | Blog Show Notes: 01:44 - New Developments in ember-redux 04:23 - New Developments in the Wider Redux Community 06:26 - Using Redux in Ember 09:40 - Omit 10:45 - Reducers 25:42 - Fulfilling the Role of Middleware in Ember 28:12 - Ember Data in Redux-land 31:24 - What does Toran do with this stuff?? Links: The Frontside Podcast Episode 55: Redux and Ember with Toran Billups The Frontside Podcast Episode 18: Back-End Devs and Bridging the Stack with Toran Billups redux-offline ember-redux-yelp create-react-app "Mega Simple redux” Twiddle ember-concurrency Thomas Chen: ember-redux The Frontside Podcast Episode 067: ember-concurrency with Alex Matchneer normalizr Rich Hickey: Simple Made Easy Other Noteable Resources: ember redux: The talk Toran prepared for EmberJS DC in April 2017 github.com/foxnewsnetwork/ember-with-redux Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 69. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me Wil Wilsman, also a developer here at The Frontside. Hello, Wil. WIL: Hello. CHARLES: Today, we have a special guest, an actual elite member of the three-timers club, counting this appearance. We have with us Toran Billups. Thank you for coming on to the show today. TORAN: Absolutely. I'm not sure how the third time happened but I'll take it. CHARLES: Well, this is going to be the second one, we're going to be talking about Redux and then I believe you're on the podcast back in 2014 or 2015. TORAN: That's right. CHARLES: That's one of our first episodes. Make sure to get in touch with our producer afterwards to pick up your commemorative mug and sunglasses to celebrate your third time on the show. Awesome. I'm glad to have you. We actually tend to have people back who are good podcast guests. TORAN: Thank you. CHARLES: Yeah, I'm looking forward to this one. This is actually a continuation of a podcast that we did back in January that was actually one of our more popular episodes. There was a big demand to do a second part of it. That podcast we talked about the ember-redux library, which you're a maintainer and just kind of working with Redux in Ember in general. We’re going to continue where we left off with that but obviously, that was what? Almost six months ago? I was wondering maybe you can start there and there been any kind of new developments, exciting things, what’s kind of the state of the state or the state of the reducer or the state of the store in ember-redux. TORAN: For ember-redux, in particular, we're working on three initiatives right now. The first is making the store creation more customizable. A lot of people that come from the React background in particular are very used to hand crafting how the stores put the other with the right middleware and enhancers and reducers and that's been fine. I wanted to drop people into the pit of success and everybody's cool with that but now we're getting to a point where there are people wanted to do different things and it's great to open the door for those people if they can, while keeping it very simple so we're working on that. We have here that's just undergoing some discussion. We’re also, just as the wider Ember community -- you guys maybe involved in this as well -- and trying to get the entire stack over to Babel 6, the ember-cli Babel 6.10 plus stack. There is a breaking change between Babel 5 and 6 so we're also having some discussions about the ember-redux 3.0 version bump at some point later this year, just because we really can't adopt this without introducing basically a breaking change for older ember-cli users. CHARLES: Just in general, this is a little bit off topic, what does it mean to go from Babel 5 to Babel 6, if I'm an add-on author. TORAN: I would probably ensure that need to speak more with Robert Jackson about this. We just kind went back and forth because I thought I had a Babel compile error. He’s like, "No, you're missing this dependency which is the object spread." Unfortunately, the object spread is rampant in React projects and this is totally cool. I had to actually add that and that's just a breaking difference between these two. If we adapt the new version of this in the shims underneath of it as an Ember 2.43 user, if you're on node four which is still supported, you will break without this. I'm trying to get some discussion going about what we should do here and if we even should push ahead and just say only node six is supported. There’s some discussion and then back to your original question, the third piece is we've introduced the ability to replace the reducer but we need to get some examples for hot reloading the reducer. That’s a separate project but it needs to be enabled by ember-redux. Those are the three main initiatives. CHARLES: Being able to you hot load your reducers, just to make changes to your reducer and you just thunk them into the applicatio

After the cliffhanger left in Episode 62: UI for U and I, we follow up with a short discussion about how we specifically do UI Testing at The Frontside in Austin, Texas. Resources: Tweet that led to this discussion Unit Testing Acceptance Testing Ember CLI Mirage Percy Test-Driven Development Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #68. My name is Charles Lowell. I'm a developer here at The Frontside and podcast host-in-training. I'm here today with Jeffrey and Elrick, two other developers here at The Frontside. We are going to carry on where we left off back in Episode 62. There was an implicit promise to talk about the way that we do UI testing. JEFFREY: We had a cliffhanger. CHARLES: Yeah, we did. It ended with a cliffhanger and someone actually called us on it, which I hate it because they're making more work for you. But Ian Dickinson from Twitter writes, "Hey, you guys promised to talk about how you do UI testing at The Frontside but never actually delivered on that promise." We're going to try and make good on that today. JEFFREY: We like to resolve our promises. CHARLES: Oh! [Laughter] CHARLES: You've been on vacation for a week, Jeffrey and I forgot what it was like to have you in the office. JEFFREY: Not enough code puns. CHARLES: Oh, code pun. There you go. It's like CodePen except all of the code has to make puns. I like it. Internet is awash with people bloviating about testing so we figured we'd take our turn at it. We promise to keep it short. We'll keep it focused but it seems like a value that we do have so might as well talk about it a little bit. You guys ready? JEFFREY: Let's talk about testing. CHARLES: I think one of the best things to do is to use something concrete, not just to talk about abstractions, not just to talk about things that might be but we're actually starting a project here in three days. It's going to kick off on Monday and testing is going to be a key part of that. Why don't we talk a little bit about what it's going to look like as we kind of lay the groundwork for that project? JEFFREY: As we start this project, the very minimum baseline that we want to get immediately is acceptance tests in the browser. We want to make sure that when you fire up this app, it renders, you get the fallbacks for the basic functionality of this app immediately. As we're building features on top of this app, that's when we bring in unit tests, as we say, "We're building this new component. We're building this new feature. That's part of this app. We're going to use test driven development and unit tests to drive the creation of that," but ultimately, our test of quality for that app and our assurance of quality over the long term comes from the acceptance testing. CHARLES: People often ask the question, "When is it appropriate to write those unit tests? When is it appropriate to write those acceptance tests and how much time so I spend doing each one?" Personally, when I was starting out with testing many, many, many years ago, I really, really like unit tests and I like developing my code based around unit tests. The thing that I liked about them was that they were fast. The entire test suite ran in a matter of seconds or minutes. JEFFREY: And you get coverage. CHARLES: Yes. JEFFREY: Like you get your coverage numbers up. It is like every line that I wrote here has some kind of code coverage. CHARLES: Right and it feels really good. I also think that unit tests really are great for mapping out the functionality in the sense of getting an intuitive feel of what it's like to use a unit before it's actually written. You get the experience like, "This is actually a terrible API because I can't write the test for it," so obviously it's not flexible and it's really mungy so I really, really enjoyed that. The thing that I hated most is acceptance tests. They're hard to write. They were slow to run and it seemed like when they would break, it was not always clear why. JEFFREY: Wait, so we were just singing the praises of unit tests. What's wrong with them? CHARLES: Part of it is kind of the way that you conceive of a test: what are you actually doing? I think if you think of tests not so much as something that's there for regression or something that's there to drive your design, both of which are very, very important things but more is just kind of measurement: taking a data point, what is it that I want to measure? In the case of a unit test, I want to measure that this library call does exactly what I think it's going to do so I can take that data point, I can put it on my spreadsheet and I can say, "I got that base covered." The thing is that an acceptance test just measures a completely separate thing and by acceptance test, we're talking about testing as much of the stack your entire integrated application as you can. Oh, boy. Don't get me started on terminology but when you have an acceptance te

Alex Matchneer: @machty | FutureProof Retail Show Notes: 01:07 - The Introduction of ember-concurrency 02:15 - What is ember-concurrency? What are the problems it solves? 05:37 - Why not use observables or other alternatives? 09:49 - Could observables be used in conjunction with ember-concurrency? 12:16 - Simple Made Easy 14:23 - Coming Soon to ember-concurrency 16:04 - Communicating Changes in State; Glimmer Reference Primitives 23:09 - Using References 29:31 - Submitting RFCs; Adding Pipelines 32:10 - Pipeline Use Cases Resources: ember-concurrency The Frontside Podcast Episode 007: The Ember Router with Alex Matchneer The Frontside Podcast Episode 019: Origin Stories with Tom Dale and Alex Matchneer Introduction to ember-concurrency by Alex Matchneer from Global Ember Meetup RxJS Rich Hickey: Simple Made Easy Glimmer.js redux-saga Lauren Tan's RFC: Cancellable task pipelines Railway Oriented Programming Apache Kafka Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 67. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today also is Elrick Ryan, a developer here at The Frontside. Hello, Elrick. ELRICK: Hey, what's going on, Charles. CHARLES: Now, we have with us today someone who we love to have on the show. Everybody probably already know him. I know the first time I actually heard about him was when we had him on the podcast the first time, I was like, "Who the hell is this guy?" But since then, he's become one of my favorite developers, just with all of the things that he's done, from Router.js to more recently ember-concurrency. We have Alex Matchneer on the program. ALEX: Hey, everybody. Thanks for having me. CHARLES: Hey, Alex and you know what? I pronounced your name right this time. First time out of the gate. Boom! ALEX: Nice. Which one did you go with? Matchnear? Matchner? [Laughter] ALEX: I really actually don't even know which ones correct anymore. CHARLES: Was it about a year ago that you first introduced ember-concurrency? ALEX: Yeah, I had a really embarrassing introduction of it at an Ember Meetup in January before it was really done and I just kind of botched it and didn't really introduce why it was even solving problems. Then a month later, I had some time to refine it, driven by the feel of that embarrassment. I guess around February of last year, it's been pretty much in its present state. CHARLES: I remember when it came out. I must've seen the non-botched version because I remember hitting the ground running with it and being able to refactor all of this code. I definitely know that I got the honed version because you provided in that initial blog post a whole host of examples like what are the symptoms, what are the cases where it solves and then before presenting the solution. I think that was great because I didn't even realize that I had a lot of pain. I didn't realize that at all. I didn't realize I had a problem but then you were very, very elegantly packaged the problem with the solution which is always great because otherwise, it's just complaining. Maybe we should talk a little bit about -- I don't think we've officially talked about -- ember-concurrency. Even though it's been out for quite a while, the way that you model these concurrent processes using the stack is just pretty incredible. Do you want to just very briefly touch on what the problem is and what have lead you to this solution? ALEX: Sure. It's a little bit difficult to sort of succinctly say what ember-concurrency is because it kind of hits them like five different separate but kind of related but not really pain points. At its core, it's just like a task primitive and it's definitely not the first library to ever introduce that the JavaScript, I think particularly when the generator function syntax was introduced into the spec, I think a few years back. Dave Herman who's also known as, I think a Little Calculist. I think he works on the TC39. I always get those groups a little confused in my head but he introduced a task.js library that let you use the generator function syntax and then lets you yield Promises to sort of pause where you were in that task and then continue when it resolved. It had some support for cancellation. It played well with Promises and I brought that to Ember in a way that fit really nicely with Ember more than it probably does or will with other frameworks like React or Vue. By bringing it to Ember, basically if you're implementing any feature that involves async, if it's a button that needs to show that it's been clicked while you're waiting for some response to come back from the server, instead of using Promises, instead of using actions, here's an ember-concurrency task. It makes it easier to express that operation you're trying to do and it makes it really easy to drive your UI with state that comes from the state of that operation -- Is the test still running? Is your form still submitti

Michael Coté: @cote | cote.io | Pivotal | Software Defined Talk Show Notes: 00:54 - Pivotal 04:39 - Being a Professional Muller aka Analyst 11:08 - Iterative Development 32:54 - Getting a Job as a Professional Muller aka Analyst Resources: Pivotal Cloud Foundry GemFire Greenplum Pivotal Labs Wardley Maps Software Defined Talk Episode #79: From a vegan, clothing optional co-op to working with banks and oil companies - Coté’s professional life, part 1 Software Defined Talk Episode #85: Being an analyst without being an asshole - Coté’s professional life, part 2 RedMonk Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #66. I am a developer, Charles Lowell at The Frontside and also host-in-training for 65 episodes. This is my 66th and I'm flying alone this week but we do have on the show with us a very special guest. Actually, the person who taught me how to podcast, I think it was about 10 years ago and he was like, "Charles, we should do this podcasting thing." I started my very first podcast with him and I still haven't figured it out. But his name is Michael Coté and he's a fantastic guy and welcome to the show, Coté. MICHAEL: Thanks for having me, Charles. It's great to be here. CHARLES: Now, what are you up to these days? You're over at Pivotal. MICHAEL: That's right. I work at Pivotal and probably people who are in the developing world know them for Spring. We have most of the Spring people. Then we also have this thing Pivotal Cloud Foundry. We're not supposed to call it a platform as a service but for matters of concision, it's a platform as a service that's the runtime that you run your stuff in. Then we also have a bunch of data products like GemFire and Greenplum and things like that. Then, 'openymously', if that's a word, we have Pivotal Labs. Now -- CHARLES: I think, it's eponymously. MICHAEL: Eponymously, yes. Now, you might remember Pivotal Labs as the people who use Chef Scripts to configure their desktops. Remember that? CHARLES: Yeah, I remember that. I was into that. MICHAEL: Yeah, in coincidental kind of way, the inspiration for the project Sputnik thing, which is coincidentally because now Dell Technologies owns Pivotal so all of that stuff has come for a full circle. I guess also since I'm intro-ing myself, I work on what we call the Advocate Team because we don't call them evangelists. No one likes to be called that I guess. I guess there's 12 of us now. We just hired this person, also in Austin actually McNorma who's big in the Go community and apparently can make images of gophers really well. I'm sure she does many other extraordinary things, not just the illustrator master. Everyone else basically like codes or uses the terminal but I do slides. CHARLES: Well, that's your weapon of choice, right? It's a more elegant weapon for civilized time or something like that. I'm going to look it up on Wikia. MICHAEL: Yeah, basically what we do on our team is we just talk about all the stuff Pivotal does and problems that we solve in the way people in an organizations like would think to care about our stuff. Most of what I do is I guess you call it the management consultant type of stuff. Since I have a background as an analyst and I used to work on corporate strategy and M&A at Dell so I have a vantage point in addition to having programmed a long time ago. If you're changing your organization over to be more agile or trying to devops, we would say cloud-native with a hyphen. How do you change your organization over what works and doesn't work? Most people in large organizations, they sort of pat you on your head. I'm sure you encounter this. That sounds really nice that we would be doing all of the good, correct ways of using computers but we're basically terrible and we could never make that happen here. Thanks for talking with us, we're going to go back and stew in our own juices of awfulness. You've got to pluck them out of that self-imposed cannibal pot there in the jungle and show them that they actually can improve and do things well. CHARLES: Would you say you feel like your job is being that person who shakes them away and can be like, "Good God! Get a grip on yourself!" MICHAEL: Sure. That's a very popular second or third slide in a presentation -- the FUD slide, the Fear of Uncertainty and Doubt slide where you're basically like, "Uber!" and then everyone just like soils their pants because they're afraid that are like Airbnb and Uber and [inaudible] and Google is going to come in and, as they say, disrupt their state industry. I try not to use the slides anymore because they're obnoxious. Also, most people in large organizations nowadays, they know all of that and they've already moved to putting on a new pair of pants stage of their strategizing. CHARLES: You've got the kind of the corporate wakeup call aspect of it but then it's also seems like a huge component of your job which is when you were at RedMonk, when

Balint Erdi: @baaz | balinterdi.com | Rock and Roll with Ember.js Show Notes: 01:58 - What is JSON API? Advantages 03:22 - Tooling and Libraries 05:49 - Relationship Loading 07:51 - Designing a Data Loading Strategy 11:23 - Pitfalls of Not Designing a Data Loading Strategy 13:53 - Ember Data 16:37 - Pagination & Sorting 23:06 - Writing a Book 25:48 - Implementing Searches with Filters 31:08 - What’s next for Balint? Resources: Balint Erdi: Data Loading Patterns with JSON API @ EmberConf 2017 (Talk) Balint Erdi: Data Loading Patterns @ EmberConf 2017 (Slides) jsonapi-resources GraphQL JSON API By Example by Adolfo Builes ember-cli 101 by Adolfo Builes 33 Page Minibook + Coupon Code! Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 65. My name is Charles Lowell. I'm a developer here at The Frontside. With me, also from The Frontside is Elrick Ryan. Thank you for being with us, Elrick. I know this is your first podcast. ELRICK: This is my first podcast. It's great to be here. CHARLES: All right. Fantastic. Yes, we hired Elrick a little bit ago and it's been fantastic. I'm glad to get you on. With us today is a really awesome guest. His name is Balint Erdi. I actually like to tell a little bit of a story when I have an anecdote and I do have one about you that I think you might like, although you might not even remember it. But it was shortly after EmberConf. Last year you and I got on a pairing session remotely and I don't even remember what we were working on but I was struggling with this way to decorate objects without changing them, without touching them or mutating them in any way and you showed me this technique of actually decorating it by creating a new object with the old object as the prototype. Do you remember that? BALINT: Yes. I totally knew. How could I forget? CHARLES: Yeah. That one hot tip changed my life. It is one of the best techniques that I have discovered in the last five years of working with JavaScript. It really was great and I use it all the time. BALINT: Wow. Amazing. CHARLES: Thank you. I don't know if I ever said, "Thank you," but thank you, thank you, thank you. BALINT: Yeah, no problem. I also learned a lot from this pairing session actually. I didn't know that my small contribution made such an impact. I'm glad to hear that. CHARLES: Yeah, that was fantastic. We need to actually make that happen again. I don't know why we only did that once. BALINT: Yeah, we should. CHARLES: Anyway, we're here to talk about data loading, it’s something that is absolutely critical to building good frontend and building UI and yet, it's something that the users never really see. Sometimes, it feels like it's 90% of the problem. BALINT: Exactly, yeah. ELRICK: Yeah, that's so true. CHARLES: We're going to talk about techniques that we use and you use and, in particular JSON API, what it is and what's so great about it. So, what is JSON API for folks who've never heard of it? BALINT: JSON API is a standard way to build APIs. I think the specification has reached 1.0, I would say two years ago or three years ago. I remember it was in June, I'm not sure which year. It basically lays down everything that's usually consider when you build an API: how do fetch relationships, how to paginate data, how to sort, all of these things that I think developers tend to invent again and again. I think probably the biggest advantage of JSON API is that it just declare a standard way to do that. It basically reduces the byte sharing going on at the start of the project. Well, not just at the start, later on too. In my talk at EmberConf, I coined a JSON API the conventional over configuration for APIs. CHARLES: I see. Pagination is something that everybody does. Why need to byte share over the syntax, like the actual data from it? BALINT: All of these things are things that everybody does. It's just that everybody does it differently. There's a lot of discussion going on which the best ways, for example when there's a team, at least every team that I was involved with had several discussions going on about what data formats to send data in and how to paginate and all these, I think details where it's more important to get to an agreement just to agree on something and move on than to get it perfectly, if at all there is a perfect way to do it. CHARLES: I guess my question is if you have the standard way of doing of everything, what kind of tooling can you build, that can you kind of inherit for free? At what level, both from the low level and then up to the top level? When I say top level, I mean what the user is seeing. BALINT: By low level, I guess you mean the actual libraries that implement JSON API in different frameworks, right? CHARLES: Exactly. Are there now a lot of libraries out there so whatever I'm using, if I'm using JSON API, is it available in a lot of different ecosystems now? BALINT: Yes. It definitely is. There is a full page on the JSONAPI.org, on th

Ginger Whalen: @gingerwhalen Show Notes: 01:28 - Everyone Does Sales 02:11 - Sales is an Exchange: Understanding and Solving Others’ Problems 05:58 - “Personas”; Empathy vs Sympathy 11:47 - Empathy Requires Introspection 15:12 - Persona Example 20:33 - Making Incremental Improvements 23:15 - Challenges in the UI Business Space 29:25 - TL;DR on the Business Development Process Resources: Thinking, Fast and Slow by Daniel Kahneman Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 64. My name is Charles Lowell. I'm a developer here at The Frontside. I'm here with Jeffrey Cherewaty. Hello, Jeffery. JEFFREY: Hey, there. CHARLES: With us today is someone also at The Frontside but not one of our developers. Her name is Ginger Whalen. Just to give you a little bit of backstory on her and why I'm so excited to have her on the podcast is we, about the middle of last year, began a search to bring someone on to help manage and grow and just have their eye on our business pipeline because that's something that's really, really critical, it turns out, to a software agency is making sure that we have clients. We put together a pretty extensive search plan and then we executed it and it was, I think about six months but in the end, we ended up hiring her. The reason we did was because she had a very unique take on what we would typically deemed the sales process so we learned a lot about it and I wanted to have her on the show so that we could just kind of share with our, I would say, mostly skewed on the technical side audience about what a healthy sales process might look like. Welcome, Ginger. Thank you for coming. GINGER: Thank you. My pleasure. It's so funny when people talk about sales and they say to me, "Oh, you're a sales person," I think that's so funny because I've never viewed people to be in sales and people not to be in sales. To me, everybody is in sales because all sales is to me is somebody just exploring somebody's problems with them and then when the time's right, you educate them and then you help them see the value of acting on some solution. Who doesn't do that? We all do that. CHARLES: We all do that. We do it in our day-to-day when we're proposing and discussing and talking about technical solutions, the same principle may be applied in a different level. GINGER: Yes, some people are just on the hook for it, that their professional goals are tied to that end game. CHARLES: Yeah. One of the things that struck me as kind of setting you apart when we were doing the interview process is the way in which, I want to say the focus of building those relationships and kind of the focus on understanding and understanding who exactly potential customers are and trying to categorize them and tailor our message so that we can actually maybe help them. Maybe you could explain a little bit about that. What's the front half of that process looks like? GINGER: That's kind of the bigger subject. I guess sales is the exchange, the educating and helping somebody solve a problem, get what they want to solve that problem. But if you're not speaking in their language and sometimes you hear the term 'knocked around personas' -- the persona you're talking to or the person you're talking to -- if you're not speaking in their language or addressing their pain, talking about their problems, it just so boring to them. It doesn't really seemed like it's going to solve their problem and you just don't hit the target right. You're probably not going make a sale in the end. That’s what we talked about when we first start talking with Charles and The Frontside team. We talked about personas, who are you approaching, what are their pains -- their business pains, their pains with their engineering team? What do they come to the table with and what would they like you to help them solve? The subject today, we're going to get into this a little bit later about empathy and then is really what it's all about is that gift of really understanding somebody else's experiences, somebody else's problems, their emotions and how we use that in sales as we're going to talk about a little bit more today. CHARLES: Yeah, I really like that because the drive there is to maybe not always shoot for a sale, to really try and understand like you said, someone's problems and just go out there and talk with interview, listen to a lot of different people and realized you're not going to be a good match for most of those people out there. If that's the case, not trying to view that as a potential opportunity that you want to just kind of force through but rather say, "How can I help this person even when it's not through my services and developing that and having this sales process?" because I think we tend to have a stereotype of what it is as being like I have a goal. When I want to interact with this person, what my agenda is actually to make a sale to them. It's clearly not like that. I think it varies

Saron Yitbarek: @saronyitbarek | CodeNewbie | Codeland Conference Show Notes: 00:32 - Codeland Conference and The Conference Experience 08:06 - Impostor Syndrome 15:32 - The CodeNewbie Community and Growing Junior Developers 20:06 - Dev Job Red Flags and Should-be Basic Requirements Resources: Codeland Volunteer Form The CodeNewbie Podcast Episode 60: Impostor Syndrome with Alicia Liu Alicia Liu: Overcoming Impostor Syndrome: Or How I Learned to Stop Worrying and Love Coding Alicia Liu: Impostor Syndrome Is Not Just a Confidence Problem: The dangers of becoming a buzz word CodeNewbie TwitterChat Transcript: JEFFREY: Hello everyone. This is Episode 63 of The Frontside Podcast. I'm Jeffrey Cherewaty, developer here at The Frontside. With me is Robert De Luca, also a developer at The Frontside. ROBERT: Hello, hello. JEFFREY: Our guest today is Saron Yitbarek. She's the founder of CodeNewbies and host of The CodeNewbies Podcast. Hi, Saron. SARON: Hey, how is it going? JEFFREY: Great. ROBERT: Pretty good. JEFFREY: You have a big event coming up, the Codeland Conference. Why don't you tell us a little bit about what's going on there? SARON: Yeah, I'm so excited for Codeland. It is our first CodeNewbie conference. I've done a good amount of speaking at different tech conferences all over the world for a few years now. Ever since the first one I went to, I thought, "We really need one for junior people, for folks who are just getting started," so I kept a running list of everything I hate about conferences and the things that I like about conferences. This is my chance to put it all to the test. It’s a two-day conference, single-track and the idea is really to get people excited about all the things they can do with code, especially for our community. The two types of jobs we generally hear about are working in a really, really small startup or working in a really big tech company like a Microsoft or a Google. But we don't hear about working at the hospital or working at the library or the many nonprofits who need technical help. The idea is to bring in people from all different backgrounds, walks of life, solving different problems and showing how code can be a really, really great tool for that JEFFREY: What are some of the things from previous conferences that you really like that you're bringing in Codeland? SARON: I like that you started positive. That's a good start. JEFFREY: We'll go for negative later. SARON: Yeah. [Laughs] Save the best for last. The stuff that I really like about conferences is the community part. It's being able to see a bunch of Twitter avatars come to life for the first time and being able to sit and talk. I feel like conferences are the only place where I can network without feeling gross and without feeling like I'm networking. I feel like I'm genuinely having real relationships and conversations. I think it's because we are going through this experience together and I can say, "Oh, did you hear that talk on this and that? It was so cool." It's a very organic way to start a relationship. That's probably one of my favorite things about conferences. ROBERT: There's a lot of ability in there for small talk about anything because there's so much going on. You could pick anything that you want and you're all experiencing the same thing and you're all kind of vulnerable. I love conferences for that reason. SARON: Yes, exactly and a lot of times, you're in a new city for the first time, you're staying in the same hotel, you're eating the same food. There's so many created and forced points of connection there for you so you can pick anything and start a conversation. ROBERT: Yeah, I really like that. I'm looking at the website right now and I see inspiring talks and it doesn't look like they're all exactly technology specific so I like to see the city life and health. That's super interesting. I want to hear a little bit more about that. SARON: Sure. I wanted to pick topics that are generally not covered as much in tech. Also, I didn't want to start from the technology. I think that a lot of people our community are very excited about the possibilities of tech and what they can do with it. We hear a lot of stories of people who say, "You know, I see this problem in my neighborhood. I see this problem in my community. I see this problem at work and I think that code is a really great way to solve it and to put together these solutions that I have in my head." The way that we're working -- and that's another thing -- you are working very, very closely with all of our speakers and we're starting from the problem space. We're starting from the users and then we end up in a place where the technology becomes the solution. I think that when you start at that more common, human, empathetic element, I think you are much more likely to bring people in, who may not feel as comfortable with the tech because the way we've kind of organized and thought through stuff is focu

Show Notes: 00:56 - What does UI mean? UI = User Interface 02:26 - Software Interfacing with Software vs Human Beings 03:57 - At what point does UI stop? 05:55 - Responsive and Stateful UI 10:10 - Tooling: Past, Present, and Future 16:00 - Planting Business in UI Engineering 19:26 - How The Frontside Brands Itself; JavaScript Portability Resources: Linguistic Intelligence Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 62. My name is Charles Lowell. I'm a developer here at The Frontside and I'm here today with Jeffrey Cherewaty and Robert De Luca, also developers here at The Frontside. We're going to do a little bit of navel gazing today. We're just going to talk about how we roll and who we are and because we've there's been a lot of conversations about that, as we had a couple of different projects come in that use different tool sets so what is it about us that is constant and what is it about us that changes? I just wanted to talk a little bit about that. The core idea is about UI. The shop has always been about UI and I'm curious for you guys, what does UI mean to you all? ROBERT: The frontend to the frontend? JEFFREY: That's a loaded question. CHARLES: Okay, let's step back a little bit from that because we've been in business for a long time and right now, we're doing mostly Ember, a little React. Before that, we were doing all Ember. Before that we were doing mostly Rails. Before that we were actually doing a little bit of wxWindows stuff and before that we were actually doing stuff in Java. But all of it fell under the rubric of UI -- user interface. What is constant? I mean, there's some radically different tools. When you look back and you think, "My goodness." What could possibly connect those things that I just listed? But I think there is a common thread so I wanted to explore that a little bit. JEFFREY: The common thread, I guess at the simplest level is always that in a lot of programming, you're dealing with the interface to the end-user of your code is simply text. It's a call-in response or they're consuming a library of yours that's where the code is the end product. What we focus on instead is the the end product of what we build is the interface as the graphic representation instead of a code or a text-based interface. CHARLES: I'm curious. In terms of all the software that gets written, how much do you think- because I think that's a key distinction. There are certain software that interfaces with other software. The connections to other software, there's a very unique set of problems when dealing with that. But there is also a different class of software where it's interfacing on one side with other software but on the other, it's interfacing with human beings. What proportion of software they get? How much of it is actually interfacing with human beings? How much is actually interfacing with other software? JEFFREY: I think the most software developers underestimate how much other human beings are interfacing with other software. Even if it is a simple HTTP protocol Rust type interface, it's still being used by human beings even if it's human beings writing code. CHARLES: That's true. There's definitely like a whole metalevel and that's like -- ROBERT: Like the developer experience versus user experience? CHARLES: Yeah but it's true. There's probably very few pieces of software where the ergonomics aren't important to actual people. That's true. There's definitely like a [inaudible]. JEFFREY: What you're getting at is that there's typically much more code underneath the surface than there is that actually is visible to a human. ROBERT: That makes it all work. JEFFREY: Exactly. CHARLES: Yeah. The part that's lying just beneath the surface is an ocean in of itself, I would say. It certainly seems like because that's the ocean we swim in it, seems vast at times. JEFFREY: Where does that UI stop? At what point does it stop becoming UI engineering and becomes more like API side of your server side? Obviously, you can say like, "Right when you start talking to an API. That's the end of it." But all of the code that goes on the frontend, the people refer to this as the frontend of the backend. All that code that is just there to get data and then massage that data so then somebody can go and present it to the user is at all UI at development. It's gotten a lot murkier in the last three years. CHARLES: Yeah it's a lot murkier because the thing is the way we structure our server technologies are changing so that they can support various interactions. For example, one thing that springs to mind is treating the data that we have inside of our client and I'm thinking of a browser tab, for example. Just one browser tab, one browsing session, you load data from the server and you write data back to the server but what we're seeing is that degrades the UI experience if you treat it just like that. I feel like the general trend is to treat the

Marcy Sutton: @marcysutton | marcysutton.com | Deque Systems Show Notes: 01:07 - Deque Systems 01:54 - Accessibility Tool Integration and Testing 05:26 - Configuration and Success Criteria 07:04 - What is accessibility? WCAG 09:22 - Spurring Adoption of Accessibility 12:09 - The Accessibility Matrix 16:56 - Accessibility-First Development 18:12 - WCAG and ARIA Roles 24:57 - Test Automation vs Human Interaction 28:56 - Empathy Building 30:45 - Porting to the Web 35:57 - Accessibility in Single-page Apps and Focus Management Resources: axe-core aXe aXe Developer Tools WCAG (Web Content Accessibility Guidelines) Web Accessibility for Designers WAI-ARIA Authoring Practices 1.1 First rule of ARIA use Access Works: Usability and Accessibility Training Marcy Sutton: Notes On Client-Rendered Accessibility a11y on Slack Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 61. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Mr Robert De Luca, a developer at The Frontside and today we have with us, Marcy Sutton who is going to be talking with us a little bit about accessibility, both in the large and the small. Welcome, Marcy. MARCY: Good morning, everyone. Happy to be here. CHARLES: I know, I understand you're actually calling us from the parking lot of a ski area. MARCY: I am at the legendary Mount Baker ski area outside of Bellingham, Washington where we have the winter that is just going on and on and on and getting after it on the last few days of my birthday vacation. ROBERT: Oh, wait. Happy birthday. CHARLES: Yeah, happy birthday. ROBERT: Happy belated or happy birthday. MARCY: Yeah, it was Sunday so still on that shiny birthday week. CHARLES: Well, thank you for getting with us on your vacation and on your birthday but doing a little bit of work, you actually work at Deque Labs. What is it that you guys do over there and what's your particular area of interest and work there? MARCY: Deque is an accessibility company. We have people who work on products and services for accessibility. We help people avoid lawsuits and make their websites and mobile apps more accessible to people with disabilities. My slice of that work is on the product team, where I work on browser extensions, APIs for developers. Basically to make it so you don't have to write every single accessibility tool or test yourself. You can pull in these APIs and get some of that experience that Deque has built up for years and years and years, which was part of the reason I went to work there was to learn from them. We make tools that make it easy for you to make use of that knowledge in your applications. ROBERT: That's awesome. It’s like a base JavaScript library that can be ported anywhere, like to browser extensions. I know we use it in Ember accessibility testing. That’s really cool. That’s where I've gone for the way I write JavaScript. It's in a base library so everybody can use it and it's even more awesome that it's testing and like wrapping tooling around accessibility because I know a lot of developer-minded people want to see like a failed built. CHARLES: Yes, what does that experience look like? I mean, coming from someone who's never even heard of these tools, how would I integrate them into my project and what would change about my workflow? What information would it surface? MARCY: The best place and the reason I work on these products is that I saw projects go out the door broken a lot of times, when working in agencies or maybe testing isn't part of your methodology. Personally in my career, I just knew there had to be a better way. I got into software testing and the more I learned about it, the more I thought that it was sustainable, you could pull in other APIs to help you write better tests. I went to work on axe-core, which is the JavaScript library that we've talked about a second ago. That really is bottling up all of these accessibility tests that you can automate some of the accessibility checks for things like if your HTML markup is in a good state and you're using attributes correctly. Basically, saving you from having to write all of those little microtests, some of which can be sort of complicated. It's all about getting test coverage for the automated things that we can actually test for. CHARLES: You described a pretty wide-ranging coverage. How do you go about actually implementing that into your CI process? Do you just install the axe-core? Do you have to load up your browser and then pointed it out? What does that look like? MARCY: Ideally, you would already have a test suite and you could just pull in the test harness. There's all different versions of aXe. There's versions in JavaScript and in Node. The core thing that you need to test is get your app running in a browser, whether it's a headless browser or could be a mounted browser but we need those actual DOM browser APIs to check things like color contrast. We need to be sort of coupled to the DOMs

Jonathan Jackson: @rondale_sc | Ember Weekend | 201 Created Show Notes: 01:01 - 201 Created 03:09 - 2017 Ember Community Survey 14:06 - Handling Changes and Churn 27:53 - FastBoot Resources: Boots and Shoeboxes [SlideShare] Typeform EmberConf JSX Isomorphic JavaScript Ember Weekend Episode #66: Bug Integrat (with Charles Lowell) Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 60. My name is Charles Lowell. I'm a developer here at The Frontside. With me is Robert De Luca, also a developer. Hello, Robert. ROBERT: Hello, hello. CHARLES: Today, we actually have a meeting of the podcast minds. We have with us a very special guest, Jonathan Jackson. You probably know him from the Ember Weekend Podcast. If that's your thing, it's a great podcast. I listen to it, you should definitely check it out. Hello, Jonathan. JONATHAN: Hey, how are you doing? I'm really excited to be on the podcast. I am an occasional listener. It's similar to my own podcast where if I don't edit it, I tend not to listen to it. It's when I have long trips you guys are number one, number two right behind The Adventure Zone which is a D&D podcast. CHARLES: You worked at 201 Created. Why don't you tell us a little bit about that? It’s an interesting company. JONATHAN: Actually, when we book to this podcast, I was not at 201 Created. This is a very new thing for me. I think I started right around the time of Ember Conference out in San Diego and I'm just realizing that this is not exclusively an Ember podcast. This is the first podcast I've been on where I can't just assume blanket knowledge of Ember stuff. But it's an Ember conference out in San Diego. I actually gave a talk there about FastBoot which is a server side rendering technology. Right after that, the entire 201 company which I think is four. It's very small. The entire thing, the whole crew went to do a company event and basically camped out in the mountains for a few days, which was really, really fun. But I started working there and 201 is a consultancy based out of New York but I think it's more than half is remote. I think Matt's on the West Coast, two of them are in New York and I'm in Jacksonville right now. We do a lot of really cool stuff. We worked in a lot of different companies. You can actually see the website at 201-Created.com and you can see the different clientele we worked with. But we specialized in consulting, training as well. As well as a couple of other services that we offer. It's been a real great experience. It's been very fun and also I'm learning a ton which is really cool to be in a different environment. I have done consulting for a little over four years, previously at Hashrocket. I got to tell you, consulting will get your wheels turning. It's been nice to see how different consultancy takes a stab at things. It's been super fun. CHARLES: Yeah, it's a fantastic company. I've definitely known them for a while, certainly through my involvement in the Ember community and one of the things that always struck me is just how seriously they take the community aspect of it. We were talking about just a little bit ago, it was 201 that sponsors -- well, sponsor isn't really the right word for it. It does the Ember Community Survey which I think is a practice that we're now used to in the Ember community but I think it's something that I would love to see wider communities do. Maybe you could talk a little bit about that and explain what this community survey is, why it exists and what's the knowledge that's derived from it and how do we take action on that? JONATHAN: 201 also does contribute workshops and things like that. The idea is to make Ember a more inclusive space, a place where people feel comfortable being a part of our community and a big part of that is self-reflection and realizing where you have weak points and how you can actually mend areas that are being neglected or whatever. Basically, shining a light to figure out where we need to improve and a big part of that is the community survey so figuring out what technologies are being used, figuring out what demographics are represented or under-represented and trying to figure that out. It’s actually been really cool. I think this is the third community survey and it's live right now. I feel like we could probably shed a little bit about some of the questions. This year, they did a really cool thing where they actually put all of the questions before they put the survey up live. They actually asked for a comment period which is very, very Ember thing to do. CHARLES: Because I was actually going to ask about that. Who is the final arbiter of the questions that get in because part of the survey is determining you're trying to get hard metrics on a set of questions but it's the questions that you don't know that you should be asking which are really the tricky ones. JONATHAN: It was really interesting to watch the document change over time. There was a committee discus

Show Notes: 01:11 - Doing Dumb Stuff aka “Throwaway Projects” 06:06 - Combatting Burnout 10:01 - Dumb Projects That Pay You Back 17:00 - Brainstorming and Abstraction 25:19 - chillestmonkey.com 20:19 - “The Iron Triangle”: Creativity, Accomplishment, and Learning Resources: React Native and Chill: A tale of stupid made fast by Charles Lowell Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 59. We're getting up there, 59. That's like, I don't know, it's not a milestone but it's something. ROBERT: It's like one away from 60. CHARLES: Yeah, it is. It’s past middle age. It’s like elderly. ROBERT: Start thinking about retirement. CHARLES: Yeah, exactly. JEFFREY: These are our golden years. [Laughter] CHARLES: Welcome to the golden years. ROBERT: All right. Possibly, we need to go and watch the Golden Girls. [Laughter] CHARLES: Actually, I think it was only five or six episodes, maybe 10 episodes, we were singing The Golden Girls theme so it all comes back around. We’re here with a very special guest and that guest is nobody. It's just folks from The Frontside -- JEFFREY: I was hoping you would say it was Betty White. [Laughter] CHARLES: We're going to fly it solo or like tri-lo or like trio. ROBERT: Trello? CHARLES: Trello. I, of course, am Charles Lowell. With me is Jeffrey Cherewaty and Robert DeLuca. Hey, guys. JEFFREY & ROBERT: Hey, what's up? CHARLES: We were kicking ideas around and something that's been kind of percolating around the offices is a theme for 2017 is doing dumb stuff, just stuff that has no apparent value but that you can learn from. I think, we each have a bunch of these experiences where we've done something a very little import that ends up being really, really helpful, either both in the short-term and the near-term. JEFFREY: And who knows, maybe this episode will turn out the same way. ROBERT: Oh, how meta. This could become a black mirror episode. I'm start to questioning my values. CHARLES: I know for me, I recently did some explorations into React Native, which I found to be very edifying. I could obviously talk about that experience quite a bit I did on a blog post but I'm curious, if you guys recently had something that was a throw away, something that you did that wouldn't really matter if it had come into existence or it didn't but it's just so happens that in this thread of reality, it did. ROBERT: You know, I have. It's always been centered around the impagination library that we wrote here. I was always kind of intimidated by impagination for some reason because it was this big library that I didn't necessarily understand. I was like, "You know what? I'm just going to go for it. I'm going to go do something dumb with it," and then I just decided to implement the most useless infinite scroll. It solved absolutely nothing and as you're paginating through 500 records of robots from Faker, I sat down and spent six days and wrote some code and implemented it React Native and it was actually the most informative and fun thing I've ever did. I don't feel tied to it. CHARLES: Yeah, so what kind of inspired to do that? Because usually, it feels like there's this pressure to ship something. Ship something is like just go build something but the idea is that you're going to build something that people actually might use. ROBERT: Yeah, I always had that idea. Maybe you can think about it as like feeling getting cornered, like the pressure of shipping sort of pushing me into a corner. Then eventually, I just kind of lash it out like, "No, screw this. I'm out." I'm going to go do something that's not even useful. I don't care. I'm not going to try and support people or make it to something that other people can use. If that is what falls out of this, that's cool but I'm going to totally sidestep and this needs to be something that other people can use. Sometimes, when I go to build a project, I start thinking, "This is going to be in my GitHub public profile. What if somebody comes and finds it? What are they going to think about my code?" And I just shed all of that fear away, then what happened is I learned a ton. After that experience, I was like, "Whoa. This is massively valuable." CHARLES: Yeah, like hearing you talk about it makes me think about one time I went to a Picasso art exhibit and they had all these sketches that he'd made just in pencil from when he was younger and they were in studies. I guess, apparently artists do this a lot where it was like just a goat's leg. Or some old man's nose. You know, just in pencil or charcoal and these are little tropes that he later integrated into all of his painting -- ROBERT: That is an amazing way to put. JEFFREY: It's funny. When you see engineering tutorials are like, "This is how you learn to make software." A lot of times that is the way they're structured it is around studies. Like, "Make this little tiny thing that by itself is worthless bu

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32 Show Notes: 00:58 - Going Into Business Using Rust 03:42 - Getting Paid to do Open Source 05:31 - Prototyping Projects in Rust 06:21 - Why Rust? (Benefits) 09:58 - The Language Server 14:52 - Error Messages 19:46 - The Rust Programming Language Book 23:35 - Crates.io 27:41 - The Backend 31:11 - Working with Rust and Ember Together 33:31 - Rust Belt Rust Conference 35:59 - Integer 32 Resources: The Rust Programming Language Book The Frontside Podcast Episode 51: Rust and APIs with Steve Klabnik Rust For Rubyists Working Effectively with Legacy Code by Michael Feathers Clippy Cargo rustlings Python Koans Rust - exercism.io No Starch Tokio Diesel Rocket Nickel Iron Pencil Rust Belt Rust Conference RustFest.EU RustConf Transcript: STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols. CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol? CAROL: I'm great. Thank you for having me on the show. CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust? CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out. We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We’ve got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services. One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We’ve done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We’ve also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like. One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We’ve had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community. CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help? CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library. CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping? CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We’re not going to come in and rewrite the whole project. We’re going

Liz Baillie @_lbaillie | GitHub | Blog | Tilde Inc. Show Notes: 01:32 - Becoming a Developer 07:54 - Website Building 12:03 - Understanding Programming 17:34 - Coming to Peace with Ignorance 22:25 - Systems Programming 26:46 - Making Goals for Yourself 28:57 - Math and Programming 38:08 - Open Source Resources: Wicked Good Ember Liz Baillie: Journey to the Center of Ember Test Helpers Fibonacci Number Freewheel: Volume One by Liz Baillie The Flatiron School Skylight Impostor Syndrome Twilio Letter to a Young Haskell Enthusiast Hello, Con! OSCON Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 57. My name is Charles Lowell. I am a developer here at The Frontside and with me is Stephanie Riera, also a developer at The Frontside. Today, we have with us Liz Baillie, who is a developer at Tilde. I am actually really excited to have Liz on the show. I saw her at Wicked Good Ember back in June of 2016 and her talk was definitely one of the more memorable ones. You come away from a conference kind of only remembering a certain number of talks that stick in your mind and as time passes, the messages may fade but some of the message just stick with you and the one I got from her talk was a feeling of empowerment that, even though I have a lot of experience, I could approach any code base and try and grapple with it and understand it. I came away thinking, "There are a lot of code bases out there that I don't understand but if I apply a certain set of techniques and a certain level of fearlessness, I will actually get there." You know, if I want to go attack something like I don't know like Kafka or something like that, I would feel better about that. That was actually a great feeling coming away from that, a feeling of great power so thank you very much for that, Liz. LIZ: Yeah, no problem. CHARLES: Why don't we start with a conversation of how you came to be a developer? Everybody’s got kind of a unique path. What's yours? LIZ: Well, I went to art school and I studied comic books. I actually have a bachelor's degree in comic books. I was a cartoonist for a number of years and at some point, maybe like 10 years ago, I had a friend who was a programmer. He’s a web developer. But I didn't even what's a web developer was. But I knew he worked at home and he made his own hours and he made a lot of money. It seemed like an awesome job so I was like, "How did you get into that?" And he's like, "I don't know. I just kind of mess around and figured it out." And I was like, "Uh... I don't know what that means." Like how do you start? I have no idea. I went to the bookstore and I look at the For Dummies books and I got Programming for Dummies or something and it was like Visual Basic, I think. CHARLES: All right. What year was this? LIZ: That's 2004. I guess, it was a little more than 10 years ago. But it didn't say that on the cover. It was like 'Programming' and I was like, "Oh, cool. I'll learn programming." I don't even know what the difference of languages was or anything like that. I did a couple of exercises in that book and I had no concept of how this would become a website ever. I was making 'Hello, World' and little things that spit out Fibonacci numbers or whatever. I kind of gave up on that and I was like, "I don't care. I don't mind being poor." I'm used to it so I kept being a cartoonist, putting out books and stuff. I did a little PHP and HTML type of stuff in making websites for myself in between but I don't really consider that programming. It didn't feel like programming. CHARLES: Did you ever put any of your cartoons on the web? LIZ: Oh, yeah. Google me. They're there. [Laughter] LIZ: I might have some stuff like my web comic, I'm not sure if it's still up. But I had a web comic called Freewheel, which was about this girl who runs away from home and joins a band of magical hobos. CHARLES: That sounds like a career change to programming. It was oddly prophetic. LIZ: Yeah. It’s out there. Anyway, I got to a point where, long story short, I was tired of being broken for all the time and I have to figure out some way to make money that I like doing so I thought, "I would go back to school," so I went back to school. I didn't start out with computer science but I took some math and science classes and I got really into math a lot. I really enjoyed math so I started looking into what careers can I do that are math-y. Somebody said, "If you enjoy the problem solving aspects of math, you'll love computer science," so I took a Computer Science 101 class or something like that and I got really, really into it like I just killed it. I just loved it. It was awesome. But I still didn't understand how you made that a website. In the back of my mind, I was like, "We did this thing --" We learned Python in my class so there's some program we had that like move a little turtle around and do pictures or

Philip Poots @pootsbook | GitHub Show Notes: 00:53 - What is Elm? 03:45 - The Essence of User Interface 07:59 - “Messages” 08:31 - Scalability 14:04 - Error Handling 18:47 - The Business Case 22:35 - Where is Elm on the curve of scalability? 28:36 - Learning From Elm 32:32 - “Whole Meal Solutions” Resources: Philip Poots: Elmber @ Wicked Good Ember 2016 Cycle.js Functional Reactive Programming Evan Czaplicki Test-driven Development (TDD) NoRedInk The Elm Mailing List Try Elm Elm Guide elmtutorial.org Elm For Beginners by James Moore Transcript: CHARLES: Hello, everybody. Welcome to The Frontside Podcast Episode 56. I am Charles Lowell, a developer here at The Frontside. With me is Jeffrey Cherewaty, also a developer here at The Frontside. JEFFREY: Hey-o! CHARLES: We're going to be talking today with Philip Poots, who is a fantastic individual, who I have known over the Twitters, over the e-mails, interacted with at conferences, seen him speak on at least one occasion and today we're actually going to be talking about the thing that I saw him speak at Wicked Good Ember last June. It was actually one of my favorite talks from that conference. It was on Elm for Ember developers. Thank you very much for being on the show, Philip. Why don't you tell us a little bit about what Elm is and how you came to find out about it and really kind of dive deeply into it? PHILIP: Yeah, sure. First of all, pleasure to be on the show. The Frontside is one of my favorite podcast, if not my favorite, given a cross-section of the Dadcast, the love of programming and balancing that with the business of programming. That’s right, I'm an independent developer. I started off with Rails then got into the Ember quite early on. Last year, I think around January, that's when I started really investigating Elm in detail. It's actually a funny story how I came about because I was at Ember Amsterdam and it was a night where we had three members of the core team: we had Erik Bryn, he gave a talk, Alex Matchneer, gave a talk and Igor also came over because he's based in Europe. Alex always loves to investigate new things and one of the things he was getting into was Observables. I'd never heard about Observables at all so after the talk, I kind of pulled him aside and I asked him some very stupid questions. He was gracious enough to bear with me and to dive a little deeper into this stuff. Alex is kind of a quiet member of the core team, unless he's got his drum sticks but he's the guy that rewrote the [inaudible]. That was no mean feat because I got into Ember just before that moment and the way he managed to make that incredibly easy was fantastic so I kind of had an extra ear open to what he had to say. I went on this Observables talk. You know, you start off with React that was the framework that was using Observables the most. That brought me to Cycle.js -- CHARLES: Cycle.js? I haven't heard of that. Is Cycle.js a framework built on top of Observables? PHILIP: It is. There’s a guy called André Staltz or André Medeiros but he uses Staltz as his name. It’s largely based off the same principles as React. Cycle, basically one of his inspirations or at least one of the things which cycle is most like was the Elm architecture. He calls it Model-View-Intent. We have Model-View-Controller and Elm was model update view but essentially, the same principles. You know, I'm the kind of guy that likes to get stuck in, to go deep and where I started with Observables then I ended up at Elm. I started playing around with that, I started looking into it and I loved what I saw. The thing above all that really attracted me to it was the pure simplicity of what was going on. It was almost like they boiled down the UI paradigm to its essence and removed all the extra cruft and you just saw what you meant what you wanted and it gave you these, what I thought at the time, composable way to put things together. CHARLES: Can we unpack that just a little bit? I really love that idea of it boiled down to the essence of UI. I assume there are certain coordinating mechanisms that Elm employs. It’s interesting to hear you say that Cycle.js has used Elm as an inspiration. I also understand that Redux is inspired also by the Elm architecture. I'm very curious, what are those kind of essential mechanics that drew your attention? PHILIP: I think you can look at it from two points of view. The first is, which I didn't actually learn until later but the first is essentially boiling down functional programming. You’re decoupled, you're using functions and not only functional programming and there's a lot of arguments over this term but functional reactive programming. The idea of functional programming is stateless. Therefore, time is kind of the beast that you have to deal with. But FRP, then essentially boils time into the concept of values that can change over time so you have a reference to one value but in JavaScript that's an Observable. In Elm, in the beginning, when

Toran Billups @toranb | GitHub | Blog Show Notes: 02:23 - Ember 2.0; Data Down, Actions Up 08:28 - redux and State 16:39 - Dispatching Actions/Patterns 24:00 - Components and Routing 31:00 - ember-redux and Cloning the react-redux API 35:22 - Hot Reloading 41:22 - Audience 47:02 - Motivation 50:25 - Building Component Trees Resources: Toran Billups: Test-Driven Development By Example @ EmberConf 2015 Dan Abramov: Live React: Hot Reloading with Time Travel @ react-europe 2015 react-redux Charles Lowell: Immutability is for UI, You and I @ EmberConf 2016 redux-thunk Ryan Toronto: Safety of the herd EmberMap: Component side effects Functional Programming Browserify More Toran Billups Talks Transcript: CHARLES: Hello everybody. Welcome to The Frontside Podcast. This is Episode 55. We're broadcasting and everybody's here in Austin, although we're still remote. I am here with a really special panel today. There's me, which makes it special by default. My name is Charles Lowell. I'm a developer here at The Frontside. I'm also here with Robert De Luca, who also develops JavaScript codes at The Frontside and we have today [drum roll sound] -- I'm really, really going to work that drumroll -- Toran Billups. What's up, man? TORAN: Hey, man. Thanks for having me. I'm really excited to be here. CHARLES: Toran is with us today and he's going to be talking about a lot of things. He’s going to be talking about today mostly about Redux and his efforts to meld Redux and make it useful within the Ember community. But first, if you have not heard of Toran, I think the first time we'd interacted over email, Slack briefly but then when I really, really saw you for the first time was at EmberConf, I think in 2015 and he just gave the most amazing talk on Test Driven Development and really kind of the focus on you can set up your acceptance tests from the outside into really define that behavior and set out that firm shell and then actually build your application from the outside in. You’ve really kind of been talking about that message. We like to have people on here who all about walking the walk. That’s certainly the first thing that I've noticed that you were doing in the community but then more recently, you've been playing with Redux. Not playing with Redux, actually making a concerted effort to bring this kind of pattern into Ember. I just wanted to start out, how did you jump onto that track? TORAN: Some months after EmberConf in 2015, as you mentioned that talk was not only, probably the most well-rehearsed talk I've ever given but definitely the most well-received. I got a lot of people excited and really gave me a lot of opportunities that weren't there before that was also believe in that keynote in 2015 as when Ember 2.0 was announced. The interesting part of Ember 2.0, of course was we were using it, and it was called Ember 1.13, which actually made it really great. At the time, I was very much excited about the stability that offered. Other folks were not as much as interested in that idea or those values, in the JavaScript community so it's really exciting. Yet at the same time, there was this new mantra that was being talked about more that I knew nothing about. It was this 'data down, actions up' idea. I still remember as much as the stability was awesome, I also started to doubt not Ember core in particular but the ideas that were being espoused by other folks around the Ember core team because I didn't really understand the value. For instance, if I had the tree of components back then in early Ember 1.13 or 2.0 days and I had an Ember model or some kind of Ember object at the bottom of this tree, why would I not just do Ember.set. I remember, actually you may recall conversations you had with people at EmberConf around that time but there was actually varying definitions of what 'data down, actions up' meant to different people and actually never met the same thing to anyone. It was funny enough. Because of that, it sort of drove this fear in me that I didn't know what I was talking about. I was consulting at the time so I wanted to sound like I knew what I was talking about as you probably should. You guys are in that business so you know what I mean. Because of that doubt, eventually I sort of become apathetic to really trying to understand better what 'data down, actions up' meant or how components should be constructed and really what the wider impacts of Ember 2.0 meant. Because of that, I just found myself, not really loving learning. I felt like everything else in learning was a hyped up thing that would never happen or a hyped up thing that I didn't really understand or didn't make sense in the context of Ember at that time so I just kind of floated by. Everybody has their ebb and flows in the journey of excitement or not. For me, this was just the down moment. One of the things, like an analogy to this is when you lose your hunger in real life, you'd be very much like losing your hunger for learning.

Katie Gengler @katiegengler | GitHub | Code All Day Show Notes: 01:23 - Testing 06:20 - ember-try 14:11 - Add-ons; Ember Observer 17:43 - Scoring and Rating Add-ons 25:25 - Contribution and Funding 27:41 - Code Search 30:59 - Data Visualization 32:27 - Change in the Ember Ecosystem Since Last EmberConf? 34:35 - Code All Day 35:39 - What’s Next? Resources: ember-qunit liquid-fire capybara Selenium appraisal emberCLI Bower Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 54. I am your host, Charles Lowell, with me is Alex Ford. Today, we're going to be interviewing Katie Gengler. I remember very distinctly the first time that I met Katie, it was actually at the same dinner, I think that I met Godfrey at EmberConf in 2014. That was just a fantastic conversation that was had around the table and I did not realize how important the people that I was meeting were going to be in my life over the next couple of years. But Katie has gone on to do things like identify a hole in Ember add-on ecosystem so she created Ember Observer. There's a huge piece missing from being able to test this framework that spans multiple years and multiple versions and being able to make sure that your tests, especially for add-on authors, run against multiple versions so she created and maintains Ember-try. She's a part of the EmberCLI core team. She's a principal at Code All Day, which is a software consultancy and just an all-around fantastic woman. Thank you, Katie for coming on to the show and talking with us. KATIE: Thanks for having me. CHARLES: One of the things I wanted to start out the conversation with is something that's always struck me about you is there's a lot of people when it comes to testing, they talk the talk but you have always struck me as someone who walks the walk. Not just in terms of you make sure that your apps have tests in them, where your add-ons have tests in them but talking to people about testing patterns, making sure that when there are huge pieces of the ecosystem missing like Ember-try. I remember this as something that I struggled with. I was running up against this problem and all of the sudden, here comes Ember-try and you've been such a huge part of that. I want to know more about kind of your walk with testing and how that permeates so much of what you do because I think it's very important for people to hear that. KATIE: I got really lucky right out of college. My first job was at a place that where people think of mythical themes, XP-focused developers so the first thing I was told is everything is test first, everything is test-driven. I was primarily doing Ruby in Rails at the time but also JavaScript. At the beginning, we didn't have a way to test JavaScripts and there was a lot of missteps in the way of testing JavaScript until we came right around to QUnit. I was QUnit long before Ember even came along. It's kind of bit ingrained in my whole career. Michelle as well. Michelle is my partner in Code All Day. We’re both very test focused. I think that's what drew us to start a company together and working together. Every project we're on, we try to write encompassing tests: test drive everything, if we're on it, projects upgrade or any project to fix. We try to write tests as a framework for everything that we're doing so we know whether we're doing something right or not. When it comes to Ember-try, that wasn't entirely my own idea. That was something that Robert Jackson and Edward Faulkner were looking for something right. I remembered that appraisals gem from Ruby. I really enjoyed being [inaudible] gems that I had written Rails so I wanted it to exists for Ember so I just kind of took a promise of to do it. It was extracted from Liquid Fire. I had some scripts that would sort of test multiple versions but it was rough. It wasn't as easy as it is today. CHARLES: Yeah, it does speak to a certain philosophy because if you're coming to a problem and it's difficult to test, you often come to a crossroads where you say, "You know what? I have a choice to make here. I can either give up and not write a test or trying and test some subset of it," Or, "I can write the thing that will let me write the test." It seems like you fall more into that second category. What would you say to people who are either, new to this idea or new in their careers and they butt up against this problem of not knowing when to give up and when to write the thing to write the test. KATIE: I almost never don't write the test so if you're suspicions are true, I will write something to be able to write the test. But there are times that I'm [inaudible] and sometimes I'm just like, "This is not going to be tested. This is not going to happen." Finding that line is pretty hard but it should be extremely rare. It's not when people come to me, I work with a client and they're telling me, "No, it's too hard to write the tests." A lot of times, it's not on

Godfrey Chan @chancancode | GitHub | Tilde Inc. Show Notes: 02:27 - What is Glimmer 2? 11:24 - Key Changes for Glimmer 2 12:54 - How do these libraries (i.e. handlebars.js; htmlbars) work together? 18:02 - Maintaining Compatibility 24:38 - Components 27:55 - Looking Forward to Non-Performance-Related Features 34:43 - Animations and Visualizations 39:09 - Glimmer 2 For an End User 41:33 - Stand-alone Glimmer? 46:12 - What are the performance gains on mobile? How does it better position Ember for mobile devs? 49:23 - Bubble Tea 50:37 - Contributing to Glimmer 2 Resources: Godfrey Chan: Hijacking Hacker News with Ember.js @ EmberConf 2015 Announcing The Glimmer 2 Alpha Isemberfastyet The Quest Issue (#13127) D3.js EmberConf Yehuda Katz & Tom Dale: Opening Keynote @ EmberCamp London 2016 TypeScript Ember Community Slack Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 53, brought to you by The Frontside where we engineer user experience that is just so. If that's something that you're interested in, please feel free to reach out to us on either Twitter or at contact at the Frontside.io. Today we have a really fun episode. Again, we're second week in a row, we've got a nice fat panel. Jeffrey Cherewaty and Chris Freeman, who are developers here at The Frontside and we're also here with Godfrey Chan. Just a little bit of background on Godfrey, from my perspective, I remember very distinctly back in EmberConf 2014, I went out to dinner and I sat across from this guy who was the organizer of the Vancouver Ember Meetup. Was it Vancouver? GODFREY: Yeah, that is correct, Vancouver, BC. CHARLES: Yeah, Vancouver, BC. You know, I was struck at the time and I was like, "Wow, this guy is really smart and insightful and actually making me laugh a lot." GODFREY: You're very kind. CHARLES: I don't know if you remember that but that was borne out at the next EmberConf in 2015 where he gave this fantastic talk on the power of Ember Data's adapter and serializer layer, where he repeated the same trick except at scale in front of the audience. I think we were all rolling in our chairs with laughter but also learning a lot about this really, really powerful pattern and you had written serializer and adapter layer to basically build without a back end at all, a completely new UI for Hacker News. It was really a fantastic talk. Since then, you've just been going on to do a bunch of other great things: you joined the Rails core team, the Ember core team, and most recently, it sounds like the major thrust of what the last year or so has been giving birth to Glimmer 2, which is the next generation of the rendering engine in the Ember.js framework. It’s a really fascinating topic. Thanks, Godfrey for coming on and talking with us about this. GODFREY: Thank you for having me. CHARLES: Yeah, it's a huge deep topic so we're just going to scratch the surface. Obviously, can't cover a year of life in just under an hour but we're going to do our best. Why don't we talk just a little bit about what Glimmer 2 is? For our audience members who are deeply involved with Ember community, it probably is not going to come as a surprise but we actually do have other listeners. What is it and why is it important? GODFREY: Like all good software, Glimmer 2 was basically born out of an accident. Glimmer 2 on a very high level is the new rendering engine for Ember. That's pretty vague but I guess, we'll go back a little bit in terms of the timeline and maybe that would become more clear. The time frame was pretty much when I first joined Tilde, we shipped 1.14 for a while and we just about to ship 2.0. That’s when the original Glimmer planned it. That year at EmberConf, I believe it summer of 2015, like Tom and Yehuda talk about this new Glimmer thing on stage that has promised to basically renew the Ember programming model to better match the data down, actions up paradigm as opposed to very reliant on to a bindings and stuff like that. On one hand, it gives you better programming model and on the other hand it's promised to be much faster at rerendering. It’s more or less inspired by React so you can just treat your component as if it's refreshing a page on a server-rendered HTML or something like that. You can just update your data and then rerender a component and that's going to be efficient enough that you can just basically rely on that as the main fully-rendered model. That ship in 1.14, for most part it was great so we were planning to start working on the next thing and at that time, the plan was to work on rehydration. If you're not very familiar with it, it's basically the next iteration of FastBoot where today when you have a FastBoot render page, when it goes [inaudible] has to then download JavaScript the data and rerender the page basically for the DOM then re-insert the newly rendered content into the page. There are several problems with that. First of all, it's a lot of wasted work because

Lydia Guarino @lydiaguarino | data.world | GitHub Shannon Byrne @s_byrne | Blog | GitHub | [email protected] Stephanie Riera @stefriera | The Frontside | GitHub Show Notes: 01:23 - Emberitas 02:50 - Developing Curriculum For Women By Women 10:16 - Pairing People Together 12:14 - The Volunteers and Support 18:42 - Getting Women to Attend Meetups 23:20 - Icebreaking Exercises 27:42 - Takeaways From the Event 33:35 - The Future of Emberitas 36:10 - Favorite Parts of the Event Resources: @iheartemberitas Ember ATX Women Who Code The Iron Yard Tilde Women Who Code Austin Slack Community We Speak Too ember-women Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 52. We're coming to you live from Frontside HQ where we can help you zero in on that precise experience that you want for your users. So, if that’s something that you're interested in, go ahead and reach out to us at Frontside.io. Today, actually we got a pretty large panel today. It's a hardcore Austin posse - Lydia Guarino, Shannon Byrne, and Stephanie Riera. And we're going to be talking about kind of a passion project of theirs called Emberitas. We're going to be digging deep into it. But before we get into that, I want to introduce everybody. Lydia is a product engineer at Data.World which is a social network for your data. It's actually a really cool startup where you can go and you can upload your data and you can see other public data sets and slice and dice them. It's really cool. Shannon, who has been a developer since 2013, is kind of in the startup scene and been ubiquitous certainly in the circles that we've run in here in Austin. And so, her latest gig has been as a code school instructor teaching JavaScript and Ruby on the full stack. And of course, you’ve heard Stephanie on the podcast many times. She's a developer here at the Frontside. Without further ado, let's talk about Emberitas. What exactly is Emberitas and how did it get started? SHANNON: Emberitas is a 1-day 2-track workshop for teaching Ember to women. Last year, what was it? Like April maybe of last year, or maybe March, we were at an Ember ATX meetup. Brandon and Charles were talking about how to get more diversity into the Ember meetup. And then, of course, Lydia and Stephanie and I, as sort of the token ladies of Ember ATX, kind of huddled in a circle and we talked about how other communities in Austin were doing things. And of course, there's Rails Girls which is a 1-day workshop to teach girls programming through a little bit of Rails. We were like, "Why not do the same thing with Ember?" And so, after that, we just kind of picked up on everything, split up a lot of the work, decided we were going to do it, and made it happen. And we hosted our own 1-day workshop for teaching women who had no knowledge of coding some of the basics of HTML, CSS, and JavaScript through Ember. And then taught other women in town who maybe were using Angular or had some experience with Rails or whatever, but didn’t know what Ember was, the basics of Ember, so that they could then take that back to their companies and make more Ember jobs for all of us. CHARLES: For someone who's worked on trainings before and tried to develop them, how challenging was it to develop a curriculum for women -- literally, all spectra of experience with development. It sounds like a difficult task. And I'm curious what considerations did you take in when you were developing this curriculum and what did it encompass? LYDIA: One of the things that we did to make that a little easier on ourselves is we split the workshop into two tracks. We had a beginner track and then we also had an intermediate track. Shannon ran with the intermediate track and I ran with the beginner track with an understanding that for beginners, there's a lot more discussion about some of the basics of web development in general or how you think of a project and how you start with the basic building blocks of HTML and CSS, and then grow into building an application. For the beginner course, what I wanted to focus on was taking those basic building blocks and showing how they can be converted into an application. We actually started with making static web pages and then converted those gradually in pieces into an Ember application. Ember actually makes that pretty straightforward to do because there's such strong conventions that there's obvious places to put all of that information. So, we built everything in HTML and CSS, and then we came back and layered on Ember on top of that but the project was the same in both scenarios. And I'll let Shannon talk a little bit about how she approached the more advance course. SHANNON: For the intermediate course, one of the challenges was that it was very open as to what that would mean. It wasn’t intermediate Ember; it was an introduction to Ember for anyone who considered themselves a developer. So we had some people who came in and they had a little bit of Jav

Steve Klabnik @steveklabnik | Blog | GitHub Show Notes: 02:56 - Getting Into Rust 05:51 - Working on Rust for Mozilla 07:01 - Writing Documentation and Preventing Burnout 13:24 - The Rust Programming Language 18:45 - Rewriting Firefox in Rust 21:20 - High-level Functions 25:23 - Typesystem and Concurrency 36:35 - Rust and Web Developers; Digging Into Rust on a Deeper Level 43:46 - The Rust Ecosystem and Using Rust on a Day-to-Day Basis 48:38 - The Rust Book Resources: Rust For Rubyists Cargo Servo Application Binary Interface (ABI) MetaLanguage (ML) Tokio Systems Programming intermezzOS Steve Klabnik: Exploring Ruby Through Rust What’s new with “The Rust Programming Language”? rustbook Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 51. I'm here, my name is Charles Lowell. I'll be hosting today. With me is Chris Freeman, also of The Frontside and with us is Steve Klabnik. Now, most of you probably heard of Steve before. My first encounter with Steve was actually at the LoneStarRuby Conference back in... Gosh, I don't know. It was many, many years ago and he was giving a talk on Shoes, which I also had never heard of before. It was a wonderful story of a code archaeology project where he was kind of investigating, rehabilitating, and in carrying forward a project that the 'why the lucky stiff' had done. That was a wonderful introduction but it was certainly not the last time that I encountered him in his writings and in talks and stuff, mostly within the Ruby community. But it popped up again and again, talking about Rust APIs and always making a point to take a good knowledge that he'd learned and spread it around. Personally, I've lost track of Steve or hadn't really heard much of what he was doing for a while. But then Chris came into the office and he was always talking about this language called Rust. While I've heard Rust, Chris was just all about it and wanted to have Steve come on the show because it turns out that Steve, you've been really, really, really into Rust these last few years and sounds like concentrating most of your work there. STEVE: That is totally true and accurate. Also to go back a bit, that means that you are in attendance for my very first conference talk ever. CHARLES: Really? STEVE: That was literally the first one. CHARLES: Wow, it was a great start. That was a great story. It was educational and also touching. STEVE: Thank you. It's actually interesting because what happened was is that someone else who works on Shoes have encouraged me to submit to RubyConf and I was like, "Who would want to hear me talk at a conference?" I submitted the talk and RubyConf accepted it and I was really excited. Then a bunch of other conferences noticed and two other conferences had asked me to give a talk before RubyConf happens and LoneStar was one of them and it was the first one chronologically. That moment was also very special to me as well. CHARLES: Fantastic. What year was that? STEVE: I want to say it was like 2012 or 2011. It’s really hard for me to pay attention to time and date. My history is so complicated that I often forget. I've literally told people that I'm 10 years old or younger than I am because I would like mess up to date on the things. It just happens. CHARLES: Yeah, but it was a while ago and it's been quite a journey, in between now and then. STEVE: Yeah, definitely and you're also definitely right. It is now literally my day job to work on Rust so it is definitely the focus of most of my efforts. Partly, why I made that happen was because it was the focus of all my hobby efforts before I made my job. It’s definitely been a couple of years that I've been a full-time on all the Rust stuff. CHARLES: How was it that you actually got into Rust? How did you hear about it before everybody else and how did it capture your attention? STEVE: I've always liked programming languages and learning different programming languages. Ruby was sort of where I became known professionally. But it wasn't the first language that I knew and I knew it was never going to be the last. As much as I always loved Ruby and I'm like literally have a tattoo on my body so I will be with Ruby forever. I always try to learn new stuff and I find it exciting. I'm from middle of nowhere, Pennsylvania in the suburbs of Pittsburgh on a cattle farm and I was visiting my parents for Christmas one year. There’s not really a whole lot to do out of the very small town so I was just reading the internet, as usual and it turns out that that was the day that Rust 0.5 had been released. I saw this release announcement go by and I was like, "I vaguely heard of this programming language once or twice maybe. I don't have anything to do. Let's give it a try." I downloaded and installed it. I looked at their tutorial and the tutorial has a problem that a lot of tutorials had, which is I read it, I said, "This all makes sense," I tried this down to write a prog

Kyle Simpson: @getify | Blog | GitHub | [email protected] Show Notes: 04:19 - Styles for Learning as a Newcomer 08:41 - The Structure of the Journey “If you’re waiting until you’re already an expert on a thing to share it with somebody else, you’ve waited far too long because we missed out on the most important part which was the journey.” 12:52 - Understanding a Problem vs Solving One "I want to inspire people to be uncommonly curious." 29:02 - How do you know when to stop? 35:02 - Knowing Math and Learning Programming 43:40 - The Importance of Mentorship Resources: LABjs The JavaScript Austin Meetup Pedagogy Saron Yitbarek (CodeNewbie): I don’t belong in tech: Trying to find my place in the place I love, and constantly failing Dr. Seuss' The Sneetches (Star-Bellies Reference) Big O Notation You Don't Know JS: A Book Series Functional Light JavaScript Kyle's Frontend Masters Training Videos Transcript: CHARLES: Hey, everybody and welcome to the Frontside Podcast episode 50. I'm your host, Charles Lowell. With me, also from the Frontside, is Stephanie Riera. And with us today is a very special guest, Kyle Simpson, a fellow Austinite. We're going to talk about education and teaching JavaScript. You hear this name everywhere you go. I remember when I first moved to Austin, back in 2009, I moved back to Austin, I went to my very first JavaScript Meetup and there was this guy sitting there doing some live coding on this crazy thing called LABjs which was just like mind-blowing stuff that was going on that was doing crazy on-the-fly modules floating. And this was like back in 2008/2009, so awhile back. And that was my first experience. And then just moving inside tech circles, he just like popped again and again and that’s just like the story. It seems like Kyle is like ubiquitous. I was at Clojure Conf last weekend and one of the speakers actually gave a shout-out to Kyle Simpson. So, I don’t know Kyle if you do much Clojure, but you definitely have an impact, an outsized impact in the JavaScript community and outside the JavaScript community at large, all throughout tech. It's really a pleasure to get to have you on the show. So, welcome Kyle. KYLE: Thank you so much. It’s a huge honor to be here. I'm glad to be doing this in our home city of Austin. It's fun to actually get a chance to pull again with the Austin community because a lot of my work takes me on the road. I sometimes joke that I know more about JavaScript communities in other cities than in my own since when I'm home, I'm usually with the family. And when I go to meetups, it's usually in other cities. But it's fun to be here. It's interesting you bring up that JavaScript Meetup, the original Austin JavaScript Meetup. It started in January of 2009. Actually Joe McCann, most people will know that name. He's kind of a rockstar in the Node community and one of the founders of NodeSource. I think he's up in New York City now. But he started the Austin JavaScript Meetup in January. February, I started kind of came on and we ended up kind of tag teaming running that meetup for the next couple of years. In the early days of that, you're talking about LABjs, I remember that was summer of 2009. The early days of starting up a meetup when you have 5 or 6 attendees on a really good night, mostly consists of about a week before the meetup, "Oh, we don’t have a speaker. One of the two of us has to figure out something to speak about." So, I would often kind of take on that task and I would say, "Okay, what's something I'm interested in," or, "What's a library I could write that I could talk about something when I was coding?" CHARLES: So that actually born out of the need to actually present something at the Austin JavaScript Meetup? KYLE: Yes, actually LABjs, it was something at work at that time that I was trying to solve but I wasn’t really making a library out of it. It was just some code that I was toodling around with. I was like, "Wow, crap! It's 3 days before the meetup. I better come up with something to talk about." So I wrote the very first version of LABjs to present at that meetup and I got a bunch of good feedback from people that were looking at it and saying, "Oh, that’s cool." So I kind of ran with it. That’s literally my first kind of major open source project. Most people probably originally heard of me if they’ve been around the tech world for a while, they originally heard of me because of that one. CHARLES: Wow! I had no idea I was there. KYLE: You were there for the origination. I was the unveiling to the world of LABjs. CHARLES: It's like the Woodstock of JavaScript. KYLE: Those were some early days of meetup stuff. You're like pick up a pizza and a couple of beers from the store on the way to the meetup and there wasn’t a lot of organization but we had a lot of fun. Now, the Austin JavaScript Meetup 6 or 7 years later is, it rocks! There's 50 or 60 people every single month tha

Jamison Dance: @jergason | Blog | GitHub | Fivestack | Soft Skills Engineering Podcast | React Rally Show Notes: 00:58 - The Elm Programming Language 01:36 - Who should try Elm? What is the attraction? 03:09 - Scaling an App Across a Team; Conventions 06:19 - Routing 07:48 - Writing Tests 09:38 - Jumping Into Elm from a Component-based Framework 12:20 - Tooling 17:28 - Productivity 19:21 - The Elm Community 25:13 - Could Elm Replace JavaScript? 28:28 - Lessons Learned from Elm to Write Better JavaScript 33:45 - The Elm Syntax 35:49 - Checking Out New Languages and Communities 37:31 - Data Modeling Resources: Elm Packages elm-format Evan Czaplicki: Let's Be Mainstream! User-focused Design in Elm The Elm Guide Elm on Slack The Elm Tutorial Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 Transcript: ALEX: Hey, everybody. Welcome to The Frontside Podcast Episode 49. I am your host, Alex Ford, developer at The Frontside. With me as well is Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hi, everybody. I'm Chris. I'm also a developer at The Frontside. ALEX: We have a really special guest for today. I'm really excited. Jamison Dance is with us. JAMISON: Hello. ALEX: Jamison runs Fivestack Software Consulting Company, hosts Soft Skills Engineering Podcast, organizes React Rally Conf, and spells 'array.length' incorrectly sometimes. Is this true? JAMISON: It is true, yeah. I think I have a special ESLint plugin to yell at me now when I do that or something. But that has caused some pain in my life. CHRIS: Oh, that was very brave. Thank you. ALEX: We're going to be talking Elm today and writing better JavaScript with Elm. This is really exciting for me. I've gotten the chance to dive into the Elm tutorial a little bit, which is an absolutely beautiful tutorial if you haven't checked it out yet. JAMISON: Yeah, Elm is a programming language that runs in the browser and compiles down to JavaScript. It's a pure statically-typed programming language, which if that doesn't mean anything to you, don't worry. The take away for you is that Elm tries really hard to make it easy to write programs that don't crash and are easier to refactor and easier to work on and maintain, basically. CHRIS: And Elm is a language in of itself but it is pretty specifically intended for front-end development. Is that correct? JAMISON: Right now, there are some long term plans, but yeah. For now, it's front-end for building UIs and applications in the browser. ALEX: I heard about Elm. When should I check it out? Who do you see jumping into this language? JAMISON: I think it's aimed at people that want to build robust applications which is so vague, it sounds meaningless. Maybe I talk about what attracted me to it. The two things where I was interested in functional programming -- that's kind of like the technical language wonk, like geeky side of it. But the other side is I've worked for a while in some fairly large JavaScript applications and I've seen the nightmares that I can create for myself In just building something that works and is just really hard to work on. So the idea of a language that's focused on keeping your productivity high as the application skills and as the team skills was really attractive to me. Like the bio says, if I spell array.length wrong, sometimes I catch it, sometimes I don't, then my program breaks. Elm has a compiler that runs on all your code and basically, make sure that your code cannot crash. You could still have bugs and you can still just make your code do the wrong thing but it helps eliminate whole categories of errors. It just makes them impossible to create in Elm. If you're interested in functional programming or if you're interested in just building stuff that is easy to work with, like this kind of this curve of productivity over time where some environments and some languages start out really high, it's really easy to build something fast at the beginning and then maintaining it is just really hard so the productivity drops over time. Elm is trying to kind of flatten that out so your productivity stays high throughout the lifetime of your application. CHRIS: I actually have a question about that. I'm planning on bringing this up later but you gave me such a good segue that I feel compelled. You mentioned that one of the things that is nice about Elm-type system is that it helps scale an app, especially when it comes to a team. My experience there are kind of true different facets to what scaling an app across a team looks like. One is the categories of bugs that something like [inaudible] compiler helps you catch. But the other is, and this is totally coming from the fact that I use Ember every single day, that conventions also help scale across a team. I'm curious like what I've looked at with Elm, it looks like they definitely have the type system there and error messages there to help quite a bit. But I haven't seen conventions arising ye

We say goodbye to our friend and co-host of The Frontside Podcast, Brandon Hays. Brandon Hays: @tehviking | blog Transcript: BRANDON: Hello, everybody and welcome to Frontside Podcast Episode 48. It is a podcast, as you can tell from the intro music, about woodworking and dads and dads working with wood. CHARLES: And power washing wood. BRANDON: Yes and power washing, sanding decks. Today, we'll be talking about the difference between mortise and tenon joints and dovetail joints and when it's worth going through the extra effort for that dovetail. Our guest today is Charles Lowell, woodworking expert. CHARLES: Hi, Brandon. BRANDON: Hi. I think I've never heard anybody acknowledge the fact that there's new music in the intro. I don't know if that has been publicly acknowledged in the podcast yet. But I was on the selection committee for that music and we had many options and we went with the one that sounded most appropriate for, I don't know, a woodworking show on PBS but I like it. CHARLES: I like PBS. I like woodworking. I like the music too and the best part is I didn't have to choose it. I just had to promise to make music myself for 50 weeks running. BRANDON: It was about 150 weeks. CHARLES: About 150 weeks. BRANDON: Yeah. Charles, we are here in the new Frontside HQ, which is sort of still under construction. It's kind of cool, though. It's a different space. I haven't been here much so it doesn't feel like home to me yet, I don't know if it does to you yet. CHARLES: It's beginning. It’s still unfinished in many ways. It’s not painted. We just kind of have the bare minimum for survival. The kitchen is stocked, there's coffee in the cabinets, the grinder is set up, the bar is set up, the wall sockets are set up, and the wireless router is set up. BRANDON: Home is where the vermouth is. [Laughter] CHARLES: And cavernous is really the word to describe it. BRANDON: This is a shop that's clearly set up for a version of the Frontside that does not yet exist and it's interesting to see current day Frontside in a space that is clearly marked for a future version of this. CHARLES: Yeah, you feel small walking in. There are not enough people to fill all the seats that we have in here. BRANDON: Which is kind of cool. I don't know if you recall, maybe we'll save that discussion for later but there was a prior iteration of this company where that was very much the same thing. So it's kind of cool, like a little bit of an emotional journey to see this process start over again. CHARLES: Yeah, it is definitely a new space and it's a new era. BRANDON: Yeah, for you. Not for me. [Laughter] BRANDON: You guys can go right to hell. CHARLES: Well, it is a new era for you too. BRANDON: Yeah, that's true -- a new era of fun-employment. We wanted to do one final 'dadcast' because basically, as of officially 10 days ago or so, I no longer work at the Frontside and I've had people ask me and I was like, "I don't want to talk about it." And so, I think it’s probably time that we -- I don't want to belabor it. Nobody handed me a card when I quit as the co-founder of the Frontside that said, "You are officially invited now to Medium.com to write a think piece about my incredible journey." CHARLES: [Laughs] You'll get that in the mail. BRANDON: Okay. It may be sent to my old address. It’s sent to our old office, which is the problem. It’s lost in the mail. So yeah, instead I'm going to do my incredible journey podcast and really just regale everyone with stories of what an incredible, incredible journey it's been -- truly incredible. CHARLES: Don't leave out the travelling with the fish and the cat, and like a little pug dog. You know like all those incredible journey stories when we were kids. BRANDON: Yeah, like Homeward Bound. CHARLES: Yeah, there you go. BRANDON: I think it is like Homeward Bound. CHARLES: That time that you fell into the water with the kitten, that was adorable. BRANDON: I don't know where I'm stealing this joke from but there is an Incredible Journey sequel with a squid and a cow, truly the most unlikely of friends. [Laughter] BRANDON: Here we are giving my swan song on this podcast. I've actually actively took a month off to think about basically to try to recuperate and think about like, "Is this something that I can continue to do." I purposely took off from the podcast which was agony because I so wanted to have those conversations that you all did with Noel, and with Yehuda, and with Sarah. They turned out really good. I'm so happy with the result of stepping back and realizing, "Wait a minute, I think I'm redundant." CHARLES: It was your idea to create the podcast, in the first place and the podcast has been infused with your personality. Even on the episodes where you weren't present, like you were behind the scenes, arranging it, making sure that it all happened. I can understand like missing that part of it. It really was like your baby, so to speak. BRANDON: W

In this episode, Noel Rappin, developer at Table XI, comes on the show to talk about his new book, Take My Money: Accepting Payment on the Web. Noel Rappin: @noelrap | blog | GitHub Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast Episode 47. I'm Charles Lowell and with me today is Noel Rappin. Before we get into who you are, because I know that a lot of people know you already and you need no introduction, you're actually calling in from Chicago today, right? NOEL: That’s true, yes I am. CHARLES: Did anyone actually show up for work today? NOEL: Yeah, people did actually show up for work a little bit later. So, this is being recorded the day after the Cubs won the World Series last night. I will say that my commute in the parking lot at the commuter rail station in the suburbs was surprisingly empty this morning. The people were a little bit slow to come in. The game didn’t end till about midnight last night. CHARLES: I'm neither a Cleveland nor a Chicago Cubs fan but it was a harrowing game. It almost gave me a heart attack. NOEL: Oh, man. CHARLES: I can't even imagine what it was like. NOEL: A Cubbie Blue since I was a kid. So yeah, it was something. CHARLES: So, you're from Chicago? NOEL: Yeah, I grew up in Chicago. I grew up in the Chicago suburbs. I went away for school and I worked in Boston for a while, but came back about 12 years ago. CHARLES: Okay. So, that kind of leads me into the perfect setup for one of our questions is how did you get into development? I've known about you since I got into the Ruby community, probably back in 2010 or something like that. How did you come to be there? NOEL: I was one of those kids who was a developer at a certain age, I guess and I had an Apple II. I started programming Applesoft BASIC in the mid-80's, I guess, and eventually decided that I enjoyed it enough and got pretty over-educated at that and that’s just a very traditional background. I went and worked at what we would now call web consulting company around 2000, my first professional job was '98 - 2000. I had done a lot of different languages as a student. That job was mostly in Cold Fusion and then eventually bounced around doing a bunch of different web development solutions. At some point along the way, I picked up the Ruby Pickaxe book and then eventually came to Rails. I started Rails as a hobbyist, either pre-1.0 or very early 1.0. I used it to build some task tracker for my team and a couple of other little tools like that. And relatively shortly thereafter, I started doing it professionally. CHARLES: I think you're kind of the same generation that I am. I call this [inaudible] from that early 2000's web development background where it's kind of fueled by [inaudible] network. NOEL: Yeah, a little bit. My first professional job was at a company that is a very, very small consulting company based in Miami and Boston and they were not developers who run the company. They’ve been documentary film makers and there's like a whole 90's technology trajectory here because they were documentary film makers and then they were documentary CD makers and then they were asked to add interactive stuff to the CDs that they were putting out and then they became web developers as a sort of a natural extension. And suddenly, it was like 1998, every company in the universe wanted to be on the web and they were like, "Oh, this seems like a good business to be in." And they started trying to hire actual programmers who knew what they were doing even though I was just out of grad school and didn’t know what I was doing but it was convincingly put in. We did all the stuff then that would be like the first application that I worked there, the production server lived under my desk and was also the staging server and the development server. We didn’t use, at that point, search control although eventually we did. There were no established conventions on what was the good thing to do. CHARLES: Yeah. The production server under the desk: a more elegant weapon for a more civilized age. NOEL: [Chuckles] Certainly old. CHARLES: That was a while back but you’ve obviously been doing a lot more structured, a lot more formal development over the course of your career. So, most of us, myself included, were kind of content to write the software, maybe blog about it every once in a while, give the occasional conference talk, but you’ve really, really delved in to those activities and really kind of taken the time to really, for the topics that you're interested in, really kind of research them very thoroughly to the point where you’ve actually written several books. When I think about the concept of writing a book, it sounds like, "Oh, my goodness! That sounds terrible. That sounds like a hundred of my teeth pulled out," or something like that. But you’ve done it multiple times. I'm curious, did you experience that kind of fear and uncertainty and what was kind of the decision making process

In this episode, Yehuda Katz, co-founder of Tilde, OSS enthusiast, and world traveler, talks about what's in store for Ember. Yehuda Katz: @wycats | blog | GitHub Transcript: ALEX: Hey, everybody. Welcome to the Frontside Podcast, Episode 46. My name is Alex Ford, subbing in for our usual hosts, Brandon and Charles, today. We have an awesome episode. We have a really special treat for you. Co-creator of Ember, Yehuda Katz is joining us today. Hello, Yehuda. YEHUDA: Heyo! ALEX: We also have a first time Frontside podcaster, Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hey, everybody. ALEX: We've also got a podcast Frontside favorite, Robert DeLuca. ROBERT: Favorite? I don't know if you say that. Hey, everyone. How are you doing? ALEX: I'm really excited about our guest today. Yehuda was just in Austin a couple of days ago. He gave a great meet up talk and a deep dive into Ember and it looks like you're going on-tour with that talk, Yehuda. Is that what I saw from your website schedule? YEHUDA: Yeah, I'm not sure exactly. I change it up every time, largely because things happen. So if I say this thing is 'active' or 'in progress', and then it actually shifts, I have to change it up. I've been talking a little bit about what's up on what we were working on. ALEX: Do you want to give us a brief outline as to what's going on in that talk for those podcast listeners who might not be able to attend? What's going on with Ember? What's new? What is it that you're trying to get across here? YEHUDA: Sure. Actually, the talk I gave in Austin was, you're right, it was basically a deep dive. It was really focusing on a few targeted things that we're working on. I would say that at a high level, we're basically working on a couple of things. One of them is generally more integration with the ecosystem, things like ES6 modules, classes, components that look more like HTML and more graphic components and things like that, also improving EmberCLI so it's more integrated with other tools that people are using. A lot of that stuff has to do with the fact that Ember started a long time ago now, like five years ago or so. And so, I think we've actually done a pretty good job of keeping up with things. For example, we adopted ES6 modules and promises a while ago now, and I think generally speaking, we tend to keep up with the ecosystem. But because we've been around for so long, there are certain things like classes, where it took a while for that feature to catch up with the functionality that we were using in Ember. Decorators landed a little while ago as a stage 2 feature in TC39, and that lets us really take a bigger chunk of the functionality that we have in our class model. I make it work for everybody with class syntax and that's something we're pretty excited about. So that's one area just generally taking things where Ember had its own stuff and try to integrate a better ecosystem. Another big area is this mobile readiness and also, a lot of that has to do with the fact that things like service worker have just recently landed. For example, AppCache was a nice feature in some ways. Some people at Google will kill me for using the word 'nice' in AppCache in the same sentence. [Laughter] YEHUDA: But AppCache was trying to accomplish something for a long time. I think it did some version of what it was trying to do. But really, using AppCache is a default behavior for all users having - there's too many caveats to make it work well where service worker, because it's more of level one and more directly controllable is a better fit for something that we could ship with all Ember users. We basically want to use Ember and EmberCLI, you build an application, you get a good mobile experience out of the box. Some of that has to do with trimming down parts of Ember that we don't need to be using in simple applications. Some of it has to do with service workers, some of it has to do with things like Glimmer 2, just making the performance better. But generally, that's the other [inaudible] so it's basically mobile readiness on the one hand and just integrating better with the one ecosystem are both big picture things we're work on. ALEX: Something that you brought up in your talk where private Ember methods and how a lot of people use private methods and you have to keep them around, what you we’re just talking about that was unifying around the conventions of programming in Ember. Whatever JavaScript people bring in to Ember, you want to try to incorporate that as the language moves forward which is, I think, a really interesting problem. Also, something you could talk about a little bit further is what you look for in the way people use Ember going forward and how you have to kind of bend the framework to allow it to be backwards compatible. I'm curious what that decision making is like. YEHUDA: What you're talking about and what I talked about yesterday is what we call 'intimate APIs' and that basically means AP

In this episode, Sarah Mei, founder of RailsBridge, Director of Ruby Central, and Chief Consultant of DevMynd Software, talks about the way we write software: What’s right? What’s wrong? How can we do better? The conversation examines changing code and reassessing needs. i.e.: "Does it bring me joy? Should I get rid of this thing? Do I understand this code?" She also talks about what these needs mean for others on a team. Sarah Mei: @sarahmei Links: Sarah Mei: How We Make Software: A New Theory of Teams @ Brighton Ruby 2016 The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing by Marie Kondo Transcript: CHARLES: Welcome to the Frontside Podcast. I am Charles Lowell and with me is Robert DeLuca. We have a very special guest this week. One that I'm really excited about because the things she says and the ideas that she has - open eyes and minds all over the place, in all different types of areas that are so pertinent to the way we do our jobs. So, we'll get to it. Our guest today is Sarah Mei. SARAH: Hi. Thanks for having me. CHARLES: Like I said, we are super excited to have you here. Before we get started talking about some of the things that you've been thinking about recently, why don't you just give like a very brief introduction of how you got started with development, where you've been, and how has that brought you to where you're going right now? SARAH: You know, I actually was not one of these people that got started with it real early. I came to programming in college. I was an Engineering major. I wanted to build bridges. I wanted to be a Structural Engineer. I want to build things. I had a weird schedule the first couple of quarters of college, so I ended up taking an elective earlier than most people take it. It was a programming class in Fortran that was required for the structural engineering program. I took my class and I was like, "This is really cool." CHARLES: Wait, Fortran is what set the hook? SARAH: Yeah, and the professor of the class was like, "Well, if you think Fortran is cool. I've got some other stuff that you might like." I mean, the language and whatever doesn't really matter. What I liked about it was the fact that I could build something. I can get that same feeling of building something that you get if you build a bridge but you can do more than like one or two in your career, like you do if you're a structural engineer. I like the constant feeling of building. That's what I liked about it. So I ended up switching my major and graduating with the CS degree and coming out and doing a bunch of different things, mostly like starting in a large company and sort of doing smaller and smaller companies over time. CHARLES: Yeah, there's a lot of people in the industry who are career switchers, where they started out in something else and moved into Computer Science but I actually feel that a lot of people, like myself included, I have the degree in CS too, but that was not what I set out to do at all. It totally derailed, like the course of my life in a good way. But in that way, it’s like a career switch within a career switch. ROBERT: I'm a little odd in that aspect. I came out of high school like ready to go in software. It worries me a little bit for the later half of my life. I'm like, "Oh, am I going to do software for the entire time?" CHARLES: Probably not. SARAH: That might be a good thing. You'll never know. ROBERT: Yeah. CHARLES: Yeah, seriously, what lies ahead? ROBERT: Who knows? SARAH: I feel like in a lot of places that are like, for example, in public policy and in other places where we need more people that understand tech so if we can send you out into other parts of the world knowing a whole lot about programming, that can only be good. CHARLES: Yeah. ROBERT: Yeah, this is actually kind of funny. I was telling CHARLES about this the other days, like I'm starting to view programming more as a tool to do the things that I really want to do and less as like the thing that I'm going to be doing forever. I wanted to augment and make things that I have a passion about easier. SARAH: Yeah, absolutely. CHARLES: Yeah, it's like software is eating the world so what you're doing now is just learning how to chew. ROBERT: That's a great way to put it. SARAH: You should tweet that. [Laughter] CHARLES: All right. Please continue. I'll ignore the typing sounds. SARAH: [Laughs] Switching careers is a really interesting thing because you end up with a bunch of experience that you wouldn't have had otherwise. I'm really excited actually about the next five years as we have all these folks that switched into programming from something else who are all becoming mid to senior level because they're bringing just such amazing experience from other parts of the world. CHARLES: Yeah, I know, right? It's like, "Where've you guys been my whole career?" SARAH: Right. CHARLES: It's like you understand these things

In this episode, LaToya Allen, developer at Big Cartel and founder of SheNomads talks about apprenticeship and mentoring, finding community while working remotely, how companies can be more inclusive for hiring women and people of diverse backgrounds in technology, and avoiding burnout and maintaining balance. LaToya Allen: @HashtagLaToya | [email protected] Links: CodeNewbie Ep. 34: Newbie Story: LaToya Allen The SheNomads Podcast Garage Cowork (Polanco) Dear Tech Companies: Focus on Diversity, Not Foosball The SheNomads Job Board Women in Tech Wellness: Chicago Resources: Practical Object-Oriented Design in Ruby by Sandi Metz Exercism.io The CodeNewbie Twitter Chat Transcript: BRANDON: Hello everybody and welcome to Episode 44 of the Frontside Podcast. I'm your host Brandon Hays and I help run the Frontside. STEPHANIE: Hello, I'm Stephanie Riera and I am a developer at the Frontside. BRANDON: Awesome. And we have a special guest today, LaToya Allen. So you're a developer at Big Cartel, is that right? LATOYA: That is correct, yes. BRANDON: Cool. We wanted to talk a little with you today about your day job, your work with SheNomads, your recent blog post about inclusivity and how you balance all that stuff for people. We wanted to start, if we could, by having you introduce yourself for the listeners that don’t already know you. LATOYA: Sure, my name is LaToya. I am a software developer at Big Cartel and I'm also the founder of SheNomads. BRANDON: Cool. We actually listen to your podcast and found out some cool stuff about you. One of the things is you used to tend bar. Would you be okay telling us a little bit about your story about how you got into software, what you did before that, and why you're doing this now? LATOYA: Absolutely. I was bartending in Chicago, trying to figure out what I wanted to do with the rest of my life because I knew that it wasn’t staying up until 5 in the morning, making Martinis for folks even though it was fun and I do appreciate that time of my life. One day my yoga class got cancelled and I needed something to do. I ended up stumbling upon some coding tutorials and I really fell in love with it. I noticed that hours had gone by, I wasn’t bored, I really felt engaged, and it didn’t really feel like work to me. It felt like something that would be a cool hobby. I, like many people at that time, felt that you needed a college degree to become a software developer, so I really looked at it as more of a hobby. I started going to different meet-ups in the city and I discovered that wasn’t true. And I was lucky enough to find people that are willing to help teach me when I was very early in my career. BRANDON: Cool. And I guess the rest is history now, right? You've had a couple of jobs since then and you went through an apprenticeship program and after the apprenticeship program, you're developing lots of different kinds of software. Are there any software projects you're working on now? I know I met you at Ember Conf but you're doing less of that now. Are there any software projects now that you're fun and exciting, like what languages are you using? LATOYA: At work, we are primarily a Rails app. I've been doing a lot of work in Rails, a little bit of JavaScript. I had the opportunity to learn Ember when I came on to Big Cartel. So, that was pretty cool. As far as side projects, I started an open-source project for SheNomads as a way to help teach folks how to do simple things like create a pull request in GitHub or just the basics of working with Rails. But SheNomads has become an entirely different thing since I started that, so I don’t do any coding outside of work right now, unfortunately. [Laughs] STEPHANIE: How long was your apprenticeship? LATOYA: I was an apprentice at 8th Light in Chicago and I was there for one year as an apprentice. STEPHANIE: And is that where you learned Ember? LATOYA: No, when I left 8th Light, I landed a job working in FinTech for 6 months. And then after that, I went to Big Cartel and Big Cartel is actually where I learned Ember. STEPHANIE: What was your apprenticeship experience like? Do you have any advice or anything that you think really helped you along the way? LATOYA: I got to learn from some pretty great people such as Mike Ebert, Colin Jones, just off the top of my head. I learned from a ton of people when I was there. Ginny Hendry was also very helpful. Basically at 8th Light, they really focused on test-driven development and pair programming which test-driven development is a lot of fun and tests are great, that they're very in these days. I got to learn how to test-drive applications and languages such as Ruby, JavaScript, Clojure which is probably my favorite language that I'd never get to work in because it's not popular enough, I guess. I think I did a little bit of REST while I was there as well. And then I was working in frameworks such as Sinatra, Rails, and I worked in ClojureScript as well. STEPHANIE: Nice. I also wanted to

In this episode, Leah Silber, CEO of Tilde, Inc. and Ember.js core team member talks about what she's learned building communities, organizing events, and running a business. We talk about how people can move from "observer" to "participant" and grow their own healthy communities and companies. Links: Leah Silber: EmberConf 2016: The Morning-After Post-Mortem Event Driven: How to Run Memorable Tech Conferences Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 43. I am Charles Lowell. I'm here with Brandon Hays, and a very, very special guest. Brandon, do you want to introduce her? BRANDON: Yeah, we're here with Leah Silber. She runs Tilde? 'Tild’? I always say this incorrectly. LEAH: You can't be saying it incorrectly. When we named the company, we knew we were choosing one of those names where people are going to say it and you just have to accept it. That's fate and that's how it goes. We usually say 'til-de' here. BRANDON: Okay, I'll say Tilde, and you can say 'Frontsi-de'. CHARLES: The way you say Tilde says more about you, than it does about us. BRANDON: Yeah, it's a verbal Rorschach test. We were really, really glad to have your time. We know that people actually work with you as a consultant for these kinds of things to help with communities, conferences, build their businesses. So, you have a lot of gathered expertise around these things. Would you tell us a little bit about yourself, about your background, what you do and kind of how you got involved in tech and running businesses? LEAH: Sure, not unlike an elevator pitch but I have been working in open source startups and companies, I want to say it's probably been like 10 years now or crazy something like that. But my first open source project that I was seriously involved in was jQuery, and that was a long time ago and it was pretty magical in retrospect because jQuery was, at the time, it was like coming out of nowhere. Nobody thought it was going to really make a dent in technology. John Resig was this clearly brilliant but still this nobody, sort of working on this project in his spare time, and Yehuda Katz jumped in and a bunch of other people earlier at the beginning. It was a time in the ecosystem where they were a little bit laughed at the room. In retrospect, there was a time when the ecosystem was a little more rude, like some of the competitive behaviors that happened back then. Thankfully, it just wouldn't fly right now. But it's been super cool to be involved with something and be able to witness something at the ground floor where this little idea and project that nobody takes seriously because there are these seemingly massive projects and landscape, and then just sort of watch it take over the world. It was a process obviously that took a little while. But again, in retrospect, it didn't take all that long, so that was really an amazing experience to watch. It was also my first really intense open source community learning experience. Everything from witnessing what kind of personalities got involved and how they did it, to watching John who sort of -- I want to say he's a consummate politician, but he's not a political person. I guess what I mean, he's just really good at people. CHARLES: He's like a diplomat? LEAH: He is. But like the sort of diplomat where you're in a battle and then suddenly a treaty happens and you just don't even know what happened but everybody's happy and you vaguely remember that you all hated each other a few minutes ago. He's really talented. Obviously, also having the technical chops to build something impressive helps with that. But watching how different personalities in open source interacted with each other, and even just for myself, like learning how to be a good open source citizen and learning how to contribute to a project and finding a way as a non-coder at the time to be useful in an open source project was really amazing. That was something I was involved with for a number of years. Then, slowly as time went on, I got involved in other projects and other events. And along the way, I was like, "This is really fun. Why am I working not in technology but doing this at night." Well pretty early on, I moved out from New York to California which is, I guess, the rite of passage or at least was. Got a job at my first startup, spent a couple years there, sort of again learning everything in fast forward because that's how startups work. I've done that a couple of different times over the years, thankfully not that many. I've managed to have what I consider impressive stability in a startup land where people can end up needing to change jobs, projects and positions very rapidly. Nowadays, I mostly focus on Ember work. There was a big chunk of time in the middle where I was focused on Ruby on Rails work. I do events, conferences, meet up groups, community management. A lot of the less glamorous stuff involved in once a project does become

In this episode we cover how to handle apprenticeship, share with listeners how they can start participating in mentoring and apprenticeship in their companies and communities, and help people to understand the impact apprenticeship and mentoring can have on everybody involved. Links: open-source-ember-apps: A list of open source Ember apps Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 42. I am Charles Lowell and with me is Brandon Hays, as well as some other really, really, really, really special guests, which I'm really excited to have on the show today. BRANDON: Really? CHARLES: Yeah. BRANDON: Just really? CHARLES: Really, really. [Laughter] CHARLES: I was thinking of 'really, truly' but no, I wanted to go back to 'really'. I don't know, Brandon, are you pretty stoked about the show today? BRANDON: I am. I'm really excited today. We've actually wanted to do this for a long time and we finally were able to line it up once we've figured out that we can record a podcast more than once every six weeks. So yeah, we're really -- CHARLES: Really. BRANDON: -- Really excited to have Taras Mankovski and Lennex Zinyando with us. We'll have you each introduce yourselves. But basically, the point of this podcast is we want to talk to you and you're doing some really cool stuff with apprenticeship through us, and Lennex is one of your earlier apprentices. From everything I've seen tremendously successful, Lennex, you're an awesome developer. So we wanted to talk to you, find out how you're doing that stuff but we'd love to have each of you introduce yourselves and talk a little bit about your background. So we'll start with you, Taras. TARAS: I'm really excited to be here. I also feel like I need to point out the fact that this is podcast number 42. Right? That's the meaning of life and everything. BRANDON: We would be very quite remiss to miss that. Thank you so much. We were so really excited that we forgot about this was the purpose of everything. CHARLES: That's right. We're sitting on the main nerve right now. This is it people. This is it. It's everything. TARAS: I'm really hoping that if you ask me questions, I'm going to answer them faster than this famous answer. I'm really glad to be here. I want to give a little bit of my story because I feel like a lot of things that I've doing over the last 10 years have been adding up to what I'm doing now. I have a pretty diverse background. Programming wasn't something I wanted to do because when I was 12, my dad gave me a Java book and he said, learn how to program and I'm like, "This is terrible." [Laughter] TARAS: That was a really rough introduction for me. Even though, I think I was always technically inclined and I did like [inaudible] for a long time. I did a lot of different things. Since I was a little kid, I always want to be a businessman before I think I even knew what that was. So my focus has always been on the business of things, and technology happened to be one of the only ways that I knew how to access that in a way that was actionable based on something that I could do. I've tried a lot of different things. One of the things that I did before was a company called Positive Sum, where we spent about four and a half years trying to figure out how do you build relationships where everybody who works with you wins. When that Positive Sum company and the being as 'zero sum' for me, I end up leaving and starting from scratch. I have another company called WRKTG, Inc which is like the mothership for EmberSherpa and that acronym refers to 'working together'. Everything that I've kind of have been doing has come from the perspective of how do we bring people to work together, and how do I make it possible for people to have a win-win-win scenarios. I think that's kind of what brings us to where we are today, with this conversation about apprenticeship. BRANDON: Cool, thanks for that. Then Lennex, how did you get into software and what was your background? I don't know if you come from a computer science background or you were doing something else. LENNEX: I'm Lennex Zinyando. I'm based in Harare, Zimbabwe. I've always wanted to work with computers since an early age. But then, access to computers was really hard to come by so I used to spend a lot of money going to internet cafes so that I could access the internet. After a few years of [inaudible], I went to work with a bank for a few years and I decided to leave because I really, really wanted to become a programmer developing software. I joined a local company that does mobile marketing as a technical support person. I worked with them for a few years and I met Taras on Twitter, sometime beginning of last year. Then, I paired with him so that he could mentor me. So now, I'm an apprentice at EmberSherpa. BRANDON: You said you met him on Twitter and you said, "Hey, I'd like to be your apprentice," but how did that interaction actually occur? Was there l

Recently, there was a flurry of activity around one of Brandon's posts about defining the term "senior developer". But he left the purely technical aspects of the role for later discussion, which left a lot of lingering questions. In this episode, Charles and Brandon dive into the technical side of identifying, hiring, and growing senior developers, and explain The Frontside's somewhat unconventional standards. Links: The Conjoined Triangles of Senior-Level Development Don't use animal names as an insult Transcript: CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 41. I am your host, Charles Lowell. With me is our other host, Brandon Hays. BRANDON: Hi, welcome back. It's been too long. It's been one week since you looked at me. CHARLES: And we were actually talking right before the start off that we don't have any witty banter prepared for this episode. BRANDON: Also, you just drop that hot Barenaked Ladies reference right on the floor, like an apple pie upside down. CHARLES: Right, you got to prep me for that. BRANDON: You're like, "Nope. Pass." [Laughter] CHARLES: Like I said, you got to prep me for that. BRANDON: "In Second 7, I'm going to drop a Barenaked Ladies reference." I'm going to send you three or four music videos. I did send you one that you didn't have time to watch about don't use animal names as an insult. When you say, you're not going to be able to riff off me on that one just yet either, but yeah, I respect you and I respect dogs so don't use dog as an insult. [Laughter] CHARLES: Is that 'They Might Be Giants'? BRANDON: It is not They Might Be Giants. It is three vegan randoes on YouTube. CHARLES: Is that the name of the band or is that just the content of the band? BRANDON: No, they're just three vegan randoes on YouTube. CHARLES: Okay, three vegan randoes is a pretty good band name. BRANDON: You'll immediately know they're from Portland so you could really pick a lot out of that from just the name of the band. We want to tight 30 today. We don't let people behind the curtain very much, Charles, where people don’t see what it is that you and I do behind the scenes. But one of those things that we do is sometimes we will record a podcast and throw it in the garbage because we hate it, and this is actually one of them. You and I sat down and recorded this podcast before. Just like the hot apple pie Barenaked Ladies reference that I served you earlier, we just dumped it right in the garbage. We did not like the way that it tasted. We did not like its Barenaked Ladies references, and so this is our second attempt at this. Then the topic that we want to cover today is really important to us to not screw this up. So hopefully, we put a little more effort into preparing for this and thinking very deeply about this. The idea is that we want to understand from a technical perspective largely what it is that a senior developer is, what they do, how we can find them, how we sometimes miss that, and basically how we define a senior developer so that we can build that as a track for our people to grow toward and find the ones that want to come work with us and may self-identify a senior, how we can kind of verify that. That's the poorly defined topic in our industry, interestingly enough. CHARLES: Strange, because everybody seems to want that. BRANDON: Yeah, right. Everybody put it on their job descriptions. Anyway, I wrote a blog post about it. It did all the things that blog posts do when they sort of struck a nerve with the tech industry and they got posted around. I got called literal human feces on Reddit. CHARLES: Did they call you human feces or do they call you literal human feces? BRANDON: They said literal -- CHARLES: Did you literally get called literally human feces? BRANDON: I literally got called literal human feces. [Laughter] CHARLES: I shall wear it as a badge of honor. BRANDON: I was kind of like Ron Burgundy. I'm like, "I'm not even mad, I'm just impressed." [Laughter] CHARLES: People had some strong, strong, strong feelings about that. BRANDON: They did. So now, a skull in a cowboy hat and literal human feces are going to sit here and preach to you about what we think and how we're basically like willing to sink or basically, sink or swim for our business on this definition of senior developer because that actually is core to what it is that we're doing. I want to tee this up and then I'm going to let you just freakin' roll. I want to provide a little background. The cool thing is, I already wrote a blog post so I don't have to sit here and talk at your face about these things. I was going to tell you some additional thought I've had about this. But basically, the point of this blog post was that we generally categorize what it is to be senior developer in three broad categories that have a little bit of overlap. The three categories are technical skill, which is the one that people typically think about, evaluate for l

After a "perfect storm" of events rocked The Frontside, Charles and Brandon were faced with the prospect of what kind of future they saw, if any, for the business. In this episode, Brandon and Charles discuss what happened and why, what they are doing to avoid another "perfect storm", and how finding mentors and friends at OpsConf completely changed how they think about running The Frontside. Links: Ops Conf Charles Rocking out at karaoke What is a KPI?

There's a huge shortage of senior developers, and one (often overlooked) way to fill those positions is by bringing up some junior developers. But how do you mentor junior devs when you have so much work to do? How can you make sure that your new hires get the support they need? This week, Charles Lowell is joined by Stephanie Riera, Lydia Guarino, and Alex Ford to talk about the challenges companies face when hiring junior devs, what steps you can take to make sure the on-boarding and training process goes smoothly, and how keep new developers productive and frustration-free. Follow the Frontside crew on Twitter: Charles Lowell Alex Ford Stephanie Riera Lydia Guarino Show Links: So You Just Finished a Bootcamp, Now What? Lydia's tweetstorm: Where do junior devs fit?

The Frontside crew recaps the EmberConf 2016 experience and share their biggest takeaways and lessons learned. Show Links: EmberConf Ember Freestyle Matthew Beale - Interoperable Component Patterns Jade Applegate Estelle DeBlois Brigitte Warner Kelly Senna Katie Gengler Leah Silber - EmberConf 2016: The Morning-After Post-Mortem

This week, we talk with Sam Selikoff, the mastermind behind Ember CLI Mirage. He shares how he got started with programming, some tips for avoiding burnout, why he created CLI Mirage, some tips for using it, why it's important to write great documentation, and more. Show Links: Sam Selikoff Follow Sam on Twitter Ember CLI Mirage Pact (ruby) Contract-driven Design by Martin Fowler EmberMap Practical Object Oriented Design in Ruby by Sandy Metz

This week we have Trek Glowacki back to talk about the challenges of choosing frameworks, building reusable components, and why “thought leader driven development” (TLDD) might actually be the right way to go. Show Links: Trek Glowacki Ember Camp 2013: UX Patterns Applications: A Series of States The Grammar of Graphics by Leland Wilkinson D3.js D3 Scale The Wirecutter The Sweethome

Brandon and Charles discuss their unique and slightly unusual approach to hiring, why they focus on what success means for their candidates, the hidden value of mentoring, the vision that led them to start The Frontside, exit interviews, and more. Links: Austin Bouldering Project Trek Glowacki Stanley Stuart

Brandon and Charles discuss what they learned in 2015. Highlights and topics include: The benefits of planning your day in advance Benjamin Franklin vs. Stephen Covey Leading by example Learning how to define balance for yourself Why "Do something that terrifies you” is better advice than "Follow your passion” How to choose people to work with and more Show Links: Switch: How to Change Things When Change Is Hard Drive: The Surprising Truth About What Motivates Us