- Misko Hevery (twitter github blog)
- Igor Minar (twitter github blog)
- Jamison Dance (twitter github blog)
- Joe Eames (twitter github blog)
- Tim Caswell (twitter github howtonode.org)
- AJ O’Neal (twitter github blog)
02:33 – Angular.js compared to other frameworks
04:03 – How does it work?
05:22 – Cost
06:06 – HTML Compiler
07:02 – Directives
10:31 – Working with browsers in the future
12:07 – Dependency injection
16:50 – Main method
18:48 – Using require.js
20:53 – How would you build a TreeView widget in Angular?
24:07 – Where data is stored
24:42 – Scope
29:47 – Syncing to servers
31:34 – Testability & Services in Angular
39:04 – Benefits of Angular
- Dependency injection
- The Arrow (Joe)
- Font Awesome (Tim)
- Testacular (Igor)
- Plunker (Igor)
- The Better Angels of our Nature: Steven Pinker (Misko)
- XCOM (Jamison)
- The Foundation Series: Isaac Asimov (Jamison)
- Influencer: The Power to Change Anything (AJ)
[This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to wijmo.com and check them out.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]
JOE: Hey everybody!
JAMISON: Tim Caswell.
JAMISON: And we have two special guests. I’m going to mangle your names, so I’m sorry. It’s Misko Hevery.
MISKO: Misko Hevery. Yeah, thank you.
JAMISON: Misko Hevery and Igor Minar?
IGOR: Minar. Yeah.
JAMISON: Great. You guys wanna introduce yourself really quick?
MISKO: Sure. So, this is Misko Hevery, original creator of Angular.js.
IGOR: Hi everybody! I’m Igor. I joined Misko about 2 years ago on this venture of creating better browser and better environment for creating client-side applications.
JAMISON: And if you can’t tell, we are going to talk about Angular.js this week. So, I know it is kind of a Google project now. Did it start out that way?
MISKO: It started out with something I was working on and eventually I’ve open sourced it at a product with Google internal application and just gotten such a rave reviews and new features that people actually says, “Hey why don’t you work on this full time and turn in on to a real product?” So, that’s how it’s started.
JAMISON: Oh, wow. So, there’s actually a team in Google who are working on Angular as their job?
JAMISON: That’s awesome.
IGOR: It’s just two of us here now, but we have a bunch of other people working full time on Angular.js and also main contributors–
JAMISON: Oh, go ahead sorry.
IGOR: There is a team behind Angular.js.
JAMISON: Do you think you can give an overview and kind of a comparison to contrast Angular to some of the other MVC frameworks that people like before you? I mean, Backbone I guess is what most people know. So, what makes Angular different from Backbone? How does it work?
JAMISON: But you can still observe the changes on objects like that?
MISKO: Right. You can still observe changes on objects like that.
JAMISON: How does that work without any special code?
MISKO: That is the question.
JAMISON: Man, that seems I asked you a lot of questions and I haven’t thought Angular. It’s very magical.
IGOR: It is very magical. But we tried to keep it to the minimum and we only bring all of the magic the cost of the magic when it happens. The other way around, rather.
MISKO: So how does it work? It basically works that the model can only mean– there are certain points in time. Basically, it means when I set down — my when the next — comes back from the server or when the user attracts with the browser. And that’s the only time when people have model change. And so, what you can do is simply you can hook in to these events. You can then run a check. That sounds scary, but it actually turns out that the number of bindings we have on a page determines how many items we have to check. And because humans can only consume so much data before the page becomes —, typically, checking all those stuff is not an issue. Single, maybe double digit, millisecond range or something like that. And so it actually turns out that it’s perfectly fine and acceptable even if you had relatively complicated pages to just be verified and see if any has changed.
JAMISON: Wow. That makes a lot of sense actually. I never thought about doing it like that.
JOE: Now, what about the cost? You said its only 10 to 20 milliseconds, but how complex of a page have you guys tested this with?
MISKO: So, my measurement is always something about 2,000 bindings per page. So, if you imagine a complicated page, let’s say it has 100 rows and 20 columns, then a table would have about 2,000 items on it. That’s pretty much the limit of what you can show to the user before the user kind of scream and say, “Hey! This page is ridiculous! You don’t give me back information or do something to make the page more presentable.” So, that is the reason for page model.
JAMISON: So, I’ve totally cut you off when you were explaining kind of the basics of Angular and you only got through one feature. Do you want to talk about some of the other stuff it has too?
MISKO: Sure. There are couple of other things. One of the things that we are most proud of is what we call the “HTML Compiler”. In other words, we allow you to extend the vocabulary of HTML and add behavior to it. So, if you, for example wanted to go back in time and want to have a blink tag, you can literally teach the browser a new trick by say, “From now on, when you come across a blink tag, we introduce this behavior.” And this is very different from the rules of jQuery, where you have an imperative; a way of specifying behavior by selecting the things on a page and then registering listeners. By having this HTML Compiler, you can have a declarative way of specifying things by saying, “Here’s my blink tag. Here’s my path. Here’s my accordion. Here’s my date picker.” and so on.
JAMISON: So, it seems like some work designing in the Angular the application is figuring out good abstractions to use as… what are they called? Like, components or something? I can’t remember what they are called.
JAMISON: Directives. Yeah.
MISKO: We come with a pretty fine set of directives. Things like ng-repeat, so you can unroll arrays. Ng-show and ng-hide, ng-model for data bindings in the field, ng-view in routers for doing navigation of pages. So there’s a rich existing set of things we already have, which we think kind of figure out what the application would use. What we expect you to do is to turn your application in to components. So, if you are building a map application, presumably you have a map component. If you are building a calendar application, presumably, you will have like a day, week, and a month components and so on.
IGOR: So, first Angular is different from many other solutions, specially the pre-MVC framework solutions. Because we felt that HTML is pretty awesome in describing static layout or static pages, but it fell short when it comes to building dynamic applications. So, we started to think about why is it and how we can address it and what people would do to address this issue? And with jQuery or other approaches like Clojure and similar libraries, they just abstract the way… they are not developer friendly DOM APIs, that often inconsistently implemented with web browsers. And just make it possible to DOM manipulation with the same APIs in a consistent way. But all these DOM manipulation is very imperative. So, you are telling the browser you know, this sequence of steps you need to take in order to display something or do some kind of feedback.
But HTML, it is a very different approach. In HTML, you describe, “This is the end result.” and we let the browser to figure out how to get to that by itself. And we think that this approach is really good in building applications. And there are many environments, especially in the desktop world like WPF or Flex that showed us that declarative templating and data bindings is really awesome. And that’s when we thought, “Can we bring this to the browser? Could we bring it in a way that would feel natural and would feel like the browser just knows how to data binding, how to create declarative templates for web applications?” And we took this route and starting implementing Angular.js in a way that is very intuitive. And as Misko mentioned, what that means is that, we don’t ask you to extend any of the framework types or classes; you can work on any type of you might have or just make it arrays of objects. And we used HTML as our template and we just extend HTML just like you will in the future with features components that are coming to on to the platform in the future.
JAMISON: yeah, one of the things it says on the website that I really like is that, it’s kind of like how you imagine browsers might work in a couple of years. We just need to be able to work with stuff like that right now.
IGOR: Yeah. So actually, we work very closely with the teams and we are involved in discussions about future standards. So, some of the standards like the component standard have been affected by the work we’ve done with Angular.js. We are kind of prototyping what works and what doesn’t. And then the guys work on specs talk to us and this way, we can influence the standards and tell them, “This worked for us.” Or “We tried this and it looks horrible.”
JOE: It’s very cool.
JAMISON: So one of the thing I wanted to ask about was the way you kind of hang your application together. It looks like Angular does a lot with dependency injection and passing controllers in to things automatically and passing… I don’t know all the Angular terms, I’ve kind of dabble with it but haven’t built an application with it so. But, it uses like two strings functions and automatically resolves dependencies and stuff. So, you don’t have to really deal with… do you think it eliminates the need for a module loader like Require or something like that? or does it compliment with that?
MISKO: So I’m going to answer a slightly different question. That is, you should ask the question what it doesn’t have specifically because the kind of injection. And so, because of the dependency injection, Angular doesn’t have a main method. Something that is very common in other systems.
MISKO: So what dependency injection is a declarative way, know that you’ll love this declarative thing over and over again. The dependency injection was a declarative way of assembling your application. And because it’s a declarative, you don’t need to write the main method. It basically figures out how the application should be assembled. Because its declarative, in your tests you can assemble the application differently. Replacing components such as authentication or — with pieces that you don’t need. The end result is that all the code that you normally write for assembling the app…
IGOR: all the instantiation of the components and passing the components into another components so they can it…
IGOR: One nice side effect of using dependency injection in your application is that, since you are not in charge of instantiate in components, since it’s the framework’s role to do this kind of thing, then you don’t need to worry about the code load order because the framework is going to ensure that all the right stuff is loaded. And that’s the case with Angular applications; unless you are using dependencies there is absolutely no need to use anything like RequireJS or AMD or CommonJS. If you are building big application, you have many third party dependencies that are not Angular components and they don’t know about injection, that’s when RequireJS and similar loaders come handy. And you can use them in addition to Angular dependency injection system.
JAMISON: Are there examples of that working in the wild?
IGOR: I think the —- project contains implementation of RequireJS with Angular. So, that is one example to look at. And there were some other applications that I helped with but I don’t think that any of those are open source as far as I can remember. So, I just want to add to this because many people feels use RequireJS with dependency injection and the biggest distinction between the two is, RequireJS doesn’t create instances, it doesn’t create instances of components, it just passes around references to code and then you instantiate all the components when you need them. With dependency injection, dependency injection hands over to you instances of components. That’s the biggest advantage.
JAMISON: One of the difficulties I had with Angular just wrapping my head around it is because there isn’t a main method like you said. There is no thread that I can trace back to where all the things come in to play. So it seems like there is just a cycle where everything always exists magically. How do you train your brain to get around that?
IGOR: So, it doesn’t magically exist all the time because injection will instantiate components only when data need it. So components are instantiated lazily. And let’s talk a little bit about main method and we think its evil. What is it you like about main method?
JAMISON: Just like I said, it’s if you are trying to understand an app, and you can’t figure it out, you can always just go back to the main method and just follow stuff that happens there.
IGOR: So, what we typically see is that, for small applications, main method is fine. Because it’s very simple, it just instantiate just one or two components and it keeps up your application. But in large applications that have many, many components, these main method organically grows and becomes very hard to maintain, because the order in which you do stuff in the main method really matters. So, everybody in large projects people are afraid of editing the main method because you don’t know what kind of consequences small changes in the main method will have.
And the other part with the main method is that ties your application to the biggest particular way of constructing your application. So, if you want to construct that application in a different way using some kind of marked components, let’s say you don’t want your database in a unit test, it becomes really hard to figure out how to construct these applications for unit a test. — still preserve all the other components that you have.
JOE: So, I think that is really one of the most amazing things about Angular. It is just the whole DI system. I built a pretty large HTML5 player using Angular and it was just amazing what it can do and how much it lent itself to testability. And nobody else had really thought about that. And you know, other systems, especially ones that use Require, there is this issue that with Require you are bringing in potentially real objects, and so, there’s no way to mock them out for testing.
JOE: And with Angular, whether you use Require or not, it’s still Angular that provides you the stuff. So, when going in to Angular, “Hey for this test, use this instead of the real thing.” Angular does it all for you and handle it just great.
IGOR: So, the thing with Require, there are ways to work around this using plug ins or some configuration of the RequireJS, but it’s not pretty.
JAMISON: They are so ugly! Oh, they are so ugly.
IGOR: Yeah, it’s very ugly. And it just complicates your life. With dependency injection, things are so much easier because you just ask for dependencies that you need in tests and they provide to you. And if you need to override the dependency, you just say, “Ok instead of this HTTP client, use this mock up.” and everything just works.
TIM: I’ve been – lot of my code to dependency injection. The library archeype I made for Cloud 9 is basically the same thing. Instead of requiring some module, it just requires service and then anything can provide that service.
IGOR: Yeah, so we were inspired by — and the Java server side programming models, where – things like — container showed us how to do inversion of control and dependency injection. So, both Misko and I used to be Java developers and we were influenced by Guice.
JOE: My Java — is swing so I didn’t learn much from that.
IGOR: Yeah, actually.
JOE: So, I have a question and I have done a lot of UI frameworks over the years and things were all great and easy until you have some nice composite thing you develop like the Tree View widget. So, how would you build a Tree View widget in Angular? What techniques would you use?
IGOR: So think of directive as the instruction to the compiler that tells it whenever you come across this certain element or this CSS in the template, and you keep this kind of code and that code is in charge of the element and everything below that element in the DOM tree.
JOE: So I can just put the entire tree view in one directive, but I probably wanna break it up because I got leaf nodes and three nodes. Could those be smaller directory and smaller element types?
IGOR: Yes. And so in our homepage, we for example have an example panes and —, which are two directives that collaborate with each other in order to get the file effect having a compatible view. So the same way, you can set up individual cell rendering and put it inside a tree directive and the tree directive essentially be a fancy repeater, where instead of repeating overs items being in sequence, it will repeat where items in a direct call fashion.
TIM: So whatever the problem is, you can build a custom directive that would do that. There’s enough flexibility there?
IGOR: And you can call those directives. That’s one more thing that we thought really hard of. A directive should be, it should be possible to create directives that is used by another directive, that is using another directive and this next thing can be as deep as needed. So, that’s how we extend HTML and make it possible to create this complicated UI elements.
JAMISON: So one cool use of that I saw, someone at our company used Angular just because they’re interested in it, to build up this backend UI really quickly. And we are all pretty amazed by what he did. One cool thing he did was build up a dashboard type of thing. And it was like nested with directives, so it’s like creating graphs but it wasn’t using this normal graph library, it was just using, I think there’s a couple of jQuery plugins he used to build up his own, basically like graphing HTML text but there weren’t HTML tags which is directives. So it was really cool.
MISKO: So, the way to think about it is that, with the use of directive, it essentially allow you to turn HTML to a domain specific language for creating the app for you.
JOE: Yeah it’s a really powerful concept.
JAMISON: It’s deep. I got to let that marinade in my brain.
TIM: So, where is your data stored? Is it in these directives themselves or separate? Or does it matter?
IGOR: So scope is just the object. It’s you can think of it like the exports in NodeJS. it’s just the object that you sign stuff to and that’s available in the template. That they’ll tell you expose the model to the templating engine, then we start observation and update the view whenever necessary.
TIM: When I was building my application in Angular and we started researching it, to me, I sort of thinking of it as my view model that was scope.
IGOR: Yeah. Actually, that is very true. There is a lot of controversy about model view controller and model view, view model and all these terms and styles of structuring the code. But I think describing scope as ViewModel is very correct.
TIM: Another thing that I think initially confused me just a little bit is the controller didn’t end up being an actual object that got useful. All it did was create the scope right? And then it was really no longer anything anymore. It was the scope that was doing everything.
MISKO: For small apps, that seems to be the case. For large apps, controller would have the behavior specific to that page. Behavior that will be shared across different views in ways inside the service and that injected it to the controller. But for the most part, controller is the thing that sets things up.
JAMISON: Oh, go ahead.
TIM: I have another question. I don’t know if yours is related to this, but I was kind of curious, when we did our application, we were using HTML5 video component, right? And of course, you don’t have any built in directives for the HTML5 to get the component. So the events that it raised there is no ng- you know, on play or on stop on those video events. So we ended up wrapping ours in…I think we tried using a directive for a while and I definitely found that directives were the hardest piece of Angular to grock, so we ended up graphing it in a service. And then there was a service that handle everything that HTML5 video player did and then we just dealt with the scope that way. Does that make sense? Do you think that was a poor implementation? Would it have been a lot better for us to implement it using directive?
MISKO: So, we know it’s a common criticism that directives are complicated thing. I fully hear everybody who says that. I know that it’s complicated. I spent a lot of time trying to make it simple. I have, to some degree, failed and to some degree, succeeded but we hear you. We still feel that directives are the thing that responsible for — the DOM. So, in your particular case, it is possible to use services, as a way of communication or channel with the DOM, but it’s not really the zen of Angular, right? The zen of Angular is that, all of the DOM should be hidden behind indirectly. And so, the way you influence the DOM is that you change the model. And then the model becomes projection to the view to the DOM. If you put things inside of the service that no longer holds true, now, you went from a declarative world of DOM into the imperative world like jQuery. And so, these declarative benefits are starting to be lost. Now, sometimes it’s useful to make these shortcuts but sometimes if you have a large applications, it’s useful to invest into doing it through the directives.
TIM: it definitely felt it does when we did it.
JAMISON: So, we kind of touched on this when we were using models but what kind of support does Angular have for syncing stuff with the server? Does it just that point on that question, leave it up to you or does it have stuff work?
MISKO: We are trying to be server side agnostic. And so, it’s hard to have an opinion and not stay server-side agnostic.
IGOR: So we provide services that allow to communicate over the server through HTTP request. So we have this to make either low level — request or cross domain or — require. And we also have a higher level service for building basically restful client. So, if you want to use REST on your server, we have a way of just generating a very generic restful client. We often find that, there are so many dialects of REST out there that it’s hard to build a single REST client generator. So, there either always has to be always customize these clients that is generated, (which is the route we took) or they have to be adapters for a particular servers. So if you are using Rails, you should be able to say, “Okay generate me a Rails client.“ And I think this is a better a approach and that is something that for the future, where we will just build a bunch of generators that will give you rails specific client or app engine specific client or whatever you have. Because we find that is the easier way to deal with all these dialects on some server.
JAMISON: You mentioned services a couple of times in the past two minutes. I don’t think we ever really defined what those are. So is there a good definition for services in Angular?
MISKO: it’s a instance of that class that is not a control.
IGOR: It’s an injectable component. So, the component that is instantiated by the dependency injection system and it is provided to any other component that will ask for it. So, let’s say, like I mentioned that the audio player or the music player application, in that case, I needed a way of playing music and it should already has the audio tag, but if you just set the source and if you instruct it to play, it would just start playing music through the speakers. So what I did, I just created a server, I called it like regular audio player. And within the service, I just create the hashed audio tag and exposed APIs that would allow me to play certain music for certain Rails. And then in my controller, I could just say, if I want to play music, this controller needs an audio player. The dependency injection will instantiate this component. And the controller can then, whenever you hit on the play button or the next button, it will just delegate this piece of work to this component.
And breaking down the application in to this components is a big part of Angular, because we try to give you structure for you application. And the dependency injection and services play a big part on this. We feel that by creating many small components, that the big application will help you in maintaining the application. Because if you have smaller pieces that are focused on the particular task, then it’s easier to understand what they do, It’s easier to document them. It’s easier to maintain them. And most importantly, it’s easy to test them as well. So in your test, you can say, “I want to test this particular service.” And it’s very easy to do it because you don’t have all the dependencies. The service does just one thing, so you can say, “Let’s test it this place and use it”. And you write test for those specific task.
In jQuery, you often end up writing code that does play the music, fetching some data from the server and updating the UI at the same time. And in order to test this kind of code, you have to either write an interim test, which means you need to bootstrap your entire application and write this various low test that will verify the right thing actually happens and the step is not only slow but often flaky. And, the other kind of tests that is good for application is the unit test. Unit test target the specific components. It’s very fast and allows you to diagnose problems much faster. Because if you get error from a unit test, you know that, “Oh, this component and this particular task that this component should supposed to be doing it is not working properly.” Whereas in the interim test, when something goes wrong, there are many components that you need to deal with, you need to diagnose to figure out what is it that went wrong.
TIM: I really feel that with Angular, the testability and really just those idea of services are the two things that make is significantly… well, my favorite framework to use. Because it encourage you to… those services gives you a place to stick codes that isn’t a controller and nobody else has it. I can’t count the number of…
JAMISON: What are you talking about? Those are called views in Backbone.
TIM: I cannot count the number of views I’ve seen in Backbone that are 600 lines long because people just getting a place to put it. DHH said one of the most amazing ideas that I came up with rails, was an empty directory that gave people place to put files. Give them a place and that is what services are, they are that empty directory that place put your code in here. Go create some services; we have given you this thing to put your code in so you can put a lot of small pieces rather than you know, a 600-line long view.
IGOR: Right so, I’m very happy to hear that you like the testability of Angular because that’s one of our key goals; we really want to build large applications that are maintainable. And in order to do that, we feel that testing is must be something that is baked into a solution. It cannot be an add-on. It cannot be something that is just added later. It must be baked into the framework and the workflow must work in a way where testing is–. We do this not only for the dependency injection and the guidelines we give you to structure your application, but also by tools for writing and running test.
So we integrate really relevant JSMN or Mocha. And we also have a test runner which is actually not Angular specific, it’s called “Testacular”. And what it do is it run unit test in real browsers. So, if you want to just test your application, it would just start Chrome with an empty profile and it will test in Chrome and it will report back to you. And even better is that it will watch file system to understand the structure of the application. And whenever you change source or test source code, then it will rerun the test and it will report, “Oh you broke something just now.” or “Everything is still working.”
So, what we get off is a workflow where we run all of our unit test on every policy. So with Angular.js itself, we have 16,000 unit tests which test all the DOM manipulation, all the service interactions and all the craziness that is happening behind the scenes. And we can run all these tests within a few seconds. So I think in Chrome and Safari it’s about 4 seconds. So with this you can get really rapid response. And it will really help in your application and you just change the way you think about writing the code.
JAMISON: Alright. So, are there any final questions? if not, well get into the picks.
JOE: I don’t wanna give a question, I just wanna make a comment on everything you have just said about testability and just say that it… I just love that. If you are here in — I would kiss you full in the mouth.
MISKO: Not just testing yourself but also enabling others that use you have a testing.
TIM: So I see two main benefits in Angular, one of course is the dependency injection which we have been talking about and the other is directives which is a way to do declarative programing. And I think they are independent ideas that other frameworks can pick one or the other depending on what they like. I prefer procedural direct code on small apps, but I can still use dependency injection and have services.
TIM: One of the sayings we have in the node community is… it’s a question is “How do you build a large program?” How do you make it maintainable? And the answer is, well you don’t. You just make a bunch of small modular components and integrate them well . And dependency injection makes it possible.
MISKO: So I will still say that these are very unique features that nobody else have. As far as I know, we are the only framework that provides dependency injection. We are the only framework that extends the HTML vocabulary.
IGOR: also we do the data binding is very, very unique and I don’t think anybody as close to bringing as smooth data binding as Angular is.
JAMISON: So, I really like what you said two way data binding. I think you can probably say that any large enough Backbone application will have its own bad implementation data binding. So, it’s really cool to see it built in to the app. Are there any last things before we get to picks? Anything you wish you had said already that you didn’t get a chance to?
A: Hi. I’m AJ and I’m coming at you live from the place in –, where I am.
JAMISON: OK. Just in time, AJ.
JOE: Good timing.
IGOR: I wanna say thank you for inviting us and giving us the opportunity to talk about Angular.js here. I Enjoy your podcast and It’s great to be here.
JAMISON: I’m really glad you guys came on. Angular is like this mysterious, beautiful beast that I just kind of poke at every once in a while, and I would like to get more in to. So I think this might push me over the hill to actually build stuff with it.
IGOR: So our real goal is to make the browser smarter and to prototype ways how this can be done. And help developer community today to build applications in a simple and beautiful way. But also, influence the standards that coming and make sure that there better primitives in the browser and the web platform that will allow us to do even more. And bring even smoother the work flow through the developers.
MISKO: I just wanted to end the suffering of all the endless developers who was to write imperative code are stuck in endless loops — and doing call back.
JOE: And those developers who’s stuck without tests as well.
JAMISON: Alright. We really do have to get to the picks. There is so much interesting stuff to say, I’m sorry that I have to cut it off but we don’t wanna keep you both for too long. So, let’s start it off.
JOE: I do have one last question. Are you hiring?
JAMISON: Great. Let’s get to the picks now. So, Joe do you wanna go first?
JOE: Oh, yeah. So, my first pick is going to be Angular I don’t know if you have heard of it.
JAMISON: That’s cheating.
JOE: (laughs) No. My only pick this week is the show that is The Arrow that was on the CW.
JAMISON: What is it?
JOE: The Arrow. It’s the Green Arrow TV show.
JOE: It’s called The Arrow.
JAMISON: Right on. Is that it?
JOE: That’s it.
JAMISON: AJ, do you have any picks?
AJ: Come back to me.
JAMISON: Ok. Tim?
TIM: Yes. I would like to pick Font Awesome, which is a web font icon library. I’ve been using it and there’s some really cool stuff in it. I think its feature parody with the icons Twitter bootstrap but it’s all through fonts. So, you can do cool stuff like CSS inner shadows or whatever you want. I’ve been using it for some little apps that I’m building.
MISKO: We use Font Awesome on Angular website as well. Good choice.
JAMISON: That’s cool. Is that it, Tim?
TIM: That’s it.
JAMISON: Sweet. Misko, do you wanna go first?
IGOR: Ok I’ll go first. So I have two picks. “Testacular”, I would really like for people to check it out. It’s awesome. If you do unit testing or you can do testing but that is not the primary purpose, it’s really the unit testing. When you want to run your unit tests really, really quickly in real browsers then check out Testacular.
JOE: Can we get some numbers? Like how much faster?
IGOR: 16,000 unit test and 2 to 4 seconds.
IGOR: If you are using JSMN, you can still use JSMN. Testacular will just run the JSMN test for you. If you are using mocha, you can use mocha and Testacular will just run the test for you in a real browser. Its super-fast and people just love it. Everybody who has it… I haven’t seen a one bad about it.
And the second pick is “Plunker”. Plunker is just like jsFiddle or the general idea of jsFiddle. The editor is something that is awesome because they use Ace editor, so it’s the editor that you would see in Cloud 9. I always find myself really frustrated with jsFiddle editor; that is not the case with plunker. Plunker allows you to break your small applications that you are writing into multiple files. Definitely check it out. It’s really worth it. You won’t be disappointed.
JAMISON: Great. That sounds really cool. Igor, do you wanna go?
MISKO: That was Igor.
JAMISON: Oh, that was Igor. Okay, Misko.
MISKO: I’ve been reading this awesome book called Better Angels of Our Nature actually looks at history of people and how they got friendly and less violent over millennia. It really opens up — so I thought I have to share that with you guys.
JAMISON: I’ve actually heard of that book. This is the second time someone recommended it to me. I have to check it out. I’ll go next. So, oh, were you done? Sorry.
JAMISON: Alright. This game called XCOM came out this week. It’s a remake of a classic like strategy-tactical turn-based combat game from 1993, which is one of the best games ever made. So I have really high hopes for this game. I was also kind of scared of it because it could just ruin my baby. And they did a great job. It’s easy enough to pick up. If you haven’t played the old game yet but it’s still really true to its spirit I guess. So, it is a sci-fi game where you control this organization that is kind of defending the world from alien invasions. You have this base building part and like global strategic management part, but then you actually go on missions and have these tactical turn based squad combat or battle. So it’s a great game.
And then my other pick is just The Foundation Series by Isaac Asimov. I read it a long time ago and remember liking them and I’m just reading it again. I’m almost done with the last book and it’s so good. They are great. It’s just classic, wonderful sci fi. So if you haven’t read those books yet, definitely check them out. AJ what’s your pick or picks?
AJ: So, I’ve been listening to this book “Influencer”. It’s “Influencer: The Power to Change Anything”. And it’s interesting. It comes from the perspective of… it’s kind of like other couple of other books in maybe thinking slower, something in that genre. It focuses on the finding out where the outliers are of the results that you want. So, say want to lose weight, look at people who look fat and find the ones that are losing weight and then figure out what to do. Or if you run a company and you want people to be more safe, look at the department where people are having fewer injuries and try to figure out what they are doing different. So it’s the reverse approach of… like intuitively, a lot of times, we think of solutions and then we try to implement them and experiment with them. But in a lot of cases, the solutions in the problems are already exists. Somebody’s already using that solution. So you won’t have to think about the solution or invent it, you just have to kind of see… you have to find the who’s already got it and then why it’s working for them. So, it’s been interesting to listen to maybe think about things from business to relationships to better —. It influenced my life with the results that I want.
JAMISON: Cool. That sounds very interesting. Misko and Igor, thank you so much for coming on the podcast.
MISKO: Thank you for having us.
JAMISON: And hopefully you guys who are listening liked it too. See you guys next week!