075 AiA Pragmatic Future-Minded Angular with Dylan Johnson

00:00 0:59:44
Download MP3

The Conversation Gist that Dylan prepared prior to the show.

 

02:15 - Dylan Johnson Introduction

05:41 - What “Pragmatic” Means

06:35 - Applying Pragmatic Principles in Angular

08:28 - Pragmatic Principles

13:07 - Stone Soup

14:48 - Pragmatic Programmers Enjoy Change

  • “Why should I go learn ‘x’ when I know ‘y’?”

21:58 - TypeScript

33:30 - How do we apply these ideas to Angular 2?

39:00 - Testing

41:40 - How Pragmatic Programming Can Help

42:47 - New Year’s Resolution; Approaching Angular 2

More sleep (Ward)awesome-nodejs (A curated list of delightful Node.js packages and resources) (John)Exploding Kittens (John)Reactive Programming with RxJS Untangle Your Asynchronous JavaScript Code by Sergi Mansilla (Lukas)Greg Wilson: What We Actually Know About Software Development, and Why We Believe It's True (Joe)Star Wars: The Force Awakens Soundtrack (Joe)The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas (Dylan)The Pragmatic Programmer Wiki (Dylan)ES6 In Depth Articles (Dylan)TypeScript Deep Dive by Basarat Ali Syed (Dylan)

Transcript

[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]**[Ready to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours classes in St. Louis or San Francisco – AngularBootCamp.com.]**[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “Angularadventures” you'll get a $10 credit!]**[This episode is sponsored by Telerik, the makers of Kendo UI. Kendo UI integrates seamlessly with both AngularJS 1.x and 2.0. It provides everything you need to integrate with AngularJS out-of-the-box bindings, component configuration and directives, template directives, form validation, event handlers and much more and yet Kendo UI tooling does not depend on AngularJS. So if you want to use it with Angular or not, that’s totally up to you. You could check it out at KendoUI.com] **JOE: Hey everybody! Welcome to episode 75 of Adventures in Angular. We have our panel today, John Papa. JOHN: Hey everybody. JOE: Lukas Reubbelke. LUKAS: Hey everybody. JOE: And I’m Joe Eames; I’ll be your host. Our special guest today is Dylan Johnson. DYLAN: Hey everybody, from Sunny Tampa, Florida. JOE: Ohh. Tampa, Florida. That sound nice. [Crosstalk] It’s been eight degrees here so anything warmer than freezing sounds balmy. DYLAN: Yeah. Sometimes it’s nice for a little chill though. [Chuckles] JOHN: Not an eight degree chill, but yes. [Chuckles] JOE: So Dylan, do you want to give us a little bit of an introduction? Our topic today is pragmatic programming. To do with Angular, we kind of – it’s a nebulous topic. The name of the episode is Pragmatic ES 6 but we’re not going to be just limiting our conversation to ES 6, but before we get into the topic, I’m sure everybody wants to know about you, who you are, your background and all that stuff. DYLAN: Sure. My name is Dylan Johnson. I work at a company called Raymond James Financial and the architecture department where I do a lot of UI developments and DevOps stuff, kind of like a Jack-of-all-trades; gets to wear a lot of hats which is really exciting but I do a lot of Angular work and a lot of UI work. This topic stems from – there’s quite a bit of stuff going on in the JavaScript world now with Angular 2 and TypeScript; then there’s was AMPScript for a while and you hear people talking about Rx and Falcor and Relay. What I found is a lot of the developers that I know that are just getting into UI development – Angular development – are saying, “Wait, I just learned Angular 1; how do I get involved in Angular 2 and TypeScript?” That’s what I’m hoping to touch on a little bit. LUKAS: I probably could just jump in here. I met Dylan two months ago or so. I’m also working with Raymond James and helping with their Angular project. We had an opportunity to hangout over the course of a couple of days while I was visiting. We just had some really good conversations about Angular, the state of JavaScript that’s going to this brave, new world and some of these theoretical things that are coming down the pipeline that are really new and exciting. But at the same time, when you work in a company that’s grounded in reality, how to you actual frame those things in a way that people can embrace and actually use. That’s where this topic of being pragmatic – pragmatic, future-minded, Angular – how do we take these things and present them in a way that Angular developers, or even new developers, can wrap their minds around and see the value of – not only for new developers to even – basically, business owners with their projects. So really good conversations and so I was the one pushing Chuck to bring Dylan in to share some of those ideas. DYLAN: Yeah, I think that definitely augments where I’m trying to go with this conversation. A lot of the framing for this conversation comes from a book called The Pragmatic Programmer. It’s a book that I recommend to a lot of people that I work with and that I know a little bit more background on myself. I’m a self-taught programmer; been at this for about five years. For the first year and a half, I just – I was taking contracts, I was googling, I was reading Stack Overflow and nothing was crystallizing for me until I started exploring some books like Pragmatic Programmer which I apply principles from still today. In this environment where there’s so much going on with the JavaScript world, I found a lot of its principles especially applicable. JOHN: I’m reading through Pragmatic Principles here and some of the things – it says, “You’re always learning something new, whether it’s a language, a technique or a tool. People who are pragmatic generally enjoy change as well.” Can you define what pragmatic means to you as far as Pragmatic Programmer goes? DYLAN: Sure. The really interesting thing about that book when compared to some of the other books in papers that I find really helpful is that it’s not framed around a specific language or a specific framework. Even necessarily like a specific topic like the Gang of Four book about design patterns, or the domain-driven design book; it’s more about just thought processes and approaches to problems and characteristics that somebody who can be a productive programmer really takes to heart and tries to execute on a day to day basis. JOHN: How did this help you relate into learning things like Angular? Because you said you're going in this road of reading about this stuff. How did applying these principles help you? DYLAN: Sure. I came to Angular after a background in PHP and Rails development. JOHN: I’m sorry. [Chuckles] Just teasing because Charles isn’t here. DYLAN: And PHP of course is the butt of all programming jokes, but I actually had a pretty interesting experience with PHP development. There’s a framework called Symfony in PHP that’s somewhat analogous to Angular. They were introducing concepts from well-established frameworks like Spring, and slowly but surely, those concepts got adopted into the native PHP language. They were some really advanced topics like dependency injection and factory pattern and some of the stuff that shows up in Angular 1. So when I got to Angular development, I had gone through that process with Rails and with Symfony of being an amateur and just jumping in and running some generators on the command line, and then slowly but surely, really figuring out what these concepts were. Showing up into Angular, the pragmatic side of things was really helpful because when you look at some of the ideas that Angular has adopted from these well-established backend frameworks, things like dependency injection or the module.factory method, they're not necessarily perfect analogies to what you see in frameworks like Spring or Symfony. It had to exercise some of those pragmatic principles to say just because this is called something that I’ve heard before doesn’t necessarily mean it applies in the same way, especially when we’re talking about a JavaScript framework, a single-threaded environment and a framework that’s used to develop something completely different than a backend app. LUKAS: So what are some of the pragmatic principles that you use to guide this journey that you take as you wrap your mind around something new? DYLAN: There are a few pragmatic principles that show up early on in the book, and talk about just some general traits that you're going to have to have that as a professional developer, it’s also effective. One of the big things is you're always learning. When I got into development from a completely different career track, I figured that I could spend three to five months learning how to develop and then I would have it all figured out. About three to five months in, I’d found that that was not necessarily the case; you always have to be learning and that really struck a chord with me that this isn’t something that’s as unique to an amateur developer. If you want to be an effective developer especially in something as fast paced and as quickly changing as JavaScript and UI development, you have to want to learn; you have to seek out new information, new languages, new techniques. Then another principle that kind of piggybacks on is you have to enjoy change and be willing to adapt the way you work to adopt some of those new languages and tools. JOE: I loved The Pragmatic Programmer book and I thought it was an excellent read. It’s actually been so long; you're saying things like ‘wow, I can barely remember that stuff’. I love their stuff and this idea is – I love the advice that’s generic, things that we can learn from all disciplines and apply to all of the [inaudible] developers, not just JavaScript developers or Ruby developers. LUKAS: One thing I love that you said is ‘I was learning language tools, techniques and methods’ is that I think to be a really effective programmer in any language, it’s really important to go and look at other languages, other frameworks. So I think reactive functional programming is a big deal right now. I’ve been reading a book that is called Reactive Messaging Patterns with the Actor Model. It’s in Scala and Akka but it’s really interesting how they talk about these reactive messaging models which that is actually built on top of the enterprise integration patterns book that’s been around for a long time. A lot of these concepts that are brand new and cutting edge in the JavaScript realm had actually been around for a long time; we’re just finally discovering ‘here’s this enterprise integration patterns’. We can actually use this and this can help us do front-end web applications even better. Even Redux which is super amazing, that’s really just a couple of patterns combined together to do something really useful in a web application but it’s not really a new idea per se. But taking those ideas and bringing them in to JavaScript or in Angular, in our case, it’s incredibly powerful and a way to just progress with things that you're building and doing. DYLAN: Yeah, and I think that really applies. One of the core things is not necessarily Angular-specific but has been floating around in the JavaScript world with different implementations for a while. One of the most important things for me as a developer is modules. It’s second nature when you're talking about developing Java or C#, so think about things in packages and modules, and think about the boundaries between your system. One of the blessings and curses of being a UI developer is you can the instant gratification of seeing your work on a screen. You're refreshing the browser or you're reloading your iOS emulator and you're seeing your changes take shape, so you're not necessarily thinking at high level all the time. Another piece of reading material that I recommend to a lot of people that I talk to is a paper called Why Functional Programming Matters. It’s from ’84 or ’83 but in the introduction, something that really struck me is it’s now generally accepted that modular design is the key to successful programming. Then there’s a bunch of citations of old languages I’ve never heard of but that simple idea that – when you're thinking about developing your system and your application in a modular way, it’s composable. You can take these things and piece them together. We saw the Angular 1 module system with the [inaudible] but moving into the right direction and then things like Browserify, jspm, Webpack and now SystemJS. Rambling a little bit here, riffing  on what you were saying, Lukas, but all these things have been around for a while and it’s really exciting and interesting to see them come up in a JavaScript context. LUKAS: So tell me what – I’m looking at this list here – Stone Soup. Elaborate on that a little bit and on what that means. DYLAN: I think it’s safe to say that all this stuff is pretty green field. It’s really interesting to see ES 6, the first significant language update in a while, especially ES 6 adopting some failed features of ES 4 like classes. Stone Soup is this – I don’t think it originated from The Pragmatic Programming book; I think it’s more of a fable of some people that took a stone to a fire. They were travelling and they said they could make some soup out of the stone. They put the stone into the pot as the water was boiling then they said, “You know what, we’d make this soup great as a couple of onions.” And then they turned to somebody else and said, “You know what, make the soup great as a couple of potatoes.” On and on and on until they’ve made a great soup that they're sharing with everybody. The light that this is [inaudible] in Pragmatic Programmer is the Linux world. Talking about Linus Torvalds sitting down and writing a UNIX-y kernel and saying, “You know what, it would be great if I had a shell. And it would be great if I had a text editor.” Then you’re bringing all these ideas together and all these powerful contributors and piecing together a really powerful tool with the best ideas from a community and making something out of nothing. That’s really analogous to the opportunity that pragmatic programmers have and the current JavaScript world with ‘build a development tool, build a new Angular 2 module’; the opportunity is out there to really take the green field that’s been provided by the Angular team and extend what they're making. JOE: I love that. I want to back up slightly and talk about the fact that one of the pragmatic principles that you’ve talked about or listed is that pragmatic programmers – I think this is the way to say this – they enjoy change. [Chuckles] This is certainly one of those topics that can really end up in quite a heated debate. I don’t know if you guys have seen recently but there’s been a bunch or churn on the internet – uproar on the internet over what’s been labeled JavaScript fatigue or tooling fatigue which is – some people are complaining why is it so dang hard to set up a JavaScript app today much harder than it was two years ago? [Inaudible] they enjoy change. DYLAN: That’s an interesting point. The other thing that you commonly hear from backend developers when they're poking fun at JS and UI developer is what’s the new noun.js? Go put in some noun.js and you're going to find something on the internet. The way that I would counter that is one, there’s been an undeniable shift in the computing power that the people have on their fingertips. Web browsers are more powerful than they used to be and it’s caused people to think about problems a lot differently. It’s not all – as evidenced by Angular and React and all the other single page frameworks out there – it’s not all server-client, server-client, you can put real business logic into user interface. You can do real, complex operations on the client side and leverage the power of the device that people have at their fingertips. Maybe a little bit rambling way of addressing what you asked but I think JavaScript is just in such a rapid iteration phase that you’ll always see change occur much more rapidly in UI development than any backend technology for all the reasons I listed. Then because JavaScript as a strict backwards compatibility restriction; you can’t go change JavaScript because you're going to break old websites. So all these new language features that people want to embrace have to be added on top of what already exists. That’s going to create some – there’s going to be friction in building a JavaScript application when you have to compress business logic that formally lived on the server, but you can’t change what’s under the hood. WARD: To give the people their [inaudible] who are objecting – we’re learning things all the time but we don’t learn everything all the time; we’re trying to pick our bets because we have to. There’s some suspicion that the latest thing is just the latest thing to be different. Can anybody articulate why I should go learn X when I know Y? The people who are big fans of X are often not really good at articulating why X is better than Y; they just reach for things like ‘well, it’s more performant or it’s more efficient, or it’s more’ [crosstalk]. Yeah, for all these judgements that are – those are great to come to those conclusions after you’ve reasoned from some place – from  starting point that they just lead right to it. ‘Look at how cool or nifty this is’ – that’s really – for me, what’s underlying some of the resistance –. Everybody, you ask anybody, they all think that change, they have to cope with change. Everybody says that while being simultaneously afraid of change and so forth, but I think we understand that we need change but we’re not just out there to be jerked around. We all know people whose favorite idea of what the programming life is, is to learn the new toy. JOE: Yeah, and it’s not just a matter of ‘hey, I already know something; why do I need to do something new?’ but also the thought of what if I’m worried that before I even learn this new thing, the next new thing will already be out there to replace it. There’s some really good analogies of that recently in the JavaScript world. Bower started to be getting really popular. People started learning it and all of a sudden, we all got the memo that ‘don’t use Bower anymore; NPM is what’s being used.’ DYLAN: That’s such a great point [chuckles]. Both of the things that you just said are such great points Joe. The fact that you bring up Browserify, I’m going to be completely honest – there are things about the differences between AMD and CommonJS, Browserify, Require, Jspm, Webpack that I don’t really understand the nuances between all of them. I think this should have a modifier. They enjoy change, should have a modifier in a JavaScript world where we enjoy sensible change. We enjoy tidal changes rather than small shiny objects that indicate to us that we should move in a different direction. I think what’s not debatable is a module system of some sort is necessary. Hopefully, by the time that I’m really digging in to building some production apps with a module system, the playing field will have figured out who the winner is. So we’re not asking the question about which one we need to use anymore. JOE: Right. That’s a great point. I came from a Microsoft world before I got into frontend development several years ago. I remember what it was like as a Microsoft developer; when a new product came around, it had been a few years and we were really excited. I don’t remember; I suddenly haven’t been involved at all at Microsoft for five years, but before that time, every time something new came out – a new version of the language, we were excited because it’s been a long time. I can see how people, especially in the JavaScript world, are getting frustrated with a piece of change, how many new tools came out. I just barely learned Babel 5 and Babel 6 came out and it was 100% changed. Then the – sometimes change is just change for change’s sake but if change leads to something that is more painful – even if it brings more benefits, if it’s more painful, that could be hard. So this idea of they endure change, you're right, it kind of needs an asterisk. DYLAN: Yeah. And I think it’s partially because – what I mentioned earlier about the client has a lot more capabilities now. So you're seeing the shape of large applications change, I think it’s also just part and parcel of JavaScript as a language. It lends itself to meta-programming; the language features that we’ve seen introduced have been born out of things like CoffeeScript where people were changing the way that language looked, or people writing polyfills that essentially started the language feature development. I think a much more rapid pace of change in the JavaScript world for a lot of factors, but I totally agree with both your point, Ward, and your point, Joe, that you don’t just change for change – for change’s sake; there’s got to be a good reason to do so. WARD: So Dylan, have you had a shot at talking about what your thoughts are on TypeScript and its goals and its effects on the way we program? DYLAN: Did someone I know tell you to ask me that question? [Laughter] LUKAS: It’s a trap. WARD: No, I didn’t! I know. It’s a completely innocent question. I arrived late and I don’t know whether you covered it or not. DYLAN: [Chuckles] I just say that because a lot of my colleagues and friends and I have conversations about TypeScript. I’ve actually been fed that question while speaking before because of some of my opinions about TypeScript. There are huge benefits to any typing system in the JavaScript world, whether it be Flow, whether it be TypeScript or whether it be native ES 6 introducing something like classes; what is compelling to me is making sure that that doesn’t erase what JavaScript is and the unique aspects of something like a browser environment that change the way that your program’s half the work. Lukas and I have talked quite a bit about functional programming style. I’ve seen a lot of applications where that’s not just a religious battle to say things like peer functions. If you start introducing a lot of stateful aspects to a pretty complex Angular application, you're going to end up with really difficult to fix bugs; you're going to end up with really difficult to address performance problems. Some of the principles of JavaScript itself – I don’t want to see those get lost in TypeScript, but that being said, looking at the intellisense that you get in an IDE, looking at some of the language features that if you’re a JavaScript-only guy or gal and you see a generic for the first time; you’ve never written Java or C# and exploring what that offers you in terms of type insurance but also flexibility. All of those things are really encouraging and are language features that people can leverage in strong ways just so long as they don’t go creating messy inheritance trees the base being an anti-pattern, I think that TypeScript will be a real benefit to the JavaScript world. WARD: Yeah. People who listen to this podcast know that I always use this opportunity to deride classes which I think are – which I generally dislike. One thing that I have noticed – because I was really fearful that TypeScript – the movement of TypeScript was [inaudible] to a lot of inheritance, deep inheritance that’ll bug [inaudible]. I have to say, I haven’t been seeing much of that. It’s really been gratifying that almost all the – I hardly see any class that inherits from anything. And most of the work I’ve seen people have been doing, they're very shallow inheritance trees. If they are, they're so – classes seem not be being used or be used in the way they used to. JOHN: That’s always been my biggest issue, too, with the classes is that it’s not that it’s a class that I have a problem with; it’s the overuse of multi-level object inheritance. Although I do see occasionally in TypeScript; I’ve seen it a couple times but the thing I see very pervasive in TypeScript or the classes is the use of implementing interfaces. I see that all over the place. I think if I lead to an assumption at the reason I see a lot is people like the tooling that comes from the interface. The side effect is when you do interface, there’s zero code generator from it so you're not actually generating any JavaScript; you're just getting yourself tooling and design [inaudible] developments on experience. DYLAN: Yeah. I’m going to jump pretty far ahead in some of the stuff that I was hoping to bring in to this conversation. I was talking to some of my colleagues and friends who are developers that are big typescript fans; I’ve been very hesitant to adopt TypeScript. I’ve been waiting for the day that ES 6 or even ES 5 gets equal treatments in the Angular 2 documentation that the TypeScript does. What they brought up that you just can’t deny from a pragmatic perspective is when you're in your IDE and you're about to invoke a method and you get that suggestion about what you're supposed to pass to this method, or the comfort that you get from knowing that something’s about to compile your code and it’s going to look at everything you just did and tell you if you really messed up, you can’t really argue with that. I definitely think that’s a big benefit to TypeScript. WARD: Well, and I’m hopeful that it will – it seems to be continuing to evolve. In particular, it’s still a little hard to do mix-ins which is one of the really great strengths of JavaScript and other languages like it. I’m looking forward to seeing better support for that. [Crosstalk] JOHN: Ward, can you explain what you mean by a mix-in just because there’s a lot of connotations. WARD: Yeah. The mix-in idea is that I have stuff from a bunch of different classes – implementation stuff from a bunch of different classes. I don’t want to create a new class that has characteristics of all of them. And with single inheritance, I can only allow the inherent from one base class, which means I can’t – if I follow an inheritance level, I can’t pick up on the capabilities of multiple classes, each of which is dedicated in its implementation to doing something well that my façade class, or whatever the heck it is, could benefit from. In pure JavaScript, that’s pretty easy to do. You just pull in prototype stuff from other objects either has data call than functions or classes. But we pull things in – capabilities in from the served cafeteria of things that could be helpful. It’s not all that obvious in TypeScript how I build a class and fold in capabilities from other classes. All the interface tells you is that it’s going to implement it; it doesn’t actually give you the implementation; what you really wanted to mix-in is to have the capabilities of the other classes merged in with the class you're trying to build. DYLAN: That’s such a great point. It is so easy with a super simple ES 5 or our previous iterations of ECMASript to do things like that. The language lends itself so well to meta-programming and implementing patterns that you need just because the language is so flexible. That’s been part of my concern as well to be honest with you a little bit; either people lose the understanding of prototypical inheritance or first-class functions, higher order functions because they see the classes are available to them. Or that that aspect of JavaScript where innovation is coming from people meta-programming just disappears from the community. I read something pretty interesting that Reginald Braithwaite published on his blog the other day, showing how you can actually leverage some of the new ES 6 features with some of these meta-programming patterns, and using classes as mix-ins because classes, just like functions, can be treated as expressions in JavaScript. So you can define a class and then mix it into another class. He actually speaks to exactly what you're looking for there, Ward. The multiple inheritance that you might be able to get by traversing the prototype chain in regular ES 5 or previous but leveraging some syntactic sugar from class expressions to make that happen. I never would’ve figured it out on my own but he was able to use some of these new language features to make that happen. JOHN: I think that’s the key there – when you're doing a lot of JavaScript, ES 5 doesn’t have a year on that one, does it? [Chuckles] Yes, 1900. So we’re doing that and we’re trying to do basic JavaScript. You’ve got a lot of flexibility. The same flexibility you get from that is what a lot of classic JavaScript developers love, but when you go to TypeScript or ES 6 even, you’ve kind of stepping aside and saying, “Hey, I’ll take this newer style over that flexibility over functionality.” There’s a really cool story that I had just last week where I was helping a developer who was new to TypeScript lambdas; basically, the fat arrows that you can get in TypeScript, ES 6 [inaudible] or even in C#. This developer was trying to figure out why this one function wasn’t working, and long story short, it’s because this keyword, this context was changing and they didn’t understand what the lambda was doing. But the real nugget in here is that this person hadn’t really understood the TypeScript syntax; they didn’t really know how to debug it and when I showed that person how to debug through the browser and not look at the TypeScript but look at the JavaScript that it generated, it was instantly obvious to them why they had a problem – because they saw that ‘oh, this isn’t being captures’. The nugget out of there is that when you're doing TypeScript or ES 6, always go back and look at the JavaScript it generates when you're really trying to debug stuff because sometimes you’ll find out what it’s actually doing is not what you intended. It’s perfectly okay in some cases to revert and say, “You know what, I don’t need this ES 6 or TypeScript feature. I can just get it done pragmatically with doing basic good, old function ES 5.” DYLAN: That’s so important to understand that when you say I’m going to run this thing through Babel or Traceur or whatever the next noun.compiler.js turns out to be, that underneath the hood, you're going to compile JavaScript with its same, old primitive values available to it, with the same, old function expressions available to it. And all these new stuff you're getting is really just building upon what’s already there. Both from the aspect of being able to look at what’s been generated and understand what’s going on – like you said, it speaks to another one of the principles from the Pragmatic book – is use tracer bullets. Get up and running as soon as possible with a small piece of functionality, and while you're doing that, make sure that you can put a break point somewhere. You can figure out what’s going on when you encounter a problem rather than building a huge application and not being able to dig in when you encounter unexpected behavior. WARD: I think I mentioned it once earlier but I have – at some point months ago, I turned off debugging in the browser that uses the source map, and so I’m always debugging into the transpiled code, the JavaScript. I forgotten to turn it back on because it’s so easy for me to mantle each of that [inaudible] of the JavaScript I’ve got to the typescript. I have that satisfaction of seeing what’s really being executed as opposed to what I wrote. [Crosstalk] I’m not saying everybody should do that. JOHN: No, I really think we should do a show on debugging in general. WARD: Yeah. JOHN: I think that’s a lost art just like that funny site – let me google that for you. How many times do you get a question where somebody says, “Hey, how did you figure this out?” And you set a break point; you go and you walk through it. It’s easy for you – I’m saying ‘for you’ meaning anybody – when you’ve done it already. Once you’ve learned how to debug and you know how to do it, it’s like two seconds, you're done. But when you don’t know how to debug, I think that’s a learning curve that we all had to go through so I think it’s really important to learn how to debug not just JavaScript. When you’re doing transpolation like TypeScript to ES 6 or ES 7 when that comes for us, too, you need to know how to debug in these different environments. DYLAN: Yeah, absolutely. There’s a pretty large barrier to entry. JOE: So how do we apply these things for typescript and Angular 2? DYLAN: So the big thing that I’ve had success communicating to people from pragmatic programmer in the past is a pretty funny idea called rubber duck debugging. It sound silly and every time I tell somebody hey [crosstalk]. O: Now, you're just making stuff up on us aren’t you? DYLAN: No, this is a real thing and it’s worked for me in the past. I know that I, as a developer and I think a lot of people can relate, I got into situations where I’m so deep in the problem space that I’m editing a couple of characters and refreshing the browser, or letting Gulp reload my application, it just – kind of trying things until maybe I get the result that I expect. Rubber duck debugging encourages you to step away from the desk, pick up the rubber duck that you apparently have on your desk like all pragmatic programmers, and talk the duck through the problem because it doesn’t necessarily even need to be another developer, even another person. It’s the thought process of ‘here’s where I’m starting’, ‘here’s what I’m executing’ and that drives the problem that you're encountering out a lot better than just trying to make some small changes and see if the program works at that point. JOHN: I do that all the time. I can’t tell you how many times I grabbed somebody, asked them how to do a problem. I walk them through it. They never say a word and I figure out the answer. It’s one of those things where you just need to talk it through and somehow, you can’t do it in your own head. DYLAN: I’ve also had the exact opposite experience, too, when I do talk to people. Funny story – really great developer I’ve worked with in the past. We encountered really nasty issue with time zone translation and stuff was being stored in a database as a daytime object. The java backend was converting it to the local time. The data sender was on a different part of the country so the JavaScript engine that we were checking it on was localizing the time on the frontend and the data sender was in the same city for some people. So only some people were seeing a six hour difference in the time that they expect you to be reflected on the screen. This guy and I were talking about the problem and I said, “I don’t know how to say it any differently to you,” and he’s, “I don’t know how to say it any differently to you.” Ultimately, we stepped away for a few minutes and stepped through the problem and figured out what it was, o it’s a really powerful tool. To relate that to Angular, I think some of the changes in Angular 2 really encourage what – I’m trying to coin as a term – rubber duck design. So when you build JavaScript applications before my career started, it was all about – you click something and something else on the screen moves. Or when jQuery introduced the Ajax API, you're going to make a server call and then you're going to have nine callbacks underneath and all you're looking for is one keystroke or one click that results in the expected output. You're not thinking about a domain model or the single responsibility principle where all these good design patterns that you might see in backend systems. I think the architectural aspects that you guys covered in the previous episode – modules and components, and all the other stuff that’s core to Angular 2 really encourages developers to think about UI applications and do some rubber duck design. Before I just slap an element on the page, let me think what component goes in; before I just write a bunch of JavaScript, let me see if this is a new module or if I can refactor a little bit. JOHN: That’s a whole lot of thinking and I don’t want to think a lot when I code. [Laughter] DYLAN: The great thing is the duck does the thinking. You just talk to it and it gives you the idea. JOHN: Cool. So my duck is usually named Ward. What’s your duck named? DYLAN: Duck. [Chuckles] LUKAS: I don’t get it. WARD: Quack. JOHN: Nah, I totally get it. It’s one of those process you should all go through. It might come from a family of construction engineers in the background; a bunch of tie-ins got off the boat, landed in New York and decided to build some things. We have a couple of sayings that we didn’t in New York and the only one I can actually repeat here would be the one where we talked about you measuring when you're building a house. You're building some kind of framing, you always want to measure twice before you cut because once you cut, you're done. A lot of times, you don’t wake the time to think through what you're going to do or measure twice. You could cut it and then you’ve got a problem. You always want to measure twice before you cut once. DYLAN: Yeah, absolutely. I think it makes you think about things like design or exactly where you're placing mechanics and also thinking about how components talk to each other; let the publicly exposed API between components [inaudible] and drawing back to some of those pragmatic principles like the Law of Demeter. That’s something that shows up in Pragmatic Programmer which is just a fancy, made up term to say that a component should only know about what they need, and they should have limited capability to talk to other components. When you start thinking about stuff that way, when you're building an Angular 2 app and components are core to the design, you eliminate problems with shared states and mutability and maintain ability and really start to design solid, robust applications. WARD: So Dylan, what do you tell people they should do in terms of testing? DYLAN: In general, test. Definitely test. To be completely honest, I haven’t gotten through the testing chapter of the Angular 2 documentation, and I know from listening to previous episodes, Ward, that you’re a real, big proponent of testing. But I have seen a lot of questions come up when people start writing Angular 1 apps and ES 6. They immediately shut down when they get to the phase of how they're supposed to write test because it completely changes how – can I even run test for ES 6 code? How do I import these things that I previously was using? The phantom injector for Angular 1 to use and create stubs for? But the big thing that I’ve seen is beneficial for people making that lead is to say go take one controller or go take one service, install Babel, turn your constructor function for your controller into a class and then try to run your unit test for that new class-like controller. When people see that you can use ES 6 when you're writing your Jasmine test, but you don’t have to. I think it becomes a lot easier to wrap your head around. The same pragmatic principles really hold true – design to test. If you encounter a bug, write a test before you write any more code and don’t let this change what your code looks like – prevents you from abiding by the same principles that could’ve been successful for you in the past. WARD: Yeah. I just wished I saw more blog posts and demos and descriptions of either Angular 1 or Angular 2 that included test and like it – just as easily point that – I’m looking in the mirror on that, too, because I’ve been doing so much stuff and I don’t have much showing test on any of it. It’s just one of those things I feel we talk about but we don’t do enough. We haven’t made it easy. We haven’t made it easy for people to do it yet so it’s a frontier for me. DYLAN: I agree. I wish there was more information out there about it. I was just trying to dodge your question a little bit because what I do for testing is the same exact stuff that I’ve done for testing with Angular 1 and ES 5. I’m still getting the code coverage metrics and again, being sensible about what you're doing. Before you go introduce a whole bunch of lines of code, make sure you can test it and I hope there’s some cool stuff from the different tier for the Angular 2 world where the test tools improve a little bit. WARD: They better improve a lot but they will. JOHN: So is there any one tip that you could leave our listeners with as far as how Pragmatic Programming can help them getting up to speed or how they should apply that to Angular 2? Where would you lead them? DYLAN: That’s a big question. The book is a great place to start or the Pragmatic Programmer website. It’s not the friendliest UI but I think David Thomas put it together – who’s involved in writing the book. Jump in and get an idea of some of these principles and then immediately start thinking about how you can apply them in your daily life or even just one in your daily work flow. For instance, the principle – you used tracer bullets and what that means is get something to production as fast as possible so you can start uncovering the problems that you don’t know exist. I’d say go do that with Angular 2, with TypeScript, with Rx, with Relay, Falcor – all the various things that people are throwing around as the new big thing. Go to GitHub, look at the documentation and just try to get started with those things, not necessarily all together; just one by one and arm yourself with the knowledge so that you can decide to use them when it makes sense. WARD: Nice. So what’s your new year’s resolution, Dylan? What’s the big frontier? DYLAN: Another big question. The new year’s resolution is to take some of these things – Stone Soup is something that my friends and colleagues talk about both as a benefit and as something that do quite often. So big ideas, big things that can be really beneficial and then just create the design and let somebody else implement. But some of those things – I agree with you – where you like to see crystallized in the next year. I know a few episodes ago, Chuck picked Dan Abramov’s React Hot Loader and Time Travelling debugger. It’s something that people should watch even though it’s React; it’s not Angular. Really like to help materialize some development tools like that around Angular 2 and take the opportunity, this new landscape, to jump in and build some tools that help people be productive on a daily basis if that’s a real answer. WARD: Seems real enough to me. I don’t know if you had a chance to talk, Dylan, about how you're approaching Angular 2 given its nebulous emergence date. It’s turned beta so that we can try and change a relationship to it and stuff like that, but if you have some words of advice for the people that you see regularly, how would you recommend that they approach it? DYLAN: The Angular 2 journey has been pretty interesting. Angular, you're up 2014 – I guess it was. There was the apocalyptic outrage. It’s introduction of some of the Angular 2 APIs where they said dollar scope was dead and all the ng- attributes were going away and every Angular developer said, “Why did I just spend two years finally figuring out all this stuff and now you're going to tell that you're changing everything. That’s especially concerning if you happen to find yourself in a situation where – I know in past episodes, you guys talked about enterprise developments. These are things that you have deadlines for; they're not hypothetical things. So drawing the balance between seeing what Angular 2 is going to hit beta, figuring out if you're going to use Angular 2 or Angular 1 for your new application that you're just starting developments on, all those things have been pretty tough decisions. But I think what is held true for me throughout that entire process and seeing a [inaudible] died down in terms of the changes in Angular 2 and the realization – again, going back to the pragmatic principles – that they were fixing broken windows. They were looking at the flaws in the framework and making it nicer for people to develop. For these enterprise production applications, the thing that’s held most true for me is to stay involved in reading those conversations. Try to get involved in having those conversations with the people close to framework development and looking at the documentation as it comes out so that when you get to the point that Angular 2’s in beta, they're saying they're not going to break any APIs and it’s fit for you to jump in and convince your boss to say, “Yeah, we’re ready to go to Angular 2.” You have that security of knowing where the decisions came from and what the journey was to decide what these APIs were. Prepare yourself; learn what the framework is about, what problems it solves and how it’s advantageous for you as an app developer. JOHN: I think, too – it’s interesting if you think about the reverse of what happened. Let’s say Angular 2 didn’t exist. Let’s say the Angular team never announced anything and we’re still in Angular 1 and that’s all it was going to be and we’re trudging towards angular 1.5, 1.6, 1.7, etc. If that was the case today, would we be happy with – this is a rhetorical question, I guess – would we be happy with the state of Angular 1.x given where the rest of the JavaScript was heading towards with some of these newer frameworks? DYLAN: You look at – I know unidirectional data flow is like a buzz word, and the question is always yeah, that’s fancy but what does that do for me? When you look at some of the concepts like that from React and the emphasis that React places on pure functions. Again, going back to that Dan Abramov talk where he illustrates the importance of pure functions and being able to step through your programs, I think it’s clear that some of those influences have made their way into the Angular framework. I know that I – personally, if I was just picking for my own amusement, if I was still sitting in the Angular 1.3 world and then looking at what React had offer, that would be a very tough decision and Angular 2 definitely addresses a lot of those issues. So maybe to be more specific, you look at the Angular.io developer guide documentation in the component section. When you start looking at life cycle hooks and the APIs that are being exposed to an Angular developer in Angular 2, a lot of them are very close to React API, shoot component update, set state – things of that nature that people found convenient in React and provide a lot of advantages to developing a UI application. A lot of us – things weren’t present in Angular 1 and they changed the shape of your application and change how you think about developing. WARD: Yeah, I think that’s actually not a bad example. I think about the controllers we wrote in Angular 1 and how we wanted to have – we wanted stuff to happen but we didn’t want it to happen in the constructor and there was no way to really do that, and yet having things happen in the constructor leads to trouble. Just little things like that can help you get on stat. I think we all – there was [inaudible] spends enough time with it or if it’s starting to feel like Angular 2 isn’t just different; it’s feeling a lot better, feeling like the right choice. DYLAN: Yeah, and if you wanted to get access to a lot of that stuff in Angular 1, at least in my experience, where you would find that is digging into the ng-model directive and looking at all the state updates that happen when you type a keystroke into a text input; the life-cycle hooks a value since they propagate it from the view to the model and back to the view again, weren’t as easily accessible. You only found them when you were talking about edge cases. There weren’t really at the component level; they were really at the value level. I think that’s something that was a shift, in my thinking at least, when I saw React and the way the components were structured and all these life cycle hooks that components have that I’m really glad to see coming to Angular because it allows me to gain the same advantages of some of these functional programming styles and lifecycle driven choices and component development that we didn’t have in Angular 1. WARD: Just to be fair by the way, a lot of those notions were in other frameworks. For example, they were in Durandal; probably were in Amber. I don’t know Amber well enough. It’s good that everybody has gone shopping to look at some of the authors for instance, pick up the ideas that are available in all of them. DYLAN: I think they were in WordPress, too [laughter]. Yeah, life’s like a [inaudible] or not a – [crosstalk]. WARD: They're not new but they sure were missing. DYLAN: They sure were, Ward. WARD: Yeah. That and asynchrony. Proper driving asynchronous options throughout the framework is something that was really missing in Angular 1 and I think we have a lot more of that available to us in Angular 2. I guess some of these things you think maybe are just all theoretical and stuff like that until you face really hard questions of what am I going to do when you're trying to deal with an interaction with a user that’s part of your regular programming process. What do I do with all these changes that the users made and I’m going to go away? What am I supposed to do? How am I supposed to shut this component down when they leave? Those aren’t esoteric questions; those are questions that you confront as soon as you get away from the to-do app. DYLAN: Sure. Even the hidden life cycle hooks, right? I know; I’ve seen half of developers encounter issues where they're using some sort of event-driven architecture in Angular 1 and they're invoking scope dot on but they're not binding it to anything and they're not invoking that on scope destroy because they haven’t bound it so now you're introducing a memory leak into your application. That’s definitely [crosstalk] – yeah, and that’s a life cycle hook that isn’t explicitly exposed that you get more explicitly exposed in Angular 2. WARD: Right. Then you got all these change hooks, too, that are really nice, so how do I know when the property change? Or when a whole bunch of things happened that Angular was doing behind-the-scenes, now it’s done doing what it’s going to do, how do I tap into the fact that they're done so I know what to do myself and harvest what they did? That stuff was really missing and it’s there in Angular 2. Well, it must be time to wrap up. JOE: Yeah, let’s wrap this up. I think it’s been a really good discussion on several one of those topics that is very important for people to be looking at and thinking about, whether you're switching to a new framework or you're not switching to a new framework. Pragmatic Programming is one of the things we could certainly recommend is the book. It’s a great thing. It’s been a really god discussion but let’s move on to picks. Ward, how about you? WARD: Oh, you would do that. JOE: I would. [Chuckles] WARD: My take is that I want to close the year with more sleep. I think sleep is underrated. JOE: You’re going to start now and not end [inaudible]? WARD: I’m going to sleep right after this podcast and I’m waking up in January. That’s my pick. JOE: Good pick. WARD: More sleep. JOE: Good pick. John, how about you? JOHN: My pick is to never sleep. No. I have two picks. One is pretty technical and it’s a great list. So there’s a link up in here to a list of the essential Node links basically. Sindre Sorhus – probably saying that name incorrectly – who’s done quite a bit of the NPM modules that we all know and love like Yeoman and TodoMVC has a great list of really useful Node links for things like what if you want to manipulate dates? Or what if you want to do string manipulation? Or if you want something to do – task automation? He’s curated this list up there on GitHub and it’s a wonderful list; got a lot of people looking already. If you haven’t seen it, you definitely should check it out. It’s a great way to zero in on how to solve some problems with Node. My second pick is an Angular website. It sells a product called exploding kittens. It’s a game where you're playing a game about cats that explode. It’s really cool. It’s actually – they claim to be one of the largest kickstarter successes in history to produce this game. Just checking out the website where they sell this at explodingkittens.com. It’s actually Angular in the website itself. Definitely check it out. I was playing this game with my kids on Christmas night because they got it for Christmas. Santa brought it and we were laughing uncontrollably all the night at the kind of things you can do when the cats are exploding. JOE: Awesome. Lukas, you're up. LUKAS: Yes. So my pick this week is ironically from Pragmatic Programmer’s bookshelf – Reactive Programming with RxJS by Sergi Mansilla, I believe his name is. I just have to say that RxJS is the heat. It is insane. Just a little preview of what’s in the book, he actually writes an entire game with no side effects. That’s pretty phenomenal that all the state is entirely dynamic in these reactive strings throughout the game. Really powerful way of thinking about programming. I’m shifting my world view on asynchronous programming as a result and I highly recommend it. It’s phenomenal. JOE: Awesome. For my pick this week, I’m going to pick – this is kind of relevant – a talk. I actually picked this on another podcast, but it’s called What We Actually Know About Software Development and Why We Believe It’s True which is a talk about the fact that we – there are many things in software that we think are true, we believe are true mostly because of anecdotal evidence but is simply something that we believe is true under real scientific, rigorous scrutiny may not be true. WARD: You mean like a good program where it’s ten times better than a not so good programmer? JOE: He discusses that one specifically. So it’s a great talk, one of those talks that I think every developer should watch because there are so many things that we go along with the [inaudible] flow of ‘well, this must be true, it must be the right thing’ or ‘this must be better, this must be easier to maintain because everybody says it is’. It’s just a great talk. Then my second pick is going to be the Star Wars movie of course, but also specifically the soundtrack to the new Star Wars movie. Awesome programming music if you're looking for some programming music. Fantastic stuff to listen to while coding. JOHN: And no Ward, I did not put you up to listening Star Wars this week. [Chuckles] WARD: You guys are just constantly on me. JOHN: Well, you know. [Crosstalk] Maybe the best movie ever made. But you don’t have to agree. WARD: I’m sure to watch it before the end of the century. [Chuckles] JOHN: Ward, you are the Jar Jar of our show. WARD: Oh! Brutal! LUKAS: Burn! JOHN: He’s a secret Sith Lord. WARD: Uh-hm. Oh gosh. JOHN: Alright. Well, just so you know, Ward, I’m on my way to see it for the third time tonight. WARD: I just can’t believe you guys. I’m going to have to send you this image I’ve got. I’ll put it on [crosstalk]. JOHN: It hasn’t made that much money either out there so it’s not doing too well. WARD: If money were the major of quality, where would we be? JOE: Jurassic Park would be the best movie ever made. [Chuckles] Jurassic World, sorry, would be the best movie ever made. DYLAN: I saw a blog post the other day – Things to Look For the Next Few Times You Go to Star Wars. JOHN: I was just reading that today. I’m excited to check some of these – some of which I noticed already but some – I’ll check them out. JOE: Cool. Alright. Dylan, you're up. You’re our last [inaudible] of picks. DYLAN: Alright. So I think I’ll have to pick the Pragmatic book and the corresponding Wiki where you can find most of the material in the book which has really been invaluable for me as a – progressing through a programming career. The other couple of things are – Mozilla has a series called Mozilla ES 6 inn Depth which is really interesting if you want to start learning about some of these new language features and exploring how you can apply them in your work flow. Something that I haven’t really gotten totally through and plan to get through is if you look at gitbooks.io, there’s a TypeScript book by – I don’t even know the gentleman’s name – his handle is basarat but we’ll post it on the show notes. I’m excited to look through the TypeScript deep dive and see what differentiates it from out of the other cool, new stuff in the UI development world. JOE: Fantastic. Well, thanks again for being on the show, Dylan. We really appreciate the time that you spent with us and the conversation. Thanks to all of our panel and all of our listeners. See you all next week.[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.