225 JSJ Functional Programming with John A. De Goes
03:08 - John A. De Goes Introduction
- SlamData 04:07 - PureScript
- Object-oriented Programming
- Procedural Programming 14:36 - Organizing a FP Codebase
- John A. De Goes: A Modern Architecture for FP 17:54 - Beginners and Functional Programming; Getting Started
- Learning About the History of Functional Programming
- Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 (Aimee)
- React Rally (Jamison)
- Cleanup Algorithm (Jamison)
- PostgreSQL Exercises (Jamison)
- iPad Pro (Chuck)
- Smart Keyboard for iPad Pro (Chuck)
- Apple Pencil (Chuck)
- GoodNotes (Chuck)
- John A. De Goes: Halogen: Past, Present, and Future (John)
- slamdata (John)
CHUCK: Jamison Dance.
JAMISON: Hello, friends.
CHUCK: I'm Charles Max Wood from DevChat.tv. And this week we have a special guest and that's John De Goes.
JOHN: Howdy. Good to be here.
CHUCK: Do you want to introduce yourself real quick?
JOHN: Yes, so I'm John De Goes. I'm currently CTO at a company called SlamData. And we do quite a lot of frontend programming. In fact, we just came out with release 3.0 of SlamData out today. And it is probably the largest PureScript codebase in existence. So, it's an example in the wild of both functional programming and alt JS. A hundred percent open source and available on GitHub for people who want to take a look at what sort of scale that looks like in functional programming.
CHUCK: What do you mean by alt JS?
CHUCK: Interesting. So, why build it in PureScript and go all functional programming on it?
JAMISON: Well first, can you tell us what PureScript is?
AIMEE: I have a quick question actually. Can you explain what you mean exactly by purely functional?
JOHN: Yeah, that's a great question. So basically, purely functional means that if ever you see a function inside a purely functional program then you have the following guarantee. If you pass the function the same arguments, you'll get back the same return value always. And that's actually the definition of a function, really. It's a mathematical function, maybe not a programming language function. But it's a really nice property to have because when you're testing you know if always pass it one, two, and three, you're always going to get back the same value. It's not going to change out from underneath out. And this property of being purely functional makes code not just easier to test but also easier to understand in the large scale because there's less state that you have to keep track of in your head.
Whereas a function that's not purely functional, you pass it one, two, three one time and it will return, “Hello world.” You pass it one, two, three another time it'll return undefined. Pass it one, two, three another time and it's going to pop up an alert. Who really knows what's going to happen? Because its behavior is not dictated by its return value. It's dictated by all the other stuff it's doing behind the scenes, all the global variables it's reading and the console logging functions that it's calling and this and that. And purely functional programs don't have that property. It's all, “Pass me your variables and I guarantee you I will always return the same thing.”
CHUCK: So first off…
CHUCK: I want to mention. We asked real quick what PureScript is but if you want to know more about that, we did an episode with John and Phil Freeman back in December. So, you can go check that out. We'll have a link to that in the show notes.
And secondly, it seems like if you're building an application with purely functional stuff then what about things like the global variable called your database? Or things like that where…
CHUCK: You have to deal with that, right? Or an API that you're hitting or something like that. Can you write real-world applications with purely functional stuff?
JOHN: Yes. And in fact you can. In fact, why don't I paste a screenshot into Skype? You can take a look and maybe upload it for your listeners. But this is an example of the kind of real-world application you can build. Alright. So, the question is can you build real-world applications with functional programming? Which is actually probably the most common question that I get when I tell people that I'm a functional programmer. And the answer is, well look at that screenshot there and it will give you a taste of the type of applications you can build in a purely functional style. And yeah, you're right. There are things like databases and things like web servers that you have to call. And all of this involves lots of state. And purely functional programming languages, they have a bunch of means to deal with such things.
And the simplest is just to basically describe such effects as a hunk of code. So, when you call a function that does like a 'run this query on this database' you get back not the result but you get back a promise to run that result at some future time. And this is the idea behind Haskell's I/O monad. And it's the idea behind PureScript's F type and it's the idea behind a lot of ways to model the impure messy stuff that happens in the real world. And what it does is it means that you pass a function a parameter like its SQL query and you get back this promise to run this hunk of code at a future time, which enables you to have a purely functional way to model that thing that we need to do, which is things like global state or third-party web services and so forth.
And yeah, if you're going to write your whole functional program in that style by passing around hunks of code it's going to be a lot harder to test and a lot harder to reason about. But fortunately in most cases, you can write 90% of your program in a way that's much more declarative and easier to reason about where you're not just passing around hunks of opaque code but you're actually describing your problem at a high level and a declarative way. And then for the messy stuff that every single program has to do, you end up passing around these hunks of code or an equivalent technique. That's actually not the only technique in functional programming. It's not even the one used in SlamData. We used a more advanced one but it's just the easiest one to describe.
JAMISON: So, I have a few questions. So, I wasn't programming when object-oriented programming became the solution to everyone's problems.
JAMISON: But I imagine it felt a lot like it feels to hear about functional programming. Like everything is better if you have these objects. They encapsulate all their state. They send messages to each other and you bundle their behavior in your data. And you just get this long list of amazing benefits. And we have those with functional programming too, right?
JAMISON: Easier to reason about is one of the key phrases that every functional programmer loves to say. And pure functions and easier to test. But there's this giant laundry list of problems with object-oriented programming and some downfalls it encounters in the real world. And I feel like I don't hear any of that side about functional programming. Do you feel like you know enough to talk about maybe some of the weaknesses with functional programming? Things that it struggles with or that teams might struggle to adopt it with or anything like that?
JOHN: Yeah, that's a good question. So, I think that many of the problems in object-oriented programming, they became apparent after people started writing multi-million line of code applications and maintain those over some period of time. And as anyone who's ever worked in a Java codebase of that size knows well, your application becomes so incredibly coupled. And reasoning about something becomes very, very difficult. And of course programmers being programmers they end up making shortcuts in many cases. And that leads to things like singletons for basically passing around information, avoiding the need to propagate information through a billion different methods. And you see all these sort of just grossly coupled and stateful patterns emerging in object-oriented programming in the wild at that scale.
Functional programming has been around long enough. Unfortunately we do have millions of lines of code codebases out there. And I'm not seeing the same types of problems that I see with object-oriented codebases. I think there still are problems. [Chuckles] Any time you try to scale an application by number of people or by size of the codebase you're going to run into problems in any paradigm. But I think the types of problems that you run into in functional programming are more similar to the types of problems you run into in C. obviously you don't run into all sorts of the same problems. But organization of your codebase, how do you really organize a functional codebase well in a way that lends itself to comprehension by developers new to the team, enables people to find what they're looking for…
JOHN: Helps reduce, reuse, and so forth. Those kinds of concerns that you see in a large C codebase, you see in large functional programming codebases as well. The discoverability and the ability for someone to just jump right in, know what to work on, know where to put stuff, that is an issue in large scale functional programming codebases. But what you don't see is a lot of the super tight coupling between state. And you see this to some degree… I often talk about purely functional programming as being a strict superset of procedural programming. Anything you can do in an imperative programming language like C you can do in a language like PureScript, only you can do it better and easier. [Chuckles]
So for example, you can pass around functions instead of passing around void pointers that need to be functions. So, you can do all the same types of stuff which means that you can literally just transition your codebase to PureScript and it can just look like a C program. And it'll be a C program with maybe stronger type level guarantees. But it will suffer from all sorts of the same problems that your C codebase does when it comes time to reason about that. So, you actually have to work to improve it. But I'd say your baseline level of quality is basically like a C program codebase and suffers from all the sorts of problems that a large scale C codebase does.
JAMISON: Except seg faults. [Laughs]
JOHN: Right. [Chuckles] You know, you are guaranteed no seg faults.
JOHN: No null pointer exceptions, no undefineds.
JOHN: None of that nasty stuff. And that's a benefit of total functional programming as you call a function and you're going to get a value back. And it's not going to throw an exception. It's not going to give you null. It's not going to give you anything except what its type tells you. And having that ability in a large codebase just has a tremendously simplifying effect on the way you reason about it.
JAMISON: So, it sounds like you're saying there are still… it's not a silver bullet but the baseline of just you go to write some code, you don't think about it a ton, the end result you'll get in a functional programming language is easier to maintain and better than in I guess a procedural or object-oriented language.
JOHN: Yeah, I would say that. I would say even if you don't spend a lot of time working to overcome your natural desire to write everything imperatively the baseline is going to be a bit better than what it's like in an imperative programming language like C and certainly substantially better, at least my experience has been that large C codebases are easier to work on and easier to add people to the team than large Java codebases.
JOHN: Although your mileage may vary.
JAMISON: Sure. So, I'm glad you brought up the organization thing because that's a thing that I've struggled with in functional programming is I just end up with a bag of functions.
JOHN: Yeah. [Laughs]
JAMISON: And everything feels like it's at the same level of abstraction. It takes in some stuff and puts some stuff out and they're all just kind of grouped together in the order I wrote them I guess. So, how do you organize a codebase?
JOHN: Yeah, I think that's a good question. And I think the answers to that are still emerging. But I would say that first off, that feeling of I just have a bag of functions, even though it's sort of revolting a little bit right, because [chuckles] if you're used to object-oriented programming or even procedural ones you have standard ways of organizing code in these. And it's a bit more foreign when all you have are a bunch of pure functions and a bunch of data constructors. It takes on a different feel.
So, what I would do is say first off, it's not such a terrible, awful thing that all you have is a bag of loosely coupled functions. Because in the long run, the fact that those functions and the data are not strongly coupled is most likely going to enable you to more easily change that codebase over time. Because you'll be able to throw away half the functions without really having an impact on the other half. And that's one of the properties that I've seen in larger functional codebases is you can literally just throw stuff away and replace it with new stuff. And there's less layers of tangling and coupling that you see in imperative codebases. So first off, that's not necessarily a bad problem to have. But I do see that.
And I think that to some degree the answer is grouping related functionality together, so for example data and functions that operate on those types of data structures. And if you are in a language like PureScript that has type classes then you group type classes and then instances for the type classes with data that implements them and so forth. So, you have baseline levels of let's just keep stuff that works on the same data structures or works on the same type classes, let's keep all that stuff together. And that works reasonably well but it still doesn't give you any sort of clue or guide for how you do the large scale architecture of your program.
And what I've been recommending and an approach that I've been a big, big advocate for is so called modern architecture for functional programming in which you structure your application as almost a series of layers of an onion. And in the innermost part of your program you're talking the business language. So, your acceptance tests or whatever you have, whatever is driving the requirements for a product, you're speaking that language. And then you express that language in terms of a lower-level language. And ultimately you sort of boil everything down to Ajax calls and DOM effects. But you don't speak in those terms right away. You speak at higher levels of abstraction and gradually compile down to a lower-level abstraction.
And I wrote a blog about this on DeGoes.net. It's called 'Modern FP Architectures', something like that. But I'll also be writing the sequel to that in the next week or two. So, it's actually pretty timely. And I do think that of all the approaches I've seen to organizing large scale functional programs, that's by far the best. And it shows a lot of promise for the future, in my opinion.
AIMEE: So, I wanted to back up a little bit and ask a couple of questions. I know the last time that we talked to you, I had some of these questions. But I feel like functional programming is pretty intimidating to a lot of people. So, I just wanted to bring that up because I feel like as we're talking there might be listeners… there's kind of like this elephant in the room where especially for new beginners. I know, I worked in a codebase at one point and we made the choice that we would not use currying or partial application because we wanted the codebase to be super readable for all different skill levels. And for somebody straight out of a bootcamp or something, that's not always the most readable. So, I guess I kind of… I don't have a specific question. Just your thoughts around this topic. So, do you think it's still a good choice for a codebase where you want to work with people of all levels? And then another question is what advice do you have to people, I'm assuming you've been programming for years, but what advice would you have to people who are interested but they're feeling intimidated? How do you get started?
JOHN: Yeah, so those are really great questions. And I think to answer the latter one first, hopefully I won't forget the first one [chuckles]. It's [inaudible].
AIMEE: I can [re-ack] it.
JOHN: [Laughs] Okay.
AIMEE: I know. That was just a lot of thoughts and questions all at once.
JOHN: No, that's good stuff. I think to take that latter one first, I think well first off, first time I tried to learn functional programming I failed. [Chuckles] I went [inaudible] and I…
AIMEE: That's good [to hear]. [Laughs] Thank you for admitting that.
JOHN: I'm happy to admit that. I went and I played with Haskell and thought, “No, I don't know this syntax. This isn't C-like or Java-like. And what are all these strange terms? The [mere] operators. And what's infix L mean? And what's all this crap? No way.” And I just ran away from it screaming in terror like most people do.
JOHN: Because it is. It's different and different can be scary. But eventually I sort of crept into functional programming through the back door by just seeing what a difference on a very large 400,000 line of code Java application immutable data structures made. And how just profoundly simplifying that had on the application. Just a simple thing like immutable data makes a huge difference in your application. And eventually that enticed me to learn Scala and I picked up functional programming from there. And then the next time I went back to Haskell I'm like, “Okay you know, this is less terrible than it was to begin with.” But I think to answer your question, yes it is unfamiliar and it's unfamiliar not because it's necessarily very complex. Or rather, it's scary not because it's complex but it's scary because it is unfamiliar.
But I do want to acknowledge the fact that the first time I went there, I ran away screaming in terror. And it took me a while to get back into it. And what I would say is one of the strengths that we can cultivate as a developer is the ability to learn new things.
JOHN: That's right. And Elm was obviously designed to address that gap. And I think it does a reasonably good job. A lot of people who tried Haskell that, “Nope, not for me,” the tried Elm. And they're like, “Yeah, this is still a big leap but I can sort of get it.” And I think that's a great way to approach it is find something intermediate like Elm. After you've done the, “Okay, immutable data and operations on immutable data structures,” with some of the libraries out there like Immutable.js, and the next step is, “Okay, what's going to get me on the other side of this divide?” in a language like Elm where you have a lot of the functional concepts but they've been greatly simplified and the tooling is really excellent can help you get over to that other side where you can begin to approach languages like Haskell and PureScript without fearing as much.
JAMISON: Than they are to the statically typed purely functional family of languages. And a lot of that I think comes down to their genealogy. Like our purely functional languages tend to come from an academic history and background. And they're a lot more linked to some mathematical research stuff. So, they just have a… it's like a different family of spoken languages, right? There are the dramatic languages…
JOHN: That's right.
JAMISON: The romance languages. If you learn one of those, it's pretty easy to learn all the rest of them. But then if you learn a bunch of romance languages and you try and learn something like Mandarin…
JOHN: [Chuckles] Yeah.
JAMISON: All the [rules] you've [pumped] up in your head about, “This is generally how languages work,” just get thrown away completely and there are a whole bunch of new concepts. So, recognizing that actually helped me because it made me feel less bad about being totally baffled and bewildered by these new concepts.
JOHN: I love that analogy just with natural languages, just the fact that there are families and the syntax can be a big thing for some people. Even if the concepts aren't that complex, especially in a language like Elm, it does have a totally different syntax. But once you learn that one thing over there in that family of languages, the others become a lot less [intimidating].
JOHN: And I think we're to some degree, we're still figuring out how to teach this stuff. There hasn't been the same level of effort put into educational resources in functional programming that there has been in object-oriented programming. So, we all know how to teach object-oriented programming now, right? Like you have your standard animal hierarchy or a [shape] hierarchy.
JOHN: These things that we've all seen a million times and we know how to teach that. But I think we're still figuring out, we're making progress with things like HaskellBook.com. But we're still figuring out how to teach this new style of programming. And once we become better teachers then a lot of this stuff is just going to take care of itself because you'll have so many people who are writing functional programming, is familiar with the concepts, and who know how to explain it to others because that path has been forged. It's going to become a lot easier for the population in general. And then your first question was how do you introduce it to a team or do you introduce it to a team?
AIMEE: That was kind of a question that I had too. Yeah, do you think it's a wise choice…
JOHN: [Inaudible] levels?
AIMEE: For a team where there are junior developers and senior developers all on the same codebase?
And I'm not going to say it can't be done because actually my company has done it at least once, taking a graduate from a coding camp and bringing her all the way up to functional programming. But it's not easy and it's not natural and it requires a certain degree of support and help that may or may not be there depending on how the team is structured and management's expectations around new hires, especially junior hires. So, I would honestly not choose a statically typed purely functional programming language for the frontend if I knew that we were going to be hiring a bunch of people from coding camps and a bunch of junior developers unless management understood what was going on there. And gave their support to offering an additional level of mentoring and pair programming that's necessary to more quickly ramp these people up into totally different paradigm and language and syntax.
And once the codebase crosses a certain threshold then you accept that any new feature you add is going to add its line count in bugs, in new bugs into the code. It's just become very, very important to have QA and then you have a manual QA process. The complexity of user applications is just tremendous especially compared to a lot of the other types of applications I've worked on. The potential for bugs, the amount if state there is insane. And the ways that you can tangle up a frontend and I've one many times with jQuery doing terrible, terrible things that I don't even want to talk about with jQuery and dynamic, treating the DOM as a database and all sorts of other things that I've done. I've created applications that I couldn't even understand myself six months after I wrote them let alone maintain them.
And I think that this complexity problem and this state problem and this maintainability problem, this comprehension problem that we have, this testing problem… how do you test these things? Selenium is crap. WebDriver is crap. All that stuff is terrible, varying degrees of terribleness. And functional programming comes along and says, “Well maybe [chuckles] our view should be a function from state to a bunch of DOM, a DOM model, a DOM data model.” And that is just sort of a profoundly, that's yeah, that's a profoundly simplifying way of solving the user interface problem. So, I think that… and also things like observables, Rx and Cycle.js and its family of programs in which you reason about things using streams, more like Elm, it has a profoundly simplifying effect on the way that you reason about your frontend user application.
That would just be a guess though. Honestly I've wondered the same thing, why you're seeing all this functional activity on the frontend. But I think that has to be at least part of it.
JAMISON: Sure that makes sense.
CHUCK: So, let's say that you've completely convinced me. Functional programming is the stuff. And I've got this procedural/prototypal/jQuery/mess that I'm dealing with right now and I'm like, “Well, if it simplifies it that much I've got to try it.” How do I start fitting my current application into a system like this so that I'm getting these benefits out of it? It's one thing to start fresh. It's another thing to move a working application into a paradigm like this.
JOHN: Yeah. I think that's absolutely correct. And I think that there's always going to be limitations with existing applications. And that's because you've got customers. You've got deadlines. You've got stuff in your sprint that has to be shipped. You've got all these external pressures that are going to be driving you to make changes incrementally and in a way that minimizes risk but also minimizes value, too. That's one of the flip-sides. So, I think that you sort of have to accept. If you're starting off with a jQuery UE application then there's… you can't expect to change the world. Certainly not all at once. Over time I think you'll be able to make some progress in improving the way that code is structured. But it may be more through application of principles in functional programming versus… you're never going to have the time most likely to just do a wholesale rewrite to React or rewrite to Cycle or rewrite to one of these other different paradigms. And most likely you're not going to have the option of going with an alt JS language like Elm of PureScript. You're just not going to get there.
So, what I would say is if there's one thing that you can do incrementally is it's to focus on making your functions pure over time. Focus on using immutable data structures when that's possible. And I think you can start with that more or less anywhere. You can literally make small changes in your codebase every time you're in there. And ultimately you're going to run into the limitations of jQuery. But the more stuff you can pull out as pure functions and the more data structures you can convert to be immutable, the easier it's going to be to do further architectural refactoring because things will be less coupled. And the implications of one change will be clear when you're in there modifying the codebase. The implications of something will be much clearer because functional programs do this, a nice little version of control thing where you can pass something to someone else and it's not going to change out from underneath you.
So, it gives you a confidence when you're writing code. I'm going to pass that over there and I know nothing bad is going to happen to it. All I have to worry about is the return value from that function and what I'm going to do if anything. So, I'd say that by focusing on changing as many functions as you can to be pure functions so they're easier to reason about, by using immutable data structures and so forth, you can achieve a lot of low-hanging fruit benefits of functional programming without abandoning jQuery UE which is most likely not something that's going to happen unless you have support from management. Which could happen.
Ultimately I've seen this one shop, they had a jQuery UE application that was complex. It was written and maintained by a bunch of different developers. And it got to the point where it was just so buggy and it was so hard to add new features to that codebase. They said, “Okay, we're going to give you six months. Go out there and use whatever you want,” and they ended up using Elm in order to rebuild the second version of that. And that was because I think the developers made a very good case in that particular scenario that the complexity of the application was such that they were not going to be able to ship features at the rate they wanted and not with the quality that they wanted. And so, it was worth taking a little bit of timeout for the next version of the product which had lots of changes anyway that would have required a rewrite of a good chunk of it.
However, the trade-off, there are actually a couple of trade-offs, and one of the trade-offs is that if there is a bad way of doing it and it takes less than a good way of doing it you're probably going to do that unless you have again management support for doing things the best way. And what that means is you're going to… you're going to add some lines of code that you know at the time are just going to create bugs down the line. Or maybe even bugs right there because you don't exactly understand how the existing code works and you're just incorporating this sort of sideways to disturb as little as possible. And so, you do that and you make a trade-off on the long-term maintainability and the quality of the codebase. And that is something that's going to have a very real cost of the business. We tend to discount that.
But nonetheless there's that real cost whereas if you're approaching it from a language like Elm or PureScript and you go in there, well there's going to be fewer ways to implement it. And yes, that means in general I think you're going to spend longer implementing it because you're going to have to go through… you're going to have to prove to the compiler that the types are going to line up correctly. You're not going to be able to use, or at least not easily, mutable variables everywhere over your codebase. You're going to have to thread state through your application. But even though it takes longer to implement a feature the benefits are that you threaded that state through explicitly. So, you don't have to reason about all the background stuff happening in your application. The types are reflected in the codebase so you have that extra documentation.
And in my opinion ultimately it comes down to the lifespan of the application. If you're targeting an application and it's not designed to be around very long or which has unknown lifespan because it's an experiment then just hacking things together in as fast a fashion as possible is going to deliver more business value per unit time than purely functional programming. On the other hand I would say if you're going to be maintaining this application for a long period of time, you're going to be adding new developers, you're going to scale and scale and scale this thing, then even though it's slower to start eventually you reach a point where the benefits of that approach far outweigh the approach of the other. And because you have a lot of programmers all working on a large codebase with the protection of a very strong static type system and in an environment that constrains you to do things in a way that's easier to reason about.
And so, you end up being able to make more reliable progress over the long term, less risky progress. And there's no, “Oh my goodness. There's no way to do this now,” or, “The codebase is so terrible we have to spend 50% of our time just fixing bugs.” But it's a trade-off that I think different companies will fall on different sides of that for very legitimate reasons in different cases. Just because some apps are not going to be there and you don't even know if some apps are going to be there for very long. And it makes more sense to just hack in stuff as fast as you can rather than trying to take the time to figure out how to do it in a way that's going to minimize your long-term cost of maintaining that codebase and adding new devs to the team.
JAMISON: That makes sense.
JOHN: An example is if you were to jump into the SlamData codebase, most likely any change you make would result in a compiler error [chuckles]. And the compiler would be saying…
JAMISON: Sure. Okay. My question is about alt JS in general.
JOHN: At least.
JAMISON: So, there are just a lot fewer people working to solve common problems. And you could argue that you just avoid some problems because of the language. But there are still… you need like a date time library. You need to make Ajax calls. And someone has to read that spec and make sure it's doing all the right stuff. And I don't know, there are just a lot fewer people working on the same problem. How do you weigh those trade-offs?
CHUCK: Yeah, I found the same thing kind of works with some of the other things that I've done with TypeScript and Angular.
CHUCK: Where you just pull it in as part of the build process. As long as it can export the module and do all the other stuff then it works. And it works seamlessly. It's not like I have to go and bend it to my will or write glue code. It just sucks it in and says, “Yeah, you can do that.” And it's good.
CHUCK: Alright. Any other questions before we hit picks?
JAMISON: I'm fresh out.
AIMEE: Nothing here.
CHUCK: Alright. Let's go ahead and do some picks then. Aimee, do you have some picks for us?
AIMEE: Sure. So, hopefully mine is not too much of a repeat for people because it's actually from Ruby Rogues. But I liked it so much that I wanted to share it here in case there's not an overlap. But it's a talk I'm… Chuck, you'll probably do a better job with her last name but she was actually just on Ruby Rogues. It's Nadia and her talk is on code hospitality. I think she did this at RubyConf this year. Or RailsConf or one of the Ruby conferences. But anyway, her episode on Ruby Rogues was really, really good and then the talk itself is just really, really good. So, I'll put a link in the show notes. And maybe Chuck, I'm not sure if you can help me on her name, but [chuckles].
CHUCK: Yeah, Nadia Odunayo.
AIMEE: Okay, thank you. Yeah. It was just really, really good.
CHUCK: Yeah, she was a lot of fun to talk to. So…
CHUCK: Yeah, definitely check that out. Jamison, what are your picks?
JAMISON: Yeah, I have three picks. The first one is both self-serving and not self-serving. React Rally is a conference. It's in Salt Lake City August 25th and 26th. We have some amazing people from the React community coming to talk to us about cool things they built. And we have a bunch of fun activities planned. So, if you go to ReactRally.com you can buy tickets. And I'll be happy because there'll be more people there and we can do more cool stuff. And you'll be happy because you'll learn cool things.
My other two picks, one of them is a blog post about, it shows refactoring a chunk of code from an imperative style to a functional style. And it's very detailed, almost too detailed in some places. Like yeah, okay you moved this function down there. But if you're interested in looking at what it might look like to do some of the things that we talked about today about incrementally adding a functional concept to a codebase this is a really interesting read on it. And I think the code is a lot easier to understand and feels a lot better at the end.
And my last pick is a site called PGExercises.com. It's kind of an interactive online SQL tutorial. So, they have this browser interface to a SQL database. And it's got a schema loaded with data in it already and everything. And then they just give you a bunch of tasks and explain how you might walk through those tasks. And I'm trying to brush up my SQL skills and this has been really helpful. So, those are my picks.
CHUCK: Nice. I'm going to jump in here next. I was at Podcast Movement last week which is a big conference for podcasters as you can imagine. I had a ton of fun, learned a ton of great things, going to be changing some things up as far as our process goes to make the shows hopefully better than they are. Though I know a lot of people really love them. So anyway, I just got some ideas I'm going to try out and we're going to see how they affect things. But while I was there I had to run to the Apple store three times because my iPhone broke. It was like a 10 or 15-minute walk from the hotel where the conference was so I just walked down Michigan Avenue and walked back.
But while I was there I was tempted and lured and bought the iPad Pro. And the iPad Pro is awesome. And there are a few things that I really like about it. I'm not going to give a full review here. I should probably do that though at some point. And I'm starting to do more Periscopes and video things. So, if you follow me on Twitter then I should be announcing when I'm doing those before I do them. So, just follow me, cmaxw or C-M-A-X-W. And I'm probably going to turn it into some kind of show, some video show or vlog or something. Anyway, not quite sure on that yet. But anyway, so the iPad Pro has a Smart Keyboard. And one of the things that were nice was that it fits really nicely on the tray table thing that you have on the back of the seat of the person in front of you on the airplane. My laptop is just slightly too big. I think it's a 13-inch screen and it just doesn't fit well there, especially if they lean the seat back. And the iPad Pro did.
The Smart Keyboard is really nice. It looks like a nice cover on the iPad if you're using it that way. And yeah, it just works really great. I love the way it folds out and it has a magnetic stopper, grabber thing that just works. But the thing that really got me with it was that I was using the Apple Pencil to take notes in an app called GoodNotes. And GoodNotes is a note taking app for iPad. You can type in it, sure. But the other thing that you can do is you can use the Apple Pencil and it just asks you what ruling you want on your paper. And then you can take your notes and it will actually do OCR on your handwriting and you can do full text search on your notes, your handwritten notes. So, I could just jot down the things that I really wanted to check out and it was good enough to actually go and pull that stuff off, which was awesome. So anyway, if you're looking for something that you can set on your lap and type on without it being as bulky as a laptop or something that travels well or something that you can take notes on like you would a piece of paper that is a piece of technology that you can take with you and blah, blah, blah, blah, then definitely check out the iPad Pro. And I super loved GoodNotes.
One other thing that I'll shout out about that is that yesterday I was at a café and while I was on the airplane where the Wi-Fi just wasn't great my laptop was hanging up trying to pull up the interface where I can write an email in Gmail. And by having the iPad Pro all of that interface work, it doesn't have to load it from a server anywhere. It doesn't have to talk to anything to make that work. So, I would just reply and type it and send it and then it would churn in the background sending that email and I could move onto the next thing. So, it was just a function of having a native interface or at least an interface that ran completely on the iPad and that worked out real nice, too. So, lots of stuff that I like about it and yeah, that's my pick this week.
John, what are your picks this week?
CHUCK: Sounds really cool. If people want to know what else you're working on or follow you on Twitter or anything like that, what do they do?
JOHN: Yeah. So, I'm on Twitter @jdegoes. And I also have a blog, DeGoes.net. And look for an upcoming blog post. I'll post by the end of the week on a successor to that modern FP architecture thing that some listeners might find interesting. Thanks.
CHUCK: Very cool. Alright, well we'll go ahead and wrap up the show. Thank you everyone for coming and we'll catch you all next week.
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]