React Native Radio Episode 068 [PODCAST]
Sign up for weekly Clojure tips, software design, and a Clojure coding challenge.
**Nader Dabit**: [00:13] Hello, welcome to Episode 68 of React Native Radio. I'm your host, Nader Dabit.
[00:16] Today on our panel we have Peter Piekarczyk from Preposterous.
**Peter Piekarczyk**: [00:20] Hey everybody.
**Nader**: [00:21] Gant LaBorde from Infinite Red.
**Gant LaBorde**: [00:23] Welcome!
**Nader**: [00:24] And our special guest today is Eric Normand. Eric, welcome to the show.
**Eric Normand**: [00:29] Hello. How are you going? I'm so happy to be here.
**Nader**: [00:32] Glad to have you all.
[00:50] Before we jump into our topic in general, can you give us a quick overview of maybe how you got into programming, what you're doing now and kind of what all you're working on?
**Eric**: [01:00] Wow. How I got into programming. That was a long time ago. I had very supportive parents. I remember when I was — I must have been six or seven — I was in school and I was in a meeting with my mum and my teacher. My teacher asked me what I would like to like do research, explore. For some reason, I said computer programming.
[01:29] I had no idea what that was at that time. My mum looked at me, was like, "Really? That's what you want to do?" She helped me the whole way. We spent a lot of time on the computer, and I got my own computer at some point and I just really like programming. What I like most about it is that just like an artist, or a poet, you spend a lot of time in the world of ideas.
[01:54] You're constructing ideas, and I really like that. It's like world-building. Like building a middle earth or something. How things are supposed to work. That's one of the reasons I like functional programming because I feel like it operates a lot in that world of ideas. I got into functional programming about 15 years ago while I was still in college and I just really like it.
[02:26] I'm glad to see that functional programming is now getting a lot of...people are talking about it. It's getting a lot of attention. It's now more possible than ever to be a gainfully employed functional programmer.
**Nader**: [02:41] What was Functional Programming 15 years ago? What was going on, on that space?
**Eric**: [02:47] The big one was Common Lisp. Common Lisp was written in the late '80s and really hadn't developed much since then. It has been modernized and ported to the operating systems at that time, but a lot of the Web happened in the '90s and so there were Web frameworks and stuff like that.
[03:11] That was were most of my time was spent, in Common Lisp. And it's actually a really nice system.
**Nader**: [03:17] Common Lisp, is that programming language millennials put on their Twitter profile and say they know?
**Eric**: [03:24] I guess so. I'm getting kind of old as long in the tooth. I don't really track what millennials are doing at these days.
[04:05] Nowadays, like with Clojure and other options, it's much more possible to be doing that and get paid to do it, which I think it's great. It's kind of what I'm trying to do with my business. It's called PurelyFunctional.tv. I make Clojure video tutorials.
[04:27] More broadly, I try to help people transition their career from the language that they might not be that interested in, that they're working in to a career in Functional Programming. And Clojure is kind of like the gateway drug for that. If you know Java for instance, it's an easier transition that learning something completely new.
[04:57] A lot of people who are trying to transition their careers, they got stuck in a language because there wasn't much opportunity in other languages back in the day. Now, they're older. They have a mortgage and kids and they're afraid that they won't find jobs and they'll have to take a pay cut, which is totally untrue.
[05:19] There's lot of jobs. The Clojure jobs are well paid. I try to help them transition over. Find the job, work on their resumè, get some side projects going. Learn the basics that they need. Really help them get going.
**Nader**: [06:01] Yeah. Since ClojureScript, you see it as a gateway drug, I agree with you. I think that a lot of people are looking towards taking this language, this compiled, or this checking that happens. This transpiling stuff.
**Eric**: [06:28] It's an interesting question. One thing that I have really thought about is, whether people, enough people to make it a profitable business, are actually going to be transitioning over to a new language.
**Nader**: [07:16] [laughs]
**Eric**: [07:16] They're just like, "Look, I can take this function and do this other thing. And I can represent numbers as functions." That's very fun and very useful. In fact, people who advance in functional programming, the better ones usually get into that stuff, because it is neat.
[07:35] In some way it rewires your brain to think of problems differently. As an introduction I don't think it's that useful. I would rather be able to teach someone how to use map, filter and reduce very effectively. In a way that you could show this has value to your code right now.
[08:01] You take your for loops and just replace them with map, filter and reduce, and your code is better. It's shorter, it's clearer, the intent is clearer. You have fewer bugs because there's less initialization to do at each point.
[08:19] Start there. Start with like the very basics. The stuff that you can guarantee is going to have a benefit.
[09:30] How can it be something where they don't have to spend 15 years to get there? Map, filter and reduce is a big thing. I see it even with Clojure programmers. People learning Clojure, they miss that things could be a map, things could be a filter, things could be a reduce.
[09:49] When I help them, I pair with them. I'm like, "This is obviously a map." I need to be able to explain, how do you see that? How do you see that this could be a map? It would be a lot of that. Map, filter and reduce, I would say, Lodash.
[10:07] Just teach Lodash and show how these things can be chained together and put together in new ways. I would love to get into higher order thinking, but I feel like it's a first course. Start using map filter and reduce and just see how much better your code is because of that.
[10:55] I almost forgot how to do it otherwise. It's almost enlightening to see him go through the process. It makes me understand, "OK, I have to figure out a path for you to get from what you're doing now, to being able to use map, filter and reduce."
[11:14] That's been super, super helpful for me as a mentor and a teacher. You forget about it.
**Eric**: [11:24] For sure. Especially teaching a language like Clojure, where you don't have for loops. People coming in, they're like, "So, how do I do a for loop?" I'm like, "Well, you can't actually do that. Tell me what you want to do."
[11:43] You have to guide them into thinking, is it something where you're taking an existing sequence and tracking all the elements? That's a map. Or are you removing some of the elements? That's a filter. Or are you building up another value? That's a reduce.
[12:05] Those ways of thinking are not really what people think. They think, "I have an array. It's got a bunch of elements. I'm going to make something new out of it." They just jump into a for loop and start iterating through stuff.
[12:19] It's just the way we're usually taught, and then we have for loops in most languages. They're used to translating their language from one to the other. It's more like, "What is the syntax for loops in this language?" Not, "What am I really trying to do here, and what's the best tool for that?"
**Nader**: [12:42] Essentially, the concept has to translate over as well, of staying away from mutating some state. What's funny is, when you look at it, you hit the nail on the head.
[12:58] Whenever someone comes from a different language and then they start looking at functional programming, it's like a 10-second countdown till someone mentions Monads to be all intelligent.
**Nader**: [13:12] Then the person just walks away pretty upset.
[13:17] That's going away now, fortunately. [laughs] People are being a bit less academic with functional programming. That's helping out people a lot.
[15:23] When the going gets tough, you don't call map, you just use a for loop.
[15:51] This was before I knew functional programming was a thing. I was applying at Trunk Club, and being like, "Hey, check out this Compose functioning. This is my function cook and this is my function eat. And then I can just wrap it in a cook and eat function, and just works out really nicely."
[16:14] Everybody was like, "That's cool, but we don't do that. We do object-oriented." Literally, a year later, we're looking at React and then Redux, and boom, Compose is right there. It's like, "Oh, wow. We could do this with that?"
[17:29] One of the things that is really appreciate is, he really breaks down — in the parts that he says are good, which are usually the functional parts — he really breaks down stuff into their component parts.
[17:48] In object-oriented programming, we tend to want to build something big, like a big class that does all this stuff for us. The problem is, when you have something big, it's much less likely to be A, correct, and B, reusable. It probably does something you don't want it to do in every case.
[18:14] Sure, it feels good when you do find a reuse for that, because it's big and you're saving all this code, but usually, you want something smaller. Smaller things tend to be more correct and more "timeless," I'm doing air quotes.
[18:55] Now you can do information hiding because you can return a function that will modify that thing, but nothing else can modify it. These are the things that functional programmers think about.
[19:09] This is functional programming, it's like using all these little pieces and composing them together into a solution that you want. As opposed to having a ready-made for you in this object that does all sorts of stuff.
[19:24] It holds state, has an interface, it hides the implementation details. It's like a unit of meaning. It does all sorts of stuff. It's like a namespace. If you read that book you start to see that these things are better when they are broken apart.
**Gant**: [20:12] You mentioned higher order functions. In React and React Native we have high older components, and higher order functions, and higher order functional components. Is that a functional programming principle?
**Eric**: [20:24] Yeah. It's very similar to what in object-oriented land is called dependency injection.
**Gant**: [20:34] Really?
**Eric**: [20:35] Yeah. The difference is, it doesn't require so much elaboration. Really, you're passing in a function that something else is going to call, just like a callback. That thing is going to call it but you don't know exactly how it's going to be called. It's part of the semantics of the thing you're calling.
[21:00] It just lets you start thinking in higher order terms. Meaning, you're not thinking like, "Oh, I have to construct this for loop." You're thinking, "Oh, this is a map, so I'm going to call map and pass it the function that I want done to all the elements."
[21:19] The same goes with higher order components. You can take a component as a...and the idea is that as much as possible, it's a function, it's just like a render function, and you pass that to something else, and that will transform it into a new component.
[21:39] Maybe it's a component that keeps track of its state. It has an undo or something like that.
**Gant**: [21:45] I have another question about React in general. I know with Redux, and with a lot of the modules and things that we're using in the React ecosystem, we see these curried functions.
[21:59] I'm curious, is currying a functional programming principle as well? I believe I may have read that somewhere. If so, how does that all work? I understand how currying works, but is it used in other languages as well?
**Eric**: [22:16] Yeah. Just a bit of history, currying comes from a person named Haskell Curry. Haskell is also...the language Haskell, the functional language, comes from his first name. Currying is from his last name, Haskell is his first name.
**Gant**: [23:17] That's interesting.
[24:18] Speaking of Haskell, that's what used to scare some people away. Somebody gets thrown into Haskell, where it is strict, it is insanely philosophical upfront. You say, not having a for loop. How about not being able to maintain any mutable variables at all? [laughs]
[24:44] You start to lose your mind when you're thrown into something like that from a different programming language. To me, it's really cool coming back to those same concepts, and seeing languages in entire libraries like Ramda where you can do these things.
[24:58] These are the real friendly ways to bring people into a functional set of programmers, those millennium goals with Lisp and such.
**Peter**: [25:08] Gant and I were just talking about Ramda before we jumped on this call. I've never used Ramda before, maybe once or twice when I was using the Infinite Red starter kit. I've always been like Lodash and Lodash FP, or just hand-rolling functions that I've learned from Allongè.
[25:28] I'm like, there's got to be better ways for me to do this than just have a bunch of hand-rolled functions. Exploring different libraries and seeing what works and what doesn't.
[26:00] It's good stuff. It complements the object-oriented stuff really well, and the procedural stuff. The problem they were running into was, when you start trying to use multiple libraries, you're using Lodash and you're using Immutable.JS.
[26:42] I think it's still a problem. you want to do things right. You want to do things as functional as possible, so you import all these libraries, they give you all these tools, and they don't quite work well together.
**Gant**: [26:54] Also, the fact is, a lot of the stuff is not baked into the language itself. We're importing and using all these libraries. Those things, they change, the APRs change. They add extra block freezing, if you're doing Web programming.
[27:11] One of the main things that I use Lodash for is to do map, filter and reduce on objects. I wonder why that isn't added into the language itself. Also, is that something you can do on other data structures, other than arrays?
**Eric**: [27:30] Yeah, for sure. In ClojureScript, you can do a reduce on a map, and it will give you each pair, meaning the key-value pair. Map is interesting, because map, you could actually just do something like map values and get the same structure.
[28:00] Meaning the same keys, but now all your values are changed. Or you could do something where you get both the key and the value, and you can transform them in some other way. The key set might be different when it comes out.
[28:14] There's different ways to do it. It's totally possible.
[28:30] I'm sure they thought about it but, I'm assuming there's a reason that it's not there. So many people use Lodash just for that reason.
**Eric**: [28:48] For the longest time, we didn't even have object.keys.
[29:32] That was the future. Now, here we are back. The longer things change, the more they stay the same.
**Gant**: [29:38] Let's not forget that this was just three, maybe four years ago. Not that long ago.
**Gant**: [29:49] Go ahead.
**Gant**: [30:28] [laughs]
**Eric**: [30:29] It worked. It worked perfectly. It just had no problems. We never had to upgrade. We never had to deal with any new features of the packer. It was just CAT.
**Eric**: [30:47] Yeah, that's what I remember. When people talk about, "Oh, I'm trying to configure my bower," I'm like, "I have no idea what you're doing. I just run CAT."
**Gant**: [30:59] I wonder if it would be possible to create a Babel plugin that allowed you to do these things and add these things to the language. Is that something that you can do with Babel? I mean, from what I understand it is, but do you think it would be something...?
**Eric**: [31:17] I would really love to see that because when people started transpiling, like everybody's transpiling now, and importing all these modules from the future like Level Zero. I thought we would start seeing more home-grown modules that did this kind of stuff.
**Nader**: [32:03] That may be an experiment. I may try to create a module, or a Babel plugin that does object.reduce, and object.mac, and object.filter.
**Peter**: [32:14] It's fair to say at this point, as React Native developers, we've always been benefiting from Babel. Now, take this with a grain of salt, there are quite a few people who know quite a lot [laughs] more about this than I do.
[32:29] With React Native packager, and I'm sure — Eric, I don't mean to step on your toes on this one, but it definitely...I think he was going to talk about it for a second — but moving off into its own library and the ability to tie in at the Babel level with our own CLI config.
[32:52] Even though we've been writing ES7 and all the fancy stuff that's getting transpiled for React Native development, recently it's really opened up the transpiling initiative so you can do just about any language that transpiles and start getting things moving real fast.
**Eric**: [33:16] Yeah. Wow. I have a lot to say about that. First thing I want to say is, "Yes, it is awesome that it opens up everything," because it puts all languages on an even playing field. I mean, basically, if you're transpiling anyway, why not choose the language you want.
[33:36] That means you could do PureScript, or TypeScript, or ClojureScript. Why be stuck with ES7, and especially when it's still being modified so you do it in upstate and your level zero stuff starts breaking?
[33:54] Anyway, you have this opportunity because everything's getting put — everything's transpiled now, just transpiled from what you want. The other thing I have to say is that I don't know how that's going to affect ClojureScript, because we've had our own tooling to build React Native stuff for a long time.
[34:18] We built on top of what was there, instead of — not to be derogatory or anything — waiting for React to support this...
**Peter**: [34:28] Good call.
**Eric**: [34:29] We've just built on top. We have had live code reloading. Basically, you're running your program in your iPhone simulator or on your phone, and you type some code, you save it. It gets compiled automatically by the Clojures group compiler.
[34:56] Not really even touching React at all, not talking to it. Through a WebSocket, it sends the phone a command that says, "Hey, this file is updated," download it again and it just reloads it and you see the change right there. You don't have to shake your phone. You don't have to lose where you were, so you can do...
**Peter**: [35:52] Yeah, I mean it's amazing that ClojureScript went that far before these toolings have been opened up. I mean, it's amazing to me. It speaks to the mettle of the people just to say, "Oh, yeah, well, this is available? "No." "OK, well, we're going to do it anyway." [laughs]
**Eric**: [36:13] Yeah, I think we were lucky that a lot of the stuff already existed because that's the way we would program the web too. When React Native came out, someone had also been experimenting with how do you do live coding on an iPhone in ClojureScript, and so they just hoarded all these pieces and made this system that works well.
[37:13] Is it going to be every company that you work with is going to say, "Hey, we wrote it in this language, we need you to go ahead and continue working with this language now," and then you switch over and you have to relearn everything again, almost wish there was...which ones are doing the best?
**Nader**: [37:42] Yeah, it could be a thing like how we did see the fragmentation languages were in the frameworks where there was a lot of fragmentation for a couple of years, but now we're seeing a little less fragmentation that people settle on a couple of things.
[38:12] I know there's other issues other than the syntax that some of these other languages bring to the table, such as types and things like that. I have a question though. This is about functional programming in general.
[38:27] I see this ML syntax, it's ML tacked on to different languages like ReasonML and OCaml. What does it ML actually mean? Is it something that people add to a language name to represent that it is a functional language? Where did that come from?
**Eric**: [38:46] ML is one of the original-typed functional languages. It's actually standard ML.
**Nader**: [39:02] ML is an actual language in of itself.
**Eric**: [39:06] Yeah. It is the pre-runner for OCaml, for Haskell, and then all the ones derived similar to Haskell, like Elm and PureScript. It's just an old language that was functional and had the stuff that you're used to, currying, pattern matching, type inference, that kind of thing.
[40:32] I've always considered Lodash the standard, the library I'm always going to use. I even have several flavors of that library to use. I'm sure there's many more.
[41:41] I'm sure that at some point, the more functional languages are going to influence it again in terms of what features get added officially to the language. I think that you're going to see a few splinter groups for people who, I don't know, feel like, for some reason, there's an advantage there.
[42:08] That's going to feed back into the main group slowly. This is 20 years we're talking about. That's my prediction of what's going to happen.
**Nader**: [42:18] I have a question. Have you looked into Reason at all? If so, what do you think about the language, or the tool, whatever they call it?
**Eric**: [42:26] I haven't looked at it. I feel like things are moving so fast that often, I'll look at it and be like, "That's interesting." I put in a folder to read later and I realize that there's like 300 things in that folder. [laughs] What is Reason? Tell me. Give me the one sentence.
**Nader**: [42:49] I haven't looked at it a ton. I don't know, Peter. We had a guest on last week that specializes in reason and that episode will be out probably next Monday. I'm looking forward to listening to that. From what I understand, it's basically a tool-chain built on top of a Caml.
[43:03] They're using it at Facebook. They're replacing a lot of their code at Facebook with Reason, to the best of my understanding.
**Eric**: [43:10] This is to replace Babel and web pack and stuff like that?
**Nader**: [43:14] Well, it's also compiled to JS language. I want Peter to take over.
[44:09] You can learn Reason and get the same benefits of OCaml, Immutable, the performance that comes with it but not having to relearn all that syntax all over again.
**Eric**: [45:02] That's interesting.
**Gant**: [45:02] That's really interesting. I just want to say for a second there just to tie up a few things. There's definitely a jump across a bridge to switch languages. I see that there's definitely things missing. I want to take a moment and say I think it's awesome that Facebook's going that direction. I think they needed to pick a direction and go towards.
[45:53] Now, if you're willing to switch languages and you're willing to go the full length, I honestly would say, "Go ahead and take a moment, maybe look at PurelyFunctional.tv, take a look at the other languages."
[46:07] I wouldn't just jump in because Facebook says, "This is what you should use." I say like, "Take a look at ClojureScript, take a look at all the other ones. If you're looking to switch languages completely, take a step back and spend some time on it."
[46:37] I am happy Facebook's doing this but I can't barrel down after the OCaml train and say, "Yes," because I remember I was at the talk when they announced this. I was like, "What are they talking about?" [laughs]
[46:53] I don't know if the clarity is continuing to grow but I would do some home investigation with that stuff. It sounds like you've done a lot, Peter. Honestly, Eric's got the most experience with these functional programming languages, so I'd probably ask him.
**Eric**: [47:32] Yeah. This is a really hard question because I think everybody's different and they're looking for different things. I think TypeScript and Flow are really interesting because if you're looking to learn the typed functional languages, those two...
[47:55] I think Flow might be a little bit better for this, but if you're looking to get into typed functional programming without really changing languages, that's really awesome. If you want to jump right in to a language that has a really good beginner focus, and I think it's only for the web right now, but there's Elm.
[48:23] Elm has amazing beginner experience. Type errors in functional languages are really bad in general and really hard to decipher, and you'll spend so much time just trying to get your thing to compile.
[48:43] Elm has such good error messages and it's kept a very simple type system, very powerful but simple. It's simple enough that they can cover all of the error message types and give you really nice messages from them.
[49:30] Now, ClojureScript is separate from those because it's Type. It's not strongly typed. If you are into more of the...you want Immutable data structures, you want higher order functions, you want a good standard library, and you want good interop, but you don't want to have to learn Types, you can learn all that stuff in ClojureScript.
[50:00] I would say, ClojureScript for React Native and for React development is really a nice experience. Like I said, you have the live reloading, there is decent error messages. There's source maps so you can debug right in your original source code. The set-up is a couple of commands, install a few things and then you type go and you can start editing code. That's my recommendations.
**Nader**: [50:39] Eric, we got off track at the beginning of the show but I'm curious as to what you do right now and what you're working on and your day-to-day career and your day-to-day work.
**Eric**: [50:51] Right now, I am full-time working on a company that I started called PurelyFunctional.tv. I'm mostly making video tutorials for Clojure and ClojureScript.
[51:09] That is a lot of work, running your own your own business. Right now, it's mostly subscription-based. What I mean by that is there's an all-you-can-eat subscription. You become a member. There's a monthly fee or a yearly fee. You get access to everything, old and new, new stuff as it comes out. You can also buy the courses individually.
[51:36] It's a much better deal to just go all in and get everything. I try to keep everything super practical, that means making sure that this is going to be something that people actually want to use. I do like to go a little bit into theory and philosophy. Mostly, it's like, "Let's get something done. Let's get something working."
[51:59] Not to limit anybody, but my main audience is people who want to learn functional programming to use at work. Either their current job or future job that they'll transition to.
**Peter**: [52:16] I see you have a ton of videos here. Have you become a master of creating video tutorials during this experience of creating your own business? Because I'm getting into that whole video tutorial thing and I've put quite a few on YouTube, and I'm going to be adding more. I found it to be much more challenging than I ever thought it would be.
**Eric**: [52:38] It's tough. I've been doing it for a few years now, so I've probably forgotten more than I even know. When I started, it was like a Kickstarter, and I just wanted to do intro to Clojure. My first idea was I'm going to make like all of Clojure on videos.
[53:00] Then I would want something like \$50,000 on Kickstarter to do that, and I could quit my job and just live off of that. Then someone convinced me, "Hey. If someone gave you \$3,000 would you make something smaller and not quit your job?" I said, "Yeah. Probably."
[53:21] Then I reduced the Kickstarter down that, and I reduced the scope to just be intro to Clojure. When I did that, I spent a lot of time on production quality. I got a microphone. I worked on slides and put animation in them.
[53:38] I made sure every little bit worked together to make this really cohesive whole. It was great. I think it works really well. The problem is, the courses take a long time to make. While I'm making the courses, nobody's learning. They can learn from my older courses but they can't learn the new stuff.
[54:06] Over time, I've focused more on content and less on polish, like video polish. I find that people are just insatiable for content. That's my advice. If you're going to get into this, really think about where the sweet spot is between quantity and quality.
[54:36] At this point, I'm better off making a course quickly or making even one lesson, getting it out there, and getting people asking me questions about it. I can put those answers into the next lesson.
[54:52] Whereas, if it takes three months to even get the course out there before anyone can see it, because you want it to be a totally coherent whole. You don't get that feedback, and you have to do that much more prep upfront, to make sure it is answering every possible question.
[55:13] I think a lot about this. I think about the best way to film. I've got a whole setup for recording my keystrokes and stuff, my screen as I type in an editor. It's a lot of little pieces.
**Nader**: [55:31] It's a lot of little pieces, and it's a lot of being aware of all of these little things going on, putting them together. When you watch a video tutorial, you don't really realize all of the work that's been put into it, until you actually try to do one yourself.
[55:47] It's been really, really hard getting used to it. I've gotten much more comfortable now. When I kick off a new video, I always feel extremely awkward at first. Maybe that feeling goes away after a while. [laughs]
**Eric**: [56:03] I think it does, especially if you do it more often. Not just a number of times, but more often, you'll still be in the zone, for the next one. You talk about the details. One of the details that I had to figure out was not to have my cursor blink.
[56:24] Video stretches and compresses well. Meaning, you can stretch the time and compress it. No one wants to watch you type at 1x. It's too slow. They can read much faster than that. You put it at maybe 2x or 3x. Your cursor is blinking so much, and then there's some parts where you want to slow down, and now it's blinking slower and it's just a distraction.
[56:48] There's all sorts of little things like that, like configuring your editor so that it looks good on different screen sizes. You can play with the video in different ways. Making it so that if you make a mistake, it's OK. [laughs] You can fix it in post, or you can redo it. All that stuff. It's really hard to figure out.
**Gant**: [57:14] I know that this is "React Native" podcast. I feel like if we got the three of us in a room and start talking about the process of making screencasts, that would be a really cool chat just in by itself. Peter is working on his microphone setup.
[57:33] As being a developer becomes more and more communicating via technology, being a remote developer, or being somebody who has to send a message to someone else. Not just through their app, but through their videos and their communication.
[57:49] There's an entire spectrum...Nader, you should make a note here, man. We could a special podcast just on all this stuff alone. I am enthralled in what other people have gone through in figuring out the same stuff. That's amazing [laughs]
[58:06] I feel like there's definitely a need for helping others out there — especially people looking to buy their own microphones — go through the process. Maybe even understand what editing and post feels like.
**Eric**: [58:22] Once you edit, you're not done. You still have to encode your video. There's all sorts of stuff.
**Nader**: [58:29] That's a great idea. We can do an entire episode on content creation, including podcasting and screen casting, and even a little bit about blogging.
**Gant**: [58:43] That's awesome, yeah. Bring Eric in. I'm sure there's quite a few other video people that would be good for that.
**Eric**: [58:49] Those are careers of their own. How do you find the time to figure out podcasting stuff? I'm literally looking at a freaking Canon 7D that I set up on a tripod, that I've been trying to figure out how to throw into my workflow for videos. Versus just using my laptop camera.
[59:12] Then dealing with that footage. Then I'm like, "Crap. Do I really want to deal with 1080p plus footage right now?" Or, "Isn't it just easier to take it right off my laptop camera?" Stuff like that too.
**Gant**: [59:26] Exactly. Not only that. That microphone, if you're doing a video meeting tomorrow or the next day, you can't have the setup where it's going to be in frame all the time as well. There's a million questions. There's a new science here. [laughs]
**Eric**: [59:44] Yeah, for sure. I'm seriously thinking about having single purpose computers. I'm going to record...One is just for editing video. One is for my coding work that I still have to do. Another one is going to be for recording the video. It's going to have a nice camera, USB connected right into it.
[60:15] We're getting to that point where moving a laptop around so that you can be in different places, it's not working anymore. I'm going to need...
**Eric**: [60:29] for everything.
**Gant**: [60:30] Take a look at musicians. They don't have to write their songs in the studio. They just have to be [inaudible] record it there.
**Eric**: [60:37] Then the problem is getting all the data to where it needs to go.
**Gant**: [60:40] [laughs]
**Eric**: [60:41] Video files are big.
**Nader**: [60:43] All right. Cool. We'll definitely do that soon. [laughs]
**Eric**: [60:51] Yeah, count me in.
**Nader**: [60:52] We'll definitely do that. We'll bring you back on for that. We'll go ahead and jump to the picks now. I'll start with Gant. Do you have any picks today, Gant?
**Gant**: [60:57] Absolutely. I have to say that I don't know when this recording's going to be out there, but for sure. I want to say that the Chain React Conference is coming up. As of this recording, it's in 13 days.
[61:11] You will see such fantastic people, like Nader will be doing a presentation there. It's really exciting to have the React Native conference in the US happening soon. I'm going to see all my favorite people.
[61:28] Eric, I'm surprised you didn't submit a talk. That would've been a good one for you to come out there, especially with all the React Native stuff, so you better submit next year.
[61:36] The videos will be available of course, if you're hearing this after the conference, we'll be going through con freaks. You'll see everything that you want, and it will be fantastic that you'll have missed an amazing conference.
**Nader**: [61:52] Totally looking forward to that conference, can't wait. I need to talk to you about the talk name, because I believe they saw my old talk name on the app, but I'll touch base with you later on today about that. Peter, do you have any picks?
[62:22] Anyway, this one's rewritten, ES2016. Definitely check it out. A lot of the stuff that we talked about today, Reginald Braithwaite goes into very good detail, especially how you can apply it to everyday work scenarios.
[62:41] If you read it online, it's free. Otherwise, if you want to buy it, it's \$35. It's definitely worth buying it because it's been an incredible book, and it's definitely helped shape my career.
**Gant**: [62:53] I tell you what, I'm buying that book right now.
**Nader**: [62:55] [laughs] All right, Eric, do you have any picks?
[63:21] Even though those are way more idiomatic, they don't do it. I read a book called "Refactoring to Collections," which is about functional PHP.
**Nader**: [64:26] My pick is going to be Graphcool. I'm not sure if we picked this before or not, but I've just thought of using it. It's basically a backend as a service for GraphQL.
[64:39] I would say it's similar to Firebase, or something like that. I got up and running with it about a week ago. Really enjoying it and I think we're going to have those guys on the show in about a month or so, so check out for that.
**Peter**: [64:52] I'd like to suck in to Graphcool. I'm more of a startup person than I am an open-source person. I used to spend all this time writing MySQL queries in Postgres, and then writing the APIs, and then figuring out how to connect all the data. Now, I literally just make my GraphQL Schema directly in Graph.Cool, and it just works.
[65:19] Definitely an incredible tool, just wanted to give them another shout out.
**Gant**: [65:22] Additionally, I want to say that, Nader, you did an amazing article on Medium. I was talking about React Native and such. I know you didn't want to pat yourself on the back with that one, so I'm doing it for you.
[65:37] Definitely, look at the React Native training Medium articles that Nader is putting out. Especially if this pick seems foreign to you, a good way to pick it up is to look at what he is writing.
**Nader**: [65:48] Thank you. Yeah, that post did pretty good, and I'm going to be having a new one come out this week as well about Microsoft Mobile Center, adding analytics and [inaudible] . Check out the blog when this comes out, you'll see two fairly new articles. OK, well, that wraps up episode 68 of React Native Radio.
[66:08] Eric, thank you so much for coming on the show. I think we had a really deep dive into functional programming. I think that a lot of people are going to enjoy it.
**Eric**: [66:15] Great, I had a blast. Thank you for inviting me.
**Gant**: [66:19] Yeah, we'll definitely see you back when we talk about [laughs] podcasts and recording, and all the other cool stuff, especially as you being a person who records that stuff. Wow, I think that that plus functional programming is really hot right now.
**Eric**: [66:35] Yeah, I'm a trend setter.
[66:39] [background music]
**Nader**: [66:51] Count me in. Thanks everyone for listening and we'll see you all next week.